Pentest in Zeiten von KI

Wie könnte ein Angreifer in Ihre IT gelangen? Könnte er Kundendaten lesen, Administratorrechte erlangen oder weitere Systeme übernehmen? Ein Penetrationstest prüft solche Angriffswege an den vereinbarten Systemen.

Dabei geht es um bekannte Schwachstellen ebenso wie um Fehler in eigener Software und zu weitreichende Zugriffsrechte. KI kann das Testteam bei der Analyse und den Angriffsversuchen unterstützen. Der Bericht muss zeigen, was tatsächlich funktioniert hat, welche Schutzmaßnahmen gehalten haben und was Ihre IT zuerst beheben sollte.

Arbeitshilfen: Prüfmatrix · Checkliste für den Prüfauftrag · Praxisbefund

Was verändert KI beim Pentest?

1. Unsere Sicherheitstools melden einen guten Zustand. Warum zusätzlich testen?

Ein Statusbericht zeigt eingerichtete Kontrollen und vorhandene Meldungen. Ein praktischer Test untersucht, ob die gewünschte Einschränkung unter den tatsächlichen Benutzerrechten und Geräteeinstellungen greift.

Eine Anwendungskontrolle kann beispielsweise nur protokollieren, obwohl das Unternehmen eine Blockierung erwartet. Der Unterschied wird bei einer Ausführungsprobe sichtbar. Ein solcher Befund hilft, die passende Einstellung und das Ziel eines Nachtests zu bestimmen.

2. Warum beschäftigen sich Unternehmen gerade jetzt mit Pentests und KI?

KI wird sowohl für Angriffe als auch für die Verteidigung eingesetzt. Das britische National Cyber Security Centre bewertet sie als Unterstützung bestehender Angriffstechniken, etwa bei Aufklärung, Schwachstellenanalyse und der Entwicklung von Angriffscode. Seine Einschätzung bis 2027 erwartet zudem mehr Druck auf Systeme, deren Sicherheitsupdates fehlen.

Für Ihr Unternehmen entstehen daraus konkrete Fragen: Welche erreichbaren Systeme sind ungepatcht? Halten Berechtigungsgrenzen? Und welche zusätzlichen Zugriffe erhalten eigene KI-Anwendungen? Eine gezielte Prüfung kann diese Fragen vertiefen und Maßnahmen begründen.

Einordnung der Bedrohung, einschließlich Prognosen: NCSC: Impact of AI on cyber threat from now to 2027.

3. Was ist ein KI-gestützter Pentest, und was bedeutet „Agentic Pentesting“?

„KI-gestützter Penetrationstest“ ist der übergeordnete Begriff für Tests mit KI-Unterstützung. Beim hier beschriebenen Agentic Pentesting verbinden KI-Agenten mehrere Untersuchungsschritte: Kontext auswerten, Werkzeuge einsetzen und aus Zwischenergebnissen weitere Prüfungen ableiten.

„Pentest mit KI-Agenten“ oder „agentenbasierte Sicherheitsprüfung“ beschreiben diesen Ansatz ebenfalls. Lassen Sie sich erläutern, welche Aufgaben die Agenten übernehmen, wie ihre Handlungen begrenzt werden und wer die Ergebnisse bewertet.

4. Welchen Nutzen bringt die KI für unsere IT?

KI kann beim Abgleich von Inventurdaten, Quellcode, Konfigurationen und Testprotokollen unterstützen. Aus einem Hinweis lassen sich gezielte Prüffragen ableiten: Ist die betroffene Komponente installiert? Treffen die Voraussetzungen zu? Welcher praktische Test kann die Wirkung klären?

Der Nutzen zeigt sich in nachvollziehbaren Antworten und verwertbaren Befunden. Vergleichen Sie Angebote deshalb anhand der vorgesehenen Szenarien, Nachweise und Auswertung. Aussagen über Zeitersparnis oder zusätzliche Abdeckung brauchen einen passenden Vergleich.

