On August 4, an Akira affiliate broke into a company’s network through its SonicWall VPN, which didn’t require multi-factor authentication. They got in the old-fashioned way: trying a big batch of stolen or guessed passwords until one worked. It took less than ten minutes. From there, things moved fast. Within a couple of hours the attacker had remoted into the domain controller, the server that manages logins for the whole network, and used a built-in Windows tool called msconfig to reboot the machine into Safe Mode with Networking.
That one reboot did more damage to the target’s defenses than anything else in the intrusion. Huntress, which caught and documented the attack, confirmed it’s the first time this specific ransomware family has used Safe Mode to get around endpoint protection. The technique itself isn’t new: Snatch and AvosLocker have used it since at least 2019, and MITRE tracks it as T1688, Impair Defenses: Safe Mode Boot. What’s new is that Akira, one of the most active ransomware groups in the world, has now added it to the standard playbook.
Why safe mode works as an EDR bypass
Safe Mode with Networking loads a minimal driver set: the core Windows components needed to boot and reach a network, nothing more. It was built this way on purpose, so a corrupted system could still start up and get repaired. Third-party security software wasn’t part of that design. Most EDR agents run as regular services or drivers that Windows never marks for inclusion in the Safe Mode driver set, so when the machine boots into Safe Mode, they just don’t load.
That’s exactly what happened here. Huntress’s own EDR agent failed to start. Windows Defender’s real-time protection went down too, throwing error 0x8007043c: “service cannot be started in Safe Mode.” Even Microsoft’s built-in antivirus doesn’t get a free pass into Safe Mode. If Defender can be locked out, a third-party agent has no chance.
The attacker had already planned for this. Before rebooting, they registered AnyDesk to launch automatically in Safe Mode by adding a key under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\AnyDesk. That’s the same registry location Windows checks to decide what’s allowed to run during a Safe Mode boot. The attacker used the OS’s own trust list against it: add your remote access tool to the list, and it boots right alongside the OS while everything meant to stop you stays dark.
Why it failed anyway
Akira’s payload executed at 06:34 UTC. Two minutes later, the system started throwing “Virtual Memory Minimum Too Low,” followed by “Out of Virtual Memory,” followed by a PowerShell stack guard page failure. Safe Mode’s stripped-down environment comes with a correspondingly stripped-down memory footprint, and the Akira process tree ran out of room before it could finish. Windows Defender flagged the payload at 07:43 UTC, but couldn’t quarantine it while real-time protection was still offline. Only after the attacker rebooted back to normal mode at 08:10 did Defender clean it up, two minutes later.
Worth being honest about what actually stopped this attack: it wasn’t the EDR, and it wasn’t a policy. It was the target running out of memory before the encryption finished. Huntress makes the same point: a machine with more RAM, a larger page file, or a leaner payload would have sailed through. This wasn’t a defense holding the line. It was the attacker’s tooling hitting a wall that happened to be in the right place this time.
The fix people will reach for, and why it’s not enough
Huntress’s recommendations are solid and worth doing: require MFA on every VPN account, alert on credential-spray patterns, watch for msconfig.exe and bcdedit activity, alert on the specific Kernel-Boot and Kernel-General event IDs that show up during a Safe Mode transition, flag changes to the SafeBoot registry paths, and get EDR onto every host instead of leaving gaps for an attacker to stage in.
All of that is detection. It tells you a Safe Mode reboot happened, ideally fast enough to respond before damage is done. None of it changes the fact that the reboot itself still works. An attacker who’s read this far into a defender’s playbook can slow down, avoid the memory pressure that saved this particular target, and try again. Logging the door opening doesn’t lock it.
Where kernel-level enforcement changes the equation
The root problem is structural: most endpoint protection is software that has to be running to do anything. It’s a service, and services can be excluded from boot mode. Safe Mode isn’t a flaw in any one EDR product. It’s a gap built into how Windows decides what gets to start.
Enforcement that lives in the kernel’s code integrity path doesn’t have that gap. Instead of asking “did my agent’s service start,” it asks a different question at the point where code actually tries to execute: is this binary on a known-good list, verified against a signed policy that’s part of the trusted boot chain itself. That check doesn’t depend on a service successfully launching after the OS decides what to load. It’s evaluated by the kernel as code runs, in Safe Mode or out of it, because unsigned or non-allowlisted execution simply isn’t a valid outcome, full stop.
That’s a meaningfully different guarantee than “we’ll detect if someone tries this.” An attacker who reboots into Safe Mode and pre-registers a remote access tool has done everything right by the old rules: EDR is gone, Defender is gone, and their tool of choice is running. Under known-good kernel enforcement, none of that changes what’s allowed to execute. The boot mode picked which drivers loaded. It didn’t pick what code the kernel will let run.
Akira’s affiliate got unlucky with memory limits this time. The next one might not. The lesson from this incident isn’t “watch for Safe Mode reboots,” though defenders absolutely should. It’s that any protection model built on an agent needing to start successfully has an off switch built into the operating system, and attackers have just proven they know where it is.
