A 3AM ransomware attack encrypted about 37 machines across a UK school estate in September 2026. The intrusion combined human direction with command patterns that researchers believe may indicate AI-assisted automation.
Bitdefender publicly disclosed the incident on 3 November 2026. Its investigation found that a 3AM affiliate stole credentials from backup servers, created concealed administrator accounts and connected previously separate Active Directory domains before deploying ransomware.
How the 3AM ransomware attack unfolded
Malicious activity was observed between 10 and 19 September 2026, although investigators could not determine how the attackers initially entered the environment. This means the incident cannot currently be linked to a particular vulnerability, phishing message or exposed remote access service.
The victim was a UK school estate spanning several Windows Active Directory domains. Secondary reporting described approximately 47 systems in scope, including servers, multiple domain controllers and some Windows 10 workstations. Around 37 machines were ultimately encrypted.
The main stages of the 3AM ransomware attack were:
-
10 to 11 September: The affiliate recovered and decrypted credentials stored on three Veeam backup servers using a modified publicly available script.
-
13 September: Telemetry recorded repeated commands, small corrections and changes of approach at intervals consistent with a possible AI agentic loop.
-
15 September: Reporting on the investigation described the staging and exfiltration of finance files.
-
18 September: The attackers established two-way trusts between three previously separate Active Directory domains.
-
19 September: The affiliate tried to remove endpoint protection, deleted system-state backups and deployed the 3AM encryptor, successfully encrypting about 37 machines.
-
3 November: Bitdefender disclosed the case, with independent reports confirming the principal findings on the same day.
Veeam credentials enabled deeper access
An important early stage of the 3AM ransomware attack involved Veeam Backup and Replication. The operator used a modified public PowerShell technique to extract and decrypt credentials from three Veeam backup servers.
No affected Veeam software version was identified, and the incident was not attributed to a new Veeam vulnerability. Instead, it demonstrates how access to a backup server or its configuration database can expose stored credentials through documented recovery procedures.
Backup credentials are particularly valuable because they may provide privileged access to production systems as well as the infrastructure needed for recovery. After obtaining these credentials, the affiliate used Mimikatz and LSASS memory dumping to collect further authentication material.
The attackers also searched logon-script folders and mapped relationships between domains. They created two backdoor domain administrator accounts named library and svc_bkpmon, names likely selected to resemble legitimate education or backup service accounts.
Separate school domains were connected
The estate had previously operated with separate Active Directory domains. On 18 September, the attacker established two-way trusts between three of them, creating routes for lateral movement between schools that had previously been logically separated.
This was a significant escalation in the 3AM ransomware attack. Domain trusts can allow authenticated users and administrators to access resources across organisational boundaries, depending on how permissions are configured.
The operator relied heavily on tools already present in Windows, including PowerShell, WMI, reg, netsh and rundll32. Public tools included Mimikatz and an Impacket-style remote execution utility comparable to WMIExec. Using legitimate administration features can make malicious activity harder to distinguish from routine technical work.
Why researchers suspect AI-assisted command loops
The unusual feature of this 3AM ransomware attack was not a fully autonomous malware system. Instead, Bitdefender assessed that a person probably selected objectives while an AI-like agent handled repetitive execution, interpreted command output and retried failed actions.
On 13 September, one command was repeated unchanged after 41 seconds. A modified call followed 49 seconds later, and the operator switched to another tool after a further 47 seconds. Across the intrusion, retries occurred at intervals of roughly 40 to 101 seconds, while changes to an entirely new task took several minutes.
Researchers also observed small command modifications and errors consistent with a model generating syntax from memory. This regular cadence differs from the more variable timing normally associated with a person manually reading output, researching an error and typing another command.
However, the evidence does not prove that an AI model directly controlled the attack. Bitdefender did not have access to the attacker’s computer and could not identify a model, establish whether it ran locally or in the cloud, or exclude the possibility that a person was copying commands between an AI service and the target environment.
The most accurate description is therefore a suspected hybrid operation. Claims that the 3AM ransomware attack was entirely autonomous go beyond the available evidence.
Encryption, data theft and current status
Before encryption, the affiliate reportedly moved 40 finance files through registry-based staging and exfiltrated them to attacker-controlled infrastructure. The use of the registry for staging allowed data to be held in a less conventional location before transfer.
On 19 September, attempts to remove endpoint security were blocked by tamper protection. The attackers nevertheless deleted system-state backups and launched the Rust-based 64-bit 3AM payload, observed as host.exe. Its command options included the -k flag used to set a victim identifier.
The encryptor succeeded on about 37 of nearly 50 reachable machines. As of 3 November 2026, the incident was confirmed as a real-world attack, but the school estate had not been publicly named and no associated leak-site listing had been reported.
No attacker IP addresses, domains or malware hashes were publicly available at that point. The .threeamtime extension and deletion of Volume Shadow Copies are associated with the wider ransomware family, but the extension used in this specific incident was not disclosed.
Why this 3AM ransomware attack matters
The case shows how an affiliate can cause widespread disruption without exploiting a new zero-day vulnerability. Existing Windows tools, recoverable backup credentials and newly created domain trusts provided the access needed to move across a multi-domain estate.
The suspected agentic component also suggests that ransomware operators may use AI to accelerate repetitive work without handing over strategic control. Faster retries and automated corrections could help less experienced affiliates sustain an intrusion once privileged access has been obtained.
Actions for Windows AD and Veeam environments
Organisations running comparable environments should concentrate on the specific access paths demonstrated in this 3AM ransomware attack:
-
Restrict administrative access to Veeam servers and configuration databases, and review Veeam hardening guidance and Security and Compliance Analyzer results.
-
Audit the use of credentials stored in backup systems, particularly accounts with domain or server administration rights.
-
Search Active Directory for unexpected accounts, including library and svc_bkpmon, and investigate unexplained changes to domain trusts.
-
Monitor PowerShell, WMI and remote execution activity for repeated commands, regular retry intervals and small iterative changes.
-
Protect endpoint security with tamper controls and ensure recovery copies cannot be deleted using the same privileged credentials as production systems.
These checks address the techniques observed in the incident and can help identify activity before an affiliate reaches the final encryption stage.
Originally reported by cybersecuritynews.com.