5. Wie ergänzt ein KI-Pentest unsere Scanner und bisherigen Tests?

Ein Schwachstellenscanner kann auf veraltete Software und bekannte Sicherheitslücken hinweisen. Viele öffentlich bekannte Lücken haben eine CVE-Kennung. Diese Kennung bezeichnet die Schwachstelle; sie beweist noch nicht, dass Ihre Installation betroffen ist oder angegriffen werden kann.

Ein Pentest untersucht ausgewählte Hinweise genauer: Ist die betroffene Funktion aktiv? Ist sie für einen Angreifer erreichbar? Lässt sich die Lücke unter den tatsächlichen Bedingungen ausnutzen? Dazu können Exploits eingesetzt werden, also Code oder Methoden, die eine Schwachstelle ausnutzen. Solche Versuche müssen vom Prüfauftrag gedeckt sein.

Der Bericht trennt den ersten Hinweis von der bestätigten Schwachstelle und einem gelungenen Angriffsversuch. Eine betroffene Software sollte auch dann aktualisiert werden, wenn ihre Ausnutzung im Test nicht bestätigt wurde.

Grundlage: CVE-Programm.

Was sollten wir prüfen lassen?

6. Wie gut schützt unsere Gerätehärtung im Arbeitsalltag?

Das lässt sich für ausgewählte Geräte und Benutzerrollen praktisch prüfen. Relevante Fragen betreffen Programmausführung, lokale Rechte und administrative Abläufe. Auch Ausnahmen für Fachanwendungen gehören dazu: Verändern sie die vorgesehene Schutzwirkung?

Die Auswahl sollte wichtige Unterschiede Ihrer Geräteflotte berücksichtigen. Der Bericht nennt jeweils Konfiguration, Benutzerrolle und geprüften Stand. So bleibt erkennbar, für welche Geräte die Aussage gilt und wo weitere Tests erforderlich sind.

7. Was sollte ein Sicherheitstest unserer Software untersuchen?

Ein Test sollte prüfen, ob sich Ihre Anwendung oder API missbrauchen lässt: Kann ein Benutzer Daten anderer Kunden lesen? Lassen sich Anmeldungen umgehen, Bestellungen manipulieren oder über Eingaben unerlaubte Befehle ausführen? Solche Fehler können auch in eigener Software auftreten, für die es keine CVE-Kennung gibt.

Eine Codeprüfung untersucht die Ursachen im Quellcode. Ein praktischer Anwendungstest prüft, welche Wirkung unter den vereinbarten Bedingungen möglich ist. Dazu gehören auch eingesetzte Bibliotheken und andere Softwareabhängigkeiten. Quellcode und getestete Anwendungsversion müssen zusammenpassen. Das gilt ebenso für KI-generierten Code.

Beim Thema Schadcode sind zwei Aufgaben zu unterscheiden: Kann ein Angreifer über eine Lücke eigenen Code ausführen? Oder enthält die Software bereits eine bösartige Komponente? Eine gezielte Suche nach verstecktem Schadcode braucht einen eigenen Prüfauftrag. Ein gewöhnlicher Pentest garantiert nicht, dass jede solche Komponente gefunden wird.

Orientierung zu Codeanalyse, Anwendungstests und Geschäftsabläufen: OWASP Web Security Testing Guide.

8. Wie weit käme ein Angreifer mit einem einzelnen Zugang?

Ein Test kann von einem festgelegten Ausgangspunkt beginnen, etwa einem Benutzerkonto, Dienstkonto oder einer isolierten Anwendung. Untersucht wird, welche weiteren Rechte, Daten oder Systeme unter diesen Bedingungen erreichbar sind.

Für jeden Übergang braucht es eigene Belege. Ein beschreibbarer Ordner allein beweist noch keine Rechteausweitung. Zu klären ist beispielsweise, ob eine privilegierte Komponente diesen Pfad nutzt und welche Wirkung dadurch tatsächlich erreichbar wäre. Die Prüfung weiterer Systeme muss vom Auftrag erfasst sein.

9. Lassen sich Microsoft 365 und Cloud-Ressourcen einbeziehen?

Je nach Auftrag können Ihre Identitäten, Berechtigungen, Anwendungen und ihre Verbindungen untersucht werden. Die Ressourcen Ihres Unternehmens und die Infrastruktur des Plattformanbieters müssen dabei klar zugeordnet sein.

Microsoft veröffentlicht eigene Rules of Engagement für Sicherheitstests. Zusätzlich zu Ihrer Freigabe gelten diese Regeln für die jeweiligen Dienste. Der zulässige Rahmen begrenzt auch Ziele und Werkzeuge der KI-Agenten.

Quelle: Microsoft: Security Testing Rules of Engagement.

10. Wo sollten wir mit begrenztem Budget anfangen?

Beginnen Sie dort, wo ein Angriff wichtige Daten oder den Betrieb gefährden könnte: etwa bei einer öffentlich erreichbaren Kundenanwendung, einem administrativen Zugang oder Systemen mit sensiblen Daten. Vor der Freigabe einer neuen Anwendung kann beispielsweise geprüft werden, ob Kunden ausschließlich auf ihre eigenen Daten zugreifen können.

Beziehen Sie die Verantwortlichen des Geschäftsprozesses ein: Welche Daten sind sensibel? Welche Funktion muss verfügbar bleiben? Daraus ergeben sich die wichtigen Systeme und Szenarien. Ein breiterer Test ist sinnvoll, wenn die vermutete Angriffskette mehrere Bereiche verbindet.

11. Was ist bei eigenen KI-Anwendungen und Unternehmensagenten zu prüfen?

Eigene KI-Systeme können ein gesondertes Prüfziel sein. Dabei geht es um erreichbare Daten, verbundene Werkzeuge und die Reaktion auf fremde Inhalte. Darf ein Agent beispielsweise nur die vorgesehenen Dokumente lesen? Können Inhalte aus einer Webseite ihn zu einer unzulässigen Handlung veranlassen?

Die Tests orientieren sich an seinen Aufgaben und erlaubten Handlungen. Im Auftrag wird festgehalten, ob die KI bei der Untersuchung eingesetzt wird, selbst das Ziel der Untersuchung ist oder beides zutrifft.

Arbeitshilfe 1: Was sollte ein Pentest in Ihrem Unternehmen prüfen?

Wählen Sie die Bereiche passend zu Ihren Systemen und Risiken aus. Der Auftrag legt fest, was getestet wird. Die Tabelle beschreibt mögliche Prüfungen und keine bereits nachgewiesenen Sicherheitslücken. Eigene KI-Anwendungen können zusätzlich untersucht werden, wie in Frage 11 beschrieben.

Wie behalten wir Kontrolle über Ablauf und Daten?

12. Wann ist der richtige Zeitpunkt, und was sollten wir erneut prüfen?

Ein guter Anlass ist eine Änderung, deren Sicherheitswirkung Sie beurteilen möchten: ein größerer Release, eine neue Geräte-Baseline, geänderte Rechte oder zusätzliche Verbindungen zwischen Systemen. Planen Sie die Untersuchung so, dass ihr Ergebnis noch in die Freigabe oder weitere Umsetzung einfließen kann.

Nach einem früheren Pentest sind die damaligen offenen Fragen und die Änderungen seitdem maßgeblich. Für korrigierte Befunde sollte ein Nachtest denselben Weg mit dem aktuellen Stand untersuchen. Die gewünschte zusätzliche Erkenntnis gehört in den Auftrag.

13. Wie läuft ein Penetrationstest mit KI-Unterstützung ab?

Zunächst werden die Zielsysteme, die verfügbaren Zugänge und die erlaubten Angriffsmethoden festgelegt. Das Testteam untersucht erreichbare Funktionen und mögliche Schwachstellen. Anschließend prüft es ausgewählte Angriffswege: Lässt sich eine Lücke ausnutzen? Können zusätzliche Rechte erlangt oder weitere Systeme erreicht werden? Jeder weitere Schritt muss vom Auftrag gedeckt sein.

KI kann bei der Analyse und Durchführung einzelner Schritte unterstützen. Das Testteam prüft die Ergebnisse und dokumentiert, welche Angriffe funktioniert haben und wo Schutzmaßnahmen den Zugriff verhindert haben. Ihre IT erhält Empfehlungen zur Behebung. Ein Nachtest kann anschließend prüfen, ob die Korrekturen wirken.

14. Welche Vorbereitung und Zugänge benötigt das Testteam?

Die Zugänge richten sich nach der Perspektive: Ein externer Test untersucht freigegebene, von außen erreichbare Funktionen. Eine Rollenprüfung benötigt passende Testkonten. Für eine Codeanalyse wird der festgelegte Quellcode bereitgestellt. Architekturinformationen und bekannte Ausnahmen erleichtern die Planung.

Klären Sie, welche Sicht fehlt. Eine lokale Abfrage zeigt beispielsweise nicht immer die zentrale Richtlinienzuweisung. Administrative Rechte können nötig sein, um einen widersprüchlichen Laufzeitstatus zu prüfen. Bleibt diese Sicht aus, muss der Bericht die offene Frage benennen.

15. Wie selbstständig darf ein Prüfagent handeln?

Ein Agent kann freigegebene Schritte innerhalb des festgelegten Rahmens bearbeiten. Werkzeuge, Zugänge und erreichbare Ziele müssen dazu passend begrenzt sein. Fachliche Überwachung, Meldewege und Abbruchkriterien gehören in den Ablauf. Zusätzliche Ziele oder betriebsrelevante Veränderungen benötigen eine entsprechende Freigabe.

Fremde Inhalte aus Webseiten, Dokumenten oder Quellcode sind Untersuchungsmaterial. Sie dürfen den Auftrag nicht erweitern. Klären Sie mit dem Anbieter, wie er diese Grenze absichert und den Testverlauf dokumentiert.

Grundlage für die Planung technischer Sicherheitstests: NIST SP 800-115.

16. Was passiert mit Quellcode, Zugangsdaten und vertraulichen Befunden?

Vor dem Start muss feststehen, welche Daten benötigt werden, welche Produkte sie verarbeiten und wie lange sie gespeichert werden. Testkonten erhalten die für das Szenario erforderlichen Rechte. Technische Belege und Ergebnisse gehören in einen geschützten Austausch. Entfernung der Zugänge und Umgang mit verbleibenden Testartefakten werden ebenfalls festgelegt.

Für die OpenAI API gilt laut OpenAI: Eingaben und Ausgaben werden standardmäßig nicht zum Modelltraining verwendet, sofern Sie der Datenfreigabe nicht ausdrücklich zustimmen. Speicherung und weitere Datenflüsse müssen für die tatsächlich eingesetzten Produkte und Konfigurationen separat geklärt werden.

Quelle: OpenAI: Data controls in the OpenAI platform.

17. Wovon hängen Dauer und Kosten ab?

Maßgeblich sind Anzahl und Komplexität der Zielsysteme, die Zugänge und die gewünschte Prüftiefe. Auch die Überprüfung von Hinweisen, die Dokumentation und die gemeinsame Auswertung benötigen Zeit.

Ein vergleichbares Angebot beschreibt Szenarien und Ergebnisse. Klären Sie, ob die Besprechung, Unterstützung bei der Behebung und ein Re-Test enthalten sind. So lässt sich der Aufwand dem tatsächlichen Prüfauftrag zuordnen.

Arbeitshilfe 2: Was vor dem Start im Auftrag stehen sollte

Nutzen Sie die Liste für das Anbietergespräch und ergänzen Sie die Anforderungen Ihres Betriebs.

Was ist belegt, und welche Maßnahmen folgen?

18. Woran erkennen wir einen Bericht, mit dem unsere IT arbeiten kann?

Ein brauchbarer Befund nennt das Zielsystem, den geprüften Stand, die Ausgangsrechte, die Beobachtung und ihre Belege. Dazu gehören eine eindeutige Referenz, eine begründete Einstufung und eine umsetzbare Empfehlung.

Die Geschäftsleitung benötigt eine Einordnung der wesentlichen Folgen. Die IT braucht genügend Details für Umsetzung und Nachtest. Bei einer offenen Frage muss erkennbar sein, warum die Prüfung nicht abgeschlossen werden konnte und welcher zusätzliche Schritt zur Klärung nötig ist.

Orientierung zur Berichterstattung: OWASP Web Security Testing Guide: Reporting.

19. Was unterscheidet einen Hinweis von einem bestätigten Angriff?

Eine betroffene Softwareversion, eine abweichende Konfiguration und eine praktisch bestätigte Ausnutzung tragen unterschiedliche Aussagen. Ein Versionsbefund kann eine konkrete Maßnahme begründen, während die lokalen Voraussetzungen einer Ausnutzung noch offen sind.

Ein bestätigter Angriff braucht einen dokumentierten Effekt unter den getesteten Bedingungen. Ebenso kann der Test eine wirksame Blockierung belegen. Der Bericht sollte für jeden Punkt erkennen lassen, welche Aussage durch die Belege getragen wird.

20. Wie sieht das an einem konkreten Praxisbefund aus?

In einem ausgewerteten Endgeräte-Prüfbericht ließ sich eine neu kompilierte, unsignierte Testanwendung aus einem Benutzerordner ausführen. AppLocker protokollierte mit Ereignis 8003, dass die Datei bei erzwungener Richtlinie blockiert worden wäre. Die EXE-Regelsammlung stand im Auditmodus.

Skriptdateien wurden durch eine andere, erzwungene Regelsammlung blockiert. Der Test zeigte damit eine gezielte Konfigurationsfrage für EXE-Dateien. Eine Umgehung einer erzwungenen Regel oder eine Rechteausweitung wurde durch diese Ausführungsprobe nicht nachgewiesen.

Arbeitshilfe 3: Vom Praxisbefund zum überprüfbaren Abschluss

Einordnung der Ereignisse 8003 und 8007: Microsoft: AppLocker-Ereignisse. Maßnahme und Abschlusskriterium beschreiben das weitere Vorgehen.

21. Was bedeutet ein Test, bei dem kein Angriff bis zum Ziel gelingt?

Sein Wert hängt davon ab, welche Fragen beantwortet wurden. Im ausgewerteten Endgeräte-Bericht wurden kein bestätigter Exploit und keine vollständige Angriffskette dokumentiert. Dennoch ließen sich Maßnahmen für Patchstand, Härtung und Protokollierung ableiten.

Der Bericht muss unterscheiden, ob eine Kontrolle den Test blockierte, eine Voraussetzung fehlte oder ein Szenario offenblieb. So war etwa der Laufzeitstatus einer Schutzfunktion wegen widersprüchlicher Angaben und fehlender administrativer Sicht nicht abschließend geklärt. Daraus folgte die Empfehlung einer gezielten Zusatzprüfung.

22. Wie werden aus den Befunden wirksame Maßnahmen?

Verbinden Sie die technische Bewertung mit Erreichbarkeit, Voraussetzungen und Bedeutung des Geschäftsprozesses. Jede Maßnahme braucht einen Verantwortlichen, einen Termin und ein überprüfbares Ziel. Bei offenen Ergebnissen kann der erste Schritt eine zusätzliche Prüfung sein.

Ein Re-Test wiederholt den ursprünglichen Fall mit dem geänderten Systemstand und dokumentiert die Wirkung. Gegenproben prüfen notwendige Funktionen, etwa den Start einer erlaubten Fachanwendung. Auch KI-generierte Korrekturvorschläge durchlaufen Ihren Freigabeprozess.

23. Was kann eine Angriffssimulation über unsere Erkennung im SOC zeigen?

Für festgelegte Szenarien lassen sich Testhandlungen mit lokalen Protokollen, zentralen Signalen und der Alarmbearbeitung vergleichen. Dazu muss vorher geklärt werden, ob das SOC den Test begleitet oder seine Erkennung geprüft wird und welche Quellen ausgewertet werden.

Im beschriebenen Endgeräte-Bericht erzeugte eine harmlose Inline-PowerShell-Probe im untersuchten lokalen Kanal kein Ereignis mit dem Skriptinhalt. Das begründete eine Frage an die lokale Protokollierung. Die Erkennung in weiteren Datenquellen oder der zentralen Sicherheitsplattform wurde damit nicht bewertet.

Eine abgestimmte Übung kann anschließend konkrete Aufgaben für Datenerfassung, Erkennungsregeln und Reaktionsabläufe ergeben.

Welche Rolle spielen Daybreak und hochzwei?

24. Was ist OpenAI Daybreak?

Daybreak verbindet OpenAI-Modelle, Sicherheitswerkzeuge und kontrollierte Arbeitsabläufe für Cybersecurity. Dazu gehören die Analyse, Überprüfung und Behebung von Schwachstellen sowie autorisierte Sicherheitstests. Fachliche Aufsicht und begrenzte Zugänge sind Teil des beschriebenen Ansatzes.

Für Ihren Auftrag ist maßgeblich, welche Funktionen konkret eingesetzt werden und welche Nachweise daraus entstehen. Fragen Sie nach dem Ablauf vom ersten Hinweis bis zur Bewertung und zum erneuten Test einer Korrektur.

Quelle: OpenAI: Daybreak.

25. Wie unterstützt hochzwei dabei?

hochzwei ist OpenAI Daybreak Partner. OpenAI bezeichnet sein Partnerprogramm als Daybreak Defense Network; es umfasst auch Dienstleistungen, bei denen geschulte Partnerteams die praktische Arbeit übernehmen.

Unsere Einsatzfelder umfassen Endgeräte-Härtung, Codeprüfungen und Tests von Berechtigungs- und Isolationsgrenzen. Gemeinsam legen wir fest, welche Systeme und möglichen Angriffe untersucht werden. Ihre IT erhält die Ergebnisse und Empfehlungen zur Behebung.

Quelle zum Programm: OpenAI: Daybreak Defense Network.

Passende Vertiefungen

• Intune-Reifegrad prüfen: Gerätebetrieb bewerten und Verbesserungen priorisieren.
• App Registrations absichern: Anwendungszugriffe und Berechtigungen in Microsoft 365 prüfen.
• Microsoft-SOC optimieren: Datenabdeckung, Fallbearbeitung und Reaktion beurteilen.

Die Einordnung von KI-Bedrohungen stützt sich auf die verlinkte NCSC-Einschätzung. Produkt- und Verfahrensaussagen beziehen sich auf die genannten Herstellerquellen und Leitfäden, abgerufen am 10. und 11. Oktober 2026. Prüffragen und Tabellen sind redaktionelle Arbeitshilfen von hochzwei. Das Praxisbeispiel basiert auf anonymisierten Beobachtungen eines ausgewerteten Endgeräte-Prüfberichts vom 2. Oktober 2026. Es dokumentiert keine durchgeführte Behebung und keinen abgeschlossenen Nachtest. Die weiteren Szenarien beschreiben mögliche Prüfaufträge. Produktfunktionen und zulässige Tests sind vor der Durchführung erneut abzugleichen.