Akira Windows Enterprise Recovery:
The Master DFIR Guide

While Akira’s Linux/ESXi variants frequently make headlines, the vast majority of enterprise intellectual property and identity infrastructure sits squarely within Microsoft Windows Server environments. If you have discovered files appended with .akira, .akiranew, or .powerranges across your network shares, Domain Controllers, or Hyper-V clusters, you are in the final, destructive phase of a highly orchestrated breach.

Responding to a Windows-centric ransomware attack requires surgical Digital Forensics and Incident Response (DFIR) precision. Standard IT practices — indiscriminately rebooting servers, running generic antivirus sweeps, or hastily merging Hyper-V checkpoints — will permanently destroy volatile evidence and can turn a partially recoverable database into a total loss. This guide lays out the procedures a rapid-response team uses to evict the Akira syndicate and recover enterprise data. It is written for planning and triage; the deeper recovery steps (hex-level carving, ESE repair, AD metadata cleanup) should be performed by, or under the direct supervision of, an experienced DFIR practitioner in an isolated environment, not on production.

1. The Windows Server Triage Protocol (Evidence Preservation)

The first 60 minutes after payload detonation dictate the success or failure of the entire recovery operation. Your primary objective is strict containment and the preservation of volatile memory and logs.

Implement the following containment procedures immediately:

• Logical Network Isolation (Not Shutdown): Don’t shut the machine down. Disconnect affected servers at the hypervisor virtual switch level, or physically pull network cables. This halts SMB/CIFS lateral encryption and cuts the attacker’s Command & Control (C2) link without destroying RAM state.
• Acquire Memory Dumps (Order of Volatility): Following RFC 3227’s order-of-volatility guidance, use a forensic acquisition tool (e.g. Magnet RAM Capture, Belkasoft RAM Capturer, or WinPMEM) to capture bit-for-bit images of volatile memory on Domain Controllers and critical database servers before any other disk-level work.
• Preserve Windows Event Logs (EVTX): Make sure no script or well-meaning admin clears logs — threat actors and cleanup crews alike sometimes run wevtutil cl Security. Preserve C:\pagefile.sys, C:\swapfile.sys, and the .evtx files in %SystemRoot%\System32\Winevt\Logs\; these reconstruct the attacker’s lateral movement and credential-dumping activity and are often required for breach notification and cyber-insurance claims.

2. Anatomy of the Akira Windows Attack

Akira’s Windows payloads are built to disable security tooling and drop database file locks quickly. Understanding the typical pre-encryption sequence helps you reconstruct what happened and where to look for persistence.

2.1 EDR Evasion & BYOVD Tactics

Akira affiliates rarely deploy the .akira encryptor immediately after gaining domain access — they typically need to blind the security stack first. Because modern EDR agents (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, etc.) have anti-tamper protections, some Akira intrusions have used a “Bring Your Own Vulnerable Driver” (BYOVD) technique, a pattern documented across multiple ransomware families, not unique to Akira.

The technique works by loading a legitimately signed but vulnerable kernel driver (older Akira campaigns have been reported using drivers such as the Zemana AntiMalware driver, zam64.sys). Because the driver carries a valid signature, Windows Driver Signature Enforcement allows it to load. The attacker then exploits a known CVE in that driver to obtain kernel-level (Ring 0) code execution. A malicious service creation of this kind shows up in System.evtx as Event ID 7045:

Log Name:      System
Source:        Service Control Manager
Event ID:      7045
Task Category: None
Level:         Information
Description:
A service was installed in the system.
Service Name:  ZemanaAntiMalware
Service File Name:  C:\Windows\Temp\zam64.sys
Service Type:  kernel mode driver
Service Start Type:  demand start
Service Account:  LocalSystem

With kernel-level execution, the attacker can use a tool like PowerTool or PCHunter to forcibly terminate EDR sensor processes, bypassing the anti-tamper protections that would otherwise stop a user-mode process from doing so.

2.2 The Pre-Encryption Kill Sequence

With EDR disabled or blinded, the encryptor uses the Windows Restart Manager API (and direct service/process termination) to release file locks on services likely to be holding open handles on high-value data. Security Event Logs (Event ID 4688, Process Creation — if command-line auditing is enabled) often show a sequence resembling:

Process Command Line:  net stop vss /y
Process Command Line:  net stop sqlserveragent /y
Process Command Line:  net stop mssqlserver /y
Process Command Line:  net stop MSExchangeIS /y
Process Command Line:  net stop VeeamBackupSvc /y
Process Command Line:  taskkill /F /IM sqlservr.exe
Process Command Line:  taskkill /F /IM msftesql.exe

