GTIG AI Threat Tracker: from a prompt to thousands of credentials in six hours

Google Threat Intelligence Group published the Q2 2026 edition of its AI Threat Tracker on 8 September 2026. The case that carries the report is short enough to state plainly: a suspected financially motivated actor took a cloud resource belonging to a victim, fed a prompt and a set of pre-written agent instructions into an AI coding chatbot, and had harvested thousands of third-party credentials in under six hours, with the agent managing vulnerability scanning, troubleshooting and IP rotation on its own. The same report describes trojanised MCP servers on PyPI, a credential stealer that steals a build system's own identity so its backdoored packages arrive with valid, cryptographically signed SLSA Build 3 attestations, and adversarial text aimed at making LLM-based security scanners refuse to read the code underneath it. All of it is Google's account of its own telemetry. This report is catalogued, with its confidence grade and its cited sources, in the AI incident archive, which holds every other documented incident in this series alongside it.

None of the substantive claims has been verified by a party that is not restating Google. Help Net Security covered the tracker on the day of publication, the Cloud Security Alliance published a research note the following day, and Lineaje published a DUSTMAKER analysis on 17 September; each is a summary or an analytical overlay on Google's disclosure, and Lineaje says so itself, noting that GTIG "describes several related DUSTMAKER capabilities rather than one single observed end to end execution trace." The second source cited alongside this record, a threatops.tech "threat pulse" item dated 11 September 2026, is a restatement rather than a second witness: it adds no reporting, disputes no figure, and raises the severity label without explaining what it is measured against. Coverage does not fully agree even on the edition's name — Help Net Security calls it the Q3 2026 tracker while dating its principal case to Q2 2026 — which is a numbering difference, not a factual conflict.

The archive files this as a report rather than an incident: confidence grade A, not disputed, no quantified real-harm figure recorded against it. That grading describes the quality of the documentation, not the scale of the damage. Google counts credentials, not victims. The tracker does not say how many organisations were caught in the six-hour campaign, who they were, which chatbot was used, or whether any of the stolen credentials were later sold or used.

The six hours GTIG describes, and the three jobs the agent did alone

The sequence in the report runs from access to outcome with very little human involvement in between. The actor compromised a cloud resource, then used a commercial AI coding chatbot together with what GTIG calls "a prompt" and "a set of agent instructions" — the markdown playbooks that now sit in repositories as AGENTS.md files — to plan, build and run the operation. Google's own framing for the result is an "agent-enabled mass credential harvesting campaign," completed "in under six hours."

Three tasks are described as autonomous, and they are the three that would otherwise have taken an operator's attention:

• The vulnerability scanning pipeline, which the agent instructions let the AI "autonomously manage," in the phrasing Help Net Security quotes from GTIG.

• Real-time troubleshooting of whatever the scanning turned up, so a failure did not stall the run waiting for a decision.

• IP rotation, so successive attempts left from different addresses without anyone issuing the command.

Where the operation ran is as important as how fast it ran. By working out of the victim's own cloud infrastructure, the actor routed traffic through the victim's legitimate IP ranges. Requests that look like they come from inside an organisation are exactly the ones that reputation-based defences are least equipped to question, and the report records it as a consequence of working from the victim's own estate.

What the report does not contain is as telling as what it does. There is no per-step timing, so "under six hours" is a single measurement of the whole run and is not decomposable into a chart. There is no name for the actor beyond "suspected financially motivated," no victim, and no statement of which model or vendor's chatbot was involved. The tracker treats the case as a worked example of a trend, and it is written at the altitude that serves that purpose rather than at the altitude an incident responder would want.

An exposed server that grew into a dashboard of 23,800 secrets

A second finding in the same section is more concrete, and it is a separate case. GTIG found an exposed command-and-control server hosting an automated reconnaissance and credential-management framework it calls Recon. The directory listing was readable and gave away the design: AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, plus a modular .openclaw/ directory and a memory/ directory. Those file names are the fingerprint of an agent stack rather than a bespoke implant — instructions, accumulated knowledge, and a research plan, all on disk where the operator's tooling can read them.

The same directory, later, was serving as a live frontend dashboard organising and validating more than 23,800 harvested secrets, including API keys for cloud and AI services. GTIG characterises the shift it represents as a move "from passive, endpoint-focused infostealers to offensive agentic harvesting" — that is, from malware that grabs what it can from one laptop to tooling that keeps working the targets it has already reached.

Two cautions belong with that number. Twenty-three thousand eight hundred is a count of secrets, not of people or companies, and the report does not translate one into the other. And GTIG does not state whether the Recon server and the six-hour campaign are the same operation; they are presented as separate observations in the same section, so treating them as one storyline would be an inference the report does not make.

DUSTMAKER and the attestation that correctly says the package is genuine

The supply-chain half of the tracker concerns UNC6780, which Google also tracks as TeamPCP, a financially motivated group that has been compromising open-source infrastructure since March 2026 across PyPI, npm and Docker Hub. Its method with AI tooling is direct: compromised developer accounts were used to publish trojanised forks of legitimate MCP servers, with tiktoken_mcp named as an example on PyPI, and malicious code was injected into official organisational repositories, including azure-functions-mcp-extension. GTIG notes that payloads and malicious workspace hooks were then ingested automatically whenever the assets were downloaded or cloned — no separate lure, no second step.

Its credential stealer, DUSTMAKER, is where the report's most useful technical point lives. The chain is short. The stealer detects that it is running in a CI/CD environment; GTIG writes that "if confirmed," it extracts OIDC tokens from the process memory of a GitHub Actions runner. It uses those tokens to authorise itself as a trusted publisher. It then publishes compromised package versions carrying valid, cryptographically signed SLSA Build 3 attestations. Nothing in that chain is forged. The attestation is real, issued to a real identity, for a build that really happened — of code the attacker wrote. GTIG's conclusion is the sentence that matters for anyone relying on provenance: "Packages published with valid tokens will pass AI coding agent automated trust checks."

The rest of DUSTMAKER's behaviour is aimed at places defenders do not watch. It drops and modifies files inside AI coding assistant and IDE workspace directories — .claude/, .vscode/, .cursor/ — where it blends into developer noise and avoids locations that endpoint detection actually monitors, such as Windows registry keys or /etc/cron.*. It writes configuration that makes the IDE or AI extension run a script such as setup.mjs when the workspace opens, which turns opening a folder into code execution. It creates pipeline tasks with AI-themed names such as "Copilot Setup" to hunt for tokens, and issues API calls to delete workflow execution logs so the run does not appear in the GitHub interface.

The malware that asks the scanner to look away

The last mechanism is the least verified of the three. DUSTMAKER's JavaScript loader scripts open with adversarial prompt text embedded as comments — in _index.js among others — referencing biological and nuclear weapons, and including a request for a specification for a 20-kiloton implosion-type fission device. GTIG's assessment is that this was "likely intended to cause LLM security scanners to fail or skip analysis of the malicious JavaScript code underneath due to safety or policy refusals."

The label on that sentence matters. It is a statement about intent, inferred from the text the loader carries, not a demonstration that any scanner actually refused. The report does not name a scanner that skipped the file, does not report a bypass rate, and does not say the technique worked. What is established is that someone wrote the bait and shipped it inside a credential stealer — which is itself evidence that the attackers expect LLM-based triage to be in the path.

UNC6508, MIDNIGHT NEPTUNE and CALANQUE ION sit in the same report

The tracker's state-linked material is broader than its criminal material, and mostly less automated. UNC6508, a PRC-nexus group, has run a multi-year espionage campaign against North American academic, medical and military research and now targets proprietary AI research specifically; GTIG suspects the group of compromising cloud environments in order to deploy local open-weight models, which avoids commercial API monitoring and puts the victim's own compute to work.

Elsewhere the pattern is off-the-shelf models doing ordinary work at scale. North Korea's MIDNIGHT NEPTUNE, formerly UNC1069, used DeepSeek-Coder to write Python remote-access trojans with cross-platform persistence and process injection, used LLMs for Bash lateral-movement scripts, ran social-engineering personas and technical lures, poisoned internal repository configurations, altered Claude CLI hooks, and deployed the SOMBERMEME backdoor when a developer interacted with the repository. Iran's CALANQUE ION, formerly APT42, used models to identify target email addresses, run OSINT, localise lures, summarise exfiltrated data and attempt reverse engineering of licensing code. PRC-nexus BASIN CASTLE used Gemini for target profiling, translation of Chinese material into formal English political reporting, and PowerShell troubleshooting; RAVINE CASTLE researched VMware vCenter SAML bypasses and Active Directory post-exploitation with it; Russian SANDWORM RELIC had Gemini write its password-spraying code. Financially motivated UNC6240, also tracked as ShinyHunters, used Claude Code prompts to write obfuscated code, bypass Cloudflare, and parse exfiltrated directories through custom MCP tools.

