2026-08-17 · view entry permalink →
Akira blinds EDR by rebooting a victim host into Safe Mode with Networking — the operator's first observed use of the technique, and the stripped-down boot starved its own encryptor
An Akira affiliate took a compromised Windows host into Safe Mode with Networking to strip its endpoint defences, which Huntress reports is the first time it has observed this operator using the technique — Snatch and AvosLocker have abused Safe Mode for years, but not Akira (Huntress, 2026-08-12). Everything around that step is the operator's familiar chain. From roughly 03:45 UTC on 4 August the SonicWall logged a burst of failed logins against multiple usernames from several external addresses, and about seven minutes later one succeeded against an SSL VPN with no multi-factor authentication in front of it; nearly two hours passed before any hands-on-keyboard activity (Huntress, 2026-08-12). The operator then reached the domain controller over RDP, spawned an elevated command shell, and ran full-property Get-ADUser and Get-ADComputer exports to files under C:\ProgramData — prefixed with $formatenumerationlimit = -1 so PowerShell's default four-item truncation would not clip multi-valued attributes such as group membership. Collection followed on an application server: WinRAR was installed mid-intrusion and used to recursively archive mapped file shares with the same flag string Huntress has documented in earlier SonicWall-entry Akira cases, and the archives went out to cloud object storage.
The evasion itself is three cheap steps. AnyDesk was installed as a service to carry both hands-on control and payload delivery; because third-party services do not start in Safe Mode — including the attacker's own — the operator first wrote that service into the Safe Mode allow-list with a single reg.exe add against HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network, then ran msconfig.exe at 06:29:21 UTC and forced the reboot. The host came back with Kernel-Boot event 27 recording a SAFEBOOT:NETWORK load option and Kernel-General event 12 recording BootMode = 2. Windows Defender logged event 3002 seconds into the boot, and Huntress states plainly that "For the entire Safe Mode window, the host had no working EDR, and AV was blinded" (Huntress, 2026-08-12).
What the operator did not anticipate is that the same stripped-down environment starved the ransomware. The encryptor launched at 06:34:29 UTC, and within about two minutes the host logged System event 26 for virtual-memory exhaustion and a cascade of PowerShell stack failures; it never encrypted. A scheduled Defender scan identified the binary at 07:43:50 UTC but its cleanup routine failed repeatedly because real-time protection was down, and quarantine only succeeded at 08:12:28 UTC — after the attacker rebooted back to normal operation at 08:10:38 UTC and thereby restored the very protection they had removed (Huntress, 2026-08-12). Huntress calls that "a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around", and notes that a host with more memory or a larger page file, or a retooled encryptor with a lighter footprint, could carry the same play to completion (Huntress, 2026-08-12).
Triage: Safe Mode with Networking is a legitimate diagnostic boot mode, so a lone Safe Mode boot is not the signal and IT-driven troubleshooting will generate them. The discriminators are what surrounds it: a SafeBoot Minimal or Network registry write naming a remote-access tool rather than a core Windows driver, a boot-configuration change made from an interactive session that traces back to an external VPN logon minutes earlier, and third-party security services stopping without a corresponding maintenance window. A genuine support-driven Safe Mode boot carries none of those, and the registry write in particular has no benign reason to name a remote-support binary.
Ransomware families like Snatch and AvosLocker have abused Safe Mode for years, but this is the first reported tie to Akira that Huntress has observed.
For the entire Safe Mode window, the host had no working EDR, and AV was blinded.
Alert on boot-configuration changes and Safe Mode boots: msconfig.exe / bcdedit activity, Kernel-Boot EID 27 with a SAFEBOOT load option, Kernel-General EID 12 BootMode=2, and third-party security services stopping (System EID 7036).
That's a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around.