Canonical: https://uhl.cloud/resources/ai-assisted-penetration-testing/
Language: de-CH
Format: public page content, generated from HTML

# KI-gestützte autorisierte Penetrationstests

Wie wir LLMs und Agenten in abgesteckten Sicherheitsaufträgen einsetzen - und die menschlichen Gates, die daraus autorisierte Tests statt unbeaufsichtigte Scans machen.

Geprüft vom UHL-Team · 28. Oktober 2026

PlaybookAktualisiert am 28. Oktober 2026

[PDF herunterladen](https://uhl.cloud/assets/resources/ai-assisted-penetration-testing-de.pdf?v=842b4df9fc9f)

## Wo KI hilft - und wo sie nicht führen darf

Ein Penetrationstest ist ein autorisierter Auftrag gegen einen definierten Umfang. Dieser Rahmen ändert sich nicht, wenn ein LLM in den Workflow kommt: Das Modell beschleunigt die Analyse, entscheidet aber nie, was getestet wird, wie weit eine Exploitation geht oder was im Bericht steht. Jeder KI-gestützte Schritt in diesem Playbook liegt hinter einem menschlichen Genehmigungs-Gate.

Das Modell schlägt vor. Der Tester entscheidet. Nichts erreicht das Ziel, den Kunden oder den Bericht ohne die Freigabe einer namentlich verantwortlichen Person.

Wählen Sie die Analyseumgebung nach Auftragsvereinbarung und Sensibilität der Eingaben. Senden Sie Kundennachweise nicht ohne ausdrückliche Erlaubnis und geeignete vertragliche Kontrollen an externe Modelle. Auch bereinigte Eingaben benötigen eine Prüfung auf indirekte Identifikatoren. Siehe den [Architekturleitfaden zum Self-Hosting](https://uhl.cloud/resources/self-hosted-ai-stack/).

## Die vier Phasen, in denen sich KI bewährt

- **Aufklärung zusammenfassen**
  Passive Daten - Certificate Transparency, öffentliche Repositories, Technologie-Fingerprints - fallen in Menge an. Ein LLM verdichtet sie zu einem Zielprofil, das der Tester Zeile für Zeile prüft, bevor irgendein aktiver Zugriff erfolgt. Die gewonnene Zeit fliesst in die interessanten Hosts, nicht ins Lesen von Rauschen.

- **Finding-Triage**
  Scanner-Output ist verrauscht. Das Modell gruppiert doppelte Funde, entwirft Schweregrad-Kandidaten und markiert wahrscheinliche Fehlalarme. Der Tester akzeptiert, korrigiert oder verwirft jede Einschätzung; der Schweregrad wird nie automatisch vergeben.

- **Exploit-Recherche**
  Zu einer bestätigten Service-Version entwirft das Modell Angriffspfade und Referenzen. Der Tester verifiziert jeden gegen die reale Umgebung; ein plausibel klingender Pfad, der nicht existiert, ist schlimmer als keiner.

- **Berichtsentwurf**
  Jeder Fund erhält einen Entwurf: Beschreibung, Auswirkung, Nachweis, Behebung. Der Tester schreibt um, was der Entwurf verfehlt - meist die geschäftliche Auswirkung, denn das Modell kennt den Kontext des Kunden nicht.

## Harte Regeln, die nicht verhandelbar sind

- Die schriftliche Autorisierung definiert Umfang, Zeitfenster und Techniken, bevor irgendein Werkzeug läuft - KI oder nicht

- Keine Kundendaten, Zugangsdaten oder Beweismittel gehen an externe Modellanbieter; die Analyse läuft auf selbst gehosteten Modellen oder mit bereinigten Eingaben

- Aktive Exploitation-Schritte werden vom Tester ausgeführt und beobachtet, nie an eine Agentenschleife delegiert

- Jede Aussage im Bericht wird vor der Übergabe manuell reproduziert - was wir nicht wiederholen können, wird nicht geliefert

- Die Auftragsdokumentation legt offen, welche Schritte KI-Unterstützung nutzten, damit der Kunde die Methode prüfen kann

## Warum diese Disziplin für Kunden zählt

Das Risiko KI-gestützter Sicherheitsarbeit ist nicht Tempo - es ist ungeprüfte Selbstsicherheit. Eine halluzinierte CVE-Referenz oder ein erfundener Exploit-Pfad verschwendet Behebungsbudget und untergräbt das Vertrauen in echte Funde. Unsere Gate-Struktur stellt sicher, dass Ihr Bericht nur enthält, was demonstriert wurde, im Schweregrad, den ein Mensch vergeben hat, innerhalb des Umfangs, den Sie autorisiert haben. Das ist der Standard, den wir an unsere eigenen Systeme anlegen - und an jeden Auftrag, den wir annehmen.

## Praxiskontext statt offengelegtem Kundentest

Unser [Penetration-Testing-Angebot](https://uhl.cloud/penetration-testing/) beschreibt abgegrenzte, autorisierte Prüfungen. Diese Ressource ist ein Methodenblatt. Sie enthält weder Kundenschwachstellen noch Exploit-Protokolle oder ungeprüfte Behebungsergebnisse. Ein kundenspezifisches Beispiel gehört in den vertraulichen Prüfbericht.

## Wiederverwendbares Befund- und Nachprüfprotokoll

- **Umfangsbezug**
  Erfassen Sie autorisiertes Ziel, Zeitfenster, Technikbeschränkungen und eine benannte Kontaktperson zum Stoppen. Halten Sie Erlaubnisse für KI-Unterstützung und externe Verarbeitung fest.

- **Nachweis und Einordnung**
  Erfassen Sie beobachteten Zustand, bereinigten Nachweis, Reproduktionsvoraussetzungen und betroffene Komponente. Trennen Sie belegte Auswirkungen von möglichen Folgen.

- **Behebung und Nachprüfung**
  Benennen Sie Behebungsverantwortung, Lösungsvorschlag und vereinbarte Nachprüfung. Eine Codeänderung allein belegt keine Behebung im ausgelieferten Dienst.

## Abnahme und weiterführende Quellen

- Die schriftliche Erlaubnis deckt tatsächlich geprüfte Ziele und Techniken ab.

- Eine Person prüft Quellen, Schweregrad und Nachweise vor der Berichtsabgabe.

- Der Nachprüfstatus ist eindeutig: nicht beauftragt, ausstehend, bestanden oder weiterhin betroffen.

- Der [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) bietet eine strukturierte Prüfreferenz.

- [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) behandelt Planung und Durchführung technischer Sicherheitsprüfungen.

## Mit UHL chatten

Starten Sie einen geführten Chat. Der Assistent stellt ein paar Fragen und speichert Ihre Anfrage zur Prüfung durch unser Team.

## Weiter entdecken

- [Penetrationstests](https://uhl.cloud/penetration-testing/)

- [Sicherheit & verantwortungsvolle KI](https://uhl.cloud/security/)

- [Wazuh Security Operations](https://uhl.cloud/wazuh/)

## Sprechen wir über Ihr Projekt.

[UHL kontaktieren](https://uhl.cloud/contact/)