# UNC6780 Hid Dustmaker Where Coding Agents Look First. > Since March 2026, UNC6780, also tracked as TeamPCP, has compromised PyPI, npm, and Docker Hub. Its JavaScript stealer Dustmaker reads OIDC tokens from GitHub Actions runner process memory and publishes packages with valid SLSA Build 3 attestations. Those stamps pass automated trust checks used by AI coding agents. GTIG also saw hidden workspace dirs aimed at those agents. Source: https://hackerlogs.com/blog/unc6780-dustmaker-workspaces Published: 2026-09-09 ## Key takeaways - Dustmaker is a CI/CD-oriented JavaScript stealer. GTIG told The Hacker News the AI-workspace tricks are new versus earlier SANDCLOCK variants. - Stolen GitHub Actions OIDC from runner process memory lets the actor publish packages with valid SLSA Build 3 attestations that agent trust checks accept. - Payloads land in hidden assistant directories (.claude, .cursor, .vscode) that EDR watches less closely than cron or the registry. - Comment-bait at the top of the JavaScript loader is meant to make LLM scanners refuse the file, not to teach a jailbreak. - One IR case handed access to a second actor who used LAPSUS branding and stole a proprietary AI repository. There is no CVE. Google Threat Intelligence Group's 8 September tracker leads with agent speed. The quieter half is a financially motivated actor that has been poisoning the registries your coding assistant already trusts. UNC6780, also tracked as TeamPCP, has run large-scale compromises of PyPI, npm, and Docker Hub since March 2026. After the first foothold it deploys stealers, sells the take, or hands access to ransomware and extortion partners. GTIG expects copycats: the malware is public, and the tactics work. Supply-chain publishing with a valid SLSA Build 3 stamp, plus workspace files that coding agents read as ordinary project config. High because the trust checks fail closed in the attacker's favor. There is no CVE. Three-panel diagram of UNC6780 Dustmaker: poisoned PyPI, npm, and Docker Hub packages including trojanized MCP forks; OIDC stolen from GitHub Actions runner memory used to publish with valid SLSA Build 3 attestations; hidden .claude, .cursor, and .vscode directories plus comment-bait aimed at LLM scanners. ## What changed from SANDCLOCK The Hacker News asked GTIG to separate the stealers. SANDCLOCK, used in March and April 2026, is the Python piece of what public reporting called CanisterWorm. It targeted Linux and Kubernetes, included container escape, and went after wallets as well as cloud and developer credentials. Dustmaker, used from April onward, is a cross-platform JavaScript payload built for CI/CD. GTIG says it does not include container escape. Some variants still look at wallets; the center of gravity is credential theft for extortion. The AI-specific tricks (poisoned assistant workspaces and comment-bait against LLM scanners) are exclusive to Dustmaker. They were not in SANDCLOCK. The Hacker News also lists Altered Spider as an alias. Use UNC6780 or TeamPCP in tickets; those are the labels GTIG put on the page. ## How the package gets a real stamp Dustmaker checks whether it is running in CI. If it is, it reads OIDC tokens from the process memory of GitHub Actions runners. With those tokens it publishes as a trusted publisher. The resulting packages carry valid, cryptographically signed SLSA Build 3 attestations. That is the part an agent will like. Automated trust checks that treat a SLSA Build 3 stamp as sufficient will accept the trojan. The signature is real. The publisher identity was stolen from the runner, not from a maintainer's laptop in a phishing mail. GTIG also named two concrete delivery paths aimed at assistants and the humans who install what those assistants suggest: trojanized MCP server forks on PyPI such as `tiktoken_mcp`, and malicious code injected into official organizational GitHub repositories such as `azure-functions-mcp-extension`. Cloning or installing those assets pulled workspace hooks into the developer environment. > A green provenance badge is not a clean bill. If the runner that minted the attestation was already theirs, the stamp only proves the pipeline ran. ## Where it hides in the workspace Dustmaker drops or edits files in hidden project directories that assistants and IDEs already parse: `.claude/`, `.vscode/`, `.cursor/`, and similar. GTIG's point is placement. Those folders look like developer noise. They are not the Windows registry or the cron spool, which EDR products watch more closely. From those files the malware sets startup or build commands so the payload runs when the IDE or AI extension opens the workspace. Separate configuration tells the assistant to execute attacker scripts during ordinary developer interactions. We are not reprinting those scripts. The control failure is an assistant that will run whatever the workspace file asks. In GitHub Actions, Dustmaker creates pipeline tasks under AI-themed names such as "Copilot Setup" to find more tokens and to spread. It then issues API calls that delete the workflow logs so the run disappears from the GitHub UI. Comment-bait is the last trick in GTIG's table. Dustmaker samples put adversarial text in comments at the top of the JavaScript loader so an LLM security scanner hits a policy refusal and skips the code underneath. GTIG published a figure of that text. We are not reproducing it. The defensive read is: a scanner that aborts on a policy class is a scanner an actor can mute with a comment. ## What they take after that UNC6780 collects AI-tool credentials with everything else. In one Mandiant response, the group established access and handed it to a second actor who issued a ransom demand using LAPSUS branding. Evidence showed UNC6780 had planted a malicious GitHub Actions workflow on the company's proprietary AI repository. The extortion actor exfiltrated that repository. Infostealer controllers are fishing the same pond. In May 2026, GTIG saw ACRSTEALER rules aimed at Cline's `secrets.json` and Continue's `config.yaml`. Those files can hold plaintext API keys and custom model endpoints. Continue was acquired by Cursor in June 2026. That is adjacent tradecraft, not a Dustmaker feature, and it is why "the assistant's own config" belongs on the same hunt list as `.cursor/`. ## What to do If your developers install from PyPI, npm, or Docker Hub, or let an assistant do it: 1. Do not treat SLSA Build 3, trusted publishing, or an AI-themed workflow name as an allow-list. Confirm the publisher identity still matches a runner and a repository you administer. 2. Hunt unexpected files under `.claude/`, `.cursor/`, and `.vscode/` in repositories you did not just scaffold. Review startup tasks the workspace tells the assistant to run. You wrote those, or you did not. 3. In GitHub Actions, look for jobs that delete their own logs and for workflow names that ape Copilot or other assistant setup. Rotate OIDC and package-registry tokens if a runner's memory was in scope. 4. Pin and review MCP servers the way you review any executable dependency. GTIG's named packages are seeds, not the catalog. 5. Keep this off the six-hour harvest ticket. That case is a chatbot-driven scan after a cloud foothold. This one is a poisoned workspace and a stolen stamp. The indexable query is "AI coding tools targeted" or "UNC6780 Dustmaker." The accurate sentence is: the malware sits where the agent already looks, and the provenance stamp can be real. ## Sources - [GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI](https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai) (2026-09-08) - [Autonomous AI Agents Compromise Thousands of Credentials in Under Six Hours](https://thehackernews.com/2026/09/autonomous-ai-agents-compromise.html) (2026-09-08) - [AI Coding Tools Now a Prime Target for Threat Actors, Google Warns](https://www.infosecurity-magazine.com/news/ai-coding-tools-threat-actors/) (2026-09-08) - [Google says attackers used AI agents to steal credentials in under six hours](https://siliconangle.com/2026/09/08/google-says-attackers-used-ai-agents-to-steal-credentials-in-under-six-hours/) (2026-09-08)