Akira Reboots Into Safe Mode to Blind EDR, and Starves Its Own Encryptor

An Akira ransomware affiliate broke into a company through an exposed SonicWall VPN with no MFA on August 4, stole credentials and file share data, then rebooted the compromised host into Safe Mode with Networking to kill its security tools before launching the encryptor ^[1]. The move worked on the EDR and failed on the ransomware: in Safe Mode's stripped-down memory environment, according to a Huntress report, the Akira process tree hit an out-of-virtual-memory failure seconds after launch ^[2][3].

Everything before the reboot was routine Akira. A VPN credential spray resolved into a successful login at 03:52 UTC ^[4], followed by roughly two hours of quiet before the operator used RDP to reach the domain controller ^[5]. From there the affiliate dumped all Active Directory users and computers with a PowerShell enumeration configured to disable truncation, capturing every group membership ^[6], archived mapped file shares with WinRAR using the same flags documented in earlier Akira campaigns ^[7], and uploaded the data to an attacker-controlled S3 bucket with s5cmd ^[8]. Exfiltration finished before any encryption was attempted, which is why a failed encryptor does not mean a failed extortion ^[9].

The interesting part is the boot configuration change. Before restarting, the attacker added AnyDesk to the Safe Mode service registry so remote access would survive the reboot even though the defensive stack would not ^[10]. For ten minutes the host had no working EDR and Microsoft Defender's real-time protection was down ^[11]. Then akira.exe executed at 06:34:29 UTC, spawned its child-process burst at 06:36:21 UTC, and about 13 seconds after that the host began throwing memory errors, with an "Out of Virtual Memory" dialog and a cascade of PowerShell hard errors ^[12]. That is roughly two hours and 42 minutes from first login to encryptor launch ^[13]. Defender's scheduled scan later identified the binary as Ransom:Win32/Akira.B!ibt but could not quarantine it with real-time protection disabled ^[14]; the file was only removed once the attacker rebooted back to normal mode and restored Defender's protections ^[15].

Safe Mode abuse is not new. Huntress notes Snatch and AvosLocker have used it for years, but says this is the first time it has seen Akira do so in its telemetry ^[16][2]. The company's detection guidance is aimed at the boot layer rather than the payload: alert on msconfig.exe or bcdedit activity, on Kernel-Boot Event ID 27 with a SAFEBOOT load option, on Kernel-General Event ID 12 with BootMode=2, and on third-party services stopping ^[17]. It also flags remote-access tools appearing in the Safe Mode service registry as the tell that the operator intends to keep access through the restart ^[18].

Huntress is blunt about why the outcome was fortunate rather than defensive: Safe Mode blinded the controls and also prevented the encryption it was meant to enable, which the report calls a lucky side effect of the attacker's own mistake and not a defence you can plan around ^[19].

What to watch: memory headroom and payload tuning. Huntress warns that a host with more physical memory or a larger page file might have given akira.exe enough virtual memory to encrypt in Safe Mode ^[20], and that Akira's developers or affiliates could reduce the encryptor's memory demands or make the Safe Mode launch sequence more reliable, so the same failure should not be expected next time ^[21]. The practical read for defenders is that MFA on the VPN edge would have ended this at 03:52, and that a boot-configuration alert is now a ransomware alert.