Your backup server is the crown jewel: why ransomware crews go after backups first

Between 10 and 19 September 2026, an attacker worked its way through a UK school estate. It did not start with the school's data. It started with the backup servers.

According to Bitdefender's report, published on 3 November and covered by BleepingComputer, an affiliate of the 3AM ransomware group used a modified public PowerShell script to read stored credentials from three Veeam backup servers and decrypt them. Nine days after that first step, about 37 machines were encrypted.

Two things make this case worth reading. The first is the order of events: backups first, encryption last. The second is a suspicion, which we label as one: Bitdefender thinks parts of the intrusion may have been driven by an AI model in an automated loop. It could not confirm that. We come back to it below. The lesson holds either way.

One point before anything else. Nothing in the report says Veeam, or any backup product, was vulnerable. The attacker already controlled the servers, and it read credentials that the backup software has to keep in order to do its job. That is the point: a backup system must hold the keys to everything it protects, so whoever reaches it gets those keys.

What happened, in order

Bitdefender describes a school estate of 47 systems, about 21 of them servers (8 domain controllers), split across several separate Active Directory domains. Ten workstations still ran Windows 10 and one domain controller ran Windows Server 2012 R2. How the attacker got in is unknown. Bitdefender says so plainly.

What it could see started on an internal machine with no Bitdefender agent on it. Every attacker action Bitdefender observed came from that unmanaged host, and Bitdefender could not examine it.

From there, according to Bitdefender:

• 10 to 11 September: backup credentials. A modified public script (Veeam-Get-Creds.ps1) read stored credentials from the Veeam databases on three backup servers and decrypted them. A Chrome credentials file was also copied from a terminal server.
• 12 to 14 September: domain admin. The attacker checked who the Domain Admins were, downloaded Mimikatz, saved registry hives from the Windows Server 2012 R2 domain controller, and tried to dump LSASS memory (the outcome is unknown). It created a backdoor account named library and added it to Domain Admins on the 14th.
• 15 September: a second backdoor and data theft. A second account, svc_bkpmon, joined Domain Admins. Bitdefender notes the names were chosen to blend into a school's account list. About 40 finance files were staged and sent to the unmanaged host.
• 18 September: three domains joined. The attacker built two-way trusts between three separate domains, then pushed a script to about 40 machines to give its backdoor account access. A trust does not grant permissions by itself, which is why that second step was needed. Bitdefender counts about 50 machines reached from the unmanaged host, slightly more than the 47 in the machine list it describes.
• 19 September: security tools, backups, encryption. Scripts tried to remove Sophos and Bitdefender protection, and anti-tampering controls blocked them. System-state backups were deleted with wbadmin delete systemstatebackup -keepVersions:0. The 3AM encryptor then ran from 05:07 to 05:33, and about 37 machines were encrypted.

Bitdefender states that nothing in the toolkit was novel: built-in Windows tools plus public tools. That is good news for defenders, because standard controls should stop standard techniques.

The suspicion: was an AI model driving?

Bitdefender calls the operation a "hybrid" and is careful about it. On 13 September, on one domain controller, a PowerShell command ran twice, byte for byte, 41 seconds apart. Forty-nine seconds later a third run changed only its last call, and 47 seconds after that the attacker gave up on PowerShell and switched to wmic. Bitdefender says the same rhythm held across nine retries. Other signs it lists: a call to Veeam's REST API on the wrong port and with the wrong authentication scheme (the documented examples use another), Bash-style syntax inside Windows PowerShell, and numbered script revisions.

Against that, Bitdefender lists the counter-indicators: a conventional encryptor, public tooling, no natural-language reasoning text in the payloads, and no decision cycle faster than about 40 to 60 seconds. Because it could not access the attacker's machine, it cannot say which model was involved, and it cannot rule out a person pasting commands and results between a shell and a chat tool. Of its three claims, it rates "a model generated the commands" as strongly supported, "an agentic loop chose each next action" as behaving like one, and "no human involved in the hands-on phase" as unsupported. It also stresses this is one case.

Treat the AI part as unconfirmed. The practical takeaway is Bitdefender's own: a tool that retries every minute will beat a defense that depends on a person correlating alerts quickly. Prevent, rather than race.

Why backups come first

A backup server is among the most useful machines on a small network for an attacker, for three reasons:

1. It holds credentials. To back up servers, it stores accounts with broad access to them. Read them out and you hold many of the keys at once.
2. It holds the way back. Delete or encrypt the backups and the victim cannot restore, so paying becomes the only way out. Here, system-state backups were deleted minutes before the encryptor finished.
3. It is often trusted. It sits inside the production domain, its traffic is expected, and nobody looks at it until a restore is needed.

Protections that exist, tied to what happened

