SURIQ
Turning off endpoint detection used to take a vulnerable driver or a signed kernel exploit. An Akira affiliate showed a cheaper route this month: reboot the Windows machine into Safe Mode, where third-party security services never load, and walk around the agent instead of through it. No exploit, no dropped driver, just a boot option Windows has shipped for decades. The intrusion also lands a point defenders keep relearning. The ransomware itself failed to encrypt anything, and it did not matter, because the data was already gone.
The incident was reconstructed by managed-detection firm Huntress, which published the full timeline after its analysts watched the attack unfold on a customer host on August 4, 2026. It is, by Huntress's account, the first time they have seen Akira use the Safe Mode trick, though the technique itself is older. What makes it worth your attention is not the novelty. It is how ordinary every step was, and how few of them your endpoint agent could see.
How did Akira turn off EDR without an exploit?
The operator ran the built-in system-configuration tool, msconfig, set the machine to boot into Safe Mode with Networking, and forced a restart. Safe Mode loads only the drivers and services Windows needs to start, so third-party software is left out by design. On reboot, the Huntress agent stopped and Microsoft Defender's real-time protection went dark. For a roughly ten-minute window the host ran with no working detection and networking still on, which is exactly what an attacker wants.
This is the part worth sitting with. We have written about ransomware crews that blind detection with a signed kernel driver and kits that hot-swap vulnerable drivers to kill the agent. Those need a driver to abuse and leave driver-load artifacts to hunt. Safe Mode needs neither. It is a native Windows feature, so there is no vulnerable component to patch away and nothing to allowlist. The bar to disable your security stack just dropped from "bring a driver" to "own an account and press restart."
The ransomware failed. The company still lost.
Here is the full arc of the intrusion, from the first valid login to the point the encryptor gave up.
Read the order carefully. According to Huntress, the attacker logged into an internet-facing SonicWall SSL VPN account on which multi-factor authentication had not been enabled at 03:52 UTC, after a short burst of failed logins from the same address. Within two hours they had reached a domain controller over RDP, enumerated Active Directory, and staged and shipped the files out to attacker-controlled cloud storage using off-the-shelf archiving and upload tools. The Safe Mode reboot and the akira.exe launch came after all of that. In this case the encryptor tripped over Safe Mode's stripped-down memory and died with out-of-virtual-memory errors seconds after it started.
Treat that failure as luck, not a control. Safe Mode broke the ransomware here, but nothing the defender did caused it, and a slightly different payload or a machine with more memory would have finished the job. More important: the encryption was the last act, not the loss. The theft happened at 06:10, twenty minutes before the reboot. This matches a pattern we flagged with Kairos, a crew that encrypted nothing and still collected a seven-figure payment. When the extortion model is "pay or we leak," the file locker is optional theater. If your ransomware plan starts at the ransom note, it starts hours too late.
The reboot is the detection, not the agent
The obvious defensive instinct, "watch for the process that kills the EDR," does not work against this. There is no kill. The agent simply is not running, because Windows never started it. Any detection that depends on the agent being alive is blind for the whole Safe Mode window. So the signal has to come from somewhere the attacker did not switch off: the operating system's own boot record.
Three artifacts survive because Windows writes them, not the agent. First, the boot-configuration change itself, which is what msconfig and bcdedit do when they set a machine to Safe Mode. Watching for those tools executing on a server is a high-value, low-noise trip wire. Second, the boot-mode event Windows logs on the next start, which records that the system came up in Safe Mode with networking. Third, persistence: to keep their remote-access tool working after the reboot, the operator registered it under the SafeBoot\Network branch of the registry, the small allowlist of services permitted to run in Safe Mode. That branch rarely changes on a production server, so a new entry in it is worth an alert on its own.
The reason this detection is strong is the same reason the attack works: a production server or a domain controller almost never has a legitimate reason to reboot into Safe Mode with networking on its own. The false-positive rate is close to zero. Most security teams alert on process termination and driver loads and never watch boot mode at all, which is precisely the gap the technique exploits. MITRE ATT&CK tracks this as Impair Defenses: Safe Mode Boot (technique T1562.009), and it is not an Akira invention. Snatch and AvosLocker used it before. Build the detection once and it covers the whole class.
Require MFA on the VPN and alarm the Safe Mode boot
Two fixes address the two ends of this intrusion, and both are things you can check today. At the front door, the entry point was a VPN account with no second factor, reached by guessing credentials. Multi-factor authentication on every remote-access account closes that specific door, and an alert on a burst of failed VPN logins followed by a success from the same address catches the attempt in progress. At the back end, add the boot-centric detections above so the Safe Mode window is not a hole in your telemetry.
This is the kind of cross-signal detection that host-based monitoring is built for: correlating a suspicious VPN login, an unusual RDP session to a domain controller, a boot-configuration change, and a new Safe Mode service registration into one story a human can act on. Suriq's managed detection service watches Windows boot events, registry changes, and authentication anomalies across the hosts it monitors, and surfaces the sequence rather than the isolated events. Whatever tooling you run, the takeaway is the same. When the attacker's plan is to turn your agent off, your best signal is the one thing they had to turn it off with.