Once those locks drop, the encryption routine — reported to use a ChaCha8-based stream cipher with RSA-wrapped keys, applied intermittently rather than to full file contents — begins, typically prioritizing locally mounted drives and mapped network shares.

3. Active Directory Recovery & NTDS.dit Identity Reconstruction

The highest-value target in a Windows-focused Akira breach is usually the Domain Controller. File encryption causes downtime; a stolen Active Directory database compromises the cryptographic trust of the entire organization.

A Cautious AD Restoration Approach

Restoring a Domain Controller after a suspected NTDS.dit compromise calls for an isolated, staged approach:

1. Boot into DSRM (Directory Services Restore Mode): Restore from an immutable, offline backup into an air-gapped or heavily segmented forensic VLAN, and boot into DSRM so AD services don’t start and begin broadcasting on the network.
2. Hunt for Persistence: Before bringing AD online, review Run/RunOnce registry keys, Scheduled Tasks, and WMI event subscriptions (Sysinternals Autoruns is a good starting point) for backdoors. Akira intrusions have been reported using legitimate remote-access tools (e.g. AnyDesk) installed silently, alongside tunneling tools such as Ngrok, as persistence mechanisms.
3. Metadata Cleanup: Use ntdsutil to perform metadata cleanup — removing rogue or orphaned Domain Controller objects, unexpected trust relationships, or unfamiliar nested group memberships created during attacker dwell time.
4. The KRBTGT Double Reset: Once the AD database is verified clean, reset the KRBTGT account password using Microsoft’s documented process, twice, with enough time between resets for replication to complete (not back-to-back). The KDC retains the current and previous password hash, so a single reset alone leaves one valid forged-ticket window open; two properly spaced resets flush both.

4. Hyper-V Recovery: VHDX and Checkpoint Chains

In Hyper-V environments, Akira can encrypt both virtual hard disks (.vhdx) and their differencing disks/checkpoints (.avhdx). A common and costly mistake is attempting to merge corrupted checkpoints through Hyper-V Manager: if the parent-child chain has encrypted or missing metadata, the merge can fail partway through and leave the disk set in a worse state than before.

Assessing header damage

The VHDX format signature is the ASCII string vhdxfile, expected at offset 0x00000000. Comparing a damaged file’s opening bytes against this signature is a useful first diagnostic step to confirm whether the primary header specifically was targeted:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  Decoded Text
00000000  76 68 64 78 66 69 6c 65 00 00 00 00 00 00 00 00  vhdxfile........
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

If this signature is missing or corrupted, a forensic engineer will typically check the secondary header region (VHDX stores a second copy for redundancy), attempt to rebuild the region table and BAT from surviving metadata, and only then attempt a read-only mount — usually via a dedicated VHDX-parsing library or tool rather than manual sector editing, since a single mis-set offset in the BAT can silently corrupt data that was otherwise intact. This work should happen on a copy of the disk, never the original.

5. SQL Server Salvage: Rebuilding .mdf and .ldf Fragments

SQL Server databases sit at the operational core of most Windows environments. When Akira’s encryptor uses intermittent (chunked) encryption on large .mdf (primary data) and .ldf (log) files, meaningful portions of the underlying data can remain unencrypted even though the file as a whole is unusable.

Working around damaged SQL headers

Encryptors that target the start of a file will typically hit the database’s header page (Page 0) and boot page (Page 9) first. Because SQL Server Management Studio needs those pages to attach a database, a damaged header alone is enough to produce severity 823/824 I/O errors and block a normal attach — even if 95%+ of the file’s data pages are untouched.

Recovery in this scenario means locating intact data outside the damaged header region rather than repairing the header in place. SQL Server pages are fixed at 8 KB and begin with a recognizable page header structure (byte 0 identifies page type — 0x01 for a data page, 0x02 for an index page, and so on). Scanning past the encrypted region for the first page that matches this structure marks the start of recoverable data:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  Decoded Text
00200000  01 01 04 00 00 02 00 01 00 00 00 00 00 00 24 00  ..............$.
00200010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Carving and repair

Once surviving page ranges are mapped, the intact data is extracted and reassembled into a new, structurally valid database file with a clean header — a “surrogate” that SQL Server can at least attempt to open, even though its internal catalog and B-tree structures will still be inconsistent. That surrogate is attached in emergency mode, and DBCC CHECKDB (N'YourDB', REPAIR_ALLOW_DATA_LOSS) is run against it.

