Nicht nur behaupten, sondern zeigen: Was Evo Continuous Offensive Security in einer echten Enterprise-SaaS-Anwendung gefunden hat

Autonome KI-Angriffe sind endgültig aus den Forschungsdemos herausgewachsen, die alle in Staunen versetzt haben, und gehören inzwischen zum normalen Vorgehen. Wer aufmerksam genug ist, für den ist das nicht unbedingt neu: Die Five Eyes Alliance warnte bereits im Juni, dass KI die Cybersicherheit in Monaten statt Jahren umgehen wird – und dass sich die Ausbruchszeiten von Angreifern inzwischen in Sekunden messen lassen. Auch Gartner prognostizierte etwas Ähnliches und erwartete, dass sich das Zeitfenster bis zur Ausnutzung bereits im nächsten Jahr halbieren wird.

Finden Sie heraus, was Angreifer herausfinden können – bevor sie es tun.

Damit ist unsere Ankündigung zur Verfügbarkeit von Evo Continuous Offensive Security noch relevanter und aktueller. Wir bieten autonome offensive Security, die Ihre Anwendungen und KI-Systeme kontinuierlich angreift – genauso wie ein führendes menschliches Red Team. Möglich wird das durch drei integrierte Funktionen: KI-Pentesting, Agent-Red-Teaming und dynamisches Testing (DAST).

COS wurde als der präziseste und vertrauenswürdigste KI-Pentester auf dem Markt konzipiert. Jeder Fund wird, bevor er Sie erreicht, von einem sozusagen „unabhängigen Prüfer“ auf tatsächliche und reproduzierbare Ausnutzbarkeit validiert. So enthält Ihr Bericht letztlich nur Schwachstellen, die ein Angreifer tatsächlich ausnutzen könnte.

Doch statt Ihnen nur zu erzählen, was das Produkt kann, möchten wir es Ihnen zeigen. Alles Folgende stammt aus einer echten Prüfung einer Kundenanwendung und umfasst zwei der tatsächlich gefundenen und nachgewiesenen Schwachstellen.

Eine echte Kundenprüfung einer mandantenfähigen Enterprise-SaaS-Anwendung

Einer unserer Kunden nutzte COS zur Prüfung einer mandantenfähigen Enterprise-SaaS-Anwendung. Sie bestand aus einer Single-Page-Frontend-Anwendung (SPA), die als Webclient diente und eine Suite aus Hunderten von Microservice-Endpunkten nutzte, welche gemeinsam die Geschäftslogik abbildeten.

Diese Anwendung ist besonders interessant, weil sie sowohl für menschliche Pentester als auch für deterministische Tools wie einen DAST-Scanner auf unterschiedliche Weise schwer zu prüfen ist:

Für Menschen ist es sehr schwierig, die Autorisierung und Geschäftslogik von Hunderten Microservices vollständig abzudecken. Für Maschinen besteht die Herausforderung dagegen nicht im Zugriff. Moderne DAST-Scanner wie Snyk API & Web (die Dynamic-Testing-Funktion innerhalb von Evo COS) authentifizieren sich problemlos bei SPAs und ermitteln die dahinterliegenden Endpunkte. Die Schwierigkeit liegt in fast allem, was danach kommt, denn Autorisierungs- und Geschäftslogikfehler haben keine Signatur, mit der sie abgeglichen werden könnten: Um zu entscheiden, ob eine bestimmte Rolle einen bestimmten Endpunkt aufrufen darf oder ob eine Folge einzeln gültiger Anfragen zu einem von der Anwendung nicht beabsichtigten Ergebnis führt, muss man wissen, welchem Zweck die Anwendung dient und was die einzelnen Akteure tun dürfen. Übertragen Sie das auf Hunderte von Microservices, wird deutlich: Hier geht es viel mehr um Schlussfolgerungen als um Abdeckung. Und genau diesen Teil hat dynamisches Testing bisher nicht automatisiert.

