A 3AM affiliate encrypted about 37 machines after reaching roughly 50 systems from an unmanaged host in a UK school estate. Researchers’ assessment suggests that AI-generated commands helped with parts of the intrusion. However, fully autonomous execution remains unproven. Stolen credentials, malicious administrator accounts, and newly created domain trusts helped expand access. The attacker also targeted endpoint protection and backups. For distributed organizations, the practical lesson is to control both devices and the identities connecting them. Priorities include closing endpoint coverage gaps, limiting administrative privileges, monitoring trust changes, and protecting recovery copies. Unmanaged devices must not be permitted to use valid credentials to cross network and directory boundaries.
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.
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.
Who is 3AM?
3AM, 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’s Team 2.
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.
What happened?
The observed September activity ran from September 10–19, 2026. The investigation became public on November 3.
Stage
What the investigation established
Entry and staging
The original entry method remains unknown. Observed commands originated from an internal host without the investigating provider’s endpoint agent. No initial phishing method or MFA bypass was established.
Credential theft
The attacker executed a modified Veeam-Get-Creds.ps1 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.
Continued access
Malicious domain-administrator accounts named library and svc_bkpmon provided persistence.
Expansion across schools
On September 18, the attacker used netdom and dnscmd to create two-way trusts between three domains, then distributed access changes through scheduled tasks.
Data exposure
Files from a finance share were collected and transferred to the attacker-controlled internal host.
Security interference
Anti-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, subsequently ran.
Encryption
On 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.
A domain trust enables authentication between directories; permissions still determine access to resources. The attacker also granted access through compromised administrative authority.
Feature Resource
Microsoft Defender Management with Hexnode UEM
See how Hexnode UEM simplifies Microsoft Defender management by centralizing supported Windows security settings and policy deployment.
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.
Retries occurred every 40–101 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.
Why this matters
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.
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.
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.
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.
dentity Provider Setup: What IT Teams Should Know Before Deployment
Plan your identity provider setup with key steps for authentication, testing, and ongoing access management.
How Hexnode can help
Hexnode UEM: Strengthen controls on enrolled endpoints
Hexnode UEM can help administrators review enrolled devices, monitor configured compliance requirements, and apply application restrictions on supported Windows 10/11 workstations.
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’s documented scope.
Additional capabilities can strengthen workstation security:
Patch Management: Identify missing updates and schedule available OS and supported application patches on enrolled Windows endpoints. Pair deployment with an OS support review and upgrade plan for older workstations. Maintain a separate patching and lifecycle plan for Windows Server infrastructure.
Microsoft Defender policy configuration: Centrally configure documented Windows Security settings, including preventing users from overriding exploit-protection settings. Verify real-time protection through supported Microsoft management controls. Enable Defender tamper protection separately through the Microsoft Defender portal; Hexnode cannot configure it directly.
Custom Script Deployment: Run tested PowerShell or batch scripts on supported, enrolled Windows workstations to audit local administrator membership. Hexnode’s documented administrator-listing script returns results in Action History, helping teams compare accounts against an approved baseline and investigate unexpected privileges.
For a school estate, these controls can help reduce unnecessary software and standardize endpoint policies. Test restrictions against teaching and support workflows before expanding deployment.
Pair enrollment with asset discovery and network access controls to cover devices outside management. A compliance flag alone does not prevent access to an internal Windows share or control Active Directory trusts.
Hexnode XDR: Investigate and contain endpoint threats
Hexnode XDR provides process context for investigating detected threats on supported endpoints with a functioning agent. Analysts can examine related process activity, terminate malicious processes or process trees, quarantine files, and isolate affected devices.
These actions support containment when investigation confirms malicious execution. Isolation restricts network communication while retaining the XDR management connection, helping limit further movement.
These capabilities do not establish guaranteed detection of this 3AM variant or reverse encryption. Administrators must also secure compromised accounts and review directory changes; endpoint isolation alone does not remove an attacker’s remaining access.
What security teams should do next
The school incident shows how an unmanaged staging device and compromised identities can support wider ransomware deployment. Organizations should review the access connecting their sites alongside the security coverage on individual computers.
Start with five actions:
Reconcile device inventories with network and directory records, then investigate coverage gaps. Where the UEM and identity provider support compliance integration, enforce Conditional Access policies that require a compliant device. Deny access when compliance cannot be verified or requirements are unmet, and protect on-premises paths outside that coverage separately.
Review privileged and backup accounts, remove unnecessary permissions, and rotate credentials exposed during an incident.
Monitor new administrator accounts and trust changes; restrict remote administration to approved systems. Configure alerts for netdom.exe and dnscmd.exe executions outside approved change windows. Investigate the initiating account, source device, and command-line arguments to identify unauthorized trust or DNS changes.
Validate endpoint anti-tampering settings and rehearse isolation procedures while preserving investigation evidence.
Protect offline or immutable backups and test restoration before relying on them.
Hexnode UEM can help maintain endpoint policies, while Hexnode XDR supports investigation and containment. Combine those capabilities with directory governance and segmented administration.
Assign an owner to each uncovered device and excessive access path, then verify that the fixes work across every connected site.
Try Hexnode free for 14 days
Sign up for Hexnode to strengthen endpoint controls and support threat investigation across your school estate.
I’m a technical content writer at Hexnode who loves simplifying tech. I break down complex ideas, remove the fluff, and help readers understand our product for what it actually is: simple, reliable, and built to solve real problems.
