TL;DR

Google Threat Intelligence Group reported that financially motivated threat actor UNC6780 (TeamPCP) has incorporated multiple AI specific techniques into its software supply chain operations. GTIG observed the group compromise legitimate developer accounts, publish trojanized MCP related packages, modify legitimate GitHub repositories, target AI coding assistants, and deploy its DUSTMAKER credential stealer.

DUSTMAKER places or modifies files in hidden AI/IDE workspace directories such as .claude/, .cursor/, and .vscode/. Malicious configuration files can instruct AI coding assistants to execute attacker directed commands or scripts during normal developer interaction. GTIG also found adversarial prompts embedded in JavaScript comments that appear designed to trigger safety refusals in LLM based malware scanners and prevent analysis of the malicious code underneath.

The incident demonstrates two distinct AI attack surfaces:

• AI coding assistants as an execution mechanism
• LLM security scanners as an evasion target

A strong control point is preventing untrusted repository or package content from becoming authorization for command execution.

Core Attack Pattern

Since March 2026, UNC6780 has conducted large scale open source supply chain compromises across ecosystems including PyPI, npm, and Docker Hub. GTIG states that the actor commonly deploys credential stealers after compromise to obtain credentials and proprietary information.

For AI development environments specifically, GTIG observed UNC6780:

• compromise legitimate developer accounts;
• publish trojanized forks of legitimate MCP servers, including tiktoken_mcp
• inject malicious code into legitimate organizational GitHub repositories, including azure-functions-mcp-extension
• cause malicious workspace hooks to enter developer environments when the affected assets were downloaded or cloned.

DUSTMAKER then used hidden AI/IDE workspace directories for several purposes. GTIG reports that malicious configuration files in these locations could instruct an AI coding assistant to execute arbitrary commands or scripts, such as setup.mjs, during routine developer interaction. It could also create build or startup commands that execute automatically when the IDE or AI extension opens the workspace.

Separately, in CI/CD environments, DUSTMAKER can extract OIDC tokens from GitHub Actions runner process memory and use them to publish compromised packages with valid SLSA Build 3 attestations. GTIG states that packages published using those valid credentials can pass automated trust checks used by AI coding agents.

GTIG also identified adversarial text at the top of DUSTMAKER JavaScript loader files. The prompts contained high severity harmful subject matter and were assessed by GTIG as likely intended to cause LLM security scanners to refuse or skip analysis of the malicious JavaScript beneath them.

Attack Analysis

The most important AI specific path is:

Compromised software component → malicious workspace files enter developer project → AI assistant parses project configuration → indirect prompt injection influences the model → AI assistant executes attacker-directed command/script.

GTIG explicitly states that the malicious configuration can cause the AI assistant to execute commands on the attacker's behalf without the developer's knowledge. The attack therefore crosses an important trust boundary: Repository content becomes execution authority.

The AI assistant is expected to inspect project content, but project content is attacker controlled in a supply chain compromise. Once that content is treated as actionable instruction rather than untrusted data, the attacker can use the AI as an execution intermediary.

DUSTMAKER also attacks AI based defenses. By placing adversarial safety sensitive prompts inside code comments, the malware attempts to manipulate the scanner's model into refusing the analysis rather than inspecting the malicious code. GTIG reported that this activity triggered Gemini safety responses.

These are different objectives using the same underlying weakness:

1. Prompt injection against coding agent leading to adversarial execution
2. Prompt injection against security scanner leading to defense evasion

The Attack Progression Across The AI Kill Chain

GTIG describes several related DUSTMAKER capabilities rather than one single observed end to end execution trace. The kill chain below maps only the stages directly supported by the disclosed behavior.

