They switched the EDR off with a reboot, and the encryption failed for lack of memory

At 06:29:21 UTC on 4 August, someone who had been inside since a quarter to four in the morning opened msconfig.exe and forced a reboot. The machine came back in Safe Mode with Networking, a boot in which Windows does not load third-party services. The EDR agent stayed out. Defender logged an error of its own, 0x8007043c: "this service cannot be started in Safe Mode".

The case was published by Huntress on 12 August, and one thing is worth saying up front: the agent that went dark was theirs. They wrote it up anyway, with the event IDs and the timestamps. We run managed EDR/MDR on other companies' estates and we staff the on-call rota, so the report reads from here as a list of what we should have caught.

The timeline, with the times there are and the ones there aren't

Everything below is in UTC, which is how Huntress publishes it. Two phases of the attack carry no timestamp in the report, and we are not going to invent one here either.

One hour forty-one, not ten

Some of the coverage puts the EDR-less window at ten minutes. That number is in the report, but it measures something else: Huntress says the AnyDesk session, including the preceding Safe Mode reboot, lasted less than 10 minutes. The blind window is a different sentence, two paragraphs earlier: for the entire Safe Mode window, the host had no working EDR, and AV was blinded.

What stopped the encryption was memory

Safe Mode boots with a stripped-down environment and constrained virtual memory. Huntress phrases it carefully and we are going to borrow their caution: the Akira process tree appears to have starved it, and the "Out of Virtual Memory" box lines up exactly with the moment the payload tried to get going. Their sentence on this goes in whole, because the second half is the one that matters: "a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around".

And they add the detail that finishes the argument: a host with more physical memory or a larger page file might have given akira.exe enough virtual memory to encrypt in Safe Mode. The same intrusion, on a server with 256 GB, ends somewhere else. So the honest summary of this incident contains the word luck, and that word never describes the incident: it describes the security programme underneath it.

The files left before the reboot

The report doesn't date the exfiltration, but it does order it: WinRAR over the mapped file shares and an upload with s5cmd before the 06:29:21 reboot, which in turn comes before the 06:34:29 encryptor. By the time the attacker touches the binary, the files are already in a bucket that isn't yours. Textbook double extortion: the encryption is there to hurry along someone who has already lost the data.

Worth saying even though it makes us look worse: a flawless backup would have changed nothing about that day. It gives you the files back and leaves the blackmail lever untouched. We sell managed backup and even so the right order in this post is access first, watching second, and the copy as the safety net underneath. And if your backup server lives inside the same domain they have just dumped wholesale with Get-ADComputer, that is a different problem we wrote up separately.

In Safe Mode your agent is not essential to Windows

There was no exploit, no signed vulnerable driver, no kernel tricks. There was an msconfig.exe and a reboot, and the operating system's own design did the rest: the minimal driver and service set excludes third-party security products by definition. MITRE has a technique for it, T1688, and Huntress points out that families such as Snatch and AvosLocker have done it for years. What they are seeing for the first time is Akira doing it.

It fits what the quarter looks like as a whole. In its Q2 2026 report, Halcyon counted 1,988 publicly claimed attacks and 89 active groups, with Akira fourth by volume on 119. Infosecurity opened its piece on that report by summing it up this way: shutting endpoint detection tools down before encryption begins has become standard operating procedure across the ransomware ecosystem.

The line almost nobody quoted

It sits in the mitigations section and reads fast: in this environment, the agent was on a fraction of the machines the attacker enumerated. That is where an attack gets prepared, on the hosts nobody watches, which is why the Get-ADComputer at the start isn't a forensic curiosity: it is the map that tells the attacker which ones. An EDR rollout with holes turns your inventory into somebody else's.

This part lands closest to home. When we take over someone else's estate, the first sum we do in managed EDR/MDR is how many hosts are in the directory and how many carry an agent. The gap between those two numbers is the attack that hasn't happened yet.

The times are UTC, and that changes the conversation

Huntress doesn't say where the victim was, so converting to local time is our exercise and not a fact of the case. Had this happened in mainland Spain, the spray falls at 05:45 and the valid login at 05:52 — small hours, nobody about — and the blind window would run from 08:29 to 10:10. Mid-morning. With the office open.

We prefer that scenario to the easy headline, because it is more uncomfortable. A machine that reboots on its own and goes without an agent for an hour and three quarters can slip past at ten in the morning on a Tuesday, with everyone at their desk, and hiring a night shift doesn't fix that. What fixes it is 24x7 support wired to the console, and a rule saying that a silent agent wakes somebody up, whatever the hour.

Seven minutes at the door

Everything above happens afterwards. The door was an SSL VPN with a username and a password, and it opened in roughly seven minutes of spraying. It doesn't matter how good the rest is if the perimeter gives to a reused password, and we have written about this in another guise: when the thing that fails is the perimeter appliance itself, and when there are authentication paths that never get around to asking for the second factor.

The mitigations, in the order Huntress puts them

The list is theirs and so is the order. In brackets is what we do with each point, which is the only thing here that is ours:

What we are NOT going to tell you

In short

A VPN with no second factor, a dump of the entire directory, file shares archived with WinRAR and pushed to S3, and a reboot that left the host one hour and forty-one minutes without an agent or an antivirus. The encryptor was brought down by Safe Mode's virtual memory, and Huntress warns that on a host with more RAM it wouldn't have been. Everything else in the case — events 27, 12, 26 and 7036, the burst against the VPN, the agent going quiet — was being written into logs that most environments already generate.

Sources: timeline, timestamps, commands (Get-ADUser, Get-ADComputer, WinRAR, s5cmd, reg.exe add on SafeBoot\Network, msconfig.exe), events Kernel-Boot 27, Kernel-General 12, System 26 and Defender 3002 / 0x8007043c, the Ransom:Win32/Akira.B!ibt detection with cleanup failing 0x80004005, their own agent being the one disabled, technique T1688 with the Snatch and AvosLocker precedents, the partial EDR coverage and the mitigations in their published order, plus the quote about the lucky side effect — Huntress, 12 August 2026, read in the original rather than in summaries. Coverage placing the EDR-less window at ten minutes — BleepingComputer; reproduction of the side-effect quote — SC Media. Quarterly figures (1,988 attacks, 89 groups, Akira fourth on 119) and the opening summary about EDR shutdown — Halcyon's Q2 2026 report, as covered by Infosecurity Magazine. Our own arithmetic: the 1 h 41 min 17 s window (06:29:21 → 08:10:38) and the conversion to mainland Spanish time, neither of which Huntress publishes.