Vulnerability Assessment – Phase 3

Scripts: build_phase3.py + vuln_check.py (auto-generiert)
Pfad: /home/andre/Claude/Hacking/bgv_de/phase3_vuln_check/
Phase: 3 – CVE Presence Detection (passiv, kein Exploit)

Phase 3 besteht aus zwei Schritten:

1. build_phase3.py liest die Phase-2-Findings, extrahiert alle CVEs und lässt Claude zielspezifische Probe-Funktionen generieren → schreibt vuln_check.py
2. vuln_check.py (auto-generiert) führt die Probes aus und erstellt einen Vulnerability-Report

Der Ansatz ist rein passiv: HTTP-Anfragen auf bekannte vulnerable Endpunkte, keine Authentifizierung, keine Payload-Ausführung. Ziel ist die Feststellung ob ein verwundbarer Endpunkt erreichbar ist (Presence Detection).

build_phase3.py ist der Builder – er wird einmalig pro Ziel ausgeführt und erzeugt den zielspezifischen Scanner vuln_check.py.

1. Phase-2-JSON einlesen (web_recon.json)
2. CVE-IDs normalisieren (CVE-YYYY-NNNNN via Regex aus Rohtexten)
3. CVEs nach Produktfamilie gruppieren: citrix, ivanti, exchange, checkpoint, jsf, log4j, other
4. Für jede Gruppe: Claude generiert Probe-Funktionen (passiv, HTTP-only)
5. Nuclei-Template-Verfügbarkeit prüfen (~/nuclei-templates/cves/)
6. Vollständiges vuln_check.py aus Template + generierten Funktionen zusammenbauen

cd /home/andre/Claude/Hacking/bgv_de/phase3_vuln_check
 
python3 build_phase3.py \
    --web-recon ../../phase2_web_recon/web_recon.json \
    --domain bgv.de

Für jede Produktgruppe wird ein Batch-Prompt an Claude gesendet:

• Passiver HTTP-Probe auf bekannte vulnerable Endpunkte
• Kein Auth-Versuch, kein Exploit, kein Payload
• Response-Analyse: Status-Code, Body-Strings, Header-Werte
• Return-Dict: {„status“: „CONFIRMED“|„LIKELY“|„NOT_VULNERABLE“, „evidence“: „…“}

Beispiel Probe-Funktion (CVE-2023-3519, Citrix NetScaler):

def probe_CVE_2023_3519(host, session):
    url = f"https://{host}/logon/LogonPoint/tmindex.html"
    try:
        r = session.get(url, timeout=10, verify=False)
        if r.status_code == 200 and "Citrix" in r.text:
            return {"status": "CONFIRMED", "evidence": f"HTTP {r.status_code}, Citrix-Page gefunden"}
    except Exception as e:
        return {"status": "ERROR", "evidence": str(e)}
    return {"status": "NOT_VULNERABLE", "evidence": f"HTTP {r.status_code}"}

Der auto-generierte Scanner – zielspezifisch, enthält alle Probe-Funktionen für die in Phase 2 identifizierten CVEs des Ziels.

python3 /home/andre/Claude/Hacking/bgv_de/phase3_vuln_check/vuln_check.py

Keine Parameter nötig – Zieldomain, Hosts und CVE-Liste sind eingebettet.

1. Alle Probe-Funktionen über globals() automatisch registriert
2. Tor-Session aufbauen (SOCKS5 auf 127.0.0.1:9050)
3. Optional: Nuclei mit verfügbaren CVE-Templates ausführen
4. Alle Custom-Probes parallel ausführen (ThreadPoolExecutor)
5. Ergebnisse klassifizieren: CONFIRMED / LIKELY / NOT_VULNERABLE / ERROR
6. Reports generieren: JSON + Maltego CSV + PDF

Reports unter /home/andre/Claude/Hacking/bgv_de/phase3_vuln_check/reports/<domain>_<ts>/:

Aus dem bgv.de-Scan (Phase 3, März 2026):

Führe Phase 3 (Vulnerability Assessment) für bgv.de durch –
lies die Phase-2-Ergebnisse, generiere den Scanner und führe ihn aus.

Claude erledigt dann:

1. build_phase3.py ausführen → vuln_check.py erzeugen
2. vuln_check.py ausführen → Reports generieren
3. Ergebnisse zusammenfassen

• „Welche CONFIRMED-Findings haben CVSS ≥ 9.0? Wie hoch ist das Risiko?“
• „CVE-2023-3519 ist auf 5 Hosts confirmed – welche Angriffsmöglichkeiten gibt es?“
• „Sind die LIKELY-Findings wirklich anfällig oder nur möglicherweise gesichert?“
• „Schreibe eine Executive Summary für den Vorstand.“
• „Welche Patches müssen sofort eingespielt werden?“

Phase 2 (web_recon.py)    →  web_recon.json  (CVEs, KRITISCH-Hosts)
                                     ↓
Phase 3 (build_phase3.py) →  vuln_check.py   (zielspezifischer CVE-Scanner)
         (vuln_check.py)  →  vuln_check.json (CONFIRMED/LIKELY-Findings)
                                     ↓
Phase 4 (build_phase4.py) →  Exploit-Dokumentation, Angriffsketten, MSF-Configs

• vuln_check.py ist zielspezifisch – für ein neues Ziel immer build_phase3.py neu ausführen
• Die generierten Probe-Funktionen sind passiv – kein Schaden am Zielsystem
• Nuclei-Templates werden genutzt wenn unter ~/nuclei-templates/cves/ vorhanden
• HTTP-Probes laufen über Tor (Exit-IP wechselt automatisch)
• CONFIRMED bedeutet: Endpunkt vorhanden + Fingerprint positiv – kein Beweis dass Exploit funktioniert