Akira's failed encryption run started where it usually does: an MFA-less SonicWall VPN

An Akira affiliate walked a victim network from a credential-sprayed SonicWall SSL VPN to a domain controller and out to an application server in early August, then blinded the endpoint defences and failed to encrypt anything ^[1][2][3][4]. According to Huntress, which published the teardown on August 12, the failure was caused by the attacker's own evasion step, not by any control the defender had in place ^[1][12].

The chain is worth reading in order, because none of it is exotic. Initial access came from a credential spraying attack against a SonicWall SSL VPN with no multifactor authentication deployed ^[3]. From there the actor reached the domain controller over RDP and began Active Directory enumeration, which Huntress describes as consistent with many Akira attacks ^[4]. The actor then moved to an application server, collected files, and pushed them to cloud storage using s5cmd, a fast S3 transfer utility ^[5]. Huntress called this "classic double extortion activity: steal all the victims' files before encrypting them," with the leak site as the fallback if the ransom is refused ^[6]. Nothing in the sequence up to that point needed a software exploit: sprayed credentials on an unprotected VPN, then RDP, then a built-in Windows configuration tool ^[23].

That tool was msconfig.exe, used to force a reboot into Safe Mode with Networking before the payload ran ^[7]. The effect on the defender's stack was total. In Safe Mode, third-party services including the Huntress agent do not start, and Defender real-time protection was also down, leaving the host with no working EDR and blinded AV for the entire Safe Mode window ^[8]. The technique is catalogued by MITRE ATT&CK as T1688, Impair Defenses: Safe Mode Boot ^[9]. Huntress says it had not seen it tied to Akira before, though it has been associated with Snatch and AvosLocker for years ^[10].

The evasion worked and the encryption did not. Safe Mode's stripped-down environment and constrained virtual memory appear to have starved the Akira process tree, producing an "Out of Virtual Memory" pop-up and a cascade of PowerShell hard errors at the moment the payload tried to start ^[11]. Huntress is blunt about what that means: "That's a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around" ^[12].

The durability of that luck is the open question. Huntress notes a host with more physical memory or a larger page file might have given akira.exe enough virtual memory to encrypt in Safe Mode, and that developers or affiliates could retool the encryptor to reduce memory demands or make the Safe Mode launch sequence more reliable ^[13][14].

What to watch, in order of leverage. MFA on every VPN account, with the option to disable or IP-allowlist the SSL VPN during an active attack ^[17]. Alerting on bursts of failed VPN logins from a single source, correlated with a successful login from the same IP or ASN shortly after ^[15][16]. EDR on every host, since staging often happens on unmonitored ones, and a SIEM ingesting VPN and Windows Event Logs for warning before detonation ^[19][20]. For the Safe Mode play specifically, Huntress points to msconfig.exe or bcdedit activity, Kernel-Boot EID 27 with a SAFEBOOT load option, Kernel-General EID 12 with BootMode=2, third-party security services stopping via System EID 7036, and tooling being added to the Safe Mode minimal-service registry list ^[21][22]. If the VPN is already compromised, rotate all AD and VPN credentials ^[18].