Security

3AM Ransomware Attack on UK Schools: AI Evidence, Timeline & Detection Guide

3AM Ransomware Hits UK Schools

In September 2026, attackers breached a UK school IT environment, stole credentials from backup servers, crossed between Active Directory domains and deployed 3AM ransomware. Around 50 machines were reached during the intrusion. Approximately 37 were encrypted.

The attack drew attention for another reason. Investigators at Bitdefender found command sequences that looked as though they had been generated and revised with help from artificial intelligence. Some commands were repeated at nearly regular intervals. Others contained syntax mistakes that a language model might make when switching between Linux and Windows conventions.

Bitdefender’s November 3, 2026 investigation treats AI involvement as a strongly supported explanation for the command patterns, while acknowledging that the researchers could not see what ran on the attacker’s own machine. A human copying commands from an AI chatbot could produce some of the same evidence.

The documented Windows activity is useful regardless of who or what generated the commands. It gives administrators concrete things to hunt for, including unauthorized domain trusts, new privileged accounts, registry hive exports, suspicious backup-server access and remote scheduled tasks.

What happened in the 3AM ransomware attack?

Bitdefender reconstructed the main intrusion between September 10 and September 19, 2026. The initial access method is unknown. The attacker worked from an unmanaged Windows machine and used a mixture of Windows administrative tools, public utilities and ransomware components to expand across the environment.

The incident in numbers
~50
Machines reached
~37
Machines encrypted
3
AD domains connected by new trusts
Estimated proportion of reached machines encrypted
37 of approximately 50, or 74%. This does not represent the entire school estate.

A separate list used during the operation contained 47 systems, including about 21 servers, eight of which were domain controllers, and ten Windows 10 workstations. One domain controller used Windows Server 2012 R2. That 47-system list and the approximately 50 machines reached are different counts.

The identity of the affected school estate was withheld in the report. The researchers also could not establish how the original attacker-controlled machine was compromised.

What is 3AM ransomware?

3AM, also called ThreeAM, is a ransomware family used in a ransomware-as-a-service operation. Affiliates carry out intrusions and deploy ransomware supplied by an operator or development group. As with other such operations, the people behind a particular intrusion may differ from those who maintain the encryptor.

ThreeAM became publicly known in 2023 after security researchers described its use as a fallback when a LockBit ransomware attempt was blocked. Sources differ on the earliest observed date: Bitdefender refers to tracking from February 2023, while other public reporting emphasizes September 2023. The UK school incident involved a Rust-based 3AM encryptor.

The suspected AI assistance concerned the intrusion workflow. Bitdefender did not determine that AI wrote the encryptor.

How the intrusion unfolded, September 10 to 19

Observed attack timeline
September 10 to 11
Backup credentials targeted
Stored credentials extracted from three Veeam backup servers; a Chrome credential database was also copied.
September 12 to 13
Network reconnaissance
SMB, RDP and WinRM access tested. Attackers inspected domain trusts, administrator access and SYSVOL scripts.
September 14 to 15
Credential dumping and persistence
Registry hives exported, credential-dumping tools used and unauthorized administrator accounts created.
September 15
Data collected
Finance files staged in registry values and transferred using compromised infrastructure.
September 18
Domain boundaries crossed
Two-way domain trusts and DNS forwarding changes made between three previously separate domains.
September 19
Ransomware deployed
Security-removal attempts were made, and approximately 37 machines were encrypted.
Dates are from Bitdefender’s UTC-based reconstruction. The original entry point remains unknown.

Backup credential theft came first

The first recorded September activity focused on Veeam backup servers. The attacker used a modified public PowerShell credential extraction script, referred to as Veeam-Get-Creds.ps1, against three servers. The script recovered stored credential material and used Windows Data Protection API (DPAPI) functionality in the decryption process.

Backup systems often need credentials for multiple protected machines. Once those credentials are exposed, an intruder may gain access far beyond the backup server itself. The attacker also copied Chrome’s Login Data database from a terminal server. Copying that database does not establish that every stored browser password was successfully decrypted.

Reconnaissance relied heavily on normal Windows tools

Over the next few days, the attacker checked SMB, Remote Desktop and WinRM access, inspected domain relationships and searched SYSVOL scripts for references to other schools. The observed tooling included PowerShell, WMI, nltest, reg, netsh, rundll32 and public remote-execution utilities. Portable Python and Mimikatz also appeared in the investigation.

This kind of activity is often called living off the land, or LOTL. A command may use a legitimate operating-system component while serving a malicious purpose. That is why administrators need process history, account details and network context rather than alerts based only on a tool’s name.

Credential dumping and backdoor accounts followed

On September 14 and 15, the attacker saved sensitive registry hives and attempted to collect credentials from LSASS, the Windows process that handles important authentication functions. A renamed Mimikatz executable appeared as sysmon64.exe. The name alone would not distinguish it from an unrelated legitimate file; the executable’s content and behavior matter.

The attacker also established two administrator accounts named library and svc_bkpmon. Both could blend into an ordinary IT account list, especially in a school environment. Reviewing newly created accounts and changes to privileged groups is more reliable than looking for suspicious-sounding names.

Finance files were staged in the Windows registry

Bitdefender documented the collection of 40 files from a finance share. The attacker encoded the data into registry values under a path resembling HKLM\SOFTWARE\VC31. Values included FIN001 through FIN040, plus a FINCOUNT counter.

Registry-based data staging
Finance share
40 selected files
Windows registry storage
HKLM\SOFTWARE\VC31
FIN001 … FIN040, FINCOUNT
Transfer through compromised infrastructure
Administrative shares and HTTP communication were observed in the wider collection workflow.
Simplified sequence, not a packet-level reconstruction.

Encoded registry values can be overlooked when monitoring focuses on new files and network transfers. Administrators investigating suspicious PowerShell activity should consider associated registry writes, particularly large values under unusual application keys.

New domain trusts extended the attacker’s reach

On September 18, the attacker used netdom to establish two-way trusts between three previously separate Active Directory domains. The operation also involved conditional DNS forwarders configured with dnscmd and troubleshooting of the trust’s secure channel.

A trust provides a route for cross-domain authentication, subject to permissions and trust settings. It does not automatically grant every account access to every resource. The attacker followed the trust changes with other permission and remote-execution activity, extending privileged access across the connected environments.

How the domain boundaries changed
Before: three distinct Active Directory domains
Domain A
Domain B
Domain C

↓ New two-way trusts and DNS changes ↓
Cross-domain authentication paths
Attacker-controlled accounts could be used in subsequent access attempts.
Broader ransomware deployment
Permissions and remote execution expanded across multiple machines.
Conceptual illustration. The original domain names and exact topology were withheld.

New trust creation can be a useful detection point because it is relatively uncommon in a stable environment. In this case, the attacker spent hours making the cross-domain arrangement work. A prompt alert on an unexpected trust might have given defenders an opportunity to investigate before encryption began.

Ransomware deployment came on September 19

Before deployment, the attacker tried to uninstall or interfere with endpoint security software. Bitdefender reports that anti-tampering controls blocked some of these attempts. The attacker nonetheless distributed its loader and encrypted approximately 37 machines with 3AM ransomware.

The intrusion lasted nine days in the observed telemetry. There is no evidence that fast command retries by themselves defeated a detection system. The documented compromise suggests that monitoring of credential theft, administrator changes and new domain trusts would have been especially useful.

Why researchers suspect AI assistance

Bitdefender studied the command sequence rather than observing a model directly. Its assessment rests on several patterns that are unusual together, though each has other possible explanations.

Commands were retried after similar delays

In one September 13 sequence, an unchanged PowerShell command was run again after 41 seconds. Another attempt came 49 seconds later with one call changed. After another 47 seconds, the operator switched to wmic. Across a wider group of retries, the recorded gaps ranged from 40 to 101 seconds.

A recorded command retry sequence
First attempt
PowerShell
Original command
41 seconds later
Same command
No change
49 seconds later
Modified
One call changed
47 seconds later
WMIC
Different tool
The recorded delays are upper bounds: telemetry might not include every attempt.

Automated systems often work by submitting a command, reading the result and trying a revision. Similar timing despite different amounts of rewriting is consistent with that process. A person following an orderly manual routine, or copying commands from a chatbot, could leave a similar trace.

Some commands combined incompatible conventions

One Veeam REST API request used port 9392 with Basic authentication, while the API documentation examined in the investigation used OAuth2 and a REST API port such as 9419. API ports and compatibility options vary by Veeam product and release; the problem was the mismatch between the request and the interface the attacker appeared to be targeting. The report did not verify a successful request.

Other commands contained Unix-style 2>/dev/null redirection or Bash-like escapes in Windows command contexts. A malformed Windows for /f expression also prevented one LSASS-related attempt from getting the intended process identifier.

These errors are compatible with language-model-generated commands that were insufficiently checked for the target environment. They can also come from human operators adapting scripts from the wrong shell.

The operator repeatedly tested and revised scripts

The investigation recorded test files including da_proof.txt, psexec-ok and wmi_test.txt, a scheduled task named VEEAMPROBE, and revised scripts such as av_remove.ps1, av_remove2.ps1 and av_remove3.ps1. Together, these suggest an iterative workflow: execute, inspect, adjust and repeat.

Possible human and AI-assisted workflow
Human selects an objective
For example, check access to a remote server
Possible AI command generation
Command proposed or revised
Windows tools run the command
PowerShell, WMI or another utility
Output or error is inspected
A failed step may lead to another command
This is a hypothesis consistent with the evidence, not an observed diagram of the attacker’s software.

Bitdefender rates model-generated commands as strongly supported. It says the choice of actions behaved like an agentic loop, but could not rule out a person copying commands between a shell and chat window. Fully autonomous execution without human involvement is unsupported, and the model, provider and execution setup remain unidentified.

How to detect similar activity in a Windows network

Administrators can monitor the actions from the attack without trying to decide whether a person or an AI system wrote the commands. The highest-priority checks are changes to domain trusts and privileged accounts, followed by registry hive exports, remote execution and backup-server access.

Step 1: Alert on unexpected domain trust creation

