{"id":2517,"date":"2026-11-04T17:03:27","date_gmt":"2026-11-04T11:33:27","guid":{"rendered":"https:\/\/www.hexnode.com\/threat-watch\/?p=2517"},"modified":"2026-11-05T17:48:43","modified_gmt":"2026-11-05T12:18:43","slug":"3am-ransomware-school-ai-endpoint-segmentation","status":"publish","type":"post","link":"https:\/\/www.hexnode.com\/threat-watch\/3am-ransomware-school-ai-endpoint-segmentation\/","title":{"rendered":"3AM Ransomware Attack on UK Schools: Lessons in AI Assistance, Endpoint Visibility, and Identity Security"},"content":{"rendered":"

Keeping track of every computer across several sites is difficult. In September 2026, a 3AM ransomware affiliate operated from an unmanaged host in a UK school estate and expanded access using compromised identities and Windows tools.<\/p>\n

While suspected AI-assisted execution highlights evolving adversary tactics, the immediate lesson is basic visibility and access control. The staging host lacked any endpoint agent, leaving security teams without agent-based telemetry from that device. A device outside security monitoring can become a base for activity across connected sites.<\/p>\n \t\t

\r\n \t\t\tWho is 3AM?<\/span> \t\t\t \t\t\t\t

\r\n \t\t\t\t\t3AM, also known as ThreeAM, is a ransomware operation whose malware encrypts files and supports financial extortion. Its encryptor uses Rust, a programming language. In September 2023, Symantec documented an affiliate using 3AM as a fallback encryptor after LockBit was blocked on the target network. Intrinsec researchers later assessed that 3AM likely had ties to Royal, which they linked to former members of Conti\u2019s Team 2.<\/p>\n

Its known victims span multiple industries, so schools should not treat it as an education-only threat. Observed activity includes reconnaissance, creating accounts for continued access, stealing files, and attempting to disrupt security and backup services. The operation also maintains a data leak site. Together, encryption and threatened disclosure can pressure victims through both operational disruption and exposure of sensitive information. \t\t\t\t<\/p>\r\n \t\t\t \t\t\t\r\n \t\t<\/div>\r\n \t\t\n

What happened?<\/h2>\n

The observed September activity ran from September 10\u201319, 2026. The investigation became public on November 3.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Stage<\/th>\nWhat the investigation established<\/th>\n<\/tr>\n<\/thead>\n
Entry and staging<\/td>\nThe original entry method remains unknown. Observed commands originated from an internal host without the investigating provider\u2019s endpoint agent. No initial phishing method or MFA bypass was established.<\/td>\n<\/tr>\n
Credential theft<\/td>\nThe attacker executed a modified Veeam-Get-Creds.ps1<\/code> script to extract credentials from three Veeam backup servers and decrypt them using Windows DPAPI (Data Protection API). Additional credential-dumping activity included Mimikatz masquerading as sysmon64.exe<\/code>.<\/td>\n<\/tr>\n
Continued access<\/td>\nMalicious domain-administrator accounts named library<\/code> and svc_bkpmon<\/code> provided persistence.<\/td>\n<\/tr>\n
Expansion across schools<\/td>\nOn September 18, the attacker used netdom<\/code> and dnscmd<\/code> to create two-way trusts between three domains, then distributed access changes through scheduled tasks.<\/td>\n<\/tr>\n
Data exposure<\/td>\nFiles from a finance share were collected and transferred to the attacker-controlled internal host.<\/td>\n<\/tr>\n
Security interference<\/td>\nAnti-tampering controls blocked attempts to uninstall Sophos and Bitdefender agents. However, the attacker deployed a loader through scheduled tasks, and the ransomware payload, host.exe<\/code>, subsequently ran.<\/td>\n<\/tr>\n
Encryption<\/td>\nOn September 19, the Rust-based encryptor host.exe ran and invoked wbadmin delete systemstatebackup -keepVersions:0 -quiet to delete system-state backups during execution. About 37 of roughly 50 reached machines were encrypted.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A domain trust enables authentication between directories; permissions still determine access to resources. The attacker also granted access through compromised administrative authority.
\n

\n
\n
\n
\n \"Microsoft-Defender-Management\"\n <\/div>\n <\/div>\n
\n
\n Feature Resource \n <\/h5>\n

\n Microsoft Defender Management with Hexnode UEM\n <\/h4>\n

\n See how Hexnode UEM simplifies Microsoft Defender management by centralizing supported Windows security settings and policy deployment.\n <\/p>\n \n Microsoft Defender Management with Hexnode UEM\n \n \n \n \n <\/g>\n <\/svg>\n\n <\/a>\n <\/div>\n <\/div>\n <\/section><\/p>\n

What the evidence shows regarding AI assistance<\/h3>\n

Investigators found Unix-style syntax, such as 2>\/dev\/null, in Windows commands. A Veeam API query also used port 9392 and HTTP Basic authentication instead of the documented port 9419 and OAuth2. Investigators considered these errors signs of potentially AI-generated instructions.<\/p>\n

Retries occurred every 40\u2013101 seconds, regardless of the complexity of the changes, while pauses between tasks lasted several minutes. This contrast suggested a human choosing tasks and a possible automated loop revising commands, although it did not prove that division of work. However, investigators could not inspect the staging host. A person copying commands between an AI tool and a terminal remains a possible explanation.<\/p>\n

Why this matters<\/h2>\n

A working password does not establish that the device using it is safe. Likewise, separate directories offer limited protection when compromised administrators can alter their relationships and permissions.<\/p>\n

For schools and other distributed organizations, this creates a practical exposure: access intended for maintenance can also support movement between sites. Legitimate administration tools complicate detection because their names alone do not distinguish routine work from abuse.<\/p>\n

A Zero Trust approach makes device posture part of the access decision. Policies protecting directory services and backup infrastructure should deny administrative access from unmanaged, unverified, or non-compliant devices, even when valid administrative credentials are presented. Device-based conditional access can enforce these requirements on supported access paths. On-premises paths outside that coverage need equivalent restrictions through approved administrative workstations and network controls that prevent bypass.<\/p>\n

Security teams therefore need context: which account acted, from which device, against which system, and whether the action was authorized. Device monitoring, restricted administrative access, and network segmentation address different parts of that problem. Protected backups support recovery if preventive controls fail.
\n

<\/div>

dentity Provider Setup: What IT Teams Should Know Before Deployment<\/h4>

Plan your identity provider setup with key steps for authentication, testing, and ongoing access management.<\/p><\/div><\/div><\/div><\/a><\/div><\/div><\/div><\/p>\n

How Hexnode can help<\/h2>\n

Hexnode UEM: Strengthen controls on enrolled endpoints<\/h3>\n

Hexnode UEM<\/a> can help administrators review enrolled devices, monitor configured compliance requirements, and apply application restrictions on supported Windows 10\/11 workstations.<\/p>\n

Application Compliance identifies devices with applications that violate the configured policy. It does not block those applications itself. For enforcement, administrators can configure separate Blocklist\/Allowlist policies using publisher or file-path rules. These policies support Windows 10\/11 editions except Home and cover executables and packaged apps. Carefully configured rules can help block unauthorized executable loaders or credential dumpers on workstations. Windows Server and script-file enforcement fall outside this policy\u2019s documented scope.<\/p>\n

Additional capabilities can strengthen workstation security:<\/p>\n