Die Erfindung von Erebus Strike und ein Durchgang durch einen Pentest mit unserem AI-Agenten von der Testvorbereitung bis zum Abschlussbericht

Moderne AI-Modelle entwickeln zunehmend Fähigkeiten, die noch vor kurzer Zeit erfahrenen Securityspezialisten vorbehalten waren. Mithilfe solcher Modelle ist es überdies teilweise ressourcenschonender, günstiger und bequemer geworden, ausnutzbare Schwachstellen beispielsweise in exponierten Diensten zu finden, als eine aufwendige Social Engineering-Kampagne durchzuführen. Auch die Zeit, die benötigt wird, um konkrete Angriffswerkzeuge und Exploits zu entwickeln, hat sich in vielen Fällen erheblich verkürzt. Was noch vor einem Jahr mehrere Tage oder Wochen dauern konnte, ist heute innerhalb weniger Minuten möglich.

Dieser Effizienzgewinn führt unmittelbar zu einer Verschärfung der Bedrohungslage. Die neuen Möglichkeiten können jedoch auch gezielt genutzt werden, um die Effizienz von Penetrationstests zu steigern. Richtig eingesetzt, kann mithilfe von Künstlicher Intelligenz beispielsweise eine größere Testabdeckung und eine höhere Testtiefe in Penetrationstests erreicht werden.

Seit Anfang 2025 forschen wir bei SySS daran, wie AI sinnvoll in unsere Sicherheitstests zu integrieren ist. Wir führten zahlreiche Tests mit unterschiedlichen Modellen und Pentest-Agenten durch, ohne jedoch ausreichend gute Ergebnisse zu erzielen. Gleichzeitig entwickelten, hosteten und evaluierten wir auch interne AI-Systeme. Schließlich begannen wir damit, unseren eigenen Pentest-Agenten zu entwickeln. Dabei war uns besonders wichtig, die Rahmenbedingungen eines Penetrationstestprojekts klar definieren und zuverlässig einhalten zu können, ohne die Kreativität und Flexibilität der eingesetzten Modelle unnötig einzuschränken. Außerdem wollten wir zeigen, dass der bloße Einsatz eines leistungsfähigen Frontier-Modells von Herstellern wie OpenAI oder Anthropic nicht ausreicht, um belastbare Testergebnisse zu erzielen. Unsere Annahme war, dass ein gutes Harnessing – sprich: ein gutes Steuerungs-, Werkzeug- und Kontrollsystem für die AI – und eine geeignete Agentenarchitektur mindestens genauso entscheidend sind wie die reine Leistungsfähigkeit des zugrunde liegenden Modells. Aus diesen Überlegungen entstand unser Pentest-Agent „Erebus Strike“.

Inventing Erebus Strike: Wie bewährt sich ein Pentest-Agent?

Erebus Strike musste sich zuerst an einer von SySS per Vibe Coding durch AI entwickelten Testanwendung beweisen. Unsere Entwickler ließen 71 Schwachstellen implementieren, verteilt über alle OWASP-Top-10-Kategorien. Zusätzlich gab es Business Logic Flaws, also anwendungsspezifische Schwachstellen in der Businesslogik, die nicht von den OWASP Top 10 abgedeckt sind. Unsere AI-Spezialisten haben die Schwachstellen nach Ausnutzbarkeit und Findbarkeit bewertet, auf einer Skala von 1 bis 5. Eine Findbarkeit von 5 bedeutet: sehr schwer zu finden, teilweise nur mit Quellcode-Review. Eine Ausnutzbarkeit von 5 läge zum Beispiel nur unter Laborbedingungen vor.

Schon nach wenigen Entwicklungsiterationen erzielte Erebus Strike in unserer internen Testumgebung deutlich bessere Ergebnisse als die zuvor getesteten Ansätze. Erebus Strike hat sämtliche 71 absichtlich implementierte Schwachstellen gefunden. Kurios war außerdem: Der SySS-Agent hat zudem Schwachstellen im Vibe-coded Code gefunden, die nicht absichtlich dort platziert worden waren.

Das heißt: AI-gestützte Pentests können bisher nie gekannte Geschwindigkeiten und eine bisher unvorstellbare Skalierbarkeit erreichen. Erebus Strike kann riesige Mengen an Quellcode, Zusammenhängen, Hypothesen und sicherheitsrelevanten Codepfaden analysieren und in kürzester Zeit verarbeiten. Zu denken ist etwa an Authentifizierungsroutinen, Eingabeverarbeitung und alles, was von außen durch Benutzer oder Angreifer in den Code gelangt und weiterverarbeitet wird. Erebus Strike ist also hervorragend geeignet für sämtliche Testgegenstände, die softwaregetrieben sind. Sicherheitsanalysen von Webapplikationen und Webservices, automatische Softwareanalysen und Reverse Engineering sowie Firmware-Analysen (etwa bei Embedded-Tests) sind mit Erebus Strike optimal durchführbar. Dabei kann SySS verschiedene Modelle verwenden. Wenn wir die SySS-eigene Infrastruktur nutzen, die in unserem Hauptsitz in Tübingen gehostet ist, bleiben sämtliche Daten innerhalb der SySS-Infrastruktur. Insbesondere bei sicherheitskritischen Kunden ist dies eine Voraussetzung. Auf der anderen Seite können wir auf Wunsch des Kunden auch Drittanbieter wie Anthropic oder OpenAI einsetzen oder die AI-Umgebung des Kunden verwenden. Als Mittelweg – der tatsächlich für die meisten Kunden am besten passt – können wir auf selbstgehostete OpenWeight-Modelle in Rechenzentren von EU-Providern und in der EU zurückgreifen. Welches Modell zum Einsatz kommt, entscheidet der Kunde.

Preparing for the Test: Was ist ein Custom Harness?

Gerade in der Testvorbereitung spielt der Kunde, wie bei klassischen Penetrationstests auch, eine zentrale Rolle. Kunde und Tester definieren gemeinsam den Custom Harness. Wie jedem anderen Pentest geht auch einem AI-gestützten Pentest ein Kick-off-Gespräch mit einem SySS-Consultant voraus. Hier werden die relevanten Informationen und Daten besprochen, etwa: Gibt es eine Testumgebung? Wann darf getestet werden? Welche Zugänge gibt es? Und so weiter.

Auch die Vor- und Nachteile der verschiedenen Modelle werden im Kick-off erörtert.

Bei AI-gestützten Pentests ist es außerdem sehr zielführend, wenn der Kunde den Quellcode zur Verfügung stellt. Während menschliche Pentester in einem begrenzten Testzeitraum den gesamten Quellcode nicht sichten können, ist Erebus Strike dazu in der Lage, ihn in kurzer Zeit zu durchsuchen und starke Hypothesen zu bilden. Dadurch steigen die Chancen, relevante Schwachstellen zu finden. Doch auch bei Blackbox-Assessments kommt Erebus Strike mit kleinen Modellen zu deutlich besseren Ergebnissen als Frontier-Modelle mit simplen Prompts und Zugriff auf den Quellcode.

Mit sämtlichen Informationen aus dem Kick-off wird Erebus Strike dann „gefüttert“. Auch individuelle Kundenwünsche können berücksichtigt werden.

Moritz Abrell, der Entwickler von Erebus Strike, erläutert den konkreten Vorgang wie folgt:

„In der Konfiguration fragt Erebus Strike zum Beispiel das Ziel ab, das getestet werden soll, und ob Dinge out of scope sind, etwa bestimmte Endpunkte oder Funktionen. Sehr wichtig ist ein Hilfsprompt. Dort kann ich alle Informationen hinterlegen, die der Kunde erwähnt hat. Wenn der Kunde im Kick-off mitteilt, dass im letzten Release eine bestimmte Funktion implementiert wurde, die noch nie einem Pentest unterzogen wurde und im Fokus stehen soll, kann ich das dort eintragen. Erebus Strike berücksichtigt diesen Fokus.“

Weiter erklärt der Entwickler: „Ein großer Vorteil von Large Language Models (LLMs) ist, dass sie viele Daten verarbeiten können. Ich kann unterschiedlichste Materialien mitgeben: Quellcode, die Ergebnisse eines vorherigen Pentests, API-Dokumentationen, allgemeine Anwendungsdokumentationen, das Kick-off-Protokoll, das zugrunde liegende Threat Model sowie Architekturdokumentationen oder User Manuals. Erebus Strike sichtet diese Materialien und berücksichtigt sie im Test. Diese Informationen verfügbar zu haben, erhöht die Testeffizienz immens.“

Im nächsten Schritt legt der SySS-Tester Zugänge für verschiedene Rollen an. Dazu können auch „Wegwerf“-Zugänge gehören, die für Brute-Force-Angriffe oder ähnliche Tests verwendet werden, damit keine anderen Testkonten gesperrt werden.

Anschließend wählt der SySS-Consultant das Back-End, also das LLM, das für den Sicherheitstest verwendet werden soll. Der Tester kann auch für bestimmte Schritte unterschiedliche Modelle wählen. Wenn der Verifizierungsschritt besonders stark sein muss, der Discovery-Schritt aber weniger anspruchsvoll ist, können jeweils unterschiedliche Modelle zum Einsatz kommen. Auch bei besonders komplexen Anwendungen können mehrere Modelle sinnvoll sein.

Starting the Test: Wie arbeitet ein Pentest-Agent?

Um zu verstehen, wie ein Pentest-Agent arbeitet, muss erst einmal klar sein, was ein Agent überhaupt ist. Ein Agent ist zunächst eine Automatisierung eines bestimmten Ablaufs. Automatisierte Abläufe in Pentests sind schon lange in Gestalt von Schwachstellenscans bekannt. Während aber ein solcher Scan einem relativ strikten Ablauf folgt, trifft das agentische System in einem AI-gestützten Pentest basierend auf dem Testgegenstand eigenständig spezifische Entscheidungen. Der Agent agiert hier wie ein menschlicher Tester. Dazu ist der Agent befähigt, weil er mit Wissen über Schwachstellenklassen, Technologien und typische IT-Sicherheitsprobleme sowie gängige Testmethoden trainiert wird. Der Agent weiß alles über SQL-, Command-, HTML-Injection-Angriffe, Zugriffskontroll- und Autorisierungsprüfungen wie IDOR/BOLA, Authentifizierungsprüfungen sowie Protokoll- und technologiespezifische Tests bezüglich z. B. OAuth, WebSockets, gRPC oder Race Conditions. Genau hier zeigt sich der Unterschied zum klassischen Scanner: Der Agent führt diese Methoden nicht strikt durch, sondern wählt sie abhängig vom Testgegenstand und passt Payloads gezielt an. Wird die Authentifizierung beispielsweise basierend auf JSON Web Tokens (JWT) erkannt, priorisiert der Agent automatisch die JWT-Testreihe; sieht er einen Dateiupload, wird der Uploadspezialist aktiviert usw. Nicht zuletzt werden Grenzen für sein Agieren definiert – und zwar von einem menschlichen Sicherheitsexperten. Der Pentester definiert nicht nur einen Systemprompt, sondern weist den Agenten konkret an, wie er arbeiten soll. Eine solche Anweisung kann beispielsweise darin bestehen, bestimmte Testschritte in Subagenten auszulagern. Ein anderes Bespiel wäre eine Anweisung, in welcher spezifischen Form der Agent antworten soll.

Conducting the Pentest: Was kann ein Pentest-Agent autonom erreichen?

Wie der menschliche Tester beginnt der Agent mit einer Discovery-Phase: Er verschafft sich einen Überblick über die Anwendung und ermittelt die Angriffsfläche. Er überlegt, welche Angriffspfade und -vektoren relevant sein könnten und wie lukrativ diese je nach Threat Model sind. Wenn Testkandidaten entstehen, versucht er, diese auszunutzen. Wenn ein Schwachstellenkandidat entsteht, wird dieser verifiziert – je nach Schweregrad auch mehrfach. Ein Orchestrator verteilt kleine Arbeitspakete an spezialisierte Subagenten. Subagenten erledigen sehr eingeschränkte, spezifische Aufgaben und melden ihre Ergebnisse an den Orchestrator zurück. Dieser wertet die Rückmeldungen der Subagenten aus, verarbeitet sie weiter und plant die nächsten Testschritte. Allgemeiner gesprochen: Der Orchestrator abstrahiert die Testschritte und legt fest, wann und wie genau sie ausgeführt werden – ganz genauso wie ein menschlicher Pentester es tut.

Ein Beispiel: In der Discovery-Phase erzeugt der Orchestrator einen Subagenten und promptet sinngemäß: „Du bist ein Pentest-Discovery-Agent und führst einen autorisierten Penetrationstest gegen dieses Webinterface durch [...].“ Dazu kommen Anweisungen, wie der Subagent das System erreicht, worauf er achten soll und in welchem Format er seine Ergebnisse zurückmelden soll. Ein Auftrag könnte wie folgt lauten: „Schau dir die Applikation an, prüfe die Sitemap, werte JavaScript aus, suche Links, Referenzen und API-Dokumentationen. Alles, was du findest, dokumentierst du in der festgelegten Form und gibst es zurück.“ Der Orchestrator erhält diese Informationen in strukturierter Form und kennt somit die vorhandenen Endpunkte und Signale. Darauf aufbauend leitet er Hypothesen ab und plant den nächsten Testschritt. Beispielsweise beauftragt er gezielt weitere Subagenten, einzelne Endpunkte auf konkrete Schwachstellenklassen zu prüfen. Jeder Subagent meldet seine identifizierten Angriffsflächen und möglichen Schwachstellen strukturiert zurück, woraufhin der Orchestrator den jeweils nächsten Schritt plant. Ist auch der Quellcode Teil des Auftrags, kommen zusätzliche Quellcode-Review-Spezialisten (Subagenten) hinzu, die Angriffsflächen auf Code-Ebene identifizieren.

Abb. 1: Findings Erebus Strike: Einblick in die identifizierten Schwachstellen

Validation of Results: Wie arbeiten Mensch und Maschine zusammen?

In diesem Prozess entstehen regelmäßig Test- oder Schwachstellenkandidaten, die sich am Ende als False Positives erweisen. Um diese abzufangen, folgt Erebus Strike einem adversariellen Verifikationsverfahren. Ein Pentest-Validator erhält einen einzelnen Kandidaten mit dem Auftrag, ihn zu widerlegen. Er nimmt also zunächst an, dass die Behauptung falsch ist, und versucht, sie aus einem neuen Kontext gezielt zu widerlegen. Nur ein Fund, der diesen Schritt übersteht, gilt als bestätigt. Bei kritischen und hohen Funden genügt eine Runde nicht. Der Fund muss mehrere unabhängige Prüfungen aus unterschiedlichen Blickwinkeln überstehen. So wird beispielsweise versucht, den Proof of Concept aus einem sauberen Zustand zu reproduzieren. In einer weiteren, unabhängigen Runde wird mit einem anderen Ansatz geprüft, ob der Effekt eine echte Sicherheitsgrenze verletzt oder eine gewollte Funktion ist. Ein Beispiel dafür wäre, dass sich Daten allein über ihre ID abrufen lassen; denn dies ist ein Indikator für einen unautorisierten Zugriff.

Die zweite Runde klärt: Handelt es sich dabei um öffentlich freigegebene Daten? Dann ist dies ein gewünschtes Verhalten und keine Schwachstelle. Es wird also das tatsächliche Risiko bewertet und geklärt, ob das anwendungsspezifische Threat Model zutrifft.

Am Ende dieser mehrstufigen Verifikation steht eine Liste bestätigter Funde, die allesamt technisch korrekt und reproduzierbar sind. Wenn ein Fund widerlegt wird, wird er als „refuted“ markiert. In solchen Fällen kann es sein, dass die technische Beobachtung zwar stimmt, aber in der realen Anwendung keine Rolle spielt, etwa weil der betroffene Code gar nicht aufgerufen wird.

All das ist dokumentiert und wird vom SySS-Tester auf Plausibilität geprüft. Der Consultant kann sämtliche Tätigkeiten und Entscheidungen von Erebus Strike, gewissermaßen seinen Denkprozess, nachvollziehen: Was hat der Agent genau gemacht? Warum hat er es gemacht? Wie kam er zu dieser Entscheidung? Welche Teile hat er nicht gesehen oder nicht betrachtet? Welche Tools und Angriffsvektoren hat er verwendet? Welche Kommandos hat er aufgerufen? Mit welchen Parametern?

Durch den Custom Harness stellt der SySS-Consultant vor Testbeginn sicher, dass die kundenspezifischen Rahmenbedingungen des Projekts berücksichtigt werden. Indem er die Testschritte nachvollzieht und auf Plausibilität prüft, garantiert er korrekte und belastbare Ergebnisse. Zusätzlich existiert ein genereller Log, in dem alle Vorgänge protokolliert sind. Nicht zuletzt kann Erebus Strike die Anwendung n-mal prüfen und die Ergebnisse anschließend zusammenführen. Bis zu einem gewissen Punkt steigt mit der Zahl der Testdurchläufe die Wahrscheinlichkeit, eine große Abdeckung der vorhandenen Schwachstellen zu erreichen. Ab einem gewissen Punkt flacht dann der Nutzen ab – es ist schlicht schon alles Relevante gefunden worden. Wo genau dieser Punkt liegt, hängt von der Komplexität der Anwendung ab, beispielsweise davon, ob Schwachstellen existieren, die nur im Zusammenspiel mit eingeloggten Benutzern auffindbar sind. Auch der Umstand, ob es sich um einen komplett neuen Test handelt oder um einen erneuten Test einer bekannten Anwendung, kann hier Einfluss haben.

Abb. 2: Log Erebus Strike: Alle Entscheidungs- und Aktionsschritte sowie Toolaufrufe und deren Ausgaben können detailliert nachvollzogen werden

Evaluation of Findings, Prioritization of measures: Wo ist der Mensch unabdingbar?

Erebus Strike zeigt am Ende einen Überblick über alle gefundenen Schwachstellen. Ein erfahrener SySS-Consultant ordnet die Ergebnisse nach unserem bewährten Verfahren ein, bevor er sie an unseren Kunden übermittelt. Der IT-Sicherheitsberater prüft die Ergebnisse, priorisiert sie und arbeitet die empfohlenen Maßnahmen individuell und passgenau für den Kunden auf.

Am Projektende erhält der Kunde einen technisch und sprachlich qualitätsgesicherten SySS-Report, wie er ihn gewohnt ist. Jeder Abschnitt darin ist manuell verifiziert und qualitätsgeprüft. Zu jedem Fund gibt es passende Empfehlungen, wie die Schwachstelle zu beheben ist. Hier greifen wir auf unser ausgeprägtes Know-how und unsere jahrelange Erfahrung zurück.

Dass mithilfe von AI mehr Schwachstellen gefunden werden als je zuvor, stellt IT- und IT-Sicherheitsverantwortliche vor große Herausforderungen bei der Planung ihrer IT-Architektur, der Priorisierung von Schwachstellen und ggf. erforderlichen Gegenmaßnahmen. Der große Vorteil eines AI-gestützten Pentests bei SySS ist, dass unsere Kunden nicht nur die Fähigkeiten des Agenten Erebus Strike einkaufen, sondern auch unsere Beratungsdienstleistung. Der große Mehrwert unseres hybriden Ansatzes liegt darin, dass die technische Unterstützung durch AI mit menschlicher Expertise, Erfahrung und Beratungsleistung ergänzt wird. Der größte Mehrwert liegt darin, dass diese Kombination genau das Problem lösen kann, vor dem IT- und IT-Sicherheitsverantwortliche derzeit stehen.

Neuer AI-Pentest-Agent Erebus Strike: So funktionieren AI-gestützte Pentests von SySS