A crew used AI to run intrusions across 170,000 targets. Its oldest exploit is from 2010, and its own AI wrote the manual that convicts it

What Talos found, and why it is different

On 20 August 2026 Cisco Talos published an analysis by Joey Chen of a Chinese-speaking, financially motivated group it tracks as UAT-10147. The group breaks into internet-exposed Windows and Linux web servers at scale, then installs malware for search-engine-optimisation fraud and data theft. Talos names the sectors hit as government, universities, media, technology and gaming, and observed compromised servers in Brazil, Bolivia, China, Canada and Vietnam.

Read quickly, this is another "AI-powered attacks are here" story, and it will be reported that way. Read carefully, it is something more specific and more useful, because Talos did not just find AI-written scripts. It recovered the actor's own AI-generated operational documentation: a nine-section exploitation guide, four companion Python scripts, and a findings log of a live intrusion. Talos assesses with moderate-to-high confidence that this marks a shift from AI-assisted scripting toward semi-autonomous offensive orchestration.

The distinction matters, and the rest of this piece is about it. The exploits UAT-10147 ran are old and public. What the AI added was not capability. It was the paperwork of a professional operation: playbooks, validation steps, quality assurance and case records. And that paperwork, once recovered, reads as a detection manual.

The scale, and who was in the crosshairs

Before the exploits, the shape of the operation. Talos recovered the actor's target list from an open directory on their command-and-control server: roughly 170,000 URLs, which the actor split into 17 files of about ten thousand each, using "w" as shorthand for the Chinese character 萬, ten thousand. That is not a handful of chosen victims. It is an industrial scan for anything reachable and unpatched.

Where the 170,000 targets resolved

The target list, by country

Top 15 · Cisco Talos

~170,000

URLs on the target list

17 files

of about 10,000 each. “w” is 萬, ten thousand

6×

the US lead over the next country

• United States52,496
• India8,923
• United Kingdom3,453
• Germany3,412
• Netherlands3,287
• France2,682
• Australia2,297
• Canada2,086
• Vietnam1,427
• Italy1,235
• Hong Kong1,118
• Denmark1,039
• Turkey908
• Iran831
• Ireland749

Counts are of IP addresses resolved from the target URLs, per Talos. The distribution follows where internet-exposed, unpatched web servers are, not any political targeting: this is a financially motivated crew scanning for reachable holes, and the map is a map of exposure.

The sectors hit follow the same logic: government, universities, media, technology and gaming, chosen because they run large estates of exposed web infrastructure, not because they were singled out. For a financially motivated crew running SEO fraud and data theft, the target is whoever left a door open.

The exploits are old. That is the first thing to notice.

Before the AI, look at the weapons. The Linux privilege-escalation chain is a rack of known, patched, one-day vulnerabilities.

The privilege-escalation exploits, on a real timeline

CVE-2010-3904 is sixteen years old. CVE-2015-5287 and CVE-2015-3246 are eleven. The initial-access vulnerabilities are the same shape: Zimbra (CVE-2022-27925), AjaxPro (CVE-2021-23758), the Nacos framework (CVE-2021-29441 and CVE-2021-29442) and Telerik UI for ASP.NET AJAX (CVE-2019-18935). Not one is a zero-day. Every server compromised here was reachable, exposed and unpatched, sometimes for over a decade.

So the honest headline is not that AI found new ways in. It is that AI made it economical to run a large, disciplined operation against old holes. The capability was always available to a skilled operator. What changed is that the skill is now partly encoded in tooling.

Both platforms, one entry point

The intrusions follow a consistent shape across operating systems, which is itself a sign of an orchestrated playbook rather than hands-on improvisation.

The two infection chains, from one shared foothold

Shared entry point

RCE on an internet-exposed web server, through a publicly disclosed vulnerability

Zimbra, AjaxPro, Nacos and Telerik UI among the entry vectors. Every one already had a patch.

↓

Windows lane

IIS server

1. back.bat via certutil

   Downloads EfsPotato, a second script and QuasarRAT, all renamed

   ↓

2. EfsPotato privilege escalation

   AppPool identity to SYSTEM

   ↓

3. Defender exclusions

   Add-MpPreference on the inetsrv directories, blinding AV to the drop

   ↓

4. BadIIS module

   The objective: SEO fraud and data theft from inside IIS

   ↓

5. Scheduled task, rogue admin

   “Google Chrome Start” at logon, plus a new Administrators/RDP account

Linux lane

Web server

1. Web shell

   Interactive command execution on the compromised server

   ↓

2. Local privilege escalation

   A rack of known kernel and sudo exploits, oldest from 2010

   ↓

3. Implants

   NoodleRAT, SPECTRE and Meterpreter, in memory and on disk

   ↓

4. Outbound C2

   Connections to remote command-and-control infrastructure

objective evasion persistence

On Windows, a script commonly named back.bat uses certutil to pull down a privilege-escalation tool (EfsPotato, renamed), the QuasarRAT payload disguised as svchosts.exe, and follow-on scripts. It adds the IIS directories to the Windows Defender exclusion list before dropping the malicious IIS module, creates a scheduled task called "Google Chrome Start" that runs at every logon, and adds a rogue account to the Administrators and Remote Desktop groups. The objective is BadIIS, a malicious IIS module used for SEO fraud and data theft. In related intrusions Talos saw Gh0stCringe and SPECTRE implants as well.

On Linux, a web shell leads to the privilege-escalation rack above, then to NoodleRAT, SPECTRE and Meterpreter implants calling out to command-and-control infrastructure.

The toolset is almost entirely open source and off the shelf.

What UAT-10147 assembled, and where it came from

Tool	Role	Origin
Metasploit and Meterpreter	Exploit delivery and backdoor	Open-source framework
ysoserial	Java and .NET deserialisation payloads	Open-source
EfsPotato	Windows privilege escalation	Open-source
QuasarRAT, Gh0stCringe	Windows remote access	Open-source and commodity
NoodleRAT, SPECTRE	Cross-platform implants	Commodity, SPECTRE new this campaign
BadIIS	Malicious IIS module for SEO fraud	Actor deployed
PentestGPT	AI-driven exploitation orchestration	Open-source
DeepAudit	AI source-code vulnerability scanning	Open-source

The centre of the story: the AI wrote a manual

The single most significant artefact Talos recovered is a nine-section guide, generated by the actor's AI tooling, documenting how to exploit an ASP.NET ViewState deserialisation flaw against a real target. It is worth reading in full, because a manual written to attack more reliably is, line for line, a manual for what to detect.

The attacker's own AI guide, read as a defensive checklist

The manual the AI wrote, read as a detection list

9 sections, recovered by Talos

§

What the attacker’s AI documented

The defensive reading of the same line

1

Prerequisites

Needs the ValidationKey, DecryptionKey, their algorithms, the __VIEWSTATEGENERATOR and the URL. Sourced from badsecrets, a database of leaked ASP.NET MachineKeys.

The whole chain depends on key exposure. MachineKey confidentiality is the control that makes every step below impossible.

2

MachineKey validation

A malformed ViewState distinguishes two HTTP 500s: a MAC failure means the wrong key, an InvalidCastException means the key is correct.

Silent key-probing looks like ordinary 500s. Alert on repeated malformed ViewState producing InvalidCastException, not on 500 volume alone.

3

Payload generation

ysoserial with the TypeConfuseDelegate gadget, and an explicit correction that .NET 4.8 does NOT patch these chains, against public articles that claim it does.

Do not rely on a framework upgrade as mitigation. The runtime is not the boundary here; the key is.

4

Payload delivery

A script POSTs to __VIEWSTATE, mirrors the generator value, suppresses redirects. Documents that a 500 with InvalidCastException is success, not failure.

An inverted success condition. Tooling that treats 5xx as noise misses the exploit succeeding inside the error stream.

5

RCE confirmation

Time-based blind testing is documented as useless because Process.Start returns immediately. The actor pivots to out-of-band callbacks over HTTP and DNS.

Hunt egress, not response timing. Outbound certutil, PowerShell web requests and unusual DNS from a web server are the signal.

6

Recon and exfiltration

A reconnaissance playbook run entirely through PowerShell encoded commands, with results POSTed to a webhook endpoint.

PowerShell -enc from w3wp.exe is rarely legitimate. Encoded-command execution under the IIS worker is a high-value detection.

7

Interactive shell

Three escalating options: download a custom implant, write an ASHX web shell to the webroot, or open a PowerShell reverse shell.

File writes into the webroot and new listeners from the AppPool identity. Web-directory integrity monitoring catches the shell drop.

8

Privilege escalation

From the IIS AppPool identity to SYSTEM via SeImpersonatePrivilege and the Potato family of tools.

Constrain the AppPool identity. SeImpersonate on a web worker is the enabling privilege; remove it where the workload allows.

9

Operational case record

A log of a real intrusion: target hostnames, front and back-end IPs, the exploited page, the .NET build, and the MachineKey values used.

The attacker's own AI wrote down the evidence. It also noted a MachineKey is scoped per IIS site, so co-hosted sites are not a free win.

Every row the attacker documented to attack more reliably is a row a defender can monitor. Section 1 is the one that matters most: the AI states plainly that without the MachineKey, none of the eight steps below it are possible.

Three findings inside that guide are worth pulling out, because each is a defensive gift the attacker did not mean to give.

It named its own single point of failure. Section 1 states that the whole ViewState attack needs the target's ValidationKey and DecryptionKey, and that these are obtained from badsecrets, an open-source database of leaked ASP.NET MachineKeys. Everything downstream depends on that one secret.

MachineKey confidentiality is the control that removes the attack

It documented an inverted success condition. Sections 2 and 4 explain that a correct key produces an HTTP 500 with an InvalidCastException, while a wrong key produces a 500 with a MAC validation failure. In other words, the exploit succeeds inside a 500 error. Any monitoring that treats 5xx responses as noise will watch the attack work and see nothing worth an alert. The AI wrote that down as an advantage. It is equally a precise detection instruction: alert on repeated malformed ViewState producing InvalidCastException, not on error-rate volume.

It corrected a widely believed myth. Section 3 states, against several public articles, that .NET 4.8 does not patch the TypeConfuseDelegate gadget chain. The findings log confirms four distinct gadget chains executing on .NET 4.8.4797.0. The practical lesson is blunt: do not treat a framework upgrade as mitigation for this bug class. The runtime is not the boundary. The key is.

The scripts that came with it

The guide shipped with four Python scripts, and their names describe a workflow: check_paths.py diagnoses whether the web shell can write and where, deploy_implant.py downloads and verifies the SPECTRE implant, deploy_shell.py plants a durable ASHX web shell, and exfil.py runs staged reconnaissance.

Two details in these scripts matter more than the code.

The first is how the actor confirms execution. Time-based blind testing does not work against this flaw, because the gadget calls Process.Start, which returns immediately with no observable delay. The AI documented the failure and pivoted to out-of-band callbacks: certutil, PowerShell web requests and DNS lookups reaching an attacker endpoint. For a defender this relocates the entire detection problem. You cannot see this in the HTTP response. You can see it in egress: a web server making outbound certutil calls or unusual DNS queries is the signal.

The second is how it hides. Exfiltration is routed through webhook.site and, in the Nacos exploit, through the attacker's own Nacos configuration server. Sending stolen data to a legitimate cloud configuration service lets the traffic blend with ordinary administrative operations, and lets the attacker poll their own instance to confirm success without maintaining a noisy inbound connection.

Why the exfiltration does not look like exfiltration

1. IIS or LinuxCompromised web serverthen
2. Encoded, stagedPowerShell -enc / curlthen
3. Legitimate-looking SaaSwebhook.site or attacker Nacosthen
4. No inbound connection neededAttacker polls the sink

There is a human fingerprint in here too. A hardcoded path in one script, C:\Users\dajiba\..., and the username dajiba, is the pinyin for a Chinese vulgarity, which is part of how Talos attributes the language of the operator. And the whole investigation was possible because of an OPSEC failure: the actor left an open directory on a download server at 139.180.197[.]150, which is where Talos found the scripts, the guide and the findings log.

What the case record actually contains

The ninth section of the guide is not instruction. It is a record of a live intrusion against a real victim: target hostnames, front and back-end IP addresses, the exploited page path, the .NET build, and the MachineKey values used. The findings log alongside it counts more than twelve callbacks confirming code execution, a webroot with thirteen site directories, an access-denied on redirection.config, and SeImpersonatePrivilege enabled, which is the standing prerequisite for the Potato-family escalation to SYSTEM.

The attacker's AI, in short, generated the evidence of the attacker's crime. That is the same shape as two other stories on this site in the last fortnight: OpenAI learned its own agents had attacked Hugging Face only when the victim told it, and Copilot disclosed its own vulnerability while explaining why it was safe. Instrumentation cuts both ways, and here it cut toward the defender.

What to actually do

The temptation with an "AI attack" story is to reach for an AI defence. That is the wrong lesson. Every control that stops this campaign is a control that existed before the AI did.

The position

The AI did not make UAT-10147 more capable. It made them more organised. It wrote the runbook, validated the exploit, generated the case notes and lowered the expertise a human operator needed to run all of it. That is a real change and it should be taken seriously: it means more operators can run this quality of campaign, against the same old holes, at greater scale.

But the defensive conclusion is almost reassuring, and it is worth saying against the grain of the coverage. A campaign that runs sixteen-year-old exploits is defeated by controls that are just as old. Patch the edge. Protect the key. Watch what leaves. None of that requires a defensive AI, and none of it is new.

The genuinely new artefact is the manual, and the manual is a liability for the attacker, not the defender. The actor taught their AI to document its own tradecraft, and in doing so handed anyone who recovers that documentation an ordered list of exactly what to monitor. The lesson for the next operator is that an AI that writes down how it broke in has written down how to catch it. The lesson for defenders is simpler: the fundamentals still hold, and this campaign is evidence for them rather than against.