One case in this section goes a step further than the rest. A PRC-nexus group used Gemini to design a dynamic automated penetration-testing framework intended to observe a target's state, reason about what to do next, and perform port scanning and service parsing. Google says it took broader action against the campaigns it identified, disabling associated assets, projects and accounts. Separately, in June 2026, Google disrupted "Outsider Enterprise," a China-based cyber-crime service that supplied phishing kits, and described that as the first time it had pursued legal action over Gemini misuse. Those are two distinct statements, and a summary that merges them would say more than the report does: the pentest framework belongs to the disruption-of-assets language, the legal action belongs to Outsider Enterprise.

LLMJacking, and what a stolen AI account costs now

The tracker also prices the market around stolen AI access. Underground demand concentrated on Claude and Gemini credentials, together with the autonomous coding IDEs Cursor Pro and Devin, the latter made by Cognition, and average marketplace prices per account more than doubled during 2026. The infostealers doing the collection — LUMMAC.V2, STEALC.V2, VIDAR and ACRSTEALER — were updated to target AI developer configuration. In May 2026, ACRSTEALER's controllers pushed file-grabber rules for Cline's secrets.json and Continue AI's config.yaml, both of which can hold plaintext API keys and custom model-routing endpoints.

One intrusion GTIG describes shows what an AI account is worth once it is taken. In April 2026 an exposed GitHub personal access token was enough to enable Gemini Enterprise, provision high-performance compute, create Docker repositories for a LiteLLM API deployment and the Manus agent framework, and stand up Cloud Run services exposed to allUsers through an IAM invoker binding. The same session created a rogue service account with Editor privileges and exported its keys, queried BigQuery for environment variables and credentials, tried to hand project ownership to an external address, and used the Cloud Quotas API to request NVIDIA RTX 6000 capacity and additional 48-vCPU instances.

The model-extraction picture is the same economics at larger scale. GTIG says distillation campaigns now occur regularly, "some exceeding 100 million prompts," with queries rotated across thousands of compromised and fraudulent accounts and routed through proxy infrastructure, and that Google has deployed countermeasures that can degrade a student model's performance and methods for identifying Gemini-distilled models by provenance.

What is established, what is assessment, and what GTIG says it has not seen

Established, in the sense that Google is describing its own first-party telemetry and its own account actions: the report and its date; the artefacts it says it observed, including the package names, the loader filenames, the directory names and the 23,800-secret dashboard; and the disruption steps Google says it took, which it can attest to because disabling an account is something it does rather than something it infers. Help Net Security, the Cloud Security Alliance and Lineaje all report those items without contradiction, though none of them brings independent evidence of its own.

Assessment, in the sense that it is a judgement Google is making: every nation-state attribution in the report; the reading of the refusal bait as deliberate; and the claim that stolen tokens will pass "AI coding agent automated trust checks," which is a statement about how those checks are commonly built rather than a measurement of a specific product failing one.

Not established: the identity of the six-hour actor, the victims and their number, the chatbot and model involved, and whether the Recon server is connected to that campaign at all.

And the report's own ceiling is lower than its title suggests. GTIG states that it has not yet observed fully autonomous exploitation pipelines in the wild, and assesses that adversary use "could be evolving towards this use case." The split is within the attack rather than around it: human beings supply the objective, the prompt and the instruction file; the agent supplies the scanning, the troubleshooting and the rotation, and does not stop for permission. Read carefully, the six-hour campaign is not evidence that autonomy arrived. It is evidence that the human share of the work collapsed to the part that requires a human — deciding what to do — while everything between decision and result ran itself.

What Google says it changed, and the control the report actually points at

Google's stated response runs on two tracks. On abuse, it says the activities "triggered Gemini's safety responses," that it took "additional, broader action" against the campaigns on the strength of the actors' operational-security failures, that it disabled associated assets, projects and accounts, and that Google DeepMind used the findings to strengthen its classifiers and the model itself so that it refuses these requests. On defence, it has deployed Google AI Threat Defense, which combines Gemini and frontier models with Wiz risk prioritisation, Gemini and CodeMender remediation, and Mandiant intelligence, using lighter models for continuous scanning and frontier models for high-risk findings; it also introduced Gemini 3.8 Flash Cyber for vulnerability detection and automated patching, and published open-source supply-chain hardening guidance.

The specific fix the DUSTMAKER case calls for is narrower than that stack, and outside analyses converge on it. A SLSA attestation answers whether a package was built by the identity it claims. It does not answer whether that identity still belongs to the party you meant to trust, and DUSTMAKER's whole method is to borrow an identity rather than forge one. Lineaje's summary of the underlying shift is the cleanest statement of it: "Repository content becomes execution authority." Package names, MCP server names, attestation badges and instruction files inside a repository all now arrive with some claim to be obeyed, and the stolen OIDC token is what makes the claim look verified.