Most security investigations end up on the dark web eventually: leaked credentials on paste sites, a ransomware gang’s victim list, a stealer-log dump, a Bitcoin ransom address, a .onion marketplace. The data exists, but it is spread across sixteen-odd platforms, each with its own API, auth, rate limits, and output shape. One investigation means a dozen browser tabs and a lot of manual correlation.
darknet-mcp-server collapses that into one interface. It exposes 66 tools across 16 data sources over the Model Context Protocol, so an AI agent can query all of them, correlate the results across surface and dark web, and hand back a single picture instead of sixteen dashboards. It’s published on npm under the MIT license (v0.1.1, a few thousand downloads at the time of writing).
What it covers
Sixteen sources, grouped by what they answer:
| Source | Auth | Tools | Provides |
|---|---|---|---|
| Tor network | none | 7 | .onion fetch/scrape, Ahmia search, exit-node intel |
| ransomware.live | none | 6 | victim lists, group profiles, country/sector filters |
| RansomLook | none | 2 | 580+ ransomware groups, recent posts |
| Have I Been Pwned | optional | 7 | breach database, k-anonymity password check, paste search |
| ThreatFox (abuse.ch) | optional | 4 | IOC database, malware-family tracking |
| URLhaus (abuse.ch) | optional | 2 | malware distribution URL tracking |
| MalwareBazaar (abuse.ch) | optional | 3 | sample repository, YARA search |
| AlienVault OTX | optional | 5 | threat pulses; IP/domain/hash/CVE intel |
| AbuseIPDB | required | 4 | IP abuse reports, confidence scoring, CIDR checks |
| GreyNoise | none | 2 | internet-noise classification, scanner detection |
| Pulsedive | optional | 3 | indicator enrichment, risk scoring |
| Hudson Rock Cavalier | required | 3 | stealer-log search by domain/email/IP |
| Vulners | optional | 3 | vulnerability + exploit search (NVD, ExploitDB, Metasploit) |
| Blockchain.info + ChainAbuse | none | 4 | Bitcoin address/tx lookup, scam reports |
| Hybrid Analysis | required | 3 | malware sandbox, MITRE ATT&CK mapping |
| IntelligenceX | required | 4 | dark-web content, leaked data, phonebook |
| CIRCL AIL + PhishTank + meta | none | 3 | .onion metadata, phishing-URL checks, source listing |
Forty-four of the 66 tools work with no API key at all. The sixteen that need one — AbuseIPDB, the Hudson Rock stealer logs, Hybrid Analysis, IntelligenceX, and the account-level HIBP searches — degrade cleanly when the key is absent: the tool returns a clear error naming the key it wants, rather than failing silently.
How it works
The server runs as a stdio process. An MCP client — CyberStrike, Claude, anything that speaks the protocol — spawns it as a child and talks to it over stdin/stdout:
{
"mcpServers": {
"darknet": {
"command": "npx",
"args": ["-y", "darknet-mcp-server"]
}
}
}A few implementation details matter more than the rest:
- Tor without a DNS leak. The
tor_*tools route through a local SOCKS5 proxy using thesocks5h://scheme. Thehis the point: hostname resolution happens on the Tor daemon’s side, not locally, so your resolver never sees the.onionlookup. Without it, the local resolver tries to resolve a.onionname and fails. - Every input is validated. Each tool has a zod schema on its arguments, so the agent can’t send a malformed query — the same argument-validation discipline we wrote about in ten ways to secure your MCP servers.
- Per-source rate limits keep each API inside its terms rather than hammering it, and
.onionpages are parsed withcheeriointo structured{ title, links, text }instead of dumped as raw HTML.
A real investigation
The reason to put all of this behind one protocol is correlation. Here is pre-engagement recon for an authorized assessment of target-corp.com, as the agent runs it:
breachSearch("*@target-corp.com")
→ 3 breaches (Adobe 2013, LinkedIn 2021, Collection #1)
stealer_domain("target-corp.com")
→ 47 infected machines in stealer logs; 12 with VPN creds, 8 with cloud console access
ransomwareSearch("target-corp.com")
→ no matches (not a known ransomware victim)
threatfoxSearch("target-corp.com")
→ 2 IOCs: a subdomain used as a C2 callback, a phishing page on a marketing subdomain
otx_domain("target-corp.com")
→ 5 threat pulses reference the domain, 2 from APT campaignsNo single one of those queries is novel. The value is that one agent ran all five in a conversation turn, then synthesized them: significant credential exposure across three breaches, 47 machines in stealer logs with twelve holding VPN credentials, two active IOCs suggesting recent compromise — rotate credentials for everyone in the stealer logs, investigate the C2 subdomain, raise monitoring during the assessment. That’s work that would otherwise mean five tabs and a spreadsheet.
The same shape applies to incident response (hash → MalwareBazaar → Hybrid Analysis MITRE mapping → ThreatFox C2 → AbuseIPDB → GreyNoise) and to ransomware tracking (group profile → claimed victims → sector/country filters → live .onion leak-site scrape → Bitcoin wallet activity). The agent chains the sources; the analyst reads the conclusion.
Where it fits in CyberStrike
darknet-mcp-server is one of the built-in MCP servers in the CyberStrike suite, alongside the browser-testing and infrastructure servers. It ships disabled by default — you turn it on deliberately in config or under Settings → MCP Servers:
// cyberstrike.json
{ "mcp": { "darknet": { "enabled": true } } }Once enabled, its 66 tools join the agent’s registry through a lazy tool layer — only lightweight metadata sits in context, and full definitions load on demand when the agent actually reaches for a tool. A web assessment might use the browser server to crawl, the infrastructure server to fingerprint, and this one to check whether discovered credentials show up in a breach or a stealer log — all in the same run. Splitting tools behind a protocol instead of baking them into one monolith is the same reasoning we laid out in MCP vs A2A.
Use it responsibly
This is dual-use tooling, and it’s worth being plain about that — the same point we made about offensive agents in when AI becomes the attacker. Breach databases, stealer logs, and dark-web search are lawful for defenders assessing their own exposure or running an authorized engagement, and a liability the moment they’re pointed at a target that never agreed to it.
A few ground rules:
- Query what you’re authorized to. Searching your own domain’s breach and stealer-log exposure is defense. Harvesting a third party’s leaked credentials is not — scope it in writing before you run it.
- Handle what comes back carefully. Stealer logs and breach dumps contain real credentials and personal data. Treat results as sensitive material: minimize what you store, and don’t paste them somewhere they’ll leak again.
- Mind the data sources’ own terms. HIBP, AbuseIPDB, IntelligenceX and the rest each set limits on how their data may be used; the API key you hold is also an agreement you signed.
The tool reaches the data; it doesn’t decide whether you should. That part stays with a human who owns the engagement.
Getting started
Standalone, in any MCP client:
npx darknet-mcp-serverThe seven Tor tools need a local Tor daemon for .onion access; everything else works without it:
# macOS
brew install tor && tor
# verify the SOCKS5 proxy is up
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ipAPI keys are all optional and passed through the environment — HIBP, abuse.ch, AbuseIPDB, Hudson Rock, Hybrid Analysis, IntelligenceX, Vulners. Set the ones you have; the rest of the tools keep working.
Published on npm as darknet-mcp-server (MIT). Part of the CyberStrike embedded MCP server suite — see also ten ways to secure your MCP servers and MCP vs A2A.