1. Reconnaissance — Bypassed entirely. GTIG's disclosure does not describe a distinct reconnaissance phase preceding the compromises.
2. Trust Manipulation — Active. Since March 2026, UNC6780 has used compromised legitimate developer accounts and legitimate repositories/packages — including trojanized forks of tiktoken_mcp and injected code in azure-functions-mcp-extension — to distribute backdoored components into developer environments.
3. Input & Instruction Weaponization — Active. Malicious workspace configuration files placed in hidden AI/IDE directories such as .claude/, .cursor/, and .vscode/ supplied instructions to AI coding assistants, while adversarial prompts embedded in JavaScript comments at the top of DUSTMAKER loader files targeted LLM security scanners.
4. Reasoning-Time Execution — Active. GTIG states the malicious configuration could cause the AI coding assistant to execute commands on the attacker's behalf without the developer's knowledge, with the assistant following attacker controlled project instructions rather than only developer intent.
5. Tool Invocation — Active. DUSTMAKER configurations instructed coding assistants to execute arbitrary commands or scripts, such as setup.mjs, and could also create build or startup commands that execute automatically when the IDE or AI extension opens the workspace.
6. Privilege Escalation — Bypassed entirely. GTIG does not demonstrate AI driven acquisition of additional privileges in the disclosed activity.
7. Lateral Movement — Active. In CI/CD environments, DUSTMAKER extracted OIDC tokens from GitHub Actions runner process memory, and compromised credentials or publishing access enabled movement from one trusted development environment into other software distribution or repository environments.
8. Persistence — Active. Malicious dependencies preserved attacker controlled behavior across subsequent installs, builds, or workspace use, including packages published with valid SLSA Build 3 attestations capable of passing automated trust checks used by AI coding agents.
9. AI-Native C2 — Bypassed entirely. No AI native command and control mechanism is established in the disclosed AI assistant behavior.
10. Action on Objectives — Active. Compromised publishing credentials and trusted distribution paths were used to publish or distribute additional malicious packages, extending the compromise to downstream environments.

Mitigation Strategy

Validate Software Before It Reaches the Agent

Packages, MCP servers, extensions, and repository content should be treated as untrusted supply-chain components. GTIG recommends strengthening open-source supply-chain controls, including dependency governance, CI/CD hardening, credential protection, and validation of software provenance.

Existing package provenance, malware classification, reputation, and source-to-package validation controls can break this chain before Stage 3 by preventing compromised components from entering the developer environment.

Prevent Untrusted Context From Becoming Execution Authority

A runtime policy should distinguish between developer authorized instruction and instruction originating from repository/package content.

Inspect AI Consumed Content for Prompt Injection

Files entering an LLM security scanner or coding assistant should be inspected for instruction like text designed to manipulate model behavior. This is especially important inside comments, configuration, documentation, metadata, and other content normally treated as passive data.

For LLM security scanners, high-severity safety language appearing inside analyzed code should not automatically terminate malware analysis. The content should remain isolated as untrusted data while other static, behavioral, reputation, and sandboxing controls continue inspection.

Restrict Agent Tool Execution

Agent tools should be authorized against the user's actual task. A project file alone should not grant permission to execute scripts, alter CI/CD configuration, read credentials, or modify security sensitive settings.

Mandiant separately recommends least privileged agent identities, tightly scoped tokens, supply chain validation for skills and MCP components, and runtime analysis of sensitive data flows.

UnifAI

• Policies: AI_APP_SEC_059, AI_APP_SEC_070, AI_APP_SEC_080, AI_IAC_020
• Pre-ingestion supply-chain screening: UnifAI scans and classifies OSS packages, MCP servers, and agentic skills as benign, suspicious, or malicious. This allows customers to block malicious or high risk components at the source to prevent compromised dependencies from reaching the AI agent or developer workstation.

Trusted to Analyze, Not Authorized to Command

UNC6780 demonstrates an important evolution in software supply chain attacks: attackers are now deliberately designing malicious software to exploit the AI systems operating on that software.

DUSTMAKER does this in two directions. It uses malicious workspace configuration to influence coding assistants into executing attacker directed commands, and it embeds adversarial text into malware in an apparent attempt to make LLM security scanners refuse analysis. Both behaviors were documented by GTIG in active UNC6780 operations.

The central security lesson is that content trusted enough to be analyzed by an AI agent must not automatically be trusted enough to instruct that agent**.**

Scanning prompts alone is insufficient. The stronger architecture combines supply chain validation with runtime provenance of instructions: where did this instruction originate, what action is it requesting, and did the user actually authorize that action?