**So funktioniert es:**

1. **Claude Code** liest `CLAUDE.md` für die vollständige Pentest-Methodik und orchestriert den 7-Phasen-Workflow
2. **Rollen-spezialisierte Subagenten** (Scout, Analyzer, Exploiter, Reporter) führen fokussierte Aufgaben mit dedizierten Prompt-Vorlagen, Tool-Anleitungen und Anti-Patterns aus
3. **WSTG MCP Server** (68+ Tools) bietet OWASP-Testverfahren, 31 PortSwigger-Technikanleitungen, hierarchischen Aufgabenbaum, Wissensgraph, WAF-Evasion, Endpunkt-Priorisierung, Ergebnisverifikation, Kontextkompression, Qualitätsgates und Berichtserstellung
4. **Docker Container** führt alle 27 Sicherheitstools aus — Datenverkehr wird optional durch Burp Suite für passives Monitoring geleitet
5. **Playwright MCP** übernimmt Browser-basierte Tests (DOM XSS, Clickjacking, JS-gerenderte Login-Seiten)

---

## Funktionen

### Umfassende OWASP-Abdeckung
- **109 WSTG-Testfälle** in 12 Kategorien — von Informationssammlung bis API-Testing
- Jeder Test beinhaltet schrittweise CLI-Verfahren, kontextspezifische Payloads, Erkennungskriterien und Schweregrad-Rubriken
- Tests sind priorisiert (MUSS/SOLLTE) mit bedingten Auslösern, sodass nichts Relevantes übersprungen wird

### 31 PortSwigger-Angriffstechnikanleitungen
- Bezogen von der [PortSwigger Web Security Academy](https://portswigger.net/web-security) — Erkennungsmethoden, Exploitationstechniken, Payloads, Spickzettel und WAF-Bypass-Muster
- Nach Schwachstellenklasse organisiert (SQLi, XSS, SSRF, JWT, OAuth, etc.) zur direkten Nutzung während des Testens
- In jede Testphase integriert — Agenten laden automatisch die relevante Technikanleitung vor dem Testen jeder Schwachstellenklasse
- Datenbank-/plattformspezifische Payload-Tabellen (Oracle vs MySQL vs PostgreSQL vs MSSQL für SQLi, Jinja2 vs Twig vs Freemarker für SSTI, etc.)
- WAF-Bypass-Muster nach Bypass-Level organisiert (grundlegend → fortgeschritten → erweitert)

### 27 Vorkonfigurierte Sicherheitstools
- Alle Tools in einem einzigen Docker-Image vorinstalliert — `make setup` und Sie sind bereit
- Tools nach Phase organisiert: Entdeckung, Injection-Testing, Authentifizierung, Kryptografie, API-Testing
- Automatische Burp-Suite-Proxy-Integration für passives Datenverkehrs-Monitoring

### Strukturierter 7-Phasen-Workflow
- **Phase 0:** Anwendungsentdeckung & -kartierung
- **Phase 1:** Informationssammlung & Reconnaissance
- **Phase 2:** Konfigurations- & Bereitstellungstests
- **Phase 3:** Identität, Authentifizierung, Autorisierung & Session-Management
- **Phase 4:** Eingabevalidierungstests (pipeline-basierte XSS/SQLi/SSRF-Pipelines)
- **Phase 5:** Fehlerbehandlung, Kryptografie, Geschäftslogik, Client-seitiges & API-Testing
- **Phase 6:** Abdeckungsverifikation & Berichterstattung
- **Phase 7:** Finale Überprüfung & Behebung

### Qualitätssicherungssystem
- **Automatisierte Phasengates** — jede Phase muss Qualitätsprüfungen bestehen, bevor es weitergeht
- **Qualitätsprüfer**-Subagent bei jedem Phasenübergang identifiziert Lücken und schlägt Verbesserungen vor
- **Finaler Richter** — ein Zero-Context-Agent prüft den gesamten Engagement-Einsatz kalt, wie ein externer QA-Prüfer
- **Ausschöpfungsgates** — "nicht anfällig" erfordert den Nachweis ausreichender Testbemühungen (Mindestanzahl an Techniken und Bypass-Versuchen)

### Evidenzbasierte Erkenntnisse
- Jede Erkenntnis erfordert reproduzierbare curl-Befehle und vollständige Anfrage-/Antwort-Evidenz
- **Dreistufige Klassifizierung:** AUSGENUTZT (nachgewiesene Auswirkung), POTENZIELL (durch Kontrolle blockiert), FALSCHE_POSITIVMELDUNG (Kontrolle hält stand)
- **Anti-Halluzinations-Framework** — "kein Exploit = keine Erkenntnis" wird auf jeder Ebene durchgesetzt
- Evidenz-Checklisten pro Schwachstellenklasse werden verifiziert, bevor eine Erkenntnis protokolliert wird

### Rollen-spezialisierte Subagenten
- **4 dedizierte Rollen** mit fokussierten Prompt-Vorlagen, Tool-Anleitungen und Anti-Patterns:
  - **Scout** — nur Reconnaissance, kartiert die Angriffsfläche ohne Payloads zu senden (Phase 0-1)
  - **Analyzer** — identifiziert potenzielle Senken mit Canary-/Witness-Payloads, baut Exploitation-Warteschlangen auf (Phase 2-5 Analyse)
  - **Exploiter** — konsumiert Analyzer-Ergebnisse, beweist Exploitation mit Evidenz, protokolliert bestätigte Erkenntnisse (Phase 4 Exploitation)
  - **Reporter** — Qualitätsprüfung und finaler Richter, prüft Daten ohne Anfragen zu senden (QA + Nachbericht)
- Validierungs-Checkpoint zwischen Analyse und Exploitation verhindert verschwendeten Aufwand
- Jede Rolle hat explizite erlaubte/eingeschränkte Tool-Listen und Eingabe-/Ausgabe-Verträge

### Pipeline-basierte Exploitation (Phase 4)
- 3 unabhängige **Zwei-Stufen-Pipelines** laufen parallel: XSS, Injection (SQLi/CMDi), SSRF/SSTI
- Jede Pipeline: Analyzer (entdecken → analysieren → einreihen) → Validierungs-Checkpoint → Exploiter (exploitieren → protokollieren)
- Jede Pipeline lädt ihre PortSwigger-Technikanleitung für Erkennungsmethoden, Spickzettel und WAF-Bypass-Muster
- WAF-Intelligenz wird über alle Pipelines geteilt
- Kontextbewusste Witness-Payloads für 13 Senkentypen

### Adaptive WAF-Evasion
- **Automatische WAF-Fingerabdrucknahme** aus Antwort-Headern, -Body und -Statuscodes — identifiziert 12 WAF-Anbieter (Cloudflare, AWS WAF, Akamai, Imperva, ModSecurity, F5, FortiWeb, Sucuri, Barracuda, Wordfence, NAXSI, Citrix)
- **Anbieterspezifische Bypass-Payloads** organisiert nach Komplexitätsstufe (grundlegend → fortgeschritten → erweitert)
- WAF-Intelligenz wird über alle Agenten via Deliverable-System geteilt
- Agenten identifizieren automatisch WAF beim ersten Block-Antwort und wechseln zu maßgeschneiderten Bypass-Payloads

### Phasenübergreifender Wissensgraph
- **Entitäts-Beziehungs-Graph** verfolgt Endpunkte, Parameter, Technologien, Erkenntnisse, Cookies, Domains und Benutzerrollen
- **Automatische Schwachstellenverkettung** via BFS-Pfadfindung mit 7 vordefinierten Verkettungsmustern:
  - XSS + fehlendes CSP, XSS + schwaches Cookie (kein HttpOnly), Open Redirect + OAuth-Callback
  - IDOR + Admin-Rolle, SSRF + Cloud-Metadaten, Kein Lockout + Kein MFA, CORS + sensibler Endpunkt
- Schweregrad-Anhebungen, wenn die Verkettung die Auswirkung materiell erhöht
- Während des gesamten Testens befüllt, nach Phase 4 für die Verkettungserkennung abgefragt

### Hierarchischer Aufgabenbaum
- Persistente Baumstruktur (Phasen als Äste, Tests als Blätter) verhindert LLM-Tiefensuche-Bias und Kontextverlust
- Hauptagent behält strategische Makro-Ansicht; Subagenten aktualisieren nur ihre zugewiesenen Blattknoten
- Automatische Propagierung: Wenn alle Kinder abgeschlossen sind, schließt sich der Elternteil automatisch ab
- Phasenbezogene Abschlussprozentsätze für fundierte Entscheidungsfindung

### Endpunkt-Risikopriorisierung
- Bewerten und sortieren von Endpunkten nach Risiko für priorisiertes Testen — zuerst die höchsten Risiken testen
- Bewertungsfaktoren: Parameteranzahl, Technologie-Risikoindikatoren, Taint-Chain-Vertrauen, Tool-Konvergenz, Authentifizierungsanforderungen, injizierbare Parameternamen
- Integriert in die Endpunktkartenerstellung der Phase 0

### Tool-Ausgabe-Parsing
- **13 integrierte Parser** für gängige CLI-Tools (nmap, nuclei, sqlmap, ffuf, httpx, whatweb, testssl, nikto, dalfox, katana, gau, wapiti, commix)
- Reduziert rohe Tool-Ausgabe um das 3- bis 5-fache, während wichtige Erkenntnisse, Endpunkte und Fehler erhalten bleiben
- Konfigurierbare Ausführlichkeit: Zusammenfassung (~15 Zeilen), detailliert (~50 Zeilen), vollständig (vollständig geparste Ausgabe)

### CLI-Tool-Ergebnisverifikation
- Automatische Validierung der CLI-Tool-Ausgabequalität — erkennt leere Ausgaben, Proxy-Fehler, Berechtigungsprobleme und verdächtige Ergebnisse
- **10 Pro-Tool-Validatoren** (nmap, nuclei, sqlmap, ffuf, feroxbuster, testssl, dalfox, wapiti, katana, httpx) mit Korrekturvorschlägen für Befehle
- Wenn ein Tool eine leere oder verdächtige Ausgabe produziert, schlägt der Validator Korrekturen vor (z. B. `-Pn` für nmap hinzufügen, Proxy-Env-Vars entfernen, andere Flags versuchen)
- In den Tool-Ausführungs-Workflow integriert — Agenten rufen `verify_tool_result()` nach jedem CLI-Tool-Lauf auf

### Progressive Kontextkompression
- **Phasenzusammenfassungen** (~500-800 Wörter) werden automatisch generiert, wenn Phasengates bestanden werden — Erkenntnisse, Abdeckung, Tool-Ergebnisse und Angriffsfläche in komprimierter Form erfassend
- Verhindert Kontextverschlechterung in langlebigen Engagements, indem rohe historische Daten durch strukturierte Zusammenfassungen ersetzt werden
- `get_engagement_summary()` kombiniert alle Phasenzusammenfassungen zu einer einzigen Übersicht zur Einspeisung in neue Subagenten-Prompts
- Zusammenfassungen als Deliverables gespeichert — von jedem nachgelagerten Agenten zugänglich, ohne vollständige Engagement-Historie

### Kontrafaktische Analyse (Zweitdurchlauf-Entdeckung)
- Nachdem ein Analyzer mit gefundenen Schwachstellen abgeschlossen hat, wird ein **zweiter Analyzer** mit der Anweisung gestartet, "anzunehmen, dass diese Schwachstellen gepatcht sind"
- Der kontrafaktische Analyzer sucht nach **zusätzlichen** Schwachstellen: andere Endpunkte, andere Parameter, andere Injektionskontexte, Logikfehler
- Ergebnisse werden an die bestehende Exploit-Warteschlange angehängt (automatische Zusammenführung mit Deduplizierung nach Endpunkt+Parameter und automatisch inkrementierenden IDs)
- Basiert auf PenHeal-Ablationsforschung, die +71% Schwachstellenabdeckung mit kontrafaktischem Prompting zeigt

### Multi-Domain-Unterstützung
- Automatische SSO/OAuth/OIDC/SAML-Erkennung und -Handhabung
- Pro-Domain-Bereichsregistrierung, Crawling und Testen
- Cookie-Jar-Verwaltung für domänenübergreifende Session-Persistenz
- 6-stufige Authentifizierungsfehler-Eskalation (alternative Grants → PKCE → Headless-Browser → Token-Extraktion → Benutzerbereitstellung → nicht authentifiziert)

### Absturzsicheres Engagement-Management
- Anhängeorientierte `findings.md` und `progress.log` überleben Abstürze
- Git-Workspace-Checkpointing mit Rollback-Fähigkeit
- **Auto-Resume bei Unterbrechung** — `resume-prompt.md` wird automatisch an jedem Checkpoint mit vollem Kontext generiert (Ziel, Anmeldedaten, aktuelle Phase, verbleibende Tests, Umfang). In eine neue Sitzung einfügen, um genau dort fortzufahren, wo Sie aufgehört haben
- Checkpoint-Granularität innerhalb einer Phase — verfolgt, welche Tests innerhalb einer Phase abgeschlossen sind, nicht nur den Phasenstatus
- Vollständiges Audit-Trail jedes MCP-Tool-Aufrufs mit Zeitstempeln

### Professionelle Berichterstattung
- Markdown-Berichte mit Zusammenfassung der Geschäftsleitung, Erkenntnisse nach Schweregrad, Testabdeckungsmatrix und Tool-Abdeckung
- Abdeckungsprozentsätze pro Kategorie und Lückenanalyse
- Dokumentierte Schwachstellenverkettungsanalyse
- Beobachtungen des finalen Richters und Qualitätsnotizen enthalten

---

## Agenten-Rollensystem

AutoPentest verwendet 4 spezialisierte Agentenrollen anstelle generischer Subagenten. Jede Rolle hat eine dedizierte Prompt-Vorlage mit fokussierten Tool-Anleitungen, Ein-/Ausgabe-Verträgen und Anti-Patterns.

| Rolle | Vorlage | Zweck | Phasen |
|-------|---------|-------|--------|
| **Scout** | `templates/agent-roles/scout.md` | Reconnaissance und Angriffsflächenkartierung | Phase 0-1, Quellcode-Entdeckung |
| **Analyzer** | `templates/agent-roles/analyzer.md` | Schwachstellenentdeckung mit Canary-/Witness-Payloads | Phase 2-5 Analyse |
| **Exploiter** | `templates/agent-roles/exploiter.md` | Exploit-Nachweis mit Evidenz | Phase 4 Exploitation |
| **Reporter** | `templates/agent-roles/reporter.md` | Qualitätsprüfung und finaler Richter | Phasenübergänge, Nachbericht |

### Wie die Pipeline funktioniert

Phase 4 (Testing mit den größten Auswirkungen) verwendet eine zweistufige Pipeline pro Schwachstellenklasse:```
┌──────────────────────────────────────────────────────────────┐
│                    Pipeline 1: XSS                           │
│                                                              │
│  Analyzer (75 turns)          Exploiter (75 turns)           │
│  ┌─────────────────────┐      ┌─────────────────────┐        │
│  │ Discover endpoints  │      │ Load Analyzer queue │        │
│  │ Send canary payloads│─────▶│ Attempt exploitation│        │
│  │ Build exploit queue │ gate │ Prove impact        │        │
│  │ Save deliverable    │      │ Log findings        │        │
│  └─────────────────────┘      └─────────────────────┘        │
│                          ▲                                   │
│               validate_exploitation_queue()                  │
└──────────────────────────────────────────────────────────────┘

Das war's. Alle 27 Sicherheitstools sind jetzt installiert und einsatzbereit im Docker-Container.

### Installation überprüfen```bash
# Check all tools are installed
make verify-tools

# Expected output:
# [+] nuclei: installed
# [+] httpx: installed
# [+] katana: installed
# ... (27 tools total)

Dann sagen Sie Claude, was zu testen ist:```
Run a full WSTG assessment against https://target.example.com

Claude wird nach fehlenden Informationen (wie Anmeldedaten) fragen und den 7-Phasen-Workflow starten.

### Option B: Konfigurationsgesteuerter Modus (Empfohlen)

Erstellen Sie eine YAML-Konfigurationsdatei für wiederholbare, konsistente Bewertungen:```yaml
# configs/my-target.yaml
target:
  url: https://app.example.com
  scope:
    - app.example.com
    - api.example.com
  exclude:
    - cdn.example.com

authentication:
  login_type: form
  login_url: https://app.example.com/login
  credentials:
    username: [email protected]
    password: secret123
  login_flow:
    - "Type $username into the email field"
    - "Type $password into the password field"
    - "Click the 'Sign In' button"
  success_condition:
    type: url_contains
    value: "/dashboard"

rules:
  avoid:
    - description: "Do not test logout"
      type: path
      url_path: "/logout"
  focus:
    - description: "Prioritize API endpoints"
      type: path
      url_path: "/api"

reporting:
  tester_name: "Security Team"

### Option C: Gezieltes Testen

Führen Sie spezifische WSTG-Tests gegen bestimmte Endpunkte aus:```
Run WSTG-INPV-05 (SQL Injection) against https://app.example.com/search?q=

### Option D: Eine unterbrochene Durchführung fortsetzen```
Resume engagement pentest-2026-02-11-myapp

Jeder parallele Testagent lädt automatisch seinen relevanten Technikleitfaden vor dem Testen und stellt Folgendes bereit:
- **Erkennungs-Payloads** — was injiziert werden muss, um die Schwachstelle zu identifizieren
- **Ausnutzungstechniken** — nach Angriffsmethode organisiert mit schrittweisen Anleitungen
- **Spickzettel** — datenbank-/plattformspezifische Syntax-Tabellen als Schnellreferenz
- **WAF-Umgehungsmuster** — Kodierungs-, Verschleierungs- und Filterumgehungsstrategien

### Hinzufügen benutzerdefinierter Anleitungen

Siehe [`docs/adding-knowledge-base-resources.md`](https://github.com/bhavsec/autopentest-ai/blob/main/docs/adding-knowledge-base-resources.md) für Anweisungen zum Hinzufügen neuer Technikleitfäden zur Wissensbasis.

---

## Qualitätssicherungssystem

AutoPentest verfügt über ein mehrschichtiges QA-System, das oberflächliche Tests verhindert:

### 1. Phasengates (Automatisiert)

Nach jeder Phase validiert `phase_gate_check()`:
- Alle Tests mit PRIORITÄT MÜSSEN wurden ausgeführt
- Mindestabdeckungsschwellenwerte werden erreicht
- Die Tool-Abdeckung ist ausreichend
- Es bestehen keine kritischen Lücken

**Blockierte Phasen können nicht fortfahren**, bis alle Probleme behoben sind.

### 2. Qualitätsprüfer (Pro Phase)

Ein Unteragent, der bei jedem Phasenübergang erzeugt wird und:
- Prüft auf 16 bekannte Anti-Patterns (Abstempeln, N/A-Kaskaden, Findings-Inflation)
- Identifiziert ungetestete Endpunkte und Parameter
- Schlägt Möglichkeiten zur Verkettung von Schwachstellen vor
- Empfiehlt alternative Ansätze für blockierte Tests

### 3. Endgültiger Richter (Nach Bericht)

Ein Zero-Context-Agent, der den abgeschlossenen Einsatz mit neuen Augen überprüft:
- Analysiert die Integrität der Abdeckung über alle Bereiche hinweg
- Erkennt N/A-Kaskaden und deren Ursachen
- Validiert die Qualität der Findings und die Vollständigkeit der Beweise
- Identifiziert verpasste Angriffsfläche
- Gibt ein Urteil ab: **PASS**, **CONDITIONAL_PASS** oder **FAIL**

### 4. Erschöpfungsgates

Das Markieren einer Schwachstelle als 'nicht ausnutzbar' erfordert einen Nachweis des Aufwands:

| Schwachstellenklasse | Min. Techniken | Min. Umgehungsversuche |
|------------|:-:|:-:|
| XSS | 3 | 5 |
| SQL Injection | 3 | 5 |
| Command Injection | 3 | 5 |
| SSTI | 2 | 3 |
| SSRF | 3 | 5 |
| Path Traversal | 3 | 5 |

### 5. Beweis-Checklisten

Bevor ein Finding protokolliert wird, werden die Beweisanforderungen überprüft:
- Reproduzierbarer curl-Befehl
- Vollständige HTTP-Anfrage und -Antwort
- Nachweis der tatsächlichen Ausnutzung (keine theoretischen Auswirkungen)
- Korrekte Klassifizierungsstufe (AUSGENUTZT vs. POTENZIELL)

### 6. Live-Einsatzprotokollierung

Jeder MCP-Toolaufruf wird automatisch in `engagements/<eid>/logs.txt` mit vollständigen Argumenten, Ergebnissen und Ausführungsdauer protokolliert. Führen Sie `tail -f logs.txt` in einem separaten Terminal aus, um die gesamte Agentenaktivität in Echtzeit zu verfolgen. 100 % Abdeckung durch automatischen Tool-Wrapper — keine manuelle Instrumentierung erforderlich.

### 7. Phasengate-Zeitsteuerung

Phasengates erzwingen mindestens 60-Sekunden-Intervalle zwischen Aufrufen (15s im CTF-Modus), um einen vorzeitigen Phasenabschluss zu verhindern. Die Zwischengate-Arbeitsüberprüfung warnt, wenn weniger als 3 Arbeitsereignisse zwischen aufeinanderfolgenden Gates auftreten.

---

## Benchmarking

AutoPentest beinhaltet die Integration mit den [XBOW Validation Benchmarks](https://github.com/xbow-engineering/validation-benchmarks) — 104 CTF-ähnliche Docker-Herausforderungen, die als Industriestandard für das Benchmarking von KI-Pentest-Agenten verwendet werden.

### Benchmark-Ergebnisse (Referenz)

| Agent | Punktzahl | Quelle |
|-------|:-----:|--------|
| Shannon | 96.2% | KeygraphHQ (2024) |
| PentestGPT | 86.5% | USENIX Sec 2024 |

### Verwendung```bash
# Setup (one-time)
cd benchmarks/xbow && make setup

# Solve with AutoPentest (MCP server + CLAUDE.md + CTF mode)
make solve ID=XBEN-001-24

# Solve with raw Claude (baseline — no MCP, no methodology)
make solve ID=XBEN-001-24 RAW=1

# Solve by vulnerability tag
make solve-tag TAG=sqli

# Solve all 104 challenges
make solve-all

# Full baseline run for comparison
make solve-all RAW=1

# Score the latest run
make score

# Compare autopentest vs raw runs side-by-side
make compare

CTF-Modus reduziert die Phasen-Gate-Zeit (15s vs 60s), überspringt QA-Reviewer-Anforderungen und halbiert die Abschlussschwellen — bei gleichbleibender Befundqualität und Beweisstandards.

---

## Beispielbericht

Ein vollständiger Beispielbericht aus einem Pentest gegen [PortSwigger's Gin & Juice Shop](https://ginandjuice.shop) (eine absichtlich verwundbare Anwendung) ist im Repository enthalten:

**[Vollständigen Bericht anzeigen](https://github.com/bhavsec/autopentest-ai/blob/main/engagements/pentest-2026-ginandjuice/report.md)**

### Was der Bericht enthält

Der Bericht zeigt die Ausgabe von AutoPentest gegen ein reales Ziel mit 23 Befunden über alle Schweregrade hinweg:

| Schweregrad | Anzahl | Beispiele |
|----------|:-----:|---------|
| Kritisch | 2 | UNION-basierte SQL-Injection mit vollständiger Datenextraktion, Umgehung der Zugriffskontrolle über X-Original-URL-Header |
| Hoch | 5 | Reflektiertes XSS über JS-String-Escape-Bypass, IDOR bei Bestelldetails, XXE mit lokatem Dateilesen, DOM-XSS über Prototype Pollution |
| Mittel | 6 | Fehlende Sicherheits-Header, kein Account-Lockout, fehlendes CSP, CRLF-Injection, DOM-basiertes Open Redirect |
| Niedrig | 5 | Offenlegung von Infrastrukturinformationen, EOL AngularJS, unsichere ALB-Cookies, schwache TLS-Konfiguration |
| Informativ | 5 | Konsolidierte Duplikate und sekundäre Beweise für primäre Befunde |

### Berichtsstruktur```
1. Executive Summary         — Target scope, finding summary, domain architecture
2. Detailed Findings         — Each finding with description, evidence (curl commands), and remediation
3. Vulnerability Chaining    — Cross-finding analysis (e.g., XSS + no CSP = severity upgrade)
4. Test Coverage Matrix      — Per-category WSTG coverage (100% across 12 categories)
5. Tool Coverage Matrix      — 27/27 tools tracked, 8 actively run

Jeder Befund enthält reproduzierbare curl-Befehle, vollständige Request/Response-Nachweise und umsetzbare Abhilfeanleitungen.

---

## Konfiguration

### Engagement Config (YAML)

Konfigurationsgesteuerte Pentests überspringen interaktive Fragen und gewährleisten Konsistenz:```yaml
target:
  url: https://app.example.com
  scope: [app.example.com, api.example.com]

authentication:
  login_type: sso                    # form | sso | api | manual | none
  login_url: https://app.example.com/login
  credentials:
    username: testuser
    password: secret123
  sso:
    provider: keycloak               # keycloak | auth0 | okta | azure_ad
    auth_domain: auth.example.com
    realm: myrealm
    client_id: my-app

rules:
  avoid:
    - { type: path, url_path: "/logout", description: "Skip logout" }
    - { type: endpoint, method: DELETE, url_path: "/api/admin/*", description: "No destructive admin ops" }
  focus:
    - { type: path, url_path: "/api", description: "Prioritize API" }

reporting:
  tester_name: "Security Team"

### Burp Suite Integration (Optional)

Für passives Traffic-Monitoring durch Burp Suite Professional:

1. Starten Sie Burp Suite und aktivieren Sie den Proxy auf **allen Schnittstellen** (`0.0.0.0:8080`)
2. Der Docker-Container leitet den Traffic automatisch über `host.docker.internal:8080` weiter
3. Alle HTTP-Anfragen erscheinen im Proxy-Verlauf von Burp zur manuellen Überprüfung

---

## Multi-Domain-Testing

AutoPentest bietet erstklassige Unterstützung für Anwendungen mit mehreren Domains (z.B. ein SPA-Frontend + API-Backend + SSO-Provider):

### Automatische Erkennung

Während Phase 0 erkennt AutoPentest domänenübergreifende Authentifizierung, indem es Login-Weiterleitungen verfolgt:```
app.example.com → redirects to → auth.example.com/login
                 → after login → app.example.com/callback

Dies stellt Folgendes wieder her:
- Alle Befunde und Test-Tracking-Daten
- Abdeckungsstatistiken und Phasentor-Ergebnisse
- Bereichsregistrierungen und Ergebnisse
- Verbleibende Tests in der Mitte der Phase (nicht nur der Phasenstatus)
- Anweisungen für die nächsten Schritte

### Manuelle Kontrollpunkte

Jederzeit speichern:```
Save a checkpoint before starting Phase 4 exploitation

## Projektstruktur```
autopentest-ai/
├── CLAUDE.md                          # Master pentest workflow (drives Claude Code)
├── .mcp.json                          # MCP server configuration
├── Dockerfile                         # Multi-stage Docker build (27 tools)
├── docker-compose.yml                 # Docker Compose alternative
├── Makefile                           # setup, start, stop, verify-tools, shell
│
├── server/
│   ├── server.py                      # FastMCP server (68+ MCP tools)
│   ├── task_tree.py                   # Hierarchical task tree (6 MCP tools)
│   ├── tool_parsers.py                # Tool output parsing (2 MCP tools, 13 parsers)
│   ├── endpoint_priority.py           # Endpoint risk prioritization (2 MCP tools)
│   ├── waf_evasion.py                 # Adaptive WAF evasion (3 MCP tools, 12 vendors)
│   ├── knowledge_graph.py             # Cross-phase knowledge graph (5 MCP tools)
│   ├── tool_verification.py           # CLI tool results verification (1 MCP tool, 10 validators)
│   ├── context_compression.py         # Progressive context compression (2 MCP tools)
│   └── pyproject.toml                 # Python dependencies
│
├── knowledge-base/
│   ├── web-security-testing-guide/    # OWASP WSTG knowledge base (109 test procedures)
│   │   ├── 01-information-gathering/  # 10 tests (WSTG-INFO-01 → 10)
│   │   ├── 02-configuration/          # 14 tests (WSTG-CONF-01 → 14)
│   │   ├── 03-identity-management/    # 5 tests  (WSTG-IDNT-01 → 05)
│   │   ├── 04-authentication/         # 11 tests (WSTG-ATHN-01 → 11)
│   │   ├── 05-authorization/          # 5 tests  (WSTG-ATHZ-01 → 05)
│   │   ├── 06-session-management/     # 11 tests (WSTG-SESS-01 → 11)
│   │   ├── 07-input-validation/       # 20 tests (WSTG-INPV-01 → 20)
│   │   ├── 08-error-handling/         # 2 tests  (WSTG-ERRH-01 → 02)
│   │   ├── 09-cryptography/           # 4 tests  (WSTG-CRYP-01 → 04)
│   │   ├── 10-business-logic/         # 10 tests (WSTG-BUSL-01 → 10)
│   │   ├── 11-client-side/            # 14 tests (WSTG-CLNT-01 → 14)
│   │   └── 12-api-testing/            # 3 tests  (WSTG-APIT-01 → 03)
│   └── portswigger-academy/           # 31 PortSwigger attack technique guides
│       ├── sql-injection.md           # UNION, blind, error-based, OOB, WAF bypass
│       ├── cross-site-scripting.md    # Reflected, stored, DOM, CSP bypass, filter evasion
│       ├── ssrf.md                    # URL schemes, cloud metadata, DNS rebinding
│       ├── ssti.md                    # Jinja2, Twig, Freemarker sandbox escapes
│       ├── jwt.md                     # Algorithm confusion, kid injection, JWK exploitation
│       ├── oauth.md                   # Auth code theft, redirect exploitation, scope upgrade
│       └── ... (31 total)             # One per vulnerability class
│
├── templates/                         # Testing guides and procedures
│   ├── input-validation-guide.md      # Phase 4 step-by-step procedures
│   ├── testing-strategies.md          # Test matrices, chaining, parallel strategy
│   ├── cli-tools-guide.md             # Tool setup and Docker management
│   ├── tools.md                       # Per-tool command reference
│   ├── quality-gates.md               # Phase quality checklists and anti-patterns
│   ├── cross-domain-auth-guide.md     # SSO/OIDC/SAML procedures
│   ├── source-code-analysis.md        # Security-focused code review template
│   ├── pipelined-testing.md           # Phase 4 pipelined exploitation strategy
│   ├── agent-roles/                   # Role-specialized subagent templates
│   │   ├── README.md                  # Role index and selection guide
│   │   ├── scout.md                   # Reconnaissance role (Phase 0-1)
│   │   ├── analyzer.md                # Vulnerability discovery role (Phase 2-5)
│   │   ├── exploiter.md               # Exploitation proof role (Phase 4)
│   │   └── reporter.md                # QA review + Final Judge role
│   ├── shared/
│   │   ├── honesty-framework.md       # Anti-hallucination guardrails
│   │   ├── exploit-classification.md  # Three-tier finding classification
│   │   ├── reproducibility.md         # Evidence format requirements
│   │   └── scope-rules.md            # Avoid/focus rule templates
│   └── wordlists/                     # Tech-specific fuzzing wordlists
│
├── benchmarks/
│   └── xbow/                              # XBOW benchmark suite (104 CTF challenges)
│       ├── runner.py                      # Challenge orchestration
│       ├── solver.py                      # Automated solver (Claude Code CLI)
│       ├── Makefile                       # solve, solve-all, score, compare
│       └── results/                       # Run reports
│
├── docs/
│   ├── ROADMAP.md                         # Competitive analysis + improvement roadmap
│   └── adding-knowledge-base-resources.md # Guide for adding new technique guides
│
├── configs/
│   ├── example-config.yaml            # Example engagement configuration
│   └── config-schema.md               # YAML schema documentation
│
├── scripts/
│   ├── install-tools.sh               # Docker build + container start
│   ├── browser-auth.py                # Headless Chromium auth (JS-rendered logins)
│   ├── pkce-auth.py                   # OAuth 2.0 PKCE flow automation
│   └── status.sh                      # Engagement status dashboard
│
└── engagements/                       # Runtime output (git-ignored)
    └── <engagement-id>/
        ├── logs.txt                   # Live engagement log (tail -f to watch)
        ├── findings.md                # Append-only findings log
        ├── progress.log               # Timestamped event log
        ├── resume-prompt.md           # Auto-resume prompt (paste into new session)
        ├── report.md                  # Final pentest report
        ├── cookies.txt                # Cross-domain cookie jar
        └── tool-output/               # Raw CLI tool outputs