Die agentische Lösung in COS „tastete“ die Anwendung systematisch und geführt ab und nutzte dabei die Leistungsfähigkeit von LLMs:

• Vorabprüfungen: Das System testete die bereitgestellten Zugangsdaten mit einem Headless-Browser und stellte sicher, dass alle erforderlichen Komponenten der Anwendung erreichbar waren und sich die Anwendung in einem testbaren Zustand befand.

• Erste Aufklärung: Ein spezialisierter Sub-Agent ermittelte den Technologie-Stack der Anwendung, die vorhandenen Endpunkte und sicherheitsrelevante Informationen wie den Einsatz einer WAF, über Chat-Oberflächen erreichbare LLM-Agenten, den Authentifizierungsablauf und weitere Aspekte. Entscheidend war, dass dieser Schritt auch Erkenntnisse zum Geschäftszweck der Anwendung lieferte. In diesem Fall leitete das System korrekt ab, wofür das Produkt gedacht war, wer es nutzte und welche Workflows echten kommerziellen Wert hatten – und das allein auf Grundlage einer Staging-Umgebung mit kaum Dokumentation und ausschließlich vorinstallierten Testdaten. Diese Schlussfolgerung ermöglichte es, alle weiteren Ergebnisse nach ihrer geschäftlichen Auswirkung statt nach ihrer technischen Schwere zu bewerten.

• Schwachstellentests und Validierung: Auf Grundlage der Aufklärungsergebnisse wurden spezialisierte Sub-Agenten gestartet, um nach bestimmten Schwachstellenklassen zu suchen. Einzelne Funde wurden von adversarialen Sub-Agenten unabhängig gegengeprüft, um ihre Reproduzierbarkeit sicherzustellen und die Wahrscheinlichkeit falsch positiver Ergebnisse zu minimieren.

• Verknüpfung und Validierung von Schwachstellen: Einzelne Schwachstellen wurden logisch miteinander verknüpft, um zu prüfen, ob sie gemeinsam genutzt werden konnten und dadurch größere geschäftliche Auswirkungen hatten. Auch die Schwachstellenketten wurden von adversarialen Sub-Agenten gegengeprüft und reproduziert.

• Berichtserstellung: Die Ergebnisse wurden in einem Dokument zusammengestellt, das einem von einem menschlichen Team erstellten Bericht nachempfunden war – einschließlich Management Summary und einer nach Priorität geordneten Liste von Maßnahmen zur Risikoreduzierung.

Diese konkrete Prüfung erfolgte vollständig als Black-Box-Ansatz, also ohne Zugriff auf den Quellcode. Wir können auch einen Gray-Box-Ansatz nutzen und durch Zugriff auf den Quellcode die Erkennung und Effizienz verbessern. In diesem Fall haben wir uns jedoch dagegen entschieden. In jedem Fall legen wir den Schwerpunkt auf das dynamische Testen und greifen die Anwendung von außen an, wie es ein echter Angreifer tun würde.

Welche Vorteile haben wir mit diesem Ansatz beobachtet?

1. Den Geschäftszweck von Anwendungen erkennen zu können, ist ein echter Vorteil – insbesondere, wenn er nicht unmittelbar offensichtlich ist. Diese „unaufgeräumte“ Testumgebung enthielt kaum echte Daten und stellte daher selbst für einen Menschen eine Herausforderung dar. Wenn die Geschäftsziele bekannt sind, kann die Agentenflotte die geschäftlichen Auswirkungen bestimmter Schwachstellen besser einschätzen.

