Akira Safe Mode Evasion: How Ransomware Blinded EDR in 2026

Here's the thing about ransomware attacks: you rarely get a lucky break. But in early August 2026, an Akira affiliate gave one organization a momentary reprieve. This incident, a clear example of Akira Safe Mode evasion, saw attackers successfully bypass EDR by rebooting into Safe Mode, stole a significant amount of data, but then their ransomware payload choked on a virtual memory error and failed to encrypt.

Don't get me wrong, the data exfiltration still happened, and that's a confidentiality breach. But the encryption failure meant the organization didn't face the immediate operational paralysis that usually comes with ransomware. The mainstream narrative might focus on this "failure to encrypt," but that misses the point. This wasn't a planned defense; it was an attacker's mistake. And we can't rely on mistakes for our security, especially when facing sophisticated tactics like Akira Safe Mode evasion.

Akira Safe Mode Evasion: Why a Hacker's Memory Blunder Doesn't Make You Safe

The attack chain, as observed by Huntress, started with a classic weak point: an exposed SonicWall SSL VPN lacking Multi-Factor Authentication (MFA). This isn't new, and it's still a top initial access vector. Around 03:45 UTC on August 4, 2026, the attacker started credential spraying, and by 03:52:42 UTC, they were in. No MFA meant a single correct credential was all it took.

From there, it was a textbook post-exploitation playbook:

• Lateral Movement: Within two hours, they were on a domain controller via RDP.
• Reconnaissance: PowerShell commands dumped Active Directory users and computers, creating AdUsers.txt and AdComp.txt in C:\ProgramData. This gives them a full map of the environment.
• Collection: They installed WinRAR to archive mapped file shares.
• Exfiltration: The s5cmd command-line tool was used to upload the staged data to an attacker-controlled S3 bucket. This is the part that did work, and it's the part that matters most for double extortion.
• Persistence & C2: AnyDesk was installed as a service, ensuring remote access.

Then came the EDR evasion. At 06:29:21 UTC, the operator ran msconfig.exe to force a reboot into "Safe Mode with Networking." This is a known technique, previously seen with Snatch, Embargo, and AvosLocker ransomware. This specific instance of Akira Safe Mode evasion highlights a critical vulnerability. The trick is simple: Safe Mode loads only essential services and drivers. Most third-party security agents, including EDR and Windows Defender Real-Time Protection (RTP), don't start. To keep their C2 alive, the attacker added a registry entry to make sure AnyDesk did launch in Safe Mode.

Once the system rebooted, the EDR agent (Huntress, in this case) and Windows Defender RTP were effectively blind. Logs showed Kernel-Boot EID 27 with SAFEBOOT:NETWORK and Windows Defender EID 3002, stating "This service cannot be started in Safe Mode." For about 10 minutes, the attacker had a clear run.

The Virtual Memory Hiccup

With defenses down, the attacker pushed akira.exe via AnyDesk and executed it at 06:34:29 UTC. The ransomware started spawning child processes, ready to encrypt. But then, the system started throwing errors: "Windows — Virtual Memory Minimum Too Low," "Windows — Out of Virtual Memory," and powershell.exe errors about guard pages.

Here's what actually happened: Safe Mode, by design, runs with a minimal resource footprint. This particular host likely had limited physical memory or a small page file, and the akira.exe payload, when executed in this constrained environment, simply ran out of virtual memory. It couldn't allocate the resources it needed to encrypt files.

This was a stroke of luck for the victim. The ransomware failed to encrypt. However, a scheduled Windows Defender scan did detect Ransom:Win32/Akira.B!ibt at 07:43:50 UTC, even though RTP was offline. Defender couldn't remove it until the attacker, at 08:10:38 UTC, rebooted the system back into normal mode. Only then, with RTP restored, could Defender quarantine the file.

The Real Impact: Don't Bet on Attacker Mistakes

The practical impact is clear: the attacker successfully stole credentials and files for data extortion. The encryption failure was a bonus for the victim, not proof of their defenses. This incident shows that even when one part of an attack fails, the core objective—data theft—can still succeed.

This Akira Safe Mode evasion technique is a serious concern. It's a known method, and Akira's adoption of it means we'll see more of it. The fact that this specific akira.exe payload failed due to virtual memory constraints doesn't mean future versions will. Attackers learn. They'll retool their payloads to be more resilient in low-resource environments or target systems with more generous page file configurations.

What We Need to Change

We can't rely on attackers making mistakes. We need to build defenses that anticipate these tactics, especially against advanced threats like Akira Safe Mode evasion.

1. Harden Initial Access: This is non-negotiable.
   • MFA on everything: Especially VPNs. If that SonicWall VPN had MFA, this whole incident likely wouldn't have happened.
   • Credential Spraying Detection: Alert on bursts of failed login attempts against VPNs and other external services.
   • Rotate Credentials: If a VPN account is compromised, rotate those credentials immediately.
2. Monitor for Safe Mode Boots: This is a critical blind spot for many EDRs. Specifically, monitoring for Akira Safe Mode evasion tactics can provide early warnings.
   • Alert on Boot Configuration Changes: Look for msconfig.exe or bcdedit activity that modifies boot options.
   • Monitor for Safe Mode Boot Events: Specifically, Kernel-Boot EID 27 with a SAFEBOOT load option, or Kernel-General EID 12 with BootMode=2.
   • Service State Changes: Alert on System EID 7036, which indicates third-party security services stopping. This can be a strong indicator of a Safe Mode reboot.
   • Registry Monitoring: Watch for remote access tools (like AnyDesk) being added to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network registry key.
3. EDR Resilience:
   • Safe Mode Awareness: EDR vendors need to find ways to maintain visibility or at least log activity during Safe Mode boots, even if full protection isn't active. This is crucial to counter Akira Safe Mode evasion and similar tactics.
   • Scheduled Scans are Not Enough: While Defender caught the file, it couldn't act. Real-time protection is essential.

This Akira incident is a stark reminder that attackers are constantly adapting. They're not just looking for new vulnerabilities; they're finding clever ways to bypass existing defenses. The Akira Safe Mode evasion is effective, and we need to assume it will become more common and more refined. Your EDR is only as good as its visibility, and if an attacker can blind it with a simple reboot, you've got a problem.