Akira Ransomware Uses Safe Mode to Bypass EDR
An Akira affiliate rebooted a compromised host into Safe Mode to bypass EDR, but constrained memory crashed the encryptor before encryption completed.
Huntress reports an Akira affiliate gained access on August 4 via an MFA-less SonicWall VPN, enumerated Active Directory, archived file shares with WinRAR, and exfiltrated data to an attacker S3 bucket. The attacker rebooted the host into Safe Mode with Networking and preloaded AnyDesk into the Safe Mode service registry, disabling EDR and Defender's real-time protection for roughly ten minutes. The encryptor failed about 13 seconds after launch with out-of-virtual-memory errors caused by Safe Mode's stripped-down environment, and Defender later removed akira.exe after reboot. Huntress says this is the first observed Safe Mode abuse by Akira, following precedents by Snatch and AvosLocker, and provides detection guidance.
- Initial access via credential spray on an MFA-less SonicWall VPN.
- Host rebooted into Safe Mode with Networking, stopping EDR and Defender.
- Encryptor crashed 13 seconds after launch due to limited virtual memory.
- Data was exfiltrated before encryption, so extortion remains possible post-failure.
- Detection: msconfig/bcdedit, SAFEBOOT Event 27, BootMode=2, AnyDesk in Safe Mode registry.
Full article700 words · extracted from securityaffairs.com · click to collapse
Akira attackers used Safe Mode to disable EDR before deploying ransomware, but memory issues caused the encryptor to fail.
An Akira ransomware affiliate broke into a company through an MFA-less SonicWall VPN on August 4, stole credentials and file shares, and then rebooted the compromised host into Safe Mode with Networking to kill the security tools before launching the encryptor. The plan worked on the EDR. It did not work on the ransomware.
“After gaining access via an exposed SonicWall VPN, an Akira affiliate rebooted the victim host into Safe Mode with Networking to defeat EDR, a first for this ransomware variant in our telemetry.” reads the report published by Huntress.
“In this incident, Safe Mode also broke the ransomware. In its stripped-down memory environment, the Akira process tree hit an out-of-virtual-memory failure seconds after launching.”
The attacker also added AnyDesk to the Safe Mode registry before rebooting, so their remote access survived the restart even though everything else didn’t. For ten minutes, the host had no working EDR and Defender’s real-time protection was down.
The attack followed Akira’s standard playbook almost exactly: VPN credential spray resolved into a successful login at 03:52 UTC, then two hours of quiet before the operator RDP’d to the domain controller, dumped all Active Directory users and computers with a PowerShell enumeration that disabled truncation to capture every group membership, archived mapped file shares with WinRAR using the same flags documented in previous Akira campaigns, and uploaded the data to an attacker-controlled S3 bucket using s5cmd. Exfiltration happened before any encryption attempt, which matters, because it means the victim can still be extorted even when the ransomware fails.
The ransomware failed because Safe Mode limited available memory. About 13 seconds after launching, akira.exe triggered multiple memory errors, apparently overwhelming the stripped-down environment and causing the encryption process to fail.
“akira.exe executed at 06:34:29 UTC and spawned its child-process burst at 06:36:21 UTC. About 13 seconds later, the host started throwing memory errors:” continues the report. “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.”
Defender’s scheduled scan eventually detected akira.exe as Ransom:Win32/Akira.B!ibt, but couldn’t quarantine it while real-time protection was disabled in Safe Mode. The file was only removed after the attacker rebooted back to normal mode, restoring Defender’s protections, at which point their own anti-EDR move undid itself.
Huntress notes that Snatch and AvosLocker have abused Safe Mode for years, but this is the first time the company observed Akira using it. The more uncomfortable takeaway is that a host with more RAM or a larger page file might have given the encryptor enough memory to run successfully in Safe Mode. Akira’s developers could also reduce the payload’s memory footprint to make Safe Mode launches reliable, which means the same lucky failure won’t necessarily repeat.
The detection guidance is specific: alert on msconfig.exe or bcdedit activity, watch for Kernel-Boot Event ID 27 with a SAFEBOOT load option, Kernel-General Event ID 12 with BootMode=2, and third-party services stopping. Also watch for remote-access tools being added to the Safe Mode service registry, that’s the tell that the operator is planning to maintain access through the reboot.
“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.” concludes the report. “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. 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.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Akira Ransomware)
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/197339/malware/akira-ransomware-uses-safe-mode-to-bypass-edr.html