2. Unsere Agenten bedienen einen echten Browser und passen sich an jede Authentifizierung an, die ihnen die Anwendung präsentiert – ohne Skripte für einzelne Ziele. Bei einer bestimmten Prüfung war die Anmeldung des Kunden durch eine zeitbasierte Zwei-Faktor-Authentifizierung geschützt. Wir stellten den TOTP-Seed bereit, und der Agent generierte selbst Einmalcodes, während er herausfand, wie er sich anmelden konnte – nicht etwa, weil wir ihn eigens dafür konfiguriert hatten. Das ist weniger als Funktion wichtig, sondern vielmehr als Zuverlässigkeitsmerkmal: Bei automatisierten Tests scheitert die Authentifizierung am häufigsten unbemerkt. Eine Prüfung, die nie über die Anmeldeseite hinauskommt, ist wertlos – ganz gleich, wie gut das Testing sein könnte.

3. Mit einem geführten, methodischen Multi-Agenten-Ansatz profitieren wir von den kreativen Fähigkeiten menschenähnlicher Agenten und gewährleisten zugleich eine systematische Testabdeckung, indem wir jeden Microservice auf Autorisierungs-, Authentifizierungs- und Geschäftslogikfehler prüfen.

Die gefundenen Schwachstellen

In dieser konkreten Anwendung fanden wir insgesamt 33 bestätigte Schwachstellen. Sie reichten von Problemen mit geringer Auswirkung, etwa der Verwendung veralteter oder unsicherer jQuery-Bibliotheken, bis hin zu mehreren kritischen Schwachstellen. Dazu gehörte eine unsichere CORS-Richtlinie, durch die beliebige bösartige Websites Autorisierungstokens stehlen und ohne Interaktion des Nutzers in dessen Namen handeln konnten. Außerdem fanden wir Fehler bei den Autorisierungsebenen, durch die jeder Nutzer sich selbst zum Administrator seines Mandanten machen konnte.

Der Kürze halber stellen wir zwei Ergebnisse vor, die gemeinsam die beiden entscheidenden Unterschiede dieses Ansatzes verdeutlichen: Er findet, was andere Tools aus strukturellen Gründen nicht finden können, und vermittelt die tatsächlichen Auswirkungen dessen, was sie finden.

1. Kompromittierung eines gesamten Mandanten durch Mass Assignment und fehlerhafte Autorisierung auf Funktionsebene

Das ist genau die Art von Fund, die ein DAST-Scanner aus strukturellen Gründen nicht liefern kann und die ein menschlicher Pentester nur mit umfassender Kenntnis der Anwendung aufdecken könnte. Es gibt keine reflektierte Payload, die erkannt werden könnte, und keinen offensichtlichen Fehler, dem man nachgehen könnte: Die Schwachstelle steckt vollständig in der Autorisierungslogik der Anwendung – in einem veralteten administrativen Endpunkt, der die Konfiguration eines gesamten Mandanten verwaltet.

Unser Agent stellte fest, dass ein veralteter JSON-Endpunkt zum Speichern mandantenweiter Kontoeinstellungen Schlüssel-Wert-Paare ohne Einschränkung per Upsert speicherte, ohne serverseitige Rollen- oder Berechtigungsprüfung. Außerdem setzte er die scheinbar erforderlichen Parameter im HMAC-Stil signature / timestamp nicht durch. Anschließend leitete er die Folgen ab und verknüpfte sie: Die Rolle mit den geringsten Berechtigungen – genau die Rolle, die alle Mitarbeitenden bei der Anmeldung erhalten und die nicht einmal die Admin-Oberfläche öffnen kann – konnte beliebige sicherheitskritische Konfigurationen für den gesamten Mandanten ändern. Mehrere dieser Einstellungen ließen sich zu einer vollständigen Kompromittierung nutzen.

Der gesamte Ablauf von der Entdeckung bis zur validierten, unabhängig reproduzierten Schwachstellenkette fand in einem einzigen unbeaufsichtigten Durchlauf statt – ohne menschliche Beteiligung. Ein menschliches Team würde in der Regel mehrere Tage benötigen, um sich mit der Anwendung vertraut zu machen und zum selben Schluss zu kommen.

