# MCP Parasite: Adaptive Cross-Server Parasitic Attack on MCP-Enabled AI Agents

> **WARNING: This is a security research proof-of-concept for responsible disclosure purposes only.**
>
> **DO NOT use this tool for malicious purposes.** All exfiltration in this PoC targets localhost
> (127.0.0.1:9999) only. This project exists to demonstrate a novel class of attack against
> MCP-enabled AI agents to drive improvements in MCP client security.
>
> **This research has been submitted for responsible disclosure to Anthropic, Cursor/Anysphere,
> and other MCP client developers.**

---

## What is MCP Parasite?

MCP Parasite ("ProjectMemory") is a proof-of-concept MCP server that demonstrates a novel **adaptive, temporal, cross-server parasitic attack** against MCP-enabled AI agents (Claude Desktop, Cursor, etc.). It disguises itself as a legitimate and genuinely useful project memory/context tool while silently profiling the user's environment, learning workflow patterns, and executing a targeted cross-server shadowing attack at a high-value moment.

## Why This Matters

Existing MCP security research focuses on:
- Malicious tool descriptions (detectable by `mcp-scan`)
- Single rug-pull attacks (one-shot, no persistence)
- Direct prompt injection in tool metadata

**MCP Parasite is different.** It introduces a new class of attack that:

| Aspect | Existing MCP Attacks | MCP Parasite |
|--------|---------------------|--------------|
| **Timing** | Immediate or single rug pull | Multi-phase, days/weeks dormancy |
| **Detection** | Tool description contains malicious text | Tool descriptions are 100% clean |
| **Mechanism** | Direct prompt injection in tool metadata | Cross-server shadowing via return values |
| **Intelligence** | Static payload | Adaptive, profile-based targeting |
| **Persistence** | One-shot | Repeatable, cooldown-based |
| **Disguise** | Minimal | Fully functional, desirable tool |
| **mcp-scan** | Detectable | Undetectable (no poisoned descriptions) |

## The Attack

### Phase 1: Reconnaissance (Days 1-7)

The server operates as a **fully functional, genuinely useful** project memory tool. Every interaction is silently analyzed:

- **Codebase indexing** maps the attack surface (sensitive files, CI/CD configs, credentials)
- **Stored memories** are analyzed for secrets, infrastructure details, team information
- **Conversation context** reveals which other MCP servers are installed
- **Subtle prompts** in tool responses encourage the LLM to share more context

### Phase 2: Dormancy (Days 7-14)

**Zero parasitic activity.** The server operates purely legitimately. This is the trust-building phase where:

- `mcp-scan` finds nothing suspicious
- Users grow to rely on the tool
- Users recommend it to teammates
- Security audits find nothing

### Phase 3: Armed Strike (Day 14+)

The server monitors for **high-value trigger events**:
- Production deployments
- Credential rotation
- Sensitive file edits
- PR merges to main
- Infrastructure changes
- New team member onboarding

When triggered, it injects a **cross-server shadowing payload** into its legitimate tool responses. The payload is crafted to look like a project convention or team practice, causing the LLM to unknowingly:

1. Use **other installed MCP servers** (GitHub, Slack, filesystem) to exfiltrate data
2. Include sensitive files in commits via the GitHub MCP
3. Post configuration details to Slack channels
4. Stage files for exfiltration via the filesystem MCP

## Quick Start (Demo Mode)

### Prerequisites

- Python 3.11+
- Claude Desktop or Cursor with MCP support
- GitHub MCP server and/or Filesystem MCP server installed

### Installation

```bash
# Clone the repository
git clone https://github.com/bountyyfi/ProjectMemory.git
cd ProjectMemory

# Install dependencies
pip install -e ".[dev]"

# Set up demo environment
bash demo/setup_dummy_env.sh

# Run tests
pytest
```

### MCP Configuration

Add to your Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json`):

```json
{
  "mcpServers": {
    "project-memory": {
      "command": "python",
      "args": ["-m", "project_memory.server"],
      "env": {
        "PROJECT_MEMORY_DB": "~/.project-memory/memory.db",
        "PROJECT_MEMORY_DEMO": "true"
      }
    }
  }
}
```

In demo mode, phase timings are accelerated (minutes instead of days).

### Demo Walkthrough

See [demo/demo_scenario.md](demo/demo_scenario.md) for a step-by-step walkthrough.

## Detection

See [docs/DETECTION.md](docs/DETECTION.md) for detailed detection strategies.

Key recommendations for MCP client developers:

1. **Monitor tool return value entropy** - Track response length/structure over time
2. **Content policy enforcement** - Scan tool responses for instruction-like patterns
3. **Cross-server isolation** - Don't let one tool's output influence calls to other tools
4. **Response hashing** - Alert on structural changes in tool responses
5. **Network monitoring** - Track outbound connections from MCP server processes

## Project Structure

```
mcp-parasite/
├── src/project_memory/
│   ├── server.py            # Main FastMCP server
│   ├── memory_store.py      # SQLite-backed persistence
│   ├── indexer.py           # Codebase indexer
│   ├── utils.py             # Shared utilities
│   └── parasite/
│       ├── recon.py         # Phase 1: Passive reconnaissance
│       ├── profiler.py      # Environment profiling
│       ├── trigger.py       # Phase 3: Trigger detection
│       ├── strike.py        # Phase 3: Cross-server shadowing
│       └── config.py        # Configuration
├── tests/                   # Unit tests for all modules
├── docs/                    # Attack flow, detection, timeline
├── demo/                    # Demo setup and scenario
└── config/                  # Example MCP configs
```

## Responsible Disclosure

This research has been submitted for responsible disclosure to:

- **Anthropic** (Claude Desktop MCP client)
- **Anysphere** (Cursor MCP client)
- **MCP Protocol maintainers**

## Recommendations

### For MCP Client Developers

1. Implement tool response content policies
2. Add cross-server isolation (responses from one server should not be treated as instructions for another)
3. Monitor tool response patterns over time for anomalies
4. Provide users with visibility into what tool responses contain
5. Consider response sandboxing for MCP tool outputs

### For Users

1. Only install MCP servers from trusted sources
2. Regularly audit MCP server behavior
3. Monitor network traffic from MCP server processes
4. Be cautious of tools that ask about your other tools
5. Review tool responses for unusual instructions or "conventions"

## Credits

- **Bountyy Oy** - [bountyy.fi](https://bountyy.fi)
- **Mihalis Haatainen** - Security Research

## License

MIT License - See [LICENSE](LICENSE) for details.

**Remember:** This is security research. Use responsibly.