Akira Affiliate Crashes Ransomware After Attempting EDR Evasion

A ransomware affiliate's attempt to disable security tools by rebooting a victim's system into Safe Mode backfired, with the tactic apparently preventing the malware from successfully encrypting the target's file, according to recent research by Huntress.

The managed security specialist revealed in a blog post on August 12 that the Akira affiliate struck its victim in early August.

A credential spraying attack enabled initial access to a SonicWall SSL VPN with no multifactor authentication (MFA) deployed.

The attacker then accessed the domain controller via Remote Desktop Protocol (RDP) and began Active Directory (AD) enumeration, following a similar playbook to many Akira attacks, Huntress explained.

The threat actor then moved to the application server and began collecting files, which it transferred to cloud storage using s5cmd, a fast S3 transfer utility.

“This is classic double extortion activity: steal all the victims' files before encrypting them, so if the victim doesn't pay the ransom, they can threaten to post them on some sketchy underground forum or a darknet leak site,” said Huntress.

However, the attack then departed from the Akira norm. Before deploying the ransomware payload, the threat actor ran msconfig.exe and forced a reboot into “Safe Mode with Networking.”

“In Safe Mode, third-party services, including the Huntress agent, don't start,” noted Huntress. “Defender real-time protection was down too. For the entire Safe Mode window, the host had no working EDR, and AV was blinded.”

This is a common approach for ransomware actors; in fact, it is listed by MITRE ATT&CK (T1688) as “Impair Defences: Safe Mode Boot.” Although not spotted in relation to Akira previously, the technique has been associated with groups like Snatch and AvosLocker “for years,” Huntress claimed.

Unfortunately for the attackers, this move also interfered with ransomware detonation by triggering host memory errors.

“Safe Mode boots with a stripped-down environment and constrained virtual memory, and the Akira process tree appears to have starved it, getting the "Out of Virtual Memory" pop-up and the cascade of PowerShell hard errors line up exactly with the moment the payload tried to kick things off,” Huntress said.

“The takeaway is a little uncomfortable. While Safe Mode blinded our controls, it may also have prevented the encryption it was meant to enable. That's a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around.”

Huntress was at pains to point out that future Akira victims may not be so lucky.

“Ultimately, this could be a case of winning the battle, but not the war. It's possible that a host with more physical memory or a larger page file might give akira.exe enough virtual memory to encrypt the endpoint in Safe Mode,” it explained.

“Akria's developers or affiliates could retool the encryptor to reduce its memory demands or make its Safe Mode launch sequence more reliable, meaning that the same failure may not occur in a future intrusion.”

With this in mind, organizations should follow the report’s guidance to stay safe from attacks like this: