Skip to content

Akira ransomware exploits Windows Safe Mode reboot to disable EDR

In brief: Akira ransomware attackers are, for the first time, deliberately forcing compromised Windows systems into Safe Mode to disable EDR and Microsoft Defender – though in the documented case, encryption failed due to resource issues within the malware itself.

Attackers from the Akira ransomware group have for the first time used a technique that deliberately reboots compromised Windows systems into Safe Mode with Networking to disable endpoint detection and response solutions and Microsoft Defender. For CISOs, the incident, documented by Huntress, marks an evolution of known evasion techniques that specifically undermines classic EDR coverage.

The incident, described by Huntress analyst James Northey, began on August 4 with a credential spraying attack against an exposed SonicWall SSL VPN. Roughly seven minutes after the failed login attempts started, the attacker succeeded in authenticating to an account without multi-factor authentication (MFA). Two hours later, the operator accessed the domain controller via RDP, conducted extensive Active Directory enumeration, and then moved to an application server to archive mapped shares using WinRAR. The stolen data was uploaded via s5cmd to an attacker-controlled S3 bucket – the data exfiltration component of a double extortion attack. The attacker then installed AnyDesk for persistent remote access and used it to deliver the Akira payload. Rather than disabling EDR directly, the operator used “msconfig.exe” to force the system into Safe Mode with Networking.

Safe Mode normally loads only essential drivers and services for troubleshooting purposes – many third-party security products are excluded from this minimal startup configuration. Anticipating that AnyDesk might also be unavailable in Safe Mode, the attackers modified the Safe Boot registry configuration so the remote access service would still start. The underlying principle is not new: ransomware families such as Snatch and AvosLocker have used Safe Mode for years to disable protective mechanisms, and MITRE ATT&CK lists the behavior under T1688 (Impair Defenses: Safe Mode Boot). Akira now adopting this approach fits recent observations of the group: earlier this year, an Akira affiliate created a new virtual machine on a victim’s hypervisor specifically to run the encryptor where Huntress was not installed.

In this particular case, however, the attempt failed due to the attackers’ own approach: after launching “akira.exe” in Safe Mode, the system reported errors such as “Virtual Memory Minimum Too Low” and “Out of Virtual Memory,” followed by PowerShell errors. The ransomware apparently could not function correctly within the constrained Safe Mode environment. Defender eventually detected the Akira binary but could not remediate it while real-time protection was disabled – quarantine only succeeded after the attacker restored the system to normal Windows operation, thereby reactivating Defender’s protective functions.

Huntress explicitly warns against misinterpreting the encryption failure as a reliable protective mechanism. It was likely a side effect of Akira’s resource requirements rather than a fundamental technical weakness. More memory, a larger page file, or adjustments to the encryptor could well enable a future version to run in Safe Mode. Detection prior to a reboot must therefore remain the priority. Huntress recommends making MFA mandatory for all VPN accounts, correlating clusters of failed VPN logins with subsequent successful authentications, and deploying EDR across all hosts. In addition, SIEM feeds should be monitored for “msconfig.exe” or “bcdedit” activity, Safe Mode boot events, the stopping of security services, and changes to the Safe Boot registry configuration.


Source: www.csoonline.com · Published August 14, 2026
Lumi AI News — AI-assisted curation pursuant to Art. 50 EU AI Act. Paraphrasing and classification by Lumi News Pipeline v1.8.3.

Share on: