Akira ransomware just killed EDR with a Safe Mode reboot

Akira ransomware just killed EDR with a Safe Mode reboot

An Akira ransomware affiliate forced a compromised Windows server into Safe Mode with Networking this month. The goal was simple: kill the endpoint agents. Huntress watched it happen — their own agent went dark, Microsoft Defender’s real-time protection vanished, and the attacker had a clean window to operate.

The technique worked. The ransomware binary launched. Then it crashed. Safe Mode’s constrained memory environment couldn’t handle Akira’s resource demands. Virtual memory errors piled up. PowerShell failed. The encryptor couldn’t finish the job.

The failure doesn’t make this a win for defenders. It’s a warning.

How the attack unfolded

It started August 4 with a credential-spraying campaign against an exposed SonicWall SSL VPN. Seven minutes in, the attacker hit a valid account — no MFA. Two hours later they were on the domain controller via RDP, enumerating Active Directory. From there they moved to an application server, archived mapped file shares with WinRAR, and exfiltrated data to an attacker-controlled S3 bucket using s5cmd.

Then came AnyDesk for persistent access and the Akira payload. Instead of trying to disable EDR directly — which triggers alerts — the operator ran msconfig.exe to force a reboot into Safe Mode with Networking.

That single command took both Huntress and Defender offline. No driver loading, no service monitoring, no behavioral analysis. Just a bare Windows kernel and the attacker’s tools.

Safe Mode is becoming a ransomware staple

This isn’t new. Snatch and AvosLocker have used Safe Mode boot for years. MITRE ATT&CK tracks it as T1688. But Akira adopting it tells you something — affiliates are actively hunting for environments where endpoint agents don’t run.

The Akira affiliate Huntress caught earlier this year took a different approach. They spun up a new virtual machine on the victim’s hypervisor to run the encryptor where no agent was installed. Same goal, different path. The endpoint is becoming a liability for ransomware operators, so they’re learning to work around it.

Why the crash doesn’t solve the problem

Akira failed in Safe Mode because its encryptor needs more memory than the minimal environment provides. That’s an implementation detail. More memory, a larger page file, or a rewritten encryptor fixes it. The technique itself — booting into a defenseless state — works perfectly.

Defender eventually caught the binary, but only after the attacker rebooted back into normal mode and real-time protection returned. The quarantine happened post-facto. The data was already stolen. The access was already established.

What actually stops this

Huntress recommends MFA on every VPN account, correlating failed login bursts with subsequent successes, and deploying EDR everywhere. Good hygiene. But it misses the structural issue: endpoint agents can be killed by a reboot.

Network-layer security can’t.

eHawu sits at the network layer, outside the operating system. A Safe Mode boot doesn’t touch it. A hypervisor-level VM doesn’t bypass it. A disabled system service doesn’t stop it. When the attacker moves laterally, exfiltrates to S3, or establishes AnyDesk persistence, the network sees it — regardless of what state the endpoint is in.

That’s the architecture African enterprises need. Not better endpoint agents that can be rebooted away. Security that doesn’t live on the endpoint at all.

Tags: #Ransomware #EDR #EndpointSecurity #NetworkSecurity #Akira #DoubleExtortion #SafeMode #AfricanCybersecurity

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *