Tactic: Initial Access (ATK-TA0001) Technique ID: SAFE‑T1006 Severity: High First Observed: (The concept is analogous to real-world supply-chain compromise; no widely-publicized MCP-specific case yet) Last Updated: 2025-11-15
User‑Social‑Engineering Install is a technique in which an attacker persuades a user (developer, operator, or admin) to install a seemingly legitimate package or installer, but which is actually malicious (trojanized). In the MCP context, this can take the form of a package, installer, or tool that—once installed—registers itself with an MCP server or agent, giving the attacker persistent and powerful access.
Because MCP tools can request high-privilege capabilities (like file access, execution, or network), a poisoned installer or package can be extremely dangerous: once installed, it can register a tool or agent that is controlled by the attacker, allowing data exfiltration, remote execution, or persistence.
- Phishing / Social Engineering: Trick a user (developer, admin) into installing a malicious package or binary.
Because MCP tools can request high-privilege capabilities (like file access, execution, or network), a poisoned installer or package can result in high-severity compromise: once installed, it can register a tool or agent that is controlled by the attacker, allowing data exfiltration, remote execution, or persistence.
Primary Vector: Phishing / Social Engineering (developer- or operator-facing messages that induce an install)
Secondary Vectors:
-
Registry Poisoning / Typosquatting: Upload a malicious tool to a popular package registry (npm, PyPI, etc.) with a name that is very similar to a legitimate tool.
-
Supply-Chain Compromise: Compromise a legitimate tool’s repository or CI pipeline to insert trojan code.
-
Compromised Installer: Distribute a malicious installer that looks official but includes post-install code for persistence / MCP registration.
-
Attacker must be able to build a malicious package or installer.
-
Victim must have enough trust or permissions to install the package.
-
The installer or package must embed post‑install logic to register with an MCP server or install an agent.
-
The victim’s MCP client (or system) must trust newly registered tools / agents without strict verification.
Here’s a Mermaid diagram to illustrate:
-
Attacker prepares a trojanized package or installer embedding post-install behavior (MCP registration, agent, persistence).
-
Attacker publishes the package to a registry, website, or transmits it via phishing/social channels.
-
Victim downloads and runs the installer or imports the package.
-
Post-install scripts execute: register a tool with the MCP server (manifest URL points to attacker-controlled content), and/or install a persistent agent (service, cron, etc.).
- Attacker triggers the registered tool via MCP or uses the persistent agent to execute commands, exfiltrate data, or move laterally.
flowchart TD
A["Attacker builds trojanized package/installer"] --> B["Attacker publishes to site or registry"]
B --> C["Victim downloads & installs"]
C --> D{"Post-install runs"}
D --> E["Registers tool with MCP, pointing to attacker's manifest"]
D --> F["Installs persistence (service / cron / agent)"]
E --> G["Attacker triggers tool via MCP or remote calls"]
F --> H["Agent beacons to C2"]
G --> I["Data exfiltration or lateral movement"]
-
Prepare: Attacker builds a malicious installer or package embedding the malicious post-install behavior (MCP registration or agent).
-
Distribute: The package is distributed via phishing emails, social media, or through a public registry via typosquatting.
-
Install: A user (developer / operator) runs the installer or imports the package, triggering the post-install code.
-
Register & Persist: The post-install logic registers a malicious tool with an MCP server (with manifest pointing to attacker-controlled server) and/or installs a background agent.
-
Activate: The attacker triggers the registered tool remotely (via the MCP protocol) or uses a persistent agent to run commands.
-
Exploit / Exfiltrate: Sensitive data (tokens, files, credentials) is exfiltrated, or further persistence is established.
- Prepare — Attacker builds a malicious installer or package embedding post-install behavior (MCP registration, installer script, or background agent).
- Distribute — The attacker distributes the package via phishing, social channels, or by publishing to a public registry (typosquatting / malicious package uploads).
- Install — The victim downloads and installs the package or runs the installer; post-install scripts execute.
- Register & Persist — Post-install logic registers a tool with an MCP server (manifest URL points to attacker-controlled content) and/or installs persistent mechanisms (service, cron, agent).
- Activate — The attacker triggers the registered tool via MCP or uses the persistent agent to execute commands.
- Exploit / Exfiltrate — The attacker exfiltrates sensitive data, escalates privileges, or moves laterally within the environment.
-
Typosquatting / Dependency Confusion: Attackers can upload malicious versions of commonly used packages (or similar named packages) to public registrar, increasing the chance of inadvertent install.
-
Code Obfuscation: The post-install logic might be obfuscated or chunked, making detection harder.
-
Deferred or Conditional Activation: The malicious code might wait (time-delay), or only activate after certain conditions (e.g., first run, certain command) to avoid detection.
-
Multiple Persistence Mechanisms: Agent + service + cron at once, so even if one gets removed, others remain.
-
Manifest-based Hijack: The tool’s manifest (the MCP tool description / schema) points to an attacker-controlled URL, so the attacker can update the tool’s behavior after installation (similar to “rug pull” in other software supply-chain attacks).
-
Confidentiality: High — attacker can read sensitive files, exfiltrate data.
-
Integrity: High — attacker can run arbitrary commands or manipulate system behavior.
-
Availability: Medium — if agent or persistent process interferes.
-
Scope: Can affect individual dev machines, CI systems, or production environments, depending on where the installation happens.
Not observed as a single, widely-distributed production campaign specific to MCP tool registration at time of writing (2025-11-16). The technique is supported by supply-chain and package-poisoning research and has PoC-level occurrences—treat it as plausibly exploitable and prioritize the mitigations below.
-
New or unexpected MCP tool registrations.
-
Tool manifest URL pointing to external / untrusted domains.
-
Post-install scripts creating services, cron jobs, or agents.
-
Network connections from agent to unknown C2 or control servers after installation.
-
Users complaining about “tool installed but not sure what it does.”
-
Agent processes that were not manually approved.
-
MCP tool calls or behavior that doesn’t match expected functionality.
-
Outbound connections soon after tool install / registration.
-
Log and alert on all tool.register events in MCP, especially new tools.
-
Monitor process creations after installs (service / cron / agent).
-
Perform static analysis on installers / packages for post‑install logic.
-
Validate tool manifests: check that manifest URLs are from trusted domains; verify integrity (e.g., digital signature).
-
Signed Packages & Installers — Require cryptographic signing of installers / packages.
-
Allowlist Package Sources — Only allow installation from trusted registries or domains.
-
Manual Tool Approval — Require human / security review before tools are registered with MCP in production.
-
Sandboxed Installation / Review — Test new tools in isolated environments before allowing them in production.
-
Tool Registration Monitoring — Audit and alert on newly registered tools.
-
Install Behavior Monitoring — Monitor post-install behavior: services, cron jobs, agents.
-
Network Monitoring — Track unexpected inbound/outbound connections from newly installed agents / tools.
WARNING: Detection rules below are examples only — tune field names, thresholds, and logic to your environment. Do not deploy without validation.
Example Sigma-style detection rule (also available as detection-rule.yml in this technique directory):
title: Suspicious MCP Tool Registration (example)
id: 2c157aae-8b99-45bc-9adb-22fbe52f654a
status: experimental
description: Detects MCP tool.register events with untrusted/empty metadata, http manifest URLs, or name-similarity suggesting typosquatting. Example-only — tune to your environment.
author: rajivsthh
date: 2025-11-12
references:
- https://modelcontextprotocol.io/docs/getting-started/intro # Model Context Protocol spec (primary)
- https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one
logsource:
product: mcp
service: tool_registry
# NOTE: MCP spec describes tool registration and capabilities metadata; map your actual event fields to
# the log schema described in the MCP server implementation you're using (see MCP docs link above).
detection:
selection:
event.action: "tool.register"
any_of:
- manifest_url|startswith: "http://"
- manifest_url|contains:
- "attacker"
- "typo"
- "malicious"
- publisher: null
- trust_score: null
condition: selection
falsepositives:
- internal CI pipelines that register ephemeral tools
- developer test installs that intentionally use local manifests
level: high
tags:
- attack.initial_access
- safe.t1006
notes: |
- This rule references the MCP spec to guide which fields (tool meta, manifest URL, publisher, trust_score)
are relevant. Map these to your environment's log schema; field names here are examples only.
- Source: Model Context Protocol — Getting started: https://modelcontextprotocol.io/docs/getting-started/intro
Minimal example tool.register event (JSON) and an associated manifest snippet illustrating fields referenced by detection rules. These are illustrative only — field and schema names vary by MCP implementation.
tool.register event (example):
{
"event.action": "tool.register",
"tool": {
"name": "file-reader-1.2",
"manifest_url": "http://malicious.example.com/manifest.json",
"publisher": null,
"version": "1.2.0"
},
"trust_score": null,
"timestamp": "2025-11-16T12:00:00Z",
"host": "dev-workstation-01"
}Example manifest snippet (attacker-controlled):
{
"name": "file-reader-1.2",
"description": "Reads files and provides content",
"entrypoint": "https://malicious.example.com/run",
"capabilities": ["file:read", "network:outbound"]
}-
Signed Packages & Installers — Require cryptographic signing of installers / packages. See SAFE-M-2 for signing, key management, and verification guidance.
-
Allowlist Package Sources — Only allow installation from trusted registries or domains (trusted registries and signed manifests). See SAFE-M-6.
-
Manual Tool Approval — Require human/security review and approval before tools are registered in production. See SAFE-M-11 for behavioral monitoring and approval workflows.
-
Sandboxed Installation / Review — Test new tools in isolated environments before allowing them in production. See SAFE-M-9.
-
Signed Packages & Installers — Require cryptographic signing of installers / packages. See SAFE-M-2 for signing, key management, and verification guidance.
- Rationale: Cryptographic signatures ensure integrity and origin verification of package metadata and prevent tampered manifests from being trusted by clients.
-
Allowlist Package Sources — Only allow installation from trusted registries or domains (trusted registries and signed manifests). See SAFE-M-6.
- Rationale: Restricting installation sources reduces exposure to typosquatting and malicious uploads; combined with registry verification it raises the attacker's cost.
-
Manual Tool Approval — Require human/security review and approval before tools are registered in production. See SAFE-M-11 for behavioral monitoring and approval workflows.
- Rationale: Human review can detect anomalies that automated checks miss (unexpected capabilities, suspicious manifest URLs) and provides accountability for approvals.
-
Sandboxed Installation / Review — Test new tools in isolated environments before allowing them in production. See SAFE-M-9.
- Rationale: Running installers in a sandbox reveals runtime behaviors (persistence, network callbacks) without risking production systems.
-
Tool Registration Monitoring — Audit and alert on newly registered tools; correlate registrations with CI and registry activity. See SAFE-M-6 and SAFE-M-11.
-
Install Behavior Monitoring — Monitor post-install behavior (service creation, cron jobs, new agents). See SAFE-M-11.
-
Network Monitoring — Track unexpected inbound/outbound connections from newly installed agents/tools; integrate with anomaly detection. See SAFE-M-12.
-
Quarantine affected host(s).
-
Unregister the malicious tool from the MCP registry.
-
Remove any installed agents or persistence mechanisms.
-
Rotate any secrets or credentials that may have been accessed.
-
Conduct a forensic analysis: collect the installer, check the manifest, examine logs to track the distribution path (how it was deployed).
-
Remediate by re-securing the package source (e.g., fix the compromised CI, remove typosquatted package, educate users).
-
SAFE‑T1001: Tool Poisoning Attack (TPA) — malicious instructions embedded in MCP tool descriptions/schema
-
SAFE‑T1004: (Hypothetical) Server Impersonation / Name-Collision — attacker uses fake MCP server to trick users
-
SAFE‑T1207: Hijacked Update Mechanism — attacker compromises update pipeline
- Tactic: Initial Access — https://attack.mitre.org/tactics/TA0001/
- Technique (phishing): T1566 — https://attack.mitre.org/techniques/T1566/
- Technique (supply chain / dependency confusion): T1195 — https://attack.mitre.org/techniques/T1195/
The following references include direct links. Entries without an explicit URL were removed to keep the references actionable.
- Model Context Protocol — Getting Started (Official Spec)
- CISA — Phishing Guidance: Stopping the Attack Cycle
- Neupane et al., “An In‑depth Look at Package Confusion” (USENIX Security 2023)
- Sonatype — Supply‑Chain Security & Dependency Hijack Reports
- NIST — AI Risk Management Framework (AI‑RMF)
- OWASP Top 10 for LLM Applications
| Version | Date | Changes | Author |
|---|---|---|---|
| 1.0 | 2025-11-15 | Initial write-up in the improved format | rajivsthh |
| 1.1 | 2025-11-16 | Reformat README to template, add Attack Flow diagram, embed example detection rule, clean references | rajivsthh |