Bitdefender calls a 3AM attack on a UK school estate hybrid: model like commands, a human not ruled out

Four runs in 137 seconds: what Bitdefender's own log supports about the AI in this attack

On 13 September 2026 Bitdefender's log shows one reconnaissance script run four times on a domain controller, at 02:50:18, then 41 seconds later, then 49 seconds after that, then 47 seconds after that. The four runs span 137 seconds (derived: 41 plus 49 plus 47). The fourth run abandoned PowerShell for the older wmic interface. Bitdefender reads that rhythm as a program feeding each result to a language model and retrying. Its post of 3 November 2026, read in full here from 15:50 UTC the same day, also says in its own words that a person pasting between a shell and a chat window could produce the same rhythm.

That is the whole difficulty with the headline. Bitdefender says a 3AM (ThreeAM) ransomware affiliate breached a school estate in the UK and that part of the hands on activity looks like a human operator and part looks like an agentic loop. It calls the case a hybrid. It does not say "AI ransomware", and it supports the three claims folded inside that phrase to very different degrees. It could not reach the machine the attacker worked from, so it "cannot document anything about the language model itself": not which model, not local or remote, not whether a person was in the loop.

Two more things before the detail. Bitdefender sells security products, its managed detection and response team saw this intrusion, and the post says anti tampering controls, citing Bitdefender's own documentation, blocked the attacker's attempt to remove its agents. That is a vendor describing a case it handled, and the post is candid that it is "one case, an anecdote, and not a trend". And the secondary press, including BleepingComputer, rests on this one post: every fact below comes from the Bitdefender page unless it says otherwise.

Three claims inside "AI ransomware", and the status Bitdefender gives each

Bitdefender first sorts AI attacks into three kinds. In an AI generated attack a model writes the malware itself, often in bulk; it points to its earlier APT36 research and the word vibeware. In an AI assisted attack human engineers build the tools and use AI to speed up the work. In an AI operated attack "AI works the intrusion itself": it chooses and writes the commands, reads the results and adjusts. The first two describe how malware is made; the third describes who, or what, is running the attack. Bitdefender says this case "does not fit a single bucket" and calls it a hybrid: some parts show a human operator at the keyboard, others behave like an AI agent.

Then comes the table that matters, reproduced here in Bitdefender's own status wording and nothing stronger. Reports of AI ransomware, it says, blur three separate claims.

Zoom

The friendly name check has four parts. First, the headline says "European Schools"; the body says the target is "a school estate in the UK". Second, "AI ransomware" is press shorthand; the post's own word is hybrid, and it warns the label blurs three claims. Third, BleepingComputer's headline calls it a "suspected AI-assisted attack", but by Bitdefender's definitions AI assisted means humans building tools with AI help, while the post itself calls this case a hybrid that fits no single bucket. Fourth, "agentic loop" is a reading of behaviour, and the post says so: "Our reading, which is interpretation and not a finding". It presents the hybrid reading "as the working model defenders should plan around, not as an established fact".

What in the commands looks like a model, and what points the other way

Bitdefender takes claim one alone in its own section and says the evidence is presented in order of strength. This briefing does not reproduce the commands; it records what Bitdefender says they show, in words.

One check of the strongest signal can be made independently. Bitdefender links Veeam's REST reference, and the archived Veeam Backup and Replication 12 page it points to, read here, requests an access token through an OAuth style token path and shows its examples on port 9419. Bitdefender says the attacker's call used port 9392 with HTTP Basic authentication, and that it could not confirm whether that resource ever returns passwords at all. The Veeam page is an archived version of the documentation, and the post's description of the vendor's documentation matches it. A wrong port and a wrong login method are what Bitdefender expects from recall rather than a manual. They are not proof of a model, and the post does not say they are.

Bitdefender also measured style across 60 distinct hands on steps. Command length splits into two regimes: sessions on 13 and 15 September run long, with a median of 365 to 493 characters, bundling reconnaissance and error handling into single commands; sessions on 12 and 14 September run short, 46 to 86 characters, one tool per command. On the same task, domain discovery, the median was 683 characters on 13 September against 80 on 14 September. The post says this shows two authoring styles and does not show two authors, because the model style errors appear in both regimes.

The retry evidence: what 41, 49 and 47 seconds do and do not prove

The second claim, the loop, rests on timing. On 13 September the attacker ran a PowerShell command, re-ran it unchanged 41 seconds later, changed a single call 49 seconds after that, and 47 seconds later switched to wmic. Bitdefender's point is that the complete rewrite arrived as fast as the minor changes before it, "and a person writing it by hand would be expected to take noticeably longer". Across nine retries the delay before the next attempt ran from 40 to 101 seconds whatever the size of the change, while moving on to a new task took minutes. Before the retry sequence on 13 September the commands sat two to sixteen minutes apart; the gaps between tasks that day were 5, 2, 14, 16 and 3 minutes, which sum to 40 minutes (derived).

Zoom

What this establishes, in Bitdefender's words: the retries "arrive at a steady pace whatever the size of the change", which is how a loop that waits on a model behaves. What it does not: a person pasting output between a shell and a chat window "could produce the same rhythm", and Bitdefender leaves the mechanism open. The log holds only detected events, so some attempts may be missing and every gap is an upper bound. On the third claim, the gaps of minutes between tasks are "the pace of a person reading each result and choosing what to do next", but "a model that simply takes longer to plan a new task could look similar". Bitdefender adds that nothing in the telemetry rules either reading out.

A note on the number 101. It appears twice in the post for unrelated things: the top of the retry delay range, and the pace of a scheduled fan out of a loader to about 40 machines, at about 101 seconds per machine. The second is a deterministic job, not a decision, and Bitdefender says so. Do not read the two as one measurement. The post also says "40 to 100 seconds" in its conclusion and BleepingComputer repeats that; the body says 101.

Zoom

The intrusion by phase, with the dates and what Bitdefender cannot see

From the first recorded credential theft on 10 September (23:50:04 UTC) to the encryptor starting on 19 September (05:07:04 UTC) is 8 days, 5 hours and 17 minutes (derived). The calendar span, 10 to 19 September, is nine days (derived). By the time of Bitdefender's post, the first of those events was 54 days old and the encryption 45 days old (derived). Bitdefender says all times are UTC and maps each observed behaviour to a MITRE ATT&CK technique.

Zoom

Zoom

Notice the counts do not sit tidily together, and the post does not reconcile them. The machine list held 47 systems. About 50 machines were reached from the unmanaged host. About 40 machines received the access push and the loader. About 37 were encrypted "the next morning". Against 47, 37 is 78.7 per cent; against 50 it is 74 per cent (both derived). BleepingComputer's summary, "around 37 of nearly 50 machines reached", is a fair reading of the post. The encryptor window, 05:07 to 05:33, is 26 minutes (derived); at the 12 to 13 seconds per machine the post gives, 37 machines would take under 8 minutes (derived). The post does not explain the difference. Bitdefender also says the encryption across domains "suggests the trusts functioned, though we treat it as suggestive rather than as proof".

A last limit on the picture: Bitdefender's own figure notes about three days with no events logged between the 15 September staging and the 18 September trust build (derived from the printed log: 3 days 10 hours between the last printed 15 September command at 05:32:56 and the 15:39 start of the 18 September trust build). The log holds only detected events. Whether the attacker was quiet, away, or on machines Bitdefender could not see is not stated.

The school estate: why the attacker went looking for other schools, and what is conventional

The target, Bitdefender says, is a school estate in the UK. Its machine list held 47 systems: about 21 servers, 8 of them domain controllers; 10 workstations "still on Windows 10, which left support in October 2025"; one domain controller on the older Windows Server 2012 R2; and the rest on Windows 11. That is all the post says about those 10 workstations and the 2012 R2 controller: it records them, and draws no conclusion about whether they were the way in or what happened to them. Initial access is unknown.

What was specific to the sector was the reconnaissance. From a domain controller the attacker listed the trust relationships between domains and searched SYSVOL, the shared folder where Active Directory keeps logon scripts that any domain user can read, for the names and subnets of other schools. The two backdoor domain admin accounts it created, library and svc_bkpmon, carried names chosen to blend into a school's account list. The estate began as several separate Active Directory domains that were not connected. The attacker joined three of them with two way trusts in a window of about three hours (derived: 15:39 to 18:37 is 2 hours 58 minutes), and the post's TL;DR says it used ordinary Windows tools to build the trusts and "reach other schools".

