What Happened
Between September 10 and 19, 2026, a 3AM ransomware affiliate compromised a UK school and encrypted 37 machines. According to Bitdefender’s investigation, the attackers gained initial access through an unknown vector, then spent nine days escalating privileges, stealing credentials, and moving laterally across three previously separate Active Directory domains.
The attackers used a modified PowerShell script to extract stored credentials, copied a Chrome database containing saved passwords, targeted LSASS memory for authentication data, and created two backdoor administrator accounts. They established two-way trust relationships between the school’s Active Directory domains, collected financial documents, and mapped the network.
On September 19, they attempted to remove Sophos and Bitdefender endpoint protection — both attempts were blocked by anti-tampering protections. They successfully deleted Windows system-state backups and deployed the 3AM ransomware encryptor, encrypting approximately 37 machines.
Bitdefender researchers identified unusual command-execution patterns that suggested possible AI assistance, including repeated attempts to run slightly modified commands at 40-to-101-second intervals. The behavior could be consistent with an agentic AI loop interpreting results and generating revised instructions, though the researchers could not confirm specific AI use.
Why the Existing Defenses Failed
The school had endpoint protection from two vendors — Sophos and Bitdefender. Both tools successfully blocked tampering attempts. But neither stopped the attack.
That’s because signature-based endpoint protection works by recognizing threats it has already seen. A researcher finds a new ransomware variant, analyzes it, creates a signature, pushes an update, and your antivirus learns to block it. That process takes time. The window between a new ransomware release and when your endpoint tool can detect it can be hours or days. That’s exactly when attacks happen.
The attackers in this case didn’t need to defeat the endpoint protection — they just needed to use a variant the tools hadn’t learned to recognize yet. When the ransomware encryptor landed on disk and executed, the endpoint tools didn’t see it as a threat.
The backup deletion worked because the attackers had valid credentials and administrative privileges. From Windows’ perspective, an authorized admin was performing a legitimate file operation. There was nothing to block.
How FileSure Defend Would Have Stopped It
FileSure Defend operates at the Windows kernel level via a filter driver that intercepts every file operation before it completes. It doesn’t try to recognize ransomware. It controls what programs are allowed to do to your files.
Ransomware has to write files to disk. There’s no way around it. The malware payload has to land on the hard drive before it can execute. The encryptor has to write encrypted versions of your files to complete the attack.
FileSure intercepts those write operations at the kernel and enforces policy. A simple rule — unauthorized programs cannot write executable files to this system — would have blocked the ransomware payload from ever landing on disk. No payload on disk means no execution. No execution means no encryption.
Here’s what that rule looks like in FileSure:
Operation: Block
File operation: Write, Create
File type filter: .exe, .dll, .bat, .ps1, .vbs, .scr
Program filter: All programs EXCEPT [authorized installers, update tools, admin utilities]
Drive type: Local fixed drives
Action on violation: Block and alert
When the attacker’s delivery mechanism — email attachment, browser download, remote execution — tries to write the malware payload to disk, the kernel blocks it. The write operation fails. The payload never lands. The attack stops before it starts.
This works on ransomware variants from this morning the same way it works on variants from five years ago, because FileSure doesn’t need to recognize the threat. It just enforces the rule.
Even if the attackers had somehow bypassed that control and gotten the encryptor onto disk, FileSure would have stopped the encryption itself. Ransomware encrypts files by reading the original, encrypting it in memory, and writing the encrypted version back to disk. That write operation goes through the kernel filter driver. A rule blocking unauthorized programs from writing to specific file types or folders would have stopped the encryption cold.
The backup deletion would have been recorded in FileSure’s tamper-resistant audit log, showing exactly which account deleted which files and when. That’s not prevention, but it’s accountability — something Windows Event Log doesn’t reliably provide, especially when attackers have admin privileges and can clear the logs.
FileSure runs on Windows Server 2003 through Server 2022 and all modern Windows workstations. It uses less than 2% CPU and 50MB of memory. Your users won’t notice it’s there. The attackers will.
If you’re responsible for a Windows environment and you’re tired of watching endpoint tools fail to stop ransomware they haven’t seen before, start a free 21-day trial at bystorm.com. Install it on one server and ten workstations. Set the rule. Run our test file that mimics ransomware behavior. Watch FileSure block it. That’s the whole demo.
Source: 37 Machines Encrypted in UK School AI-assisted Ransomware Attack
Category: Ransomware
Tags: 3am ransomware, kernel filter driver, file system security, ransomware prevention, active directory attack, backup deletion, credential theft, uk school breach
