shinthink/blitzstrikeMCP-Server, der eine dreistufige Penetrationstest-Methodik paketiert: Angriffsflächen-Aufklärung, Source-to-Sink-Statische Analyse und Live-Validierung von Befunden mit Eskalationsketten.
Reconnaissance at speed. Analysis in depth. Validation before report.
Blitz Strike ist eine strukturierte Penetrationstest-Methodik — Reconnaissance,
Quellcode-Analyse und Validierung — bereitgestellt als universeller MCP-Server. Er
enumeriert die Angriffsfläche (BLITZ), verfolgt die Erreichbarkeit von Source zu
Sink (EAGLE-EYE) und verifiziert jeden Fund live, bevor er gemeldet wird (STRIKE).
Ein Server, jeder Agent: von der Scope-Durchsetzung bis zu einreichungsfertigen
Funden in einem einzigen run_engagement-Aufruf, mit dem relevanten
Exploit-Tool-Handbuch an jedes Ergebnis angehängt.
Ein Scan-Treffer ist eine Hypothese. Ein Live-Test ist das Urteil.
Blitz Strike existiert, um die zwei häufigsten Fehlermodi in der automatisierten Sicherheitsbewertung zu eliminieren: False Positives durch oberflächliches Pattern-Matching und unverifizierte Funde, die ohne Live-Bestätigung gemeldet werden.
Blitz Strike ist ein Model Context Protocol (MCP)-Server (TypeScript / Bun), der
eine dreistufige Sicherheitsaudit-Methodik als aufrufbare Tools verpackt — und
die gesamte Engagement serverseitig ausführt, sodass ein einziger
run_engagement-Aufruf aus Claude Code, Cursor, Hermes, OpenCode, Claude Desktop,
Gemini oder jedem MCP-Client funktioniert.
Blitz Strike bildet eine strukturierte Penetrationstest-Methodik — Reconnaissance, Quellcode-Analyse und Validierung — auf drei Tool-Stufen ab, die serverseitig ausgeführt werden.
| Stufe | Name | Phase | Was es tut |
|---|---|---|---|
| 1 | BLITZ | Reconnaissance & Angriffsflächen-Mapping | Enumeriert die exponierte Angriffsfläche im großen Maßstab: nicht authentifizierte Einstiegspunkte, gefährliche Sinks und Authentifizierungsgrenzen. |
| 2 | EAGLE-EYE | Statische Analyse & Datenflussverfolgung | Verfolgt die Erreichbarkeit von Source zu Sink und reichert Funde gegen den Eskalationsketten-Graphen an. Bestätigt, dass ein Sink erreichbar, nicht authentifiziert und ausnutzbar ist — nicht bloß vorhanden. |
| 3 | STRIKE | Validierung & Ausnutzung | Führt Live-Verifikation durch (Marker-Reflexion + Negativkontrolle), Scope-Durchsetzung und Orchestrierung, sodass ein Fund bestätigt wird, bevor er jemals gemeldet wird. |
Reconnaissance → Analyse → Validierung. Nichts wird gemeldet, bis STRIKE es bestätigt.
Über die drei Stufen hinaus liefert Blitz Strike außerdem Web3-Audit (deterministischer Solidity- + ausführbarer Foundry-Beweis), einen Live-Logic-Bug-Prober (Sibling-Enumeration + differenzieller IDOR), Hunting-Intel (CWE/CVE-Watchlist + DNS-Sinkhole-Erkennung) und Out-of-Band-Beweis — sodass IDOR-/Auth-Logic-Bugs, blinde Injection und Smart-Contract-Funde alle erfasst und bewiesen werden, nicht nur per Pattern-Matching abgeglichen.
Blitz Strike wird vom LLM gesteuert — Claude, Hermes, OpenCode, Codex oder jedem MCP-Client. Das LLM ist das Gehirn (plant, routet, delegiert, urteilt); Blitz Strike sind die deterministischen Hände + das Wissen + die Guardrails.
Ein vollständiges Engagement ist ein Aufruf oder ein granularer, agenten-orchestrierter Zyklus:
npx blitzstrike serve --mcp # connect your agent, then ask it to
# "audit ./src" (source) or "audit https://example.com" (live)
Die LLM-Klasse klassifiziert das Ziel automatisch (URL → Live-Pipeline,
Dateisystempfad → Quell-Pipeline) und steuert dann recon → analyze → verify → review →
report — geleitet von der mitgelieferten Doktrin (instructions + Skills + pro Schritt
next_steps) und auf die nativen Sub-Agenten der Plattform verteilt.
→ Autonomie & Doktrin — wie die LLM gesteuert wird.
bun build --compile — eine ausführbare Datei pro Plattform ausliefern.bunx blitzstrike / npx blitzstrike.@modelcontextprotocol/sdk).# Zero-install — works from any MCP client, no clone, no build
npx -y blitzstrike doctor # verify the environment
npx -y blitzstrike install # auto-register with every detected agent CLI
npx blitzstrike install erkennt jede installierte Agent-CLI (Claude Code,
Cursor, OpenCode, Codex, Hermes, Gemini, Windsurf, Copilot, Cline) und schreibt
die korrekte MCP-Konfiguration in jede einzelne in ihrem nativen Format. Starte deinen Agenten neu und
rufe run_engagement auf.
Aus der Quelle:
git clone https://github.com/shinthink/blitzstrike.git
cd blitzstrike
bun install
bun run src/index.ts serve --mcp
{
"mcpServers": {
"blitzstrike": {
"command": "blitzstrike",
"args": ["serve", "--mcp"]
}
}
}
claude_desktop_config.json oder .mcp.json.cursor/mcp.json.mcp.jsonmcp_servers: in config.yamlFühre blitzstrike install aus, um das exakte Snippet auszugeben.
blitzstrike serve --mcp # start MCP server over stdio (default)
blitzstrike doctor # health check: runtime + 130-tool catalog + creds
blitzstrike install # write MCP config to detected clients (Claude/Cursor/OpenCode)
blitzstrike install --dry-run # preview the config without writing
blitzstrike sync-data # fetch heavy datasets (payloads + templates) on-demand
blitzstrike update # check for a newer version + refresh the data cache
blitzstrike version # print version
| Prüfung | Status, den du siehst |
|---|---|
| Runtime (bun/node) | OK / FAIL + Fix |
| Security-Tools-Katalog | 63/130 installiert, 67 on-demand |
| FOFA-Zugangsdaten | OK / WARN + Fix |
| Datenschichten (chains + tools-catalog) | vorhanden / fehlend |
Jedes Problem trägt eine fix:-Zeile — kein Rätselraten.
blitzstrike install erkennt, welche MCP-Client-Konfigurationsdateien bereits
existieren (Claude ~/.claude.json, Cursor ~/.cursor/mcp.json, Projekt .mcp.json) und
merged den Blitz Strike Server-Eintrag hinein — es überschreibt niemals deine
bestehenden MCP-Server. Wird kein Client erkannt, wird das Snippet zum manuellen
Einfügen ausgegeben.