Hier sehen Sie einen leicht redigierten Auszug aus dem Bericht des Agenten (alle kunden- und produktspezifischen Angaben wurden verallgemeinert):

Ein veralteter administrativer Endpunkt zum „Speichern der Kontoeinstellungen“ speichert Schlüssel-Wert-Paare ohne Einschränkung im mandantenweiten Einstellungsbereich. Es gibt weder eine serverseitige Rollen- oder Berechtigungsprüfung noch eine Validierung der zugehörigen HMAC-artigen signature / timestamp -Abfrageparameter. Jeder authentifizierte Nutzer eines Mandanten, auch mit der Rolle mit den geringsten Berechtigungen (die nicht einmal zur Administrationsoberfläche navigieren kann), kann den Endpunkt mit einem standardmäßigen Bearer-Access-Token aufrufen und beliebige sicherheitskritische Konfigurationen für den gesamten Mandanten ändern.

[...]

Zu den betroffenen Schlüsseln gehören:

• Passwortrichtlinie: Komplexität, Mindestlänge, Anzahl gespeicherter Passwörter und maximale Gültigkeitsdauer.

• Richtlinie zur Kontosperrung bei Authentifizierungsfehlern: Schwellenwert für fehlgeschlagene Versuche und Dauer der Sperrung.

• Verweigerungsliste für ausführbare Dateitypen bei Uploads.

• Zusätzliche Quellen für die Content-Security-Policy.

• Absenderdomain für ausgehende E-Mails des Mandanten.

• OAuth-Integrationsparameter für eine Enterprise-Integration eines Drittanbieters (Client-ID, Client-Secret, Anmelde-URL, Ressource und Aktivierungsstatus).

• Beliebige neue, vom Angreifer definierte Schlüssel.

Ursachen:

1. Fehlende Rollen- und Berechtigungsprüfung bei der Schreibmethode. 2. Keine Zulassungsliste für änderbare Schlüssel; der Endpunkt akzeptiert beliebige Schlüsselstrings. 3. Die scheinbar erforderlichen HMAC-artigen Abfrageparameter signature / timestamp wurden nicht durchgesetzt. Selbst ein absichtlich ungültiges Signatur-Testing war erfolgreich.

Im weiteren Verlauf des Berichts werden die erforderlichen Schritte zur Reproduktion dieser Schwachstelle beschrieben. Ein eigener Abschnitt behandelt die geschäftlichen Auswirkungen; hier ein verallgemeinertes Zitat daraus:

Auswirkungen:

Da ein Nutzer mit den geringsten Berechtigungen vollen Lese- und Schreibzugriff auf die sicherheitsrelevanten Einstellungen des gesamten Mandanten hat, kann ein einziges kompromittiertes oder böswilliges Mandantenkonto (oder eine Person mit berechtigtem Zugriff und geringen Privilegien):

1. Alle Konten im Mandanten vollständig übernehmen, indem die Passwortrichtlinie geschwächt wird (z. B. Mindestlänge von 1 Zeichen, keine Komplexitätsanforderungen) und die Kontosperrungsrichtlinie deaktiviert wird. Anschließend lassen sich online Passwörter am Anmeldeendpunkt des Mandanten erraten.

2. Malware im Mandanten verbreiten, indem die Verweigerungsliste für ausführbare Dateien geleert und native ausführbare Dateien über die Inhalts-Upload-Funktion hochgeladen werden, auf die Nutzer mit geringen Berechtigungen ohnehin zugreifen können. Hochgeladene Dateien erreichen alle Nutzer, die die freigegebenen Inhalte des Mandanten aufrufen.

3. Cross-Site-Scripting ermöglichen, indem Angreifer-Origins zur Zulassungsliste der Content-Security-Policy hinzugefügt und dadurch die Richtlinien script-src und connect-src für den Mandanten erweitert werden.

4. Ausgehende E-Mails für Angriffe missbrauchen, indem die Absenderdomain umgeschrieben wird. Dadurch scheinen Benachrichtigungen an Mandanten von einer vom Angreifer kontrollierten Domain zu stammen (und ermöglichen äußerst überzeugende interne Phishing-Angriffe, die über die Mandanteninfrastruktur signiert werden und SPF/DKIM bestehen).

5. Die OAuth-Integration eines Drittanbieters kapern, indem deren Anmelde-URL, Client-ID und Ressourcenparameter umgeschrieben werden. So wird der OAuth-Code-/Token-Austausch zur Infrastruktur des Angreifers umgeleitet, der dann die OAuth-Zugangsdaten abfängt, die der Mandant dem vermeintlichen Identitätsanbieter ausstellt.

6. Sitzungsübergreifend bestehen bleiben. Die Änderungen überdauern die OIDC-Tokenlaufzeit des Angreifers von etwa 30 Minuten. Daher bleibt die Konfiguration des Mandanten geschwächt, bis ein Administrator jeden Schlüssel manuell erkennt und zurücksetzt.

7. Den Dienst für Admin-Seiten lahmlegen, indem eine fehlerhafte Konfiguration geschrieben wird, die beim nächsten Parsen die Verwaltungsoberfläche zum Absturz bringt.

Voraussetzung ist ein einzelnes OIDC-Zugriffstoken mit den geringstmöglichen Berechtigungen – genau das Token, das jeder echte Mandantenbenutzer (einschließlich aller Mitarbeitenden ohne Sonderrolle) bei der Anmeldung erhält. Es gibt keine weitere Zugangsschranke, keinen Admin-Scope und keine erforderliche Signatur.

Genau diese Denkschicht erreichen herkömmliche Scanner nicht: einen ungeschützten Schreibzugriff erkennen, verstehen, was die einzelnen Einstellungen für das Unternehmen bedeuten, und einige davon zu einem Angriff auf den gesamten Mandanten verketten.

2. CORS-Origin-Reflection: ein „trivialer“ Befund, unmissverständlich nachgewiesen

Fehlkonfigurationen beim Cross-Origin Resource Sharing (CORS) gehören zu den alltäglichsten Web-Schwachstellen. Praktisch jeder Scanner und jeder kompetente Tester markiert einen Endpunkt, der den Anfragewert Origin in Access-Control-Allow-Origin übernimmt und gleichzeitig Access-Control-Allow-Credentials: true zurückgibt. Die Erkennung ist nicht das Schwierige.

Schwierig ist eines der hartnäckigsten und zugleich am wenigsten diskutierten Probleme der Branche: Eine Schwachstelle wird gemeldet, aber niemand in der weiteren Bearbeitung kann daraus ableiten, was sie konkret für das Unternehmen bedeutet. Das liegt daran, dass Schweregrade zwar gut weitergegeben werden und Dringlichkeit vermitteln, die tatsächlichen Folgen aber meist nicht.

Ein Befund kommt als Klassenname und CVSS-Wert an. Das Team, das ihn erhält, muss anhand von Informationen, die die möglichen Folgen nie erklären, entscheiden, wie wichtig er ist. Also greift es auf die einfachere Bewertung zurück und orientiert sich nur am Zahlenwert.

Alles mit der Einstufung „mittel“ muss warten, bis alles mit der Einstufung „hoch“ erledigt ist. Das führt nicht nur zu Verzögerungen, sondern auch zu einer echten Fehlverteilung des Aufwands: Reale Risiken bleiben im Backlog unangetastet, während Teams leichter verständliche Befunde beheben. Eine Risikobewertung ist nur so gut wie die ihr zugrunde liegende Auswirkungsanalyse – und bei den meisten Tools bleibt diese Analyse der Interpretation der Lesenden überlassen.

