Akira Ransomware Rebooted Into Safe Mode to Kill EDR, But the Encryption Failed

Key takeaways

• An Akira ransomware affiliate compromised an exposed SonicWall SSL VPN with no MFA, gained domain controller access, and exfiltrated data in under five hours.
• The attacker forced a reboot into Windows Safe Mode with Networking to disable EDR and Microsoft Defender's real-time protection, a technique never before documented in an Akira attack.
• The ransomware payload actually failed to encrypt files because Safe Mode's stripped-down environment couldn't supply enough virtual memory to run it.
• Despite the failed encryption, the attacker still stole data and credentials, meaning the victim organization still faces extortion risk from a security incident that "failed."
• Akira remains one of the most active ransomware operations tracked by CISA and the FBI, with more than $244 million in extorted payments as of late 2025.

A newly reported Akira ransomware security incident is a reminder that "the ransomware didn't detonate" is not the same as "we're safe." According to research published by managed detection and response provider Huntress, and corroborated by outlets including BleepingComputer and SC Media, an Akira affiliate broke into a victim environment, moved through it with speed and precision, and disabled endpoint defenses using a technique that has only rarely been seen in ransomware operations. The encryption step failed. The data theft did not.

What happened in this security incident?

In early August, the attacker gained initial access through an exposed SonicWall SSL VPN account that had no multi-factor authentication enabled. After a credential-spray attempt, a valid login succeeded. Roughly two hours later, the attacker connected via Remote Desktop Protocol directly to the domain controller and began enumerating Active Directory (accounts, computers, group structure) to map the environment.

From there, the intrusion moved fast:

• The attacker pivoted laterally to an application server.
• WinRAR was installed to archive data from four mapped file shares.
• The utility s5cmd was used to exfiltrate that archived data to an attacker-controlled Amazon S3 bucket, setting up a double-extortion play.
• AnyDesk was installed as a persistent remote access and command-and-control channel, and the attacker manually pasted commands through its clipboard channel throughout the intrusion.

The entire sequence, from initial VPN login to the attempted ransomware detonation, took under five hours.

How did the attacker disable EDR using Safe Mode?

Before deploying the akira.exe encryptor, the attacker forced a reboot into Windows Safe Mode with Networking using msconfig.exe. Safe Mode is designed to load only core Windows drivers and services for troubleshooting, which means most third-party services, including EDR agents, don't start. In this case, Huntress's own EDR agent and Microsoft Defender's real-time protection were both effectively sidelined.

To make sure their access survived the reboot, the attacker had already added a registry entry ensuring AnyDesk would still launch in Safe Mode. This maps to MITRE ATT&CK technique T1688 (Disable or Modify Tools via Safe Mode), and while it has appeared in past attacks by groups like Snatch, Embargo, and AvosLocker, this is the first time Huntress has documented it in an Akira intrusion.

Why did the ransomware encryption fail?

Once in Safe Mode, the attacker executed akira.exe, but the payload failed to launch due to insufficient virtual memory. Safe Mode's minimal operating environment simply couldn't support the process. No files were encrypted.

Windows Defender later flagged Akira during a scheduled scan, but without real-time protection active, it couldn't automatically remove the threat. It wasn't until the attacker rebooted the machine normally, exiting Safe Mode, that Defender's protections reactivated and cleaned up the malware.

Huntress researchers were careful to frame this as an attacker error, not a reliable defense. As Huntress Senior Security Operations Analyst James Northey put it, a host with more physical memory or a larger page file might have given the encryptor enough room to run in Safe Mode, and the ransomware itself could be retooled to encrypt more reliably in that environment. In other words: this specific attacker lost this specific battle. The technique itself is very much still viable.

What this means for IT and security leaders

Even a "failed" ransomware detonation is not a clean outcome. The attacker still accessed the domain controller, enumerated Active Directory, exfiltrated data from multiple file shares, and maintained persistent remote access, all before the encryption attempt ever happened. That data theft alone creates real extortion and regulatory exposure, independent of whether files were ever locked.

This incident also reinforces a pattern security teams need to watch closely: attackers are increasingly targeting the visibility layer itself, not just the data. If your EDR and monitoring depend entirely on the operating system booting normally, a technique like this can create a real blind spot during the exact window that matters most.

Akira is not a fringe threat. Per a joint CISA and FBI advisory, the group has compromised more than 340 organizations and extorted over $244 million as of late 2025, placing it among the top five most active ransomware operations tracked out of 130 monitored variants.

How can organizations detect and prevent Safe Mode abuse?

Huntress's recommendations, and ours, come down to a few concrete controls:

• Require MFA on every VPN account, no exceptions. The initial access point here was an SSL VPN with no MFA. This remains one of the most common and most preventable entry points for ransomware affiliates.
• Alert on credential-spray-to-success login patterns. A burst of failed logins followed by a success is a strong early warning signal, and in this case, the two-hour gap before RDP activity began was a missed detection window.
• Rotate VPN credentials immediately after any suspected compromise.
• Monitor for Safe Mode boot activity and boot configuration changes, including:
  • Kernel-Boot Event ID 27 with a SAFEBOOT load option
  • Kernel-General Event ID 12 with BootMode=2
  • System Event ID 7036 (third-party security services stopping)
  • Unexpected msconfig.exe or bcdedit activity
  • Unauthorized additions to the Safe Boot registry key
• Ensure EDR coverage extends across every host, including servers and domain controllers, not just endpoints.

How Logically can help

Security incidents like this one succeed because of small, fixable gaps: an account without MFA, a monitoring blind spot around boot state changes, EDR that isn't deployed everywhere it needs to be. Contact our experts today to review your VPN and remote access posture, confirm MFA coverage across every account, and assess whether your monitoring would catch a Safe Mode boot change before an attacker can use it against you.

By Vice President, Cybersecurity, Zack Finstad

Last updated September 2026

FAQs

Did this Akira attack succeed?

Partially. The attacker successfully accessed the environment, stole data, and
installed persistent remote access tools. The final step, file encryption,
failed due to a technical limitation in Safe Mode, not because it was blocked
by a security control.

Is Safe Mode abuse a new ransomware technique?

Not entirely new, it has been used by Snatch, Embargo, and AvosLocker, but this
is the first documented case in an Akira ransomware operation.

Does this mean our EDR is ineffective?

No, but it means EDR alone isn't sufficient if it can be disabled through a
system-level state change like Safe Mode. Layered monitoring for boot
configuration changes closes that gap.

What's the single most important takeaway?

MFA on every remote access point remains the highest-leverage control. This
entire intrusion, and the data theft that resulted from it, started because one
VPN account didn't have it.