KI-gestützter autonomer Penetrationstest-Agent

AIRecon ist ein autonomer Penetrationstest-Agent, der ein selbst gehostetes Ollama-LLM mit einer Kali-Linux-Docker-Sandbox, nativer Caido-Proxy-Integration, einer strukturierten RECON → ANALYSIS → EXPLOIT → REPORT-Pipeline und einer Echtzeit-Textual-TUI kombiniert — komplett offline, keine API-Schlüssel erforderlich.

---

Warum AIRecon?

Kommerzielle API-basierte Modelle (OpenAI GPT-4, Claude, Gemini) werden für rekursive, autonome Recon-Workflows, die pro Sitzung Tausende von LLM-Aufrufen erfordern können, unerschwinglich teuer.

AIRecon ist zu 100 % für den lokalen, privaten Betrieb konzipiert.

Funktion	AIRecon	Cloud-basierte Agenten
API-Schlüssel erforderlich	Nein	Ja
Zieldaten an die Cloud gesendet	Nein	Ja
Funktioniert offline	Ja	Nein
Caido-Integration	Nativ	Keine
Sitzung fortsetzen	Ja	Unterschiedlich
Lokale Wissensdatenbank	~1,09 Mio. Einträge	Keine

• Datenschutz zuerst — Zielinformationen, Tool-Ausgaben und Berichte verlassen niemals deinen Rechner.
• Caido-nativ — 5 integrierte Tools: list, replay, automate (§FUZZ§), findings, scope.
• Kompletter Stack — Kali-Sandbox + Browser-Automatisierung + eigener Fuzzer + Schemathesis-API-Fuzzing + Semgrep-SAST.
• Skills-Wissensdatenbank — 57 integrierte Skill-Dateien, 289 automatische Keyword→Skill-Zuordnungen. Erweiterbar durch airecon-skills — eine Community-Skill-Bibliothek mit 57 zusätzlichen CLI-basierten Playbooks für CTF, Bug Bounty und Pentesting.
• Lokale Sicherheits-Wissensdatenbank — Das optionale airecon-dataset indiziert ~1,09 Mio. Sicherheitsdatensätze (CVEs, Red-Team-Techniken, CTF-Writeups, Nuclei-Templates, Bug-Bounty-Payloads) in lokale SQLite-FTS5-Datenbanken. Das LLM ruft dataset_search autonom auf, bevor es unbekannte Techniken ausprobiert — und verankert seine Entscheidungen so in realen indizierten Daten.

---

Pipeline

RECON → ANALYSIS → EXPLOIT → REPORT

Jede Phase hat spezifische Ziele, empfohlene Tools und automatische Übergangskriterien. Die Durchsetzung der Phasen ist soft — der Agent wird geleitet, aber niemals blockiert. Checkpoints laufen alle 5 (Phasenbewertung), 10 (Selbstbewertung) und 15 (Kontextkomprimierung) Iterationen.

---

Speicher & Lernen (Was es tatsächlich tut)

AIRecon nimmt kein Fine-Tuning des LLM vor. Sein „Lernen“ ist eine lokale, strukturierte Telemetrie, die die Tool-Auswahl leitet und das Wiederholen fehlgeschlagener Wege vermeidet.

Lokale Persistenz (alles auf der Festplatte, keine Cloud):

• SQLite-Speicherdatenbank unter ~/.airecon/memory/airecon.db, die Sitzungen, Erkenntnisse, Muster, Zielinformationen, Tool-Nutzung, Modellleistung, Skill-Nutzung und entdeckte Angriffsketten speichert.
• Adaptiver Lernzustand unter ~/.airecon/learning/global_learning.json (Tool-Leistungsstatistiken, Strategiemuster, Beobachtungsprotokoll, destillierte Erkenntnisse).
• Pro Ziel separate Speicherdateien unter ~/.airecon/memory/by_target/, sofern persistiert, mit Endpunkten, Schwachstellen, WAF-Bypasses, sensiblen Parametern und Auth-Endpunkten.
• Payload-Speicher-Snapshots können bei laufender Sitzungspersistenz unter workspace/<target>/payload_memory.json gespeichert werden.

Wie es das Verhalten beeinflusst:

• Beim Sitzungsstart wird Speicherkontext injiziert (Zielinformationen, ähnliche Erkenntnisse, gelernte Muster, Tool-Zuverlässigkeit).
• Alle 8 Iterationen können gelernte Muster und ähnliche Erkenntnisse basierend auf der erkannten Technologie erneut injiziert werden.
• Adaptives Tool-Ranking nutzt historische Erfolge/Fehlschläge, um Tools zu ordnen und Strategien vorzuschlagen.
• Der Payload-Speicher (sofern aktiviert) überspringt Payloads, die für dasselbe Ziel/denselben Parameter wiederholt fehlgeschlagen sind.

---

Modellanforderungen

AIRecon erfordert ein Modell mit erweitertem Denken (<think>-Blöcke) und zuverlässigen Tool-Calling-Fähigkeiten. Die Fähigkeiten werden automatisch über die ollama show-Metadaten erkannt.

⚠️ Tool-Calling-Unterstützung ist ERFORDERLICH. Das Modell muss natives Funktions-/Tool-Calling unterstützen. Modelle ohne diese Fähigkeit können keine Tools ausführen (http_observe, execute, Browser-Aktionen usw.), was AIRecon völlig funktionsunfähig macht.

Empfohlenes Minimum: 8B-9B Parameter. Modelle unter 8B sind technisch nutzbar, aber stark abgeraten — sie halluzinieren häufig Tool-Ausgaben, erfinden CVEs, ignorieren Scope-Regeln und erzeugen unzuverlässige Tool-Aufrufe.

Modell	Pull	VRAM	Hinweise
Qwen3.5 122B	ollama pull qwen3.5:122b	48+ GB	Beste Qualität, am zuverlässigsten
Qwen3.5 35B	ollama pull qwen3.5:35b	20 GB	Für die meisten Benutzer empfohlen
Qwen3.5 35b	ollama pull qwen3.5:35b-a3b	16 GB	MoE — weniger VRAM
Qwen3.5 9B	ollama pull qwen3.5:9b	6 GB	Minimal nutzbar — häufige Fehler zu erwarten

Orientierung zur Modellgröße:

• ≥32B: Zuverlässig für vollständige Recon-Pipelines, gute Tool-Calling-Genauigkeit
• 8B-14B: Für einfache Aufgaben nutzbar, mit 20–40 % Tool-Call-Fehlern und Halluzinationen rechnen
• <8B: Funktioniert technisch, erzeugt aber unzuverlässige Ergebnisse — für ernsthafte Tests nicht empfohlen

Bekannte Probleme: DeepSeek R1 erzeugt unvollständige Funktionsaufrufe. Modelle < 8B haben keine zuverlässige Tool-Calling-Unterstützung.

---

Ollama auf Google Colab ausführen (Begrenzte Hardware)

Wenn du keine GPU hast oder dein lokaler VRAM unter dem Minimum liegt, kannst du Ollama auf einer kostenlosen Google-Colab-T4-GPU ausführen und AIRecon über einen öffentlichen Tunnel damit verbinden.

Notebook öffnen:

So funktioniert es:

Google Colab GPU                     Your Local Machine
┌─────────────────────────┐          ┌──────────────────────────┐
│  Ollama (qwen3.5:9b)    │◄────────►│  AIRecon TUI             │
│  cloudflared tunnel     │  HTTPS   │  ollama_url: tunnel URL  │
└─────────────────────────┘          └──────────────────────────┘

Schritte:

1. Öffne den Colab-Link oben und wähle Laufzeit → Laufzeittyp ändern → T4 GPU
2. Führe alle Zellen von oben nach unten aus (dauert beim ersten Mal ~5–10 Minuten)
3. Kopiere den in Zelle 6 ausgegebenen Konfigurationsausschnitt in ~/.airecon/config.yaml: