Ransomware

An affiliate of the 3AM ransomware operation worked through a UK school estate from September 10 to 19, then encrypted about 37 machines in a single morning. Bitdefender published its investigation on November 3. The estate ran 47 systems across several Active Directory domains that were never meant to talk to each other, and the attacker stitched them together before deploying the encryptor. The school estate has not been named.

The part getting the headlines is that some of the intrusion looks machine driven. Bitdefender describes a hybrid: a person choosing the goals, and something that behaves like an AI agent loop retrying failed commands every 40 to 101 seconds. That is a suspicion, and Bitdefender says plainly it cannot prove a model was involved. The techniques themselves were ordinary Windows administration tools, which is why any school or multi-academy trust (MAT) running Veeam and several domains should read the timeline below against its own network.

How the attack worked

How the attacker first got in is unknown. Bitdefender found no phishing email, exposed service or vulnerability it could tie to the start.

The first recorded move, on September 10 and 11, was against the backups. Veeam Backup and Replication stores the passwords it uses to reach the machines it protects, encrypted with Windows DPAPI (the Data Protection API, which ties the encryption to the server's own keys). Anyone with admin rights on the backup server can decrypt them, and Veeam documents a recovery procedure that does exactly that. The attacker ran a modified public PowerShell script that automates it on three Veeam servers, and also copied a Chrome saved-password file from a terminal server. No Veeam vulnerability was involved.

Backup servers usually hold the most privileged credentials in a school network, because they need to reach every server. With those in hand, the attacker downloaded Mimikatz on September 12 and later ran it renamed as sysmon64.exe, saved the SECURITY and SYSTEM registry hives with reg save, and created two backdoor domain admin accounts named library and svc_bkpmon, names picked to blend into a school's account list.

The step that turned one breach into an estate-wide one came on September 18. The estate's domains were separate, so a domain admin in one had no rights in another. The attacker used dnscmd to add DNS conditional forwarders, so each domain could resolve the others, then netdom to create two-way trusts between three domains. A scheduled PowerShell task pushed the backdoor account's access to about 40 machines, and Netlogon was restarted.

On September 19 the attacker ran scripts to remove the Sophos and Bitdefender endpoint agents. Tamper protection blocked them. The attacker went ahead anyway: system-state backups were deleted with wbadmin, a loader was spread to about 40 machines, and the Rust-based 3AM encryptor ran as host.exe. About 37 machines were encrypted. Bitdefender counts "nearly 50" machines reachable from the attacker's staging host, slightly more than the 47 in scope, so both figures appear in the coverage.

Data was taken too. On September 15, 40 files from a finance share were Base64-encoded into registry values, an unusual staging trick, then moved to a machine on the network that had no endpoint agent and served as the attacker's command and control host.

What points to AI, and what does not

Bitdefender's case rests on timing and style. On September 13 one command failed on a domain controller. It was rerun unchanged 41 seconds later, rerun with one change after another 49 seconds, and switched from PowerShell to a different tool 47 seconds after that. Retries landed 40 to 101 seconds apart whatever the size of the change, while moves to new tasks took several minutes.

The commands also contained errors typical of syntax recalled from memory. The attacker called the Veeam REST interface on port 9392 with Basic authentication, where Veeam's documentation uses port 9419 and OAuth2 tokens. The intrusion also left self-labelled probe files such as da_proof.txt, psexec-ok and a scheduled task called VEEAMPROBE.

Against that: Bitdefender never saw the attacker's own machine, so it cannot name a model, say whether it ran locally or in the cloud, or rule out a person copying commands between a chat window and a shell. Hackread's report stresses this was not a confirmed autonomous attack. Whoever typed the commands, the pace is what defenders have to plan for: a failed step was retried within a minute, at any hour, so an alert that waits for someone to read it the next morning arrives after the retries have worked.

Who 3AM is

Symantec first reported 3AM in September 2023, when a LockBit affiliate fell back on it after LockBit was blocked. Sophos later described 3AM affiliates flooding a target's inbox with spam, then phoning the employee from a spoofed IT department number and talking them into opening Microsoft Quick Assist. BleepingComputer reports the group has been linked to the Conti and Royal operations. In this case the entry route is unknown, but those help desk tricks are the documented ones to plan for.

What to do

For academy trusts there is an extra reason to get this right. Since the September 2025 Academy Trust Handbook, trusts must not pay cyber ransom demands, so recovery depends entirely on backups the attacker could not reach.

1. Check for this exact pattern today. Run nltest /domain_trusts or Get-ADTrust -Filter * in each domain and confirm every trust is one you created. Look for accounts named library or svc_bkpmon, and list every member of Domain Admins with its whenCreated date. Search the Security log for event ID 4706 (a new trust was created), 4720 (user account created) and 4728 (member added to a global security group such as Domain Admins).
2. Hunt for the tooling. Look for reg save of SECURITY, SYSTEM or SAM run by anything other than your backup software, for sysmon64.exe anywhere outside a real Sysinternals install, for wbadmin delete systemstatebackup, and for scheduled tasks or text files with probe names like the ones above.
3. Take the backup server out of the domain's reach. Give Veeam its own accounts with multi-factor authentication, scope its stored credentials to one domain each, and allow ports 9392, 9401 and 9419 only from named management hosts. Keep at least one copy immutable, for example a Veeam hardened Linux repository or object storage with object lock, so a domain admin cannot delete it.
4. Compare the computer list in Active Directory with your EDR (endpoint detection and response) console. The staging host here had no agent, and tamper protection is what stopped the EDR removal on the machines that did.
5. Uninstall or block Quick Assist where staff do not need it, and require help desk staff to call users back on a known number before anyone grants remote access.
6. If you find any of this, contain first. Isolate the backup servers, disable the unknown accounts and remove the trusts, then reset every credential Veeam stored, the service accounts and the krbtgt account twice in each domain. Report to Action Fraud and, for academies, to the Department for Education.

Bitdefender's own first recommendation follows from this case: keep domain admin accounts separate for each domain, and never store privileged credentials for several domains in one place. Separate domains protect a trust only while their admin accounts and backup credentials are separate too.

If you want a second pair of hands on this, our safeguarding and hardening work covers backup isolation and Active Directory tiering, and our security operations team watches for new trusts and admin accounts as they appear. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Bitdefender, BleepingComputer, Hackread, CyPro, Windows Forum, Symantec, Sophos, BleepingComputer on 3AM vishing, Azets on the Academy Trust Handbook 2025, Veeam used ports.