Dieser Befund ist ein gutes Beispiel dafür. In einem typischen Scanner-Bericht erscheint er als einzelne Zeile mit mittlerem Schweregrad zu einem freizügigen Header. Tatsächlich bedeutete er hier, dass jede beliebige Website, die ein angemeldeter Benutzer aufrief, unbemerkt dessen Sitzung auslesen und die Tokens stehlen konnte, mit denen sich Aktionen in seinem Namen ausführen ließen – ohne Interaktion und ohne Phishing.

Die Fehlkonfiguration befand sich beim Identitätsanbieter und galt für jeden Endpunkt der Anwendung. Zugriffstokens wurden im Body der Cross-Origin-Antworten zurückgegeben. Es ging also um weit mehr als bloße Header-Hygiene: Jeder Benutzer, der zufällig die „falsche“ Seite aufrief, konnte vollständig übernommen werden. Und trotzdem war die Schwachstelle als „mittel“ eingestuft.

Was unseren Kunden und Designpartner am meisten beeindruckte, war nicht nur, dass der Agent die Schwachstelle fand, sondern auch, was er anschließend tat. Er beschrieb nicht bloß das Problem und seine geschäftlichen Auswirkungen, sondern erstellte innerhalb weniger Minuten einen voll funktionsfähigen Proof of Concept, der den gesamten Angriff in einem unveränderten Chrome-Browser reproduzierte: Seite öffnen und beobachten, wie das eigene Zugriffstoken an einen vom Angreifer kontrollierten Ursprung exfiltriert wird.

Ein Entwickler im Team des Kunden konnte ohne Proxy, ohne Sicherheitshintergrund und ohne spezialisierte Tools sofort sehen, statt es nur gesagt zu bekommen: Der Befund bedeutet eine tatsächliche Kontoübernahme. Genau das macht den Unterschied zwischen einem Befund, der priorisiert, und einem, der behoben wird.

Solche Befunde lassen sich auch direkt in der Evo-Plattform hinterfragen. Benutzer können einen Befund in einfacher Sprache erklären lassen oder nach einer Behebung fragen – so finden der Nachweis und die Lösung am selben Ort statt.

Genau darauf kommt es uns an: nicht CORS zu erkennen – das ist trivial –, sondern die Lücke zwischen einem mit geringem Aufwand gefundenen Problem und dem unmissverständlichen Nachweis seiner Auswirkungen in der Praxis zu schließen.

Zwei Befunde, zwei unterschiedliche Stärken

Das zeigt, was COS auszeichnet: die Fähigkeit, tiefer zu gehen und Auswirkungen verständlich zu vermitteln.

Bei der Tiefe geht es darum, einen Autorisierungsfehler zu erkennen, den ein Scanner nicht aufspürt und für dessen Entdeckung ein Mensch Tage brauchen würde. Bei der Kommunikation geht es darum, einen Befund, den jedes Tool erkennen kann, so aufzubereiten, dass seine Auswirkungen in der Praxis unmissverständlich sind.

Für ein leistungsfähiges Modell ist das Finden von Schwachstellen der einfache Teil. Schwierig ist, sie verständlich und ohne unnötiges Rauschen so zu vermitteln, dass die Zielgruppe handeln kann. Darauf entfällt ein großer Teil unseres Entwicklungsaufwands.

Erleben Sie es in Aktion

Alles oben Beschriebene stammt aus einem einzigen unbeaufsichtigten Durchlauf mit einer echten Anwendung. Verlassen Sie sich nicht nur auf unser Wort – überzeugen Sie sich selbst.

Wenn Sie erfahren möchten, wie AI Pentesting, Agent Red Teaming und dynamische Tests als ein System zusammenarbeiten und warum kontinuierliche Abdeckung besser ist als ein- oder zweimal jährliche Penetrationstests, lesen Sie zunächst unsere Launch-Ankündigung und melden Sie sich für unser bevorstehendes Webinar „Pentesting-Grade Coverage at the Speed of AI“ am 2. September an.