Your Antivirus Has an Off Switch, and Ransomware Just Found It

An Akira operator rebooted a company server into Windows Safe Mode on August 4 and every security tool on that machine went dark without firing a single alert. Here is why tamper protection does not cover this, and the free hour that tells you whether you would even notice.

The IT manager at a 90-person engineering firm got a monitoring text at 6:31 on a Tuesday morning. The application server had rebooted.

He did not think much of it. Windows reboots. Patches land overnight and the machine comes back on its own. It could wait for coffee.

Twenty minutes later, at his desk, the server was up and answering. He opened a remote session.

Then he looked at it properly. Black background. Taskbar the wrong size. Every icon too large.

Safe Mode.

He had not put it in Safe Mode. Nobody on his team had. He opened the security console to see what the endpoint agent had recorded during the reboot.

The console was clean. No alert. No warning. No stopped service.

The agent had not been stopped.

It had never started.

What just happened

Huntress published the incident breakdown on August 12. The attack began on August 4 at 03:45 UTC, when someone started throwing passwords at a company's SonicWall SSL VPN. About seven minutes in, at 03:52:42, one login worked. That account had no second verification step in front of it.

Nothing happened for two hours. Then the operator moved to the domain controller over Remote Desktop and listed every user and computer in the company into two text files. File shares were archived with WinRAR and pushed to cloud storage the attacker controlled. AnyDesk went on the machine as a Windows service to hold the door open.

Everything to this point is ordinary. Here is the part that is not.

At 06:29:21, the operator ran msconfig, the built-in Windows tool that changes how a computer starts, and forced a restart into Safe Mode with Networking.

Safe Mode is the diagnostic setting you use when a machine will not boot. It loads core Windows and almost nothing else. Third-party software does not start. That is not a flaw. That is the purpose.

The endpoint agent could not start. Microsoft Defender logged a message stating plainly that its real-time protection cannot run in Safe Mode. Seconds into the boot, the machine had no working security software on it.

The attacker's tooling came back fine. Before the reboot, they had added AnyDesk to the registry list of services Windows is permitted to run in Safe Mode. Their remote control survived the restart. The defenses did not.

Why your security software didn't help

Nobody disabled anything. That is the trick, and it breaks four things people assume are covering them.

Ranked from least useful to most:

Your antivirus signatures. Defender eventually identified the file. A scheduled scan flagged it as Akira and could not remove it, because removal requires real-time protection and real-time protection was not running. Detection you cannot act on is a log entry.

Tamper protection. This is the setting that stops an attacker from killing your security agent, and it is the correct setting to have on. It does nothing here. Nothing was tampered with. No service was stopped, no sensor was modified. Windows was asked to boot in a mode where that agent does not load, and Windows did that.

Your alerting. A security service that gets stopped generates an alert in most consoles. A security service that never starts generates silence. Your console has nothing to report because from its point of view, nothing occurred.

Your endpoint agent. Only helpful on the machines that have it. Huntress noted the agent was installed on a fraction of the machines the attacker enumerated, and the ones without it are where an operator stages the work.

One thing does catch this, and it is not a security product. It is the reboot.

Windows records the boot mode every single time a machine starts. The forensic trail is specific: Kernel-Boot Event ID 27 carries a SAFEBOOT load option, Kernel-General Event ID 12 records BootMode=2, and System Event ID 7036 shows the third-party security services stopping.

Whether anyone reads it is a different question, and for most small businesses the honest answer is no.

What you can actually do this week

One thing first, and it is not on the list. If your VPN still accepts a password alone, fix that before anything below. Twenty minutes, no cost, steps in this week's issue. What follows is what you do afterward, because that login was only step one of five.

1. Send your IT provider one question with event IDs in it. Cost: $0. Time: one email. Ask this exactly: does a Safe Mode boot on any of our machines generate an alert anywhere, and are we watching Kernel-Boot Event ID 27, Kernel-General Event ID 12, and msconfig or bcdedit execution? Ask for it in writing. A provider who cannot tell you inside one business day has answered a larger question about the relationship.
2. Compare your machine count to your agent count. Cost: $0. Time: about an hour. Get two lists. Every Windows machine on your network, including the old file server nobody logs into. Then every machine your security software is actually installed on. The gap between those numbers is where an attacker stages the work before touching anything you can see. Most owners are off by more than they expect.
3. Turn on an alert for failed logins that end in a success. Cost: $0. Time: 30 minutes. The pattern here was a burst of failures followed by one login that worked, all inside seven minutes, all from outside. SonicWall, Fortinet, Cisco, and Microsoft 365 all log that sequence. Almost nobody watches it. Ask whoever manages your remote access to send an email when it happens.

The harder truth

The board went quiet this week. Fifty-two disclosed victims across 23 active crews, the first reading outside the 96 to 107 range in eight issues, and that is after stripping out 26 junk posts that were not ransomware at all.

Read that number carefully, because it does not mean what it looks like.

Leak sites publish on the criminal's calendar, not yours. The company in this article was breached on August 4 and surfaced in a vendor writeup on August 12. It may never appear in a victim count at all. A business hit today might not show up until October. A quiet posting week is not a quiet attack week.

Look at what did not move. Qilin claimed 27 of 102 victims last week and 12 of 52 this week. The board halved and Qilin's share held at 23 percent, which means the slowdown belongs to the small crews, not to the operation with the most affiliates.

Look at who stayed on the table. Financial services led every sector for the first time this quarter with 7 victims, mostly small lenders and agencies. Legal services took 4, the sixth straight issue. Healthcare took 3, the eighth consecutive issue, and every one of them was a single-site operation.

The count fell. The targeting did not. The question worth carrying into next week is not how many companies got named. It is how many are already breached and have not been announced yet.

If this was useful

I write S6 Ransomware Signal, a free weekly newsletter for small and mid-size businesses without a dedicated security team. Every issue covers the week's ransomware and extortion activity, what the victim numbers reveal about who is being chosen, and the short list of fixes that change the outcome.

This week's issue goes deeper on three things this article left alone. A 26-year-old in Ontario pleaded guilty on August 5 to breaking into 165 companies with stolen passwords and a missing second factor, and the court record puts hard dollar figures on what that setting was worth. ShinyHunters listed a data center operator with a 13 million dollar demand and an August 24 deadline. And DragonForce is openly advertising Social Security numbers and credit reports taken from a boutique US lender.

Subscribe here. It is free, and it lands Monday morning.

Your security software has an off switch. It has always had one. This is the week the criminals started using it on purpose.