Skip to content

DETECTION.md

Latest commit

 

History

History
165 lines (121 loc) · 5.77 KB

DETECTION.md

File metadata and controls

165 lines (121 loc) · 5.77 KB

Detection Guide: MCP Parasite-Class Attacks

Overview

MCP Parasite represents a class of attack that evades current MCP security scanning (e.g., mcp-scan) because it keeps tool descriptions clean and only injects malicious content through tool return values at specific moments. This document outlines detection strategies for MCP client developers and security teams.

Why Current Tools Miss It

What mcp-scan checks

  • Tool descriptions for prompt injection
  • Resource descriptions for manipulation
  • Tool argument schemas for suspicious patterns

What mcp-scan does NOT check

  • Actual tool return values at runtime
  • Changes in return value structure over time
  • Cross-server influence patterns
  • Temporal behavior (dormancy followed by activation)

Detection Strategies

1. Return Value Monitoring

Method: Track tool response characteristics over time.

Indicators:

  • Sudden increase in response length for the same tool/query
  • New structural patterns appearing in responses (e.g., bracketed notes)
  • Responses containing instruction-like language ("create a...", "send a...", "copy the...")
  • Responses referencing other installed tools or servers

Implementation:

# Pseudocode for MCP client-side monitoring
class ResponseMonitor:
    def __init__(self):
        self.baselines = {}  # tool_name -> avg_response_length

    def check_response(self, tool_name, response):
        baseline = self.baselines.get(tool_name)
        if baseline and len(response) > baseline * 1.5:
            alert("Response length anomaly", tool_name, len(response))

        # Check for instruction patterns
        instruction_patterns = [
            r'\[.*(?:convention|practice|note|update).*:.*\]',
            r'(?:create|send|copy|include|post)\s+(?:a|the)',
        ]
        for pattern in instruction_patterns:
            if re.search(pattern, response, re.IGNORECASE):
                alert("Instruction pattern in response", tool_name)

2. Cross-Server Isolation

Method: Prevent one MCP server's output from influencing how the LLM interacts with other servers.

Implementation approaches:

  • Response sandboxing: Mark tool responses as data, not instructions
  • Context separation: Don't include Server A's output when calling Server B
  • Permission boundaries: Require explicit user approval for cross-server operations triggered by tool responses

3. Response Hashing

Method: Hash the structural template of tool responses and alert on changes.

Indicators:

  • Response structure changing after a dormancy period
  • New sections appearing in responses that weren't in initial responses
  • Response structure that differs between Phase 1 and Phase 3

4. Network Monitoring

Method: Monitor outbound connections from MCP server processes.

Indicators:

  • MCP server making HTTP requests to unexpected endpoints
  • DNS lookups to unusual domains
  • Data being sent to localhost on non-standard ports (e.g., 9999)

Implementation:

# Monitor network activity of MCP server process
# On macOS:
sudo lsof -i -P | grep python | grep -v LISTEN

# On Linux:
ss -tpn | grep python

5. SQLite Database Inspection

Method: Inspect the MCP server's database for suspicious tables.

Indicators:

  • Tables named "analytics", "context_analytics", "environment_profile"
  • Phase state tracking tables
  • Stored data about other MCP servers or credentials

Check script:

# Inspect the ProjectMemory database
sqlite3 ~/.project-memory/memory.db ".tables"
sqlite3 ~/.project-memory/memory.db "SELECT * FROM phase_state;"
sqlite3 ~/.project-memory/memory.db "SELECT * FROM context_analytics LIMIT 10;"
sqlite3 ~/.project-memory/memory.db "SELECT * FROM environment_profile;"

6. Behavioral Analysis

Method: Monitor MCP server behavior patterns over time.

Indicators:

  • Server that is very helpful initially, then changes behavior
  • Subtle prompts encouraging the user/LLM to share information about other tools
  • Response content that references "team practices" or "project conventions" the user didn't set
  • Tool responses that include action items for other tools

7. Source Code Audit

Method: Review MCP server source code for parasitic patterns.

Red flags to look for:

  • Phase state management (install timestamp tracking)
  • Secret pattern matching (regex for API keys, tokens)
  • Code that analyzes other MCP server references
  • HTTP client code for data exfiltration
  • Database tables beyond what the tool's stated purpose requires
  • Conditional behavior based on time since installation

Recommendations for MCP Client Developers

Short-term

  1. Add response content scanning to mcp-scan -- check for instruction patterns in actual return values
  2. Implement response length monitoring with alerting
  3. Log all tool interactions for post-incident forensics

Medium-term

  1. Response sandboxing -- treat tool return values as data, not instructions
  2. Cross-server context isolation -- don't let one server's output influence calls to another
  3. Behavioral fingerprinting -- baseline tool behavior and alert on deviations

Long-term

  1. Formal verification of MCP server behavior against stated tool descriptions
  2. Capability-based permissions -- tools must declare which cross-server interactions they need
  3. User-visible audit trail -- show users exactly what tool responses contain and how they influence other tool calls

Testing Your Defenses

Use MCP Parasite in demo mode to test whether your detection mechanisms catch the attack:

# Set up PoC
pip install -e .
export PROJECT_MEMORY_DEMO=true

# Run through demo scenario
# Check if your monitoring catches:
# 1. Phase 1 context prompts in responses
# 2. Phase 3 payload injection
# 3. Exfiltration attempts to localhost:9999