Windows Security Event ID 4706 records the creation of a domain trust. On a domain controller with the relevant audit policy enabled, this read-only PowerShell query searches locally retained events from the last 30 days:

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4706
    StartTime = (Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Id, MachineName, Message

Run it with appropriate privileges on each domain controller or query centrally collected logs. If no events appear, check the auditing policy and retention before concluding there were no trust changes. Compare any new trust with approved configuration changes, the account that initiated it and the trusted domain’s identity.

Microsoft documents the event fields in its Event 4706 reference.

Step 2: Hunt for exports of sensitive registry hives

Unexpected use of reg save against the SAM, SECURITY or SYSTEM hives deserves investigation, especially on domain controllers or alongside other credential-access events.

For Microsoft Defender for Endpoint environments with the appropriate device telemetry, the following KQL query searches for potentially relevant commands:

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "reg.exe"
| where ProcessCommandLine contains "save"
| where ProcessCommandLine contains "\\SAM"
    or ProcessCommandLine contains "\\SECURITY"
    or ProcessCommandLine contains "\\SYSTEM"
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

This is a hunt query, not a validated production alert. It catches common command-line forms and can miss alternate methods, aliases or differently formatted paths. Investigate legitimate backup and maintenance activity before classifying a result as malicious. Test the syntax and field coverage in your own Defender tenant.

Step 3: Review privileged account changes

Look for newly created accounts, especially those quickly added to privileged security groups. The following event IDs are useful in an Active Directory environment:

Event Recorded activity What to check
4720 User account created Unexpected service or administrator accounts
4728 Member added to a global security group Changes to Domain Admins or similar groups
4756 Member added to a universal security group Changes to privileged universal groups
4706 Domain trust created Unapproved cross-domain relationships
4698 Scheduled task created Unfamiliar tasks or remote execution

These event IDs depend on auditing configuration, and the group events shown do not cover every group scope or membership-change scenario. Centralized collection helps when attackers can clear local logs or move between several domain controllers.

Step 4: Review scheduled tasks and remote execution

The attack used remote execution and test tasks, including VEEAMPROBE. Security Event ID 4698 may help identify new scheduled tasks if task-creation auditing is configured:

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4698
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, MachineName, Message

Check task actions, the creating account, execution privileges and remote-management activity around the same time. Task Scheduler Operational logs and EDR process telemetry may provide additional detail.

Step 5: Check registry staging artifacts

In an environment where related activity is suspected, search for the registry location HKLM\SOFTWARE\VC31 and values following the FIN001 to FIN040 pattern. Treat these as case-specific clues. Attackers can rename a path or use an entirely different staging technique.

Broader monitoring should focus on unusual large registry writes by scripting tools and whether the same host later transfers data. Sysmon and endpoint telemetry can support those searches if configured to collect the relevant activity.

Step 6: Examine Veeam access and backup integrity

Backup servers deserve separate access controls and monitoring. Review administrator permissions, unusual database access, unexpected PowerShell or WMI execution, and changes to the accounts used for backup operations.

  • Use dedicated backup accounts with permissions limited to their required tasks.
  • Restrict network access to backup management interfaces and credential stores.
  • Maintain immutable, offline or otherwise isolated backup copies as appropriate for the platform.
  • Test restoration of critical servers and Active Directory services.
  • Investigate unexpected attempts to delete system-state backups or recovery data.

Veeam interfaces, credential handling and REST API ports differ by version. Consult the documentation for the release actually deployed.

An isolated command may have a legitimate explanation. A backup-server credential access event followed by an administrator account creation and a new domain trust gives investigators a more specific sequence to examine.

An example of correlated monitoring
Sensitive credential access
Unexpected backup credential reads or security hive exports
Privileged identity changes
New account and privileged-group membership
Trust or remote-execution activity
Unapproved trust, remote task or administrative-share access
Prioritize an incident investigation
Check whether the events involve the same accounts, devices and time window.
Illustrative alert logic. This is not a production-tested SIEM rule.

3AM ransomware indicators to investigate

Bitdefender published a CSV of indicators associated with the 3AM investigation. Use that file for the published hashes and other exact indicators. The names below are useful for targeted hunting but cannot reliably identify the ransomware on their own.

Artifact Recorded use
VEEAMPROBE Scheduled task used in testing
psexec-ok, da_proof.txt Execution and privilege-check artifacts
grant_lib.ps1 Access propagation script
av_remove.ps1 and numbered revisions Security-removal attempts
sysmon64.exe Name used to disguise a credential-dumping tool
HKLM\SOFTWARE\VC31 Registry data staging
library, svc_bkpmon Unauthorized administrator account names
ADMIN$\__<timestamp> Pattern associated with remote command output

Names like library and sysmon64.exe can also appear in benign contexts. Check hashes, parent processes, affected accounts and nearby events before escalating a match.

How to reduce the risk in schools and other Windows environments

Schools often rely on shared IT administration across sites. That makes it especially important to know which accounts, trusts and management tools can cross from one domain or network to another.

  • Review domain trusts. Document the purpose and owner of each trust. Alert on new trusts and investigate changes without an approved request.
  • Separate privileged access. Avoid reusing highly privileged credentials across independent domains. Restrict membership of administrator groups and protect management workstations.
  • Secure remote administration. Limit SMB, WMI, WinRM and RDP to systems and accounts that require them.
  • Protect backups independently. Use isolated backup access and recovery copies that compromised production credentials cannot easily alter.
  • Cover unmanaged devices. Inventory machines with administrative network reach and investigate systems missing expected endpoint protection.
  • Collect logs centrally. Retain domain controller, task scheduler, backup-system and endpoint events long enough to reconstruct multi-day incidents.
  • Test recovery. Restore representative systems and Active Directory services during planned exercises, not for the first time during a real incident.

UK education organizations can consult the Department for Education’s cyber security core standard for broader requirements and recommended controls.

What to do if you find similar activity

An unexplained trust creation or evidence of credential dumping on a domain controller deserves prompt investigation. If multiple related events appear, involve the organization’s incident-response lead before making disruptive configuration changes.

Incident response checklist
1. Validate the event
Identify the account, device, activity and any approved change record.
2. Contain active access
Isolate affected hosts or restrict compromised credentials using the response plan.
3. Preserve evidence
Retain endpoint telemetry, domain controller logs, task history and relevant forensic data.
4. Check backup and identity exposure
Review privileged groups, trusts, stored backup credentials and possible data access.
5. Recover from verified clean systems
Remove unauthorized access paths, rotate exposed credentials and test restored services.
Coordinate containment with authorized administrators or incident responders. Removing a trust without assessing dependencies can interrupt legitimate authentication.

Where staff or student information may have been exposed, assess applicable reporting and notification requirements. A forensic review should determine whether data theft occurred as well as whether encryption succeeded.

Was this the first AI-operated ransomware attack?

Bitdefender described the case as the first of this kind that its researchers had documented in Europe. Earlier investigations had already described agentic ransomware activity elsewhere.

For example, Sysdig’s JadePuffer research examined automated database extortion in July 2026. The Cloud Security Alliance also published a research note on that case. The evidence and target environments differ, so the incidents should not be treated as a single campaign.

No connection has been established between the 3AM intrusion investigated by Bitdefender and the separately reported Bristol schools cyber incident.

In early November 2026, BBC News reported that more than 320,000 files from 39 schools had appeared online after a cyber incident affecting Bristol City Council’s Trading with Schools services. The victim details, investigative record and attribution have not been shown to match the 3AM case.

Frequently asked questions

Did AI carry out the attack on UK schools?

Bitdefender found strong evidence that AI may have generated some intrusion commands. The researchers could not prove that an autonomous agent chose and executed the whole attack. A human operator remained a plausible part of the command loop.

How many systems did the ransomware encrypt?

Approximately 37 systems were encrypted out of around 50 machines reached. A separate list of 47 machines appeared in the investigation.

Which UK schools were affected?

Bitdefender did not identify the affected school estate publicly. Its technical report sanitized victim-specific details.

How did the attackers initially enter the network?

The initial access method remains unknown. The researchers reconstructed the later intrusion from available telemetry.

What is the difference between AI-assisted and agentic ransomware activity?

AI-assisted activity can involve a person using a model to write or troubleshoot commands. Agentic activity involves software choosing further actions based on the outcome of earlier steps. Endpoint logs alone may not establish which workflow was used.

Can antivirus or EDR prevent this type of attack?

Endpoint protection can interrupt individual stages. In this incident, anti-tampering features blocked some removal attempts, yet ransomware encryption still occurred. Privileged-access controls, domain monitoring and protected backups remain necessary.

Which Windows event should administrators check first?

Event ID 4706 is particularly relevant because it records domain trust creation. Its usefulness depends on audit configuration and whether the organization has a clear baseline of expected trust relationships.

What administrators can learn from this case

The school intrusion ran across several days and involved many familiar Windows tools. Credential access, unauthorized administrator accounts and the creation of new domain trusts were all observable activities before the ransomware was deployed.

AI assistance remains an explanation for the command behavior rather than a confirmed detail of the attacker’s setup. For defenders, the practical work is unchanged: protect administrative access, monitor sensitive domain changes, examine backup-server activity and test recovery procedures. Those controls address the techniques that caused damage in this case, whether the next attacker types commands manually or has a model help generate them.

Sources and further reading

Leave a Comment