6. Exchange Server Restoration: .edb Extraction and DAG Rebuilds

Organizations still running on-premises or hybrid Exchange will have their Information Store databases (.edb, using the Extensible Storage Engine / ESE) and associated transaction logs targeted directly.

Resolving dirty shutdown states

Because the MSExchangeIS service is typically stopped or killed before encryption begins, uncommitted transactions sitting in the .log files are never played into the database. The .edb is left in a Dirty Shutdown state and won’t mount until that’s resolved.

The realistic recovery path:

• Assess the damage first: Run eseutil /mh against the database to check its header state before attempting anything destructive. If the header itself is encrypted or unreadable, that needs to be addressed (via a clean header rebuilt from a same-version, same-schema-version database, under expert guidance) before eseutil can even evaluate the file.
• Hard repair with eseutil /p: Run against a copy of the database, in an isolated environment. This forces the ESE engine to walk the B-tree structures, discard pages it can’t reconcile, and bring the database back to a structurally clean state. It does not recover data that was actually encrypted — it discards it so the rest of the database becomes usable again. Expect this to take hours to days on multi-terabyte stores.
• Dial-tone recovery in parallel: While the repair runs, stand up an empty “dial tone” database on a rebuilt, clean Exchange server so the organization can send and receive new mail immediately. Once the original database’s repair and integrity checks (isinteg or an equivalent mailbox-level validation) are complete, merge historical mailbox data back in using a supported swap or merge procedure rather than a raw file copy.

7. The Forensic VSS Carving Protocol (Unallocated Space Recovery)

Before encrypting, Akira typically runs a command to remove local backups and Volume Shadow Copies, most commonly vssadmin.exe Delete Shadows /All /Quiet — a step visible in Security Event Logs as a suspicious child process of the initial payload.

The forensic detail that matters: deleting a shadow copy removes the pointers to its data blocks from the Master File Table — it does not securely wipe the underlying blocks. Those blocks remain in the volume’s unallocated space until the operating system overwrites them with new data. Whether that data is still there by the time a forensic team gets access depends entirely on how much disk write activity has happened since — not on a fixed clock. A quiet file server that’s been isolated for two days can retain more recoverable data than a busy database server left running for two hours.

If a compromised server is isolated quickly — logically or physically disconnected so the OS stops generating new writes, logs, or swap activity — a forensic team can perform a raw scrape of unallocated space using tooling such as Magnet AXIOM or X-Ways Forensics, locate surviving VSS block structures, and reconstruct portions of the pre-encryption filesystem state. This is probabilistic, not guaranteed: the more the disk has been used since deletion, the less remains to recover, and running disk-repair utilities (chkdsk in particular) can overwrite exactly the unallocated blocks you’re trying to preserve.

8. Our Windows Recovery Engagement Model

Understanding these procedures on paper is different from executing them safely under the pressure of a total enterprise outage. As a specialized incident response firm, we don't experiment on production arrays.

Dividing the response between Active Directory specialists and low-level forensic engineers means the network is sanitized of Akira persistence mechanisms before any salvaged data is reintroduced to production — rather than discovering a backdoor after you've already rebuilt on top of it.

9. Zero-Trust Day-2 Hardening (Closing the Backdoors)

Recovering the data is only half the job. If the gaps that allowed the initial breach remain open, Akira — or another affiliate that purchased the same access from an Initial Access Broker — can come back and re-encrypt the environment.

• Deploy Microsoft LAPS: Local Administrator Password Solution (LAPS) randomizes and rotates local admin passwords per machine and stores them securely in AD. It closes off a common lateral-movement path: a shared local admin password across every server, dumped once and reused everywhere.
• Enforce Tiered AD Administration: Under the Microsoft tiering model, Domain Admins (Tier 0) never log into end-user workstations (Tier 2). This prevents high-privilege credentials from being cached in LSASS memory on machines that are far more likely to be compromised first.
• Disable Legacy Protocols: Disable SMBv1 domain-wide via GPO, and enforce SMB signing on SMBv2/v3 to make NTLM relay attacks significantly harder during lateral movement.
• Restrict RDP Exposure: RDP (port 3389) should never be exposed directly to the internet. Restrict internal RDP access to hardened jump servers requiring hardware- or app-based MFA.
• Confirm driver blocklisting is active: Verify Microsoft's vulnerable driver blocklist and HVCI are enabled fleet-wide to reduce exposure to BYOVD techniques like the one described in Section 2.

10. Akira Windows Technical FAQ