Ransomware · Endpoint Security

Akira Hackers Disable EDR with Safe Mode, Steal Data, but Fail to Encrypt

August 14, 2026 · 6 min read

An Akira ransomware affiliate broke into a victim network on August 4, 2026, moved from a VPN appliance to a domain controller, exfiltrated file share archives to an attacker-controlled S3 bucket, and then rebooted a Windows host into Safe Mode to kill the EDR agent before dropping an encryptor. The encryption failed due to a memory crash in Safe Mode, which is worth understanding because that failure was accidental. The data theft had already completed by then, leaving the attacker with full extortion leverage regardless of whether any files got encrypted.

What actually happened

The attacker gained initial access at 03:52 UTC through a SonicWall SSL VPN device that had no multi-factor authentication configured. A credential-spraying attack was enough to get in. Roughly two hours later, the attacker connected to the domain controller over RDP, ran PowerShell commands to dump Active Directory user and computer records into files named AdUsers.txt and AdComp.txt under ProgramData, and then pivoted to an application server. The whole reconnaissance phase was quiet and methodical.

Data exfiltration used WinRAR to archive mapped file shares and the s5cmd command-line tool to push the archives to an attacker-controlled S3 bucket. After that, AnyDesk was installed as a Windows service configured to start automatically, giving the attacker a persistent remote access channel that also served as a delivery vehicle for subsequent payloads. Huntress analyst James Northey noted that the attacker pasted four blocks of text through the AnyDesk clipboard channel, roughly 4 KB, 296 bytes, 2 KB, and 632 KB in size, indicating hands-on-keyboard operation rather than an automated script running unattended.

At 06:29 UTC the attacker used AnyDesk to force the host into Safe Mode with Networking. That move disabled both the Huntress MDR agent and Microsoft Defender's real-time protection, leaving the host without working EDR for approximately 10 minutes. The attacker also added AnyDesk to the Windows Safe Mode registry startup list so remote access would persist after the reboot. At 06:34 UTC, akira.exe started. Within about 13 seconds, Windows began logging "Virtual Memory Minimum Too Low" and "Out of Virtual Memory" errors, and PowerShell reported it could not create a new stack guard page. Akira's encryptor relies on concurrent worker threads and heavy memory mapping, and Safe Mode's constrained virtual memory environment was insufficient to run it. The encryption never completed.

A scheduled Defender scan detected the binary as Ransom:Win32/Akira.B!ibt but could not quarantine it while Safe Mode remained active. At 08:10 UTC the attacker rebooted the host back into normal Windows, at which point Defender's real-time protection restored and quarantined the file. The total intrusion window ran approximately 4 hours and 18 minutes from first VPN access to final reboot. According to Huntress, this is the first time they have observed an Akira affiliate using Safe Mode for EDR evasion, though the technique itself is tracked under MITRE ATT&CK as T1562.009 and has been used by other ransomware families including Snatch and AvosLocker for years.

Why this should matter to you even if you don’t run Akira ransomware

The framing of this incident as a near-miss misses the point. The attacker's primary goal was data theft for extortion, and that goal succeeded completely. Files were archived and exfiltrated before the Safe Mode reboot even happened. The encryption failure is a footnote. Akira has collected more than $244 million in ransoms since March 2023 according to the CISA and FBI joint advisory AA24-109A, and modern double-extortion operations do not require file encryption to extract payment. The stolen data is the threat, and it left the building hours before akira.exe ever ran.

The Safe Mode technique itself deserves attention because it is reliable in principle. Huntress researchers noted explicitly that the encryption failure was an accident of the victim's low memory configuration. A host with more physical RAM or a larger page file could have provided enough virtual memory for the encryptor to finish. Akira's tooling could also be retooled to handle Safe Mode's constraints, so the bug that saved this victim is a one-time occurrence. Earlier in 2026 a separate Akira affiliate was observed creating a new virtual machine on a victim's hypervisor specifically to run the encryptor outside EDR coverage. The group is actively iterating on ways to operate outside endpoint defenses.

If your environment has VPN appliances exposed to the internet without MFA, credential spraying is a realistic and low-effort entry path. The attacker here went from VPN authentication to domain controller access in roughly two hours. That is enough time for data staging and exfiltration to complete before most security teams even begin an investigation, particularly if the initial alert is a failed login that blends into background noise. The organizations most at risk are those that have deployed EDR and consider that sufficient, without also controlling what happens to endpoint defenses when a machine reboots into Safe Mode.

The control that would have blunted it

The specific control that would have blunted this attack is MFA on the VPN, which is also the control most cyber insurers now treat as a baseline requirement for coverage. Credential spraying works because password reuse and weak passwords are common. Adding a second factor does not make credential spraying impossible, but it does eliminate the entire class of attack where a valid username and password are enough to authenticate. The attacker here had no vulnerability to exploit and no zero-day to deploy. They sprayed credentials against an unauthenticated endpoint and logged in. MFA on remote access is specifically called out in CISA advisory AA24-109A as a primary mitigation for Akira intrusions.

Beyond MFA, the Safe Mode technique points to a second control gap: EDR agents and security services that load only in normal Windows mode are inherently bypassable by anyone with local administrator or SYSTEM privileges. Group Policy can restrict who is permitted to modify Safe Mode registry keys, and some EDR platforms now support kernel-level drivers or boot-time protections that survive Safe Mode. Checking whether your endpoint agent actually runs in Safe Mode is worth doing, because most default installations do not. If the agent goes dark on Safe Mode reboot, you have a predictable blind spot that is documented in ATT&CK and actively exploited.

The registry entry that gave AnyDesk persistence across the Safe Mode reboot (added to the Safe Mode startup list) is something application allowlisting and registry change monitoring would have flagged. Neither control is trivial to maintain. Application allowlisting in particular carries real operational overhead, especially in environments with frequent software updates or diverse endpoint configurations. That overhead is real and should be weighed honestly. However, the alternative is accepting that any attacker who reaches a local admin session can add arbitrary programs to boot sequences that your EDR will never see. For endpoints that touch domain controllers or handle sensitive file shares, that tradeoff tends to favor the monitoring cost.

Finally, the exfiltration path used s5cmd pushing to an attacker-controlled S3 bucket. Egress filtering that restricts outbound traffic to known business destinations, or that alerts on unexpected cloud storage uploads from server-class machines, would have created a detection opportunity before the Safe Mode reboot ever happened. Most organizations have invested heavily in inbound threat detection and much less in outbound data movement monitoring. Catching the exfiltration in progress would have changed the outcome here far more than stopping the encryption attempt would have.

If you want a structured way to audit whether your endpoint controls would hold up against techniques like Safe Mode abuse and persistence via registry modification, the Strondex Endpoint Protection Checklist walks through the specific policy and agent configuration checks that map to these attack patterns.