Introducing HPThreat: I Built an MCP Server That Turns Claude Into a Honeypot Operator

Turning raw attacker noise into real-time, actionable threat intelligence with Claude and MCP

Mar 31, 2026

Attackers are noisy. They scan, probe, brute-force, download malware, and pivot — leaving a trail of indicators every step of the way. The problem has never been that they don’t generate signal. The problem is that capturing and acting on that signal is hard, slow, and requires specialized tooling most blue teams don’t have the bandwidth to maintain.

Honeypots have always been the answer to that problem in theory. In practice, they sit misconfigured on a shelf, generate logs nobody reads, and get decommissioned after six months when the engineer who set them up leaves the company.

I wanted to change that. So I built HPThreat — an MCP server that connects Claude directly to your honeynet, turning raw attacker activity into structured threat intelligence in real time.

The code is live at github.com/rod-trent/HPThreat.

The Core Idea

The Model Context Protocol (MCP) lets you give Claude tools — callable functions it can use during a conversation. Most MCP servers built so far wrap things like file systems, databases, or web search. Nobody had built one for deception infrastructure.

HPThreat exposes ten tools that cover the full honeypot lifecycle:

When you connect HPThreat to Claude, your entire honeynet becomes conversational. You don’t log into a dashboard, run scripts, or grep through NDJSON files at 2am. You ask.

A Real Conversation

Here’s what working with HPThreat actually looks like. I deployed a Cowrie SSH honeypot and let it run for a few hours:

Me: Deploy an SSH honeypot called ssh-trap-01 on port 2222.

Claude: Deployed. Container is running, logs are being written to data/logs/cowrie/ssh-trap-01/cowrie.json. Simulation mode is off — this is a live sensor.

Me: What’s it caught so far?

Claude: In the last 24 hours, ssh-trap-01 has logged 569 events from 8 unique source IPs. Here’s the breakdown:

Failed logins: 412 across 14 unique usernames (root, admin, ubuntu, pi, oracle...)
Successful logins: 15 — attackers who guessed correctly
Commands executed: 66
Files downloaded: 5 — malware samples captured

TTPs detected: T1110.001 (Password Guessing), T1021.004 (SSH Lateral Movement), T1059.004 (Unix Shell Execution), T1105 (Tool Transfer), T1082 (System Discovery), T1087 (Account Discovery), T1070.003 (History Clearing), T1016 (Network Discovery), T1053.003 (Cron Persistence).

Sophistication score: APT-level (50%) — this attacker covered half the MITRE ATT&CK kill chain.

Me: Check the top attacker IP against threat feeds.

Claude: 185.220.101.47 — here’s what the feeds say:

AbuseIPDB: Confidence score 97/100. 847 total reports. Last reported 4 hours ago. ISP: Frantech Solutions (known Tor exit node host). Country: NL.
Feodo Tracker:Confirmed C2 node — associated with Emotet, last online 2 days ago on port 443.
Emerging Threats: 12 matching rules across emerging-trojan and emerging-exploit categories.

Verdict: MALICIOUS

Me: Generate a Sigma rule for the brute force pattern and give me the full report.

Claude: Here’s your Sigma rule:

YAML

title: 'Honeypot Detection: Brute Force: Password Guessing'
id: 48b3a1cf-2127-4b91-a6a4-654fcf83caae
status: experimental
description: 'Auto-generated Sigma rule from HPThreat honeypot ssh-trap-01.
  ATT&CK Technique: T1110.001 - Brute Force: Password Guessing.'
references:
  - https://github.com/rod-trent/HPThreat
  - https://attack.mitre.org/techniques/T1110/001/
author: HPThreat MCP Server
date: 2026/03/30
tags:
  - attack.t1110_001
  - attack.credential_access
logsource:
  product: linux
  service: cowrie
detection:
  src_ips:
    src_ip:
      - 185.220.101.47
      - 194.165.16.11
      - 45.142.212.100
  condition: src_ips
falsepositives:
  - Legitimate administrative access (honeypot environment only)
level: medium

Full report saved to data/reports/ssh-trap-01_20260330_142301.md. ATT&CK Navigator layer JSON is ready to paste at mitre-attack.github.io/attack-navigator.

That entire interaction — deployment, analysis, threat correlation, Sigma generation, and report — took about four minutes. No scripts. No dashboards. No terminal tab-switching.

Under the Hood

HPThreat is a Python server built on FastMCP. Here’s a simplified picture of how data flows through it:

Attacker
   │
   ▼
Docker Container (Cowrie / Dionaea / HTTP Flask decoy)
   │  bind-mounted log volume
   ▼
data/logs/{type}/{name}/
   │
   ├── parsers/          ← NDJSON → structured events
   ├── analysis/         ← IOC extraction, TTP mapping, Sigma gen
   ├── intel/            ← AbuseIPDB, Feodo Tracker, Emerging Threats
   └── exporters/        ← JSON, CSV, STIX 2.1, Markdown reports
         │
         ▼
   MCP Tools  ←──── Claude ←──── You

The three honeypot types

Cowrie (SSH/Telnet) is the workhorse. It’s a well-maintained Python honeypot that emulates a real Linux shell. Every failed login, successful login, command, and file download is written to a structured JSON log. HPThreat parses the Cowrie NDJSON format and maps events directly to MITRE ATT&CK techniques — brute force, credential access, execution, tool transfer, persistence via cron, defense evasion via history clearing, and more.

Dionaea simulates FTP, SMB, HTTP, MSSQL, MySQL, and SIP simultaneously. It’s designed to catch worms and automated exploit frameworks that spray common vulnerability probes. HPThreat reads Dionaea’s JSON logs or its SQLite database (it falls back gracefully if one isn’t available).

The HTTP decoy is a custom Flask app I built specifically for this project. It accepts every HTTP method on every path, returns convincing fake Apache responses, and logs the full request — path, headers, body, user agent — as JSON. It catches path traversal attempts, injection probes, scanner fingerprints, and .env file hunters.

Simulation mode

If you don’t have Docker running — or you’re evaluating HPThreat on a laptop on a plane — set HONEYPOT_SIMULATION=true. The server generates statistically realistic attack traffic: brute-force campaigns from real-looking attacker IPs, successful logins followed by shell commands, malware downloads with real-looking hashes, reverse shell payloads, and HTTP scan patterns from known scanner user agents.

Every tool works identically in simulation mode. The data looks like this because it is based on patterns from real-world honeypot captures.

IOC quality

One thing I cared a lot about: the IOC extractor doesn’t just pull IPs. It walks every event and extracts:

Source IPs — deduplicated, with first-seen/last-seen/count
File hashes — SHA-256 from Cowrie download events, MD5 from Dionaea
URLs — from download events and from wget/curl commands
Credentials — username:password pairs with attempt frequency (useful for spotting spray patterns)
Commands — the full command string, tied to session and source IP
Reverse shells — detected via /dev/tcp/ pattern, C2 IP extracted separately and flagged

All of this is exportable as a proper STIX 2.1 Bundle — meaning it drops straight into OpenCTI, MISP, or any other threat intel platform that speaks STIX.

TTP mapping

HPThreat ships with 15 ATT&CK detection rules implemented as pure Python functions. Each rule has a condition lambda (does the event set match this pattern?) and an evidence function (which events triggered it?). No ML, no embeddings, no external API — just deterministic behavioral matching.

The correlate_ttps tool goes further: it scores attack sophistication as a percentage of the full ATT&CK kill chain covered, labels the attacker as Script-Kiddie / Intermediate / APT-level, and produces a JSON layer you can load directly into the ATT&CK Navigator to visualize the kill chain visually.

Why MCP?

The obvious question: why not just build a web dashboard?

Dashboards are great for monitoring known patterns. They’re terrible for investigation. When you’re staring at a spike in login failures at 3am and you want to know is this the same campaign that hit us last month, and should I block this /24, and what’s the right Sigma rule to push to the SIEM right now — a dashboard gives you charts. Claude gives you answers.

The other reason: composability. Because HPThreat is an MCP server, you can combine it with other MCP servers in the same Claude session. Imagine correlating HPThreat’s attacker IPs with your Splunk MCP server, then drafting an incident response ticket via a Jira MCP server, all in one conversation. That kind of cross-tool reasoning is what makes the MCP ecosystem genuinely different from a collection of standalone tools.

Getting Started

Option 1: Local (with Docker)

Bash

git clone https://github.com/rod-trent/HPThreat
cd HPThreat
pip install -r requirements.txt
cp .env.example .env
# Add your ABUSEIPDB_API_KEY to .env (free tier works fine)

Add to your Claude Desktop config (%APPDATA%\Claude\claude_desktop_config.json on Windows, ~/Library/Application Support/Claude/claude_desktop_config.json on Mac):

JSON

{
  "mcpServers": {
    "honeypot": {
      "command": "python",
      "args": ["C:\\path\\to\\HPThreat\\server.py"],
      "env": {
        "ABUSEIPDB_API_KEY": "your_key_here"
      }
    }
  }
}

Restart Claude Desktop. You’ll see the hammer icon indicating HPThreat’s tools are available.

Option 2: Railway (no Docker required)

Deploy in one click from the GitHub repo. Set HONEYPOT_SIMULATION=true in Railway’s environment variables — the server runs fully without Docker and all tools work. Railway auto-injects PORT; the server picks it up automatically.

Connect Claude Desktop remotely using mcp-remote:

JSON

{
  "mcpServers": {
    "honeypot": {
      "command": "npx",
      "args": ["mcp-remote", "https://your-app.up.railway.app/mcp"]
    }
  }
}

Option 3: Simulation mode anywhere

Bash

HONEYPOT_SIMULATION=true python server.py --transport streamable-http

No Docker, no API keys, no network access required. Great for demos, training, or just kicking the tires.

What I’m Building Next

HPThreat v0.1 is the foundation. Here’s what I’m planning:

Persistence layer. Right now, analysis runs against in-memory parsed events. I want to add a lightweight SQLite store so you can query attack history across rolling 30-day windows, spot the same attacker IP across multiple campaigns, and track credential reuse over time.

Alert webhooks. When a honeypot catches a successful login or a known-malicious IP, fire a webhook to Slack, Teams, or a SIEM. The MCP tools are great for investigation — but you shouldn’t have to ask Claude “did anything happen?” every morning. Push-based alerting for high-severity events is the natural complement.

More honeypot types. A fake RDP service. A fake AWS metadata endpoint at 169.254.169.254. A fake Kubernetes API server. Attackers probe all of these; I want sensors for all of them.

GreyNoise and Shodan integration. AbuseIPDB and Feodo Tracker are good, but GreyNoise’s mass-scanner context and Shodan’s infrastructure data would meaningfully improve the verdict quality for individual IPs.

Campaign correlation. When the same IP hits three different honeypots in a 24-hour window with overlapping TTPs, surface that as a campaign object. Link the indicators. Name the campaign. That’s the difference between individual IOCs and actionable threat intelligence.

The Bigger Picture

Security tooling has a complexity problem. The tools that give you the deepest visibility — SIEMs, EDR consoles, threat intel platforms — require weeks of configuration and years of expertise to use well. Meanwhile, simpler tools that non-specialists can actually operate often produce signal that’s too shallow to act on.

MCP closes that gap. You can wrap sophisticated infrastructure in a conversational interface without dumbing it down. The tool remains as powerful as it was; it just becomes accessible to anyone who can describe what they want in plain English.

HPThreat is my attempt at proving that with deception technology specifically. Honeypots are one of the highest signal-to-noise threat detection mechanisms available to defenders — they virtually never false-positive, because nothing legitimate should be touching them. The only reason they’re underutilized is operational friction.

If this project removes that friction for even a handful of blue teams, it will have been worth building.

The code is at github.com/rod-trent/HPThreat. PRs, issues, and ideas are welcome.

Discussion about this post

Ready for more?