1. Keep a copy the domain cannot delete (3-2-1-1-0). Veeam's best-practice guidance sets out the 3-2-1-1-0 rule: three copies, on two kinds of media, one off site, one copy "offline, air-gapped, or immutable", and zero errors when you verify a restore. Veeam's community write-up explains that an immutable backup cannot be changed or deleted even by a compromised admin account. Immutability is a category with several implementations: a Hardened Linux Repository (Veeam's own term), S3-compatible object storage with Object Lock, tape, or a disk you unplug. Bitdefender's advice is the same in plain terms: keep immutable recovery copies that no domain account can delete.

2. Treat the backup server as a target, not as a utility. Bitdefender recommends isolating backup servers and scoping backup accounts per domain, and never storing privileged credentials for several domains in one place. In practice: give the backup system its own accounts, do not reuse a domain admin for it, and consider keeping it out of the production domain if your design allows. Turn on MFA for the backup console where the product supports it, and keep service accounts to the minimum rights the job needs.

3. Make local admin passwords unique with Windows LAPS. Microsoft's Windows LAPS rotates each device's local administrator password and stores it for authorized admins, to counter pass-the-hash and lateral movement. It is free, built into supported Windows 11 and Windows Server (Windows Server 2019 and later with the April 2023 update), and covers Active Directory-joined machines.

4. Alert on new domain admins and new trusts. Both were central here, and Windows logs them. Microsoft's reference says event 4720 fires whenever a user account is created (on domain controllers, member servers and workstations) and that some organizations monitor every one. Event 4706 records a new trust created to a domain (on domain controllers only), and Microsoft's guidance is that any change to domain trusts should alert, with unplanned ones investigated. Add the group-membership change events for Domain Admins and Enterprise Admins. Bitdefender asks for the same: put trusts and domain-admin accounts under change control and alert on any that appear without it.

5. Watch behaviors, with free tools. Sysmon from Microsoft logs process creation with full command lines (event 1), processes opening other processes such as LSASS (event 10), registry changes (events 12 and 13) and named pipes (events 17 and 18). Sigma is an open, generic format for detection rules over such logs, and Wazuh is an open-source SIEM and XDR platform with log analysis, file integrity monitoring and a Windows agent. Bitdefender suggests alerting on credential-reading access to backup-software databases, and on reg save of the SECURITY, SYSTEM or SAM hives by anything other than a known backup or admin job.

6. Turn on tamper protection in your endpoint security. In this case it worked: both removal attempts were blocked. It only protects machines that have an agent, which leads to the next point.

7. Know every device on the network. The attacker staged from a machine with no agent. Keep an inventory, put an endpoint agent on everything that can run one, and investigate unknown hosts. Bitdefender also recommends limiting WMI, remote registry, scheduled-task creation and admin shares to known management hosts, and blocking interpreters such as portable Python on machines that never use them.

8. Test the restore. The "0" in 3-2-1-1-0 is a drill, not a setting. The Veeam community write-up calls a backup that has never been tested effectively unverified. Restore one server to an isolated place, time it, and write down who does it when the domain is gone.

A checklist for tonight

1. List where your backups live. Is at least one copy unreachable by any domain account (immutable, object-locked, or physically offline)?
2. Is the backup server in the production domain? If yes, what can a domain admin do to it?
3. Which accounts does the backup software use, and what can they reach? Remove anything beyond what the job needs.
4. Is MFA enabled on the backup console?
5. Do domain controllers audit account creation, group changes and trust creation, and does someone get an alert? (Events 4720 and 4706 are a start.)
6. Are local admin passwords unique per machine (Windows LAPS)?
7. Does every machine have an endpoint agent with tamper protection on? List the ones that do not.
8. Is a Windows 10 workstation or a Windows Server 2012 R2 machine still running? Plan its replacement.
9. Restore one system from backup this month, and time it.

The lesson

The attacker in this case did not break a backup product. It reached servers, read what they had to store, and used it. Each step has a published defense, and none of the defenses is exotic. Keep one copy that no domain account can reach, treat the backup server as one of the most sensitive machines you own, and make sure you hear about a new domain admin or trust before an attacker's work is done.

I build Sentinelleai, which watches the systems of small businesses and their IT providers for this kind of attack.

Sources: Bitdefender Business Insights, "3AM Hits European Schools: A Hybrid AI Ransomware Attack, Part Human, Part Agentic Loop" (3 Nov 2026), https://www.bitdefender.com/en-us/blog/businessinsights/3am-ransomware-hybrid-ai-attack ; BleepingComputer, "UK school estate hit by 3AM ransomware in suspected AI-assisted attack" (3 Nov 2026), https://www.bleepingcomputer.com/news/security/uk-school-estate-hit-by-3am-ransomware-in-suspected-ai-assisted-attack/ ; Veeam Best Practice Guide, https://bp.veeam.com/vbr/1_Assessment/A_Infra_Overview/infra_overview.html ; Veeam Community, "The 3-2-1-1-0 rule in practice", https://community.veeam.com/blogs-and-podcasts-57/the-3-2-1-1-0-rule-in-practice-how-to-actually-implement-it-with-veeam-12799 ; Microsoft Learn, Windows LAPS overview, https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview ; Microsoft Learn, security auditing reference for events 4706 and 4720 ; Microsoft Learn, Sysmon, https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon ; Sigma, https://github.com/SigmaHQ/sigma ; Wazuh documentation, https://documentation.wazuh.com. Facts as of 11 Nov 2026; Bitdefender's analysis may be updated.