Automatisierte Penetrationstests (autorisiert)

Manuelle Penetrationstests finden ein- bis zweimal im Jahr statt und decken nur eine Stichprobe der Systeme einer Organisation ab, während sich Code und Infrastruktur täglich ändern. KI-gestützte Pentest-Werkzeuge verketten Aufklärung, Ausnutzung bekannter Schwachstellenklassen und Validierung der Befunde, sodass Webanwendungen, APIs und interne Netze fortlaufend getestet und Korrekturen nachgetestet werden können. Menschliche Tester bleiben verantwortlich für Umfang, Risikoentscheidungen und neuartige Angriffspfade mit viel Geschäftslogik.

Nur Ebene von Richtlinien und Architektur. Ausschließlich auf Systemen einsetzen, die Ihnen gehören oder für die Sie vertraglich zum Testen autorisiert sind. Das Testen fremder Systeme ohne schriftliche Erlaubnis ist in den meisten EU-Staaten eine Straftat (z. B. § 202c StGB in Deutschland, Richtlinie 2013/40/EU).

Problem & Nutzen

• Heute: jährliche oder anlassbezogene manuelle Pentests (Tage bis Wochen an Expertenzeit) plus Schwachstellenscanner, die Tausende ungeprüfter, oft nicht ausnutzbarer Befunde auflisten. Korrekturen werden selten nachgetestet, bis der nächste Auftrag ansteht; neue Releases gehen dazwischen ungetestet live.
• KI-Nutzen: (1) Validierung — belegen, dass ein Befund tatsächlich ausnutzbar ist, was Fehlalarme senkt und die Priorisierung unterstützt; (2) Abdeckung und Takt — jedes Release oder wöchentlich testen statt jährlich; (3) Schlussfolgern über Angriffspfade — Probleme mit geringem Schweregrad (Zugangsdaten, Fehlkonfigurationen, Vertrauensbeziehungen) zu realistischen Ketten verbinden; (4) Nachtest nach der Behebung.
• Leistungsfähigkeit: Autonome Agenten haben die Spitze öffentlicher Bug-Bounty-Ranglisten erreicht (XBOW in der US-Rangliste von HackerOne 2025) und schneiden bei Benchmarks zu Web-Schwachstellen gut ab, doch die Ergebnisse bei realistischen Netzen mit mehreren Hosts und bei Fehlern in der Geschäftslogik bleiben deutlich schwächer [1][2].
• Regulatorischer Sog: NIS2 verlangt Risikomanagementmaßnahmen einschließlich Umgang mit Schwachstellen und Wirksamkeitsbewertung, und DORA verlangt bedrohungsgesteuerte Penetrationstests (TLPT) für benannte Finanzunternehmen sowie regelmäßige Tests der Resilienz für andere; beides erhöht die Nachfrage nach wiederholbaren Tests [3][4].

Varianten

• Validierung der externen Angriffsfläche: automatisierte Erkennung plus sichere Überprüfung von Exploits auf aus dem Internet erreichbaren Assets.
• Tests von Webanwendungen und APIs (DAST+): agentenbasiertes authentifiziertes Crawling, Tests von Geschäftsabläufen (IDOR, fehlerhafte Zugriffskontrolle) gegen Staging-Umgebungen.
• White-Box- / codebewusstes Testen: Der Agent liest Quellcode, stellt eine Exploit-Hypothese auf und belegt sie gegen eine laufende Testinstanz (senkt Fehlalarme von SAST, siehe SEC-004).
• Interne Netzwerk-/AD- und Cloud-Pfade: Entdeckung von Angriffspfaden mit von Haus aus sicheren Exploits.
• Öffentlicher Sektor: strengere Kontrolle des Umfangs; OT/ICS ausgeschlossen, sofern nicht vereinbart. Privatnutzung: nur Heimlabor.

So funktioniert es

1. Umfang & Einsatzregeln (signiert, maschinenlesbare Allow-List, Zeitfenster, verbotene Aktionen)
2. Aufklärung (Asset-Erkennung, Technologie-Fingerprinting, Einlesen von API/Spezifikationen)
3. Hypothesenbildung (LLM-Planer: wahrscheinliche Schwachstellenklassen je Asset)
4. kontrolliertes Testen (Werkzeugaufrufe: Scanner, HTTP-Client, Browser, Exploit-Frameworks im sicheren Modus)
5. Validierung (mit harmlosem Nachweis reproduzieren, z. B. eine Canary-Datei lesen; Belege sichern)
6. Triage & Deduplizierung (Schweregrad, Erreichbarkeit, Geschäftsauswirkung)
7. menschliches Prüf-Gate (Tester/Security-Engineer gibt kritische oder eingriffsintensive Schritte und Befunde frei)
8. Bericht + Tickets / Fix-PRs
9. Retest-Schleife

• Planer-/Ausführer-Agenten: Ein Reasoning-LLM plant; spezialisierte Sub-Agenten (Aufklärung, Web, Authentifizierung, Netzwerk) rufen echte Werkzeuge auf (z. B. nmap, nuclei, Proxys im Stil von Burp, Frameworks der Klasse Metasploit, ein Headless-Browser). Das Modell „erfindet“ selten Exploits; es orchestriert und passt Werkzeuge an.
• Leitplanken sind das Produkt: harte Durchsetzung des Umfangs außerhalb des Modells (Netzwerk-Allow-Lists, Egress-Proxy, Ratenbegrenzung, Notaus), Richtlinie für verbotene Aktionen (kein Abfluss echter personenbezogener Daten, keine zerstörerischen Payloads, keine Dienstverweigerung) und unveränderliche Aktionsprotokolle.
• Mensch-in-der-Schleife (Human-in-the-Loop): Freigabe des Umfangs, Genehmigung eingriffsintensiver oder die Produktion beeinträchtigender Schritte, Prüfung jedes hohen/kritischen Befunds, bevor er die Entwickler erreicht, Verantwortung für den Abschlussbericht.

Datenaufbereitung

Der Datenbedarf ist gering und eher organisatorisch als technisch: Definition des Umfangs, eine Liste der Assets und IPs, Architekturdiagramme und Testkonten. In einem KMU liegt das in der IT-Dokumentation, der Firewall-Konfiguration, einem Wiki oder im Kopf des einen Administrators.

Typische Lücken: veraltetes oder fehlendes Asset-Inventar, unbekannte aus dem Internet erreichbare Dienste (Schatten-IT, vergessene Testsysteme), keine schriftliche Autorisierung der Systemverantwortlichen und Hosting-Anbieter, keine Test- oder Staging-Kopie und unklare Ansprechpersonen für Vorfälle während des Tests.

Schritte der Aufbereitung: 1. Das Asset-Inventar und die Liste der externen Angriffsfläche anlegen oder aktualisieren (PREP-001, PREP-005). 2. Die Einsatzregeln (Rules of Engagement) schreiben: Umfang, erlaubte Techniken, Zeitfenster, Notfallkontakte, Datenumgang. 3. Schriftliche Erlaubnis von Verantwortlichen, Hostern und Cloud-Anbietern einholen, wo erforderlich. 4. Testkonten mit realistischen Rollen und eine Staging-Umgebung mit synthetischen oder pseudonymisierten Daten vorbereiten (PREP-022). 5. Sicherstellen, dass Backups und Monitoring vor dem Test funktionieren.

Der Aufwandsanteil ist klein, etwa 10 bis 15 Prozent des Gesamtaufwands, aber fehlende Autorisierung oder ein unklarer Umfang ist der häufigste Grund, warum Projekte scheitern oder rechtlich riskant werden. GUIDE-003 hilft beim Inventar.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Ein zertifizierter Pentest-Anbieter oder ein etablierter automatisierter Scan-/Pentest-Dienst ist die sichere Wahl; eigene Werkzeuge zu bauen lohnt sich nicht.
• Enterprise: Weg B. Eigene Red Teams erweitern ihre Werkzeugkette per API um LLM-Agenten unter strikter Begrenzung des Umfangs und bleiben frei in der Wahl der Werkzeuge.
• Entwickler: Weg C. Open-Source-Frameworks und lokale Modelle auf HW3 erlauben Experimente in Laborumgebungen, ohne Zieldaten nach außen zu senden.
• Öffentlicher Sektor: Weg A. Für öffentliche Systeme sind in der Regel qualifizierte, zertifizierte Anbieter (z. B. vom BSI anerkannt) mit klarer Haftung erforderlich.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• Plattformen für autonome Pentests / KI-Pentests: Horizon3.ai NodeZero (intern/extern, AD- und Cloud-Pfade), XBOW (autonomes offensives Testen von Web/Apps), Pentera (automatisierte Sicherheitsvalidierung), Ethiack (EU, Portugal), Hadrian und Cymulate (Validierung der Exposition/BAS), Escape (EU, Frankreich; API und DAST), Synack und andere PTaaS-Anbieter, die KI mit menschlichen Testern verbinden.
• Wählen Sie A, wenn: Sie kein internes Red Team haben, schnell auditfähige Nachweise brauchen und den Umfang klar festlegen können. Prüfen: Kontrollen zur Durchsetzung des Umfangs, Richtlinie für sichere Exploits, Datenstandort der Befunde und Zugangsdaten in der EU, reproduzierbare Nachweise, enthaltener Nachtest, Haftungs- und Versicherungsbedingungen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Ein Reasoning-LLM (Modelle von Claude, GPT, Gemini oder Mistral in EU-Regionen) mit einer Werkzeug- Schicht über das Model Context Protocol (MCP) oder Function Calling orchestrieren; Frameworks wie LangGraph oder das Claude Agent SDK.
• Jedes Werkzeug hinter einen Richtlinien-Proxy legen, der die Allow-List durchsetzt und Anfragen protokolliert.
• Die Nutzungsrichtlinie jedes Anbieters prüfen: Sicherheitsarbeit mit doppeltem Verwendungszweck erfordert meist einen ausdrücklich autorisierten Testkontext oder ein verifiziertes Cyber-Programm; Ablehnungen sind ein praktisches Risiko.
• Wählen Sie B, wenn: Sie ein Sicherheitsteam sind, das Nachtests oder White-Box-Prüfungen an den eigenen Anwendungen innerhalb von CI/CD automatisiert.

Weg C — Selbst betreiben (Open Source)

• Open-Source-Agenten/-Werkzeuge: PentestGPT (LLM-Pentest-Assistent aus der Forschung), Strix und ähnliche offene agentenbasierte Scanner, Nuclei, OWASP ZAP (mit Automation Framework), Metasploit und Caldera (MITRE Adversary Emulation).
• Modelle: leistungsfähige Open-Weight-Modelle für Code/Reasoning (z. B. Familie Qwen3-Coder, DeepSeek, gpt-oss, Familien Mistral/Devstral), betrieben über vLLM oder Ollama in einem isolierten Labornetz.
• Hardware: HW3 (eine GPU mit 48–141 GB) für Modelle mit ~30–120B; HW2 reicht für enge Aufgaben.
• Wählen Sie C, wenn: Daten (Quellcode, Zugangsdaten) die Räumlichkeiten nicht verlassen dürfen, oder für die Forschung. Rechnen Sie mit geringerer Autonomie als bei Frontier-Modellen.

Weg D — Eigenes Training

Selten: Destillieren oder Feintuning auf eigenen früheren Berichten und CTF-Umgebungen, um bei hohem Volumen Kosten zu senken.

Stand der Technik (2026)

• Agentenbasierte offensive Sicherheit hat sich von Demos zu Produkten entwickelt: Autonome Plattformen melden validierte Befunde bei Webanwendungen und Netzen; wissenschaftliche Arbeiten (PentestGPT, Benchmarks wie Cybench und CVE-Bench) zeigen schnellen, aber ungleichmäßigen Fortschritt: Die besten Systeme lösen einen erheblichen Teil von Web-Aufgaben im CTF-Stil, aber deutlich weniger langfristige, mehrstufige Szenarien aus der Praxis [2][5].
• Stärken: breite Abdeckung, unermüdliches Nachtesten, schnelle Exploit-Validierung bekannter Schwachstellen- klassen, Entwurf von Berichten.
• Grenzen und Fehlerbilder: halluzinierte oder nicht reproduzierbare Befunde; schwacher Umgang mit komplexer Geschäftslogik, Multi-Faktor-Authentifizierung und empfindlichen Produktivsystemen; Abweichen vom Umfang oder unbeabsichtigte Auswirkungen (Kontosperren, Datenänderung, Last); Prompt Injection durch getestete Ziele, die den Agenten lenkt; begrenzte Kreativität im Vergleich zu menschlichen Spitzentestern; Nichtdeterminismus, der Audit-Nachweise erschwert. Behandeln Sie die Ausgabe als Nachweis in Triage-Qualität, nicht als zertifizierten Pentest, es sei denn, ein qualifizierter Anbieter zeichnet ihn ab.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-reasoning, llm-code, agent-framework): SEC-004 (Schwachstellenmanagement und automatische Korrektur) bezieht Korrekturen aus validierten Befunden; SEC-014 (KI-Red-Teaming) nutzt dasselbe Agenten- Gerüst gegen LLM-Anwendungen; SEC-010 härtet die als schwach erkannten Anwendungen.
• Vor- und nachgelagert: SEC-012 definiert, was getestet wird; SEC-009 macht aus Berichten Compliance-Nachweise; SEC-001/SEC-008 nutzen Befunde zur Abstimmung der Erkennung. Kündigen Sie Tests beim SOC an.

Aufwand, Kosten & Kennzahlen

• Aufwand: A Wochen (Abonnement je Asset); B 2–4 Monate (Token-Kosten je Lauf); C 3–6 Monate plus GPU.
• Kennzahlen: Anteil der als ausnutzbar validierten Befunde, Fehlalarmquote, mittlere Zeit bis zur Erkennung und zur Behebung kritischer Befunde, Testabdeckung (je Quartal getestete Assets/APIs), Dauer des Nachtest-Zyklus, Verstöße gegen den Umfang (Ziel: null), Kosten je validiertem Befund.

Menschen & Veränderung

Autorisiertes Testen ist Teamarbeit mit klaren Freigaben; nicht autorisiertes Testen ist eine Straftat.

• Die Geschäftsleitung erteilt die schriftliche Autorisierung und trägt das Risiko; Recht/Compliance prüft Verträge mit Hostern, Kunden und dem Pentest-Anbieter (Haftung, Vertraulichkeit).
• IT und IT-Sicherheit legen den Umfang fest, überwachen während des Tests und beheben Befunde; Datenverantwortliche und Lieferanten müssen zustimmen, wenn ihre Systeme oder Daten berührt werden.
• Betriebsrat: kommt darauf an. Technische Tests von Systemen überwachen normalerweise keine Beschäftigten. Die Mitbestimmung (§ 87 Abs. 1 Nr. 6 BetrVG) wird relevant, wenn Tests das Nutzerverhalten protokollieren oder wenn Phishing- und Social-Engineering-Simulationen zum Umfang gehören; unterrichten Sie den Betriebsrat in jedem Fall rechtzeitig (§ 90 Abs. 1 Nr. 3).
• Datenschutzbeauftragte(r): Einbeziehen, wenn Tests personenbezogene Daten berühren können; AVV mit dem Anbieter vereinbaren (Art. 28 DSGVO) sowie den Umgang mit personenbezogenen Daten in Befunden regeln.
• KI-Kompetenz: Unterstützen Sie das Sicherheitsteam dabei, Grenzen und halluzinierte Befunde von KI-Agenten zu verstehen (Art. 4 KI-Verordnung).
• Kommunikation und Pilot: Sagen Sie dem IT-Team und dem SOC, dass ein Test läuft, und beginnen Sie mit einem unkritischen System.
• Typische Sorge: „Legt es die Produktion lahm?“ Antworten Sie mit Staging zuerst, Zeitfenstern, Rollback-Plänen und menschlicher Freigabe für jeden Exploit-Schritt.

Siehe GUIDE-013, GUIDE-005 und GUIDE-004.

Risiken, Regulierung & Compliance

• Erst die Autorisierung: schriftliche Erlaubnis des Systemverantwortlichen (und der Cloud-/Hosting-Anbieter, wo deren Richtlinie es verlangt); das Computerstrafrecht der EU-Mitgliedstaaten gilt (Richtlinie 2013/40/EU).
• KI-Verordnung (AI Act): minimales Risiko bei defensivem Sicherheitstest eigener Systeme; KI-Kompetenz (Art. 4) gilt. Pentesting löst kein Verbot nach Art. 5 aus, doch das Werkzeug darf nicht zweckentfremdet werden, um Personen zu profilieren oder zu manipulieren. Wird es zum Test von Sicherheitskomponenten kritischer Infrastruktur eingesetzt, kann das getestete System hochriskant sein, nicht das Pentest-Werkzeug. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck tragen eigene Pflichten.
• DSGVO: Tests können personenbezogene Daten offenlegen; nutzen Sie Testdaten oder synthetische Daten, minimieren Sie die Erfassung von Nachweisen, schließen Sie einen Auftragsverarbeitungsvertrag mit dem Anbieter, speichern Sie Befunde in der EU und behandeln Sie entdeckte personenbezogene Daten als möglichen Vorfall, der nach Art. 33 zu bewerten ist.
• NIS2/DORA/ISO 27001: unterstützt die Pflichten zum Testen; DORA-TLPT erfordert qualifizierte Tester und Prozesse im Stil von TIBER, wo anwendbar, sodass KI-Werkzeuge diese ergänzen, aber nicht ersetzen [4].
• Gegenmaßnahmen: zuerst Staging, Ratenbegrenzung, Notaus, unveränderliche Protokolle, menschliche Freigabe eingriffsintensiver Schritte, Sandboxing des Agenten gegen Prompt Injection.

Erste Schritte

1. Assets inventarisieren und ein präzises Dokument zu Umfang und Einsatzregeln schreiben (Allow-List, Zeiten, verbotene Aktionen, Kontakte, Notstopp).
2. Pilot auf einer Staging-Kopie einer Webanwendung oder API mit einem Produkt aus Weg A oder dem Open-Source-Werkzeug ZAP/Nuclei plus einem LLM-Agenten; mit Ihrem letzten manuellen Pentest-Bericht vergleichen.
3. Rate der validierten Befunde und Fehlalarme messen; für jeden Befund einen Nachweis verlangen.
4. In CI/CD und Ticketsystem integrieren (Nachtest bei Korrektur); SOC und Datenschutzbeauftragte(n) informieren.
5. Einen jährlichen, von Menschen geführten Pentest für Geschäftslogik, Social Engineering und vorgeschriebene Compliance-Tests beibehalten.

Quellen

1. XBOW — autonomous penetration testing and HackerOne results — https://xbow.com/blog
2. Deng et al. — PentestGPT: LLM-empowered automatic penetration testing — https://arxiv.org/abs/2308.06782
3. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
4. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
5. Cybench: framework for evaluating cybersecurity capabilities of language models — https://arxiv.org/abs/2408.08926
6. Horizon3.ai NodeZero documentation — https://docs.horizon3.ai
7. OWASP ZAP automation framework — https://www.zaproxy.org/docs/automate/automation-framework/
8. Nuclei project — https://github.com/projectdiscovery/nuclei
9. MITRE Caldera — https://github.com/mitre/caldera
10. Directive 2013/40/EU on attacks against information systems — https://eur-lex.europa.eu/eli/dir/2013/40/oj
11. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj