Akira Rebooted the Machine Into Safe Mode, Blinded the EDR, and Then Its Own Ransomware Wouldn't Run. The Environment That Defeated the Defender Also Starved the Payload.
- Patrick Duggan
- 5 minutes ago
- 4 min read
Huntress documented an Akira intrusion in which the affiliate did something Akira had not been seen doing before, executed it successfully, and then watched their own ransomware fail to run. It is an instructive failure, and the lesson is not the one the failure suggests.
What happened
The intrusion began around August 4, 2026 with a credential spray against a SonicWall SSL VPN. Ordinary front door, ordinary technique, and the same class of entry point we have written about before on that platform.
Once inside, the affiliate rebooted the host into Safe Mode with Networking.
This is a well-worn move and it works because of a design decision, not a bug. Safe Mode starts Windows with a minimal set of drivers and services — deliberately, because that is the point of it. Third-party endpoint agents are among the things that do not load. The Huntress EDR agent went offline and Microsoft Defender's real-time protection was disabled. No exploit, no driver abuse, no tampering with the security product at all. They asked Windows to start without it, and Windows obliged.
Snatch and AvosLocker have abused this for years. Akira had not, in telemetry, until now.
Then akira.exe launched — and did not encrypt anything.
Why the payload died
Safe Mode restricts virtual memory allocation. The encryptor process was starved of the memory it needed to complete its encryption routines, and the core loops never ran.
The affiliate had built an environment specifically hostile to defensive software, and that same environment turned out to be hostile to their own tooling. They removed the drivers and services that let a modern endpoint work, and their modern payload needed some of what they removed.
There is something genuinely funny about it and it is worth enjoying for about ten seconds, because it changes nothing about the outcome.
The victim still lost
Credentials and file share contents had already left the network before the reboot.
The exfiltration happened first. The encryption was the last step, and it is the step that failed. What the victim faces is a data-extortion demand backed by data the attacker genuinely holds — no decryption key needed, no negotiation about file recovery, just the threat to publish.
This is the part worth internalising for anyone still measuring ransomware readiness in restore times. The backups were never the crown jewels. A defender whose entire plan is "we can restore" has planned for the half of the attack that failed here. Double extortion has been standard for years and the mental model has not caught up: encryption is the noisy, fragile, optional last act. Exfiltration is the business.
The encryptor broke and the attacker still has leverage. That should tell you which half mattered.
The uncomfortable bit about Safe Mode
There is no patch for this. Safe Mode booting without third-party drivers is intended behaviour with decades of legitimate use — it is how you recover a machine that a bad driver has wedged, and removing it would break the repair path that IT depends on.
So this joins the tier we keep writing about: things that work exactly as designed and hand an attacker an advantage anyway. Guest access in Salesforce portals. Windows Plug and Play installing signed vendor drivers for a forged USB descriptor. Now a recovery mode that is, by definition, a mode with the defences off.
Your EDR's failure here is not a product failure. It is the operating system honouring a documented request.
What actually detects this
The evasion is loud in exactly one dimension, and it is not the endpoint — because the endpoint agent is the thing being switched off.
An unexpected reboot into Safe Mode is the signal. On a server, in the middle of an incident, at an hour nobody scheduled, it has close to no legitimate explanation. Watch for the boot configuration being modified (bcdedit-style changes to safeboot), and treat an EDR agent going silent followed by the host coming back up as an alert rather than a gap in the graph.
Agent silence is data. Most consoles present a missing agent as an absence — a grey row, a stale timestamp, something to chase on Monday. In this attack, agent silence was the attack succeeding. If your monitoring cannot distinguish "laptop closed" from "server deliberately rebooted into a mode where I cannot run," it will read the second as the first.
And go looking for the exfiltration first. Whatever else happened, assume data left before the visible part started, because here it did.
Credit
The research and telemetry are Huntress's. We hold no indicators on this incident and are not claiming any — this is their catch, and the detail about the memory starvation is the kind of thing you only get from watching the host rather than reading the sample.
Ninety-five percent, as always. Akira will fix the memory problem — it is a configuration issue, not a hard limit, and the next affiliate to try this will have read the same write-up. The evasion worked. Only the payload was late.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=akira-rebooted-the-machine-into-safe-mode-blinded-the-edr-and-then-its-own-ransomware-wouldn-t-run
Comments