Why it matters, in this site's reading rather than Bitdefender's: separate domains look like separation, and a school estate that grew by adding schools can have many. Bitdefender's explanation of the weak point is plain. Creating a trust takes administrative rights in each domain involved, and after the backup server credentials were taken the attacker created the library account in at least three domains and used it to build the trusts. A boundary between domains held only as long as nobody held administrator rights on both sides, and the backup layer was where those rights were stored. Note too that the post says the trust does not grant permissions by itself, which is why the attacker followed with an explicit access push.

What is conventional, which Bitdefender says is "most of the operation": the ransomware as a service model, in which a core group develops the encryptor and leases it to affiliates who run the intrusions and share the proceeds; the affiliate playbook of remote execution tools, credential theft from backup software and endpoints, rogue domain administrators and trusts, and removal of security agents before encryption; a Rust based encryptor; and a mid sized public sector target. The encryptor build and its command line pattern match earlier public ThreeAM analyses. WatchGuard's ThreeAM tracker page lists the group as first seen in February 2023, and, read here, 56 known victims in its table, of which by this site's count 3 are listed as Education and 1 as Government (derived; the newest entry on the page I read is dated 13 February 2025, so it does not cover this case). This site's earlier briefing on Arctic Wolf's Teams external chat incidents mentions 3AM among earlier groups that used the same intrusion route, and its briefing on a Sophos report about AI agents doing the network work in a ransomware case is a different group and a different claim, which is useful to read beside this one.

On scale, Bitdefender is restrained. Vibeware, it says, accounts for only about 0.07 per cent of the malware samples it collects each month, and most intrusions it investigates still look as they did before language models. It calls this the first case of its kind it has investigated, and the first it has documented in Europe. It also forecasts, as a vendor, that hybrid attacks like this one "become more common in 2027"; that is a prediction, not an observation.

What the report does not establish

A ranked checklist, with who says what

The first four items follow Bitdefender's own advice in its conclusion and its "Defender action" lines. Items marked this site's suggestion are not in the post. Bitdefender's headline advice is to prevent rather than race: detection that depends on spotting enough events quickly enough "loses to anything that tries again every minute", so prefer controls that stop an action the first time and the hundredth. It also notes, and this site agrees, that none of this is new: the practices that stop conventional ransomware stop this too.

On time: the post says the attack "was not fast" and that "even its quickest retries took 40 seconds or more". Across the whole intrusion the span from first recorded credential theft to encryption was more than eight days (derived). That does not mean defenders had time in practice: the post's own advice is not to rely on racing. It does mean the steps were visible for days, not seconds.

The UK angle: a school estate, and what the post leaves unsaid about it

The victim is, per Bitdefender, a school estate in the UK; the victim's location is the only UK fact in the post. The post names no UK regulator, no guidance, no law, no sector body and no timeline for the victim to notify anyone. It does not say whether pupil or staff data was among the 40 finance share files staged and sent, what the estate's school count is, whether lessons were disrupted, or whether anyone was told. This briefing therefore adds no UK legal or guidance claim: none is in the primary, and none is invented here.

What a UK school or trust can take from it is the practical reading already in the checklist: the estate's separate domains, its backup servers and its unsupported machines are exactly the places the post says were involved. Item 8 above is the question to put to the IT provider.

Technical details

Everything below is what the Bitdefender post prints, attributed and copied as printed. It contains no commands, no decoded payload lines and no scripts: the post prints sanitised commands, and this briefing deliberately does not copy them. Defenders can use the names to hunt. The post prints no file hashes, no addresses and no domains for this case (addresses and hosts are replaced by placeholders); it says the full indicator set is in its GitHub indicator repository and in its IntelliZone platform, neither of which was read for this briefing.

Account, tool and script names the post prints. The two backdoor accounts were created as domain administrators. The renamed credential dumping binary and the public Veeam script are named in the post's phase sections.

Backdoor domain administrator accounts: library, svc_bkpmon
Public Veeam credential script, modified copy: Veeam-Get-Creds.ps1
Mimikatz renamed to: sysmon64.exe
Mimikatz also found as: svcstat.exe, two randomly named .tmp.exe files, a copy in a buzzypdf application folder
Mimikatz release downloaded (as printed): 2.2.0-20220919
Python: portable Python 3.11 in C:\Windows\Temp, running crackw.py
Agent removal scripts: av_remove.ps1, av_remove2.ps1 (av_remove3.ps1 known from its hash only)
Access push script: grant_lib.ps1 (two different versions under one name)
Hunting directory named throughout: C:\Windows\Temp
Earlier events: Restricted Admin mode enabled on four machines, 2026-01-23; hand typed session, 2026-06-05

Probe, confirmation and revision strings. Bitdefender's own advice is to hunt for these literal strings on hosts that should never see them; it says they are cheap, high signal and rarely benign on a production server.

Confirmation strings and files: test123, TASK-OK, psexec-ok, da_proof.txt, wmi_test.txt
Scheduled task name: VEEAMPROBE
Numbered revisions: dcboot/dcboot2, av_remove/av_remove2, prx/prx2/prx3
Trust build probes: diag_member, diag_nl, lmhosts_test, wb_probe, nl_restart
Self logging files written by the loader: step1.txt, step2.txt, step3.txt
Command output files: named with two underscores and a timestamp, in the hidden ADMIN$ share (the wmiexec pattern)

Staging and transport. Finance share files were staged into registry values and posted to a page on the unmanaged host. Bitdefender calls the registry as transport channel unusual and a strong indicator to hunt for.

Registry location: HKLM\SOFTWARE\VC31
Registry staging values: FIN001 to FIN040
Upload page on the unmanaged host: rcv.aspx
Status messages to the same page: periodic, text of the form alive HH:mm

The encryptor and its argument pattern. The post says the argument is not related to data encryption: it serves as an anti sandbox check (the real sample only runs when the argument is supplied) and as a victim identification ID for the affiliate. The value is withheld in the post and is withheld here.

Encryptor: host.exe, a Rust build
Argument pattern as printed: host.exe -k <victim ID withheld> -s 15
Behaviour the post lists: an anti debugging check; deletion of Windows system state backups with wbadmin
Ran: 2026-09-19 05:07 to 05:33 UTC, at 12 to 13 seconds per machine

Ports. The post prints these port numbers; the first three were connectivity tests in the first move, the last two are the backup software ports that matter for the model reading.

445 (SMB), 3389 (remote desktop), 5985 (WinRM): connectivity tested on 12 September
9392: port the attacker's backup software call used, with HTTP Basic authentication
9419: port Veeam's REST examples use, with an OAuth2 token (Bitdefender; the archived Veeam 12 reference read here shows the same)

ATT&CK techniques the post cites, with its own names. Initial access is not established.

Initial Access: not established
T1555 Credentials from Password Stores
T1555.003 Credentials from Web Browsers
T1003 OS Credential Dumping
T1059.006 Python
T1047 Windows Management Instrumentation
T1021.002 SMB/Windows Admin Shares
T1021.006 Windows Remote Management
T1136.002 Create Account: Domain Account
T1484.002 Domain Trust Modification
T1078.002 Valid Accounts: Domain Accounts
T1562.001 Impair Defenses
T1036 Masquerading
T1482 Domain Trust Discovery
T1087 Account Discovery
T1074 Data Staged
T1112 Modify Registry
T1105 Ingress Tool Transfer
T1041 Exfiltration Over C2 Channel
T1053.005 Scheduled Task
T1486 Data Encrypted for Impact
T1490 Inhibit System Recovery

Public ThreeAM names from a tracker, not from this post. WatchGuard's tracker page, read here, lists the ransom note name and the file extension for the 2023 ThreeAM samples. Bitdefender's post prints neither, so whether this intrusion's encryptor wrote them is not stated.

Ransom note name (WatchGuard tracker, earlier samples): RECOVER-FILES.txt
Encrypted file extension (WatchGuard tracker, earlier samples): <file name>.threeamtime

Detection guidance as the post words it. Three lines carry its own "Defender action" label: alert on credential reading access to backup software databases and on saving the SECURITY, SYSTEM or SAM hives by any process other than a known job; hunt for the probe and confirmation artifacts above; and alert on the creation of any new domain trust and on the trust tool being run. A fourth observation is not labelled a defender action but is advice in the conclusion: a loop is noisy and repetitive, and repetition is what gives it away.

The question that exposes the gap

Bitdefender did not need to know whether a person or a model typed the commands to tell defenders what to do, and neither do you. A trust between your domains is a rare change. A backup credential read is a rare event. A new domain administrator with a name that fits in is a rare account. The post's one hard lesson is that each of them was visible, and the attack still went from the first credential read to encryption in eight days.

So the question is not whether an AI was in the loop. It is this: if someone built a two way trust between three of your domains this afternoon, who would be told, and how long before anyone read the alert?