Huntress documented an Akira affiliate intrusion on 4 August 2026 that ended in failure — the ransomware would not run — and was still a serious breach.
That gap is the point of writing it up.
The timeline
| Elapsed | What happened |
|---|---|
| 0:00 | Initial access via exposed SonicWall VPN, compromised credentials, no MFA |
| ~2:00 | RDP to the domain controller, Active Directory enumeration |
| — | Files archived with WinRAR, uploaded with s5cmd to an attacker-controlled S3 bucket; AnyDesk installed |
| — | Reboot into Safe Mode with Networking |
| ~5:00 | akira.exe fails to execute |
Five hours from stolen credential to attempted encryption. Two of those hours before they were on the domain controller.
The Safe Mode trick
Safe Mode with Networking starts Windows with a limited set of drivers and services, which as Huntress puts it generally prevents most third-party software and services from loading.
Your EDR is third-party software.
the host had no working EDR, and AV was blinded
That window was about ten minutes.
The detail that shows this was practised: before rebooting, the attackers added AnyDesk to the Safe Mode registry so their remote access survived into the blinded environment. Safe Mode is useless to an intruder who cannot reach the machine once it gets there.
This is not a new technique — ransomware crews have rebooted into Safe Mode for years — but it remains effective because the thing that makes Safe Mode useful for repair is exactly what makes it useful here.
Why the encryption failed, and why that is the least important part
akira.exe failed with low virtual memory errors. Then, after the machine rebooted back to normal mode, Defender's scheduled scan found and quarantined it — despite real-time protection having been disabled.
So: the ransomware did not run, the endpoint protection eventually did its job, and the incident is still a data breach.
The files were exfiltrated to S3 before the Safe Mode reboot. Credentials were taken. Nothing about the encryption failing pulls any of that back.
Double extortion has been standard for years, and this is what it means operationally: encryption is the optional half. A crew that steals your data and fails to encrypt anything still has your data, still has a leak site, and still has a negotiation. Recovering from backups answers a question they did not ask.
The initial access is the part you can actually fix
An internet-exposed VPN, valid credentials, no MFA.
That is the same door as the UNC6671 vishing campaign, the SonicWall credential harvesting Volexity tracked, and a large share of every ransomware report published this year. It is not a clever attack. It is the absence of one control.
What to do
- MFA on every VPN and remote access path, without exception for service accounts or "temporary" access.
- Alert on unexpected Safe Mode boots. A production server rebooting into Safe Mode with Networking is either an emergency or an intrusion, and both warrant a page. The registry write that adds a service to Safe Mode is itself a detection.
- Watch for s5cmd, rclone and WinRAR on servers. Bulk archiving followed by an upload utility is the exfiltration stage, and it happened here before anything encrypted.
- Alert on outbound volume to cloud storage from hosts that have no business talking to S3.
- Do not treat a failed encryption as a near miss. Scope it as a data breach, because that is what it was.
Huntress's conclusion is the one worth carrying: the attackers exfiltrated credentials and files for extortion regardless of the payload failing. Ransomware success no longer requires ransomware.
