Cyberangriffe, die mithilfe von KI-Agenten durchgeführt werden sind eine beängstigende Realität, die wir langsam zu beobachten beginnen. Kann aber KI den Menschen in der Cybersicherheit übertreffen? In diesem Artikel betrachten wir zwei kürzlich mit KI durchgeführte Angriffe, stellen die neuesten Forschungsergebnisse zu diesem Thema vor und berichten, was wir beim Aufbau und Testen unseres eigenen KI-gestützten Pentesting-Setups gelernt haben.

Einleitung

Im November letzten Jahres veröffentlichte Anthropic einen Bericht über das, was sie als den ersten dokumentierten gross angelegten Cyberangriff beschrieben, der grösstenteils von autonomen KI-Agenten orchestriert und ausgeführt wurde. Der Angriff, der vermutlich von einer chinesischen staatlich geförderten Hackergruppe namens GTG-1002 orchestriert wurde, nutzte ein Setup auf Basis von Anthropics KI-Agent Claude. Das Ziel war Cyberspionage gegen etwa 30 Ziele, von Technologieunternehmen bis hin zu Regierungsbehörden, wobei die KI schätzungsweise 80-90% der taktischen Operationen eigenständig übernahm. Die Angriffe folgten dem üblichen Advanced Persistent Threat (APT) Playbook: Aufklärung, Diebstahl von Anmeldedaten und laterale Bewegung, um Daten zu sammeln und zu exfiltrieren. Die Angreifer verwendeten keine ausgefeilte, massgeschneiderte Schadsoftware oder Zero-Day-Exploits, sondern lediglich quelloffene Tools, die der breiten Öffentlichkeit zugänglich sind.

Ihr Setup war tatsächlich so einfach, dass wir ohne grossen Aufwand eine vereinfachte Replik davon erstellen konnten. Es entsprach nicht genau dem Original, funktionierte jedoch gut genug, um es gegen absichtlich verwundbare Maschinen zu testen und dabei einiges über KI-gestütztes Pentesting zu lernen.

Wie gut ist KI beim Hacking?

Bevor wir auf die Details unseres Setups und dessen Funktionsweise eingehen, müssen wir einen Blick auf die aktuelle Landschaft der KI-gestützten Cyberangriffe werfen, sowohl in der Forschung als auch in der Praxis.

Die GTG-1002-Fallstudie

Wie in der Einleitung erwähnt, legte Anthropic im November 2025 offen, was als erster gross angelegter, hauptsächlich von KI durchgeführter Cyberangriff gilt. Die GTG-1002 Hacker verwendeten ein Setup, bei dem eine Claude-Instanz (mit dem Modell Opus 4.6) als Koordinator fungierte, während mehrere andere KI-Subagenten die Rolle von Arbeitern übernahmen. Die koordinierende KI teilte den Angriff in kleinere Phasen auf, gab ihren Subagenten Anweisungen, aggregierte deren Ergebnisse und präsentierte sie den menschlichen Operatoren, die den Angriff dann ohne direkte taktische Ausführung steuerten.

Die KI in diesem Angriff war nicht vollständig autonom: Menschen mussten die Ziele auswählen, Angriffe verketten, die KI führen und die Fehler korrigieren, die den LLMs gelegentlich unterliefen. Während dieser letzte Punkt vielleicht nicht besonders wichtig erscheint — schliesslich machen auch Menschen ständig Fehler — ist er entscheidend für die künftige Rolle der KI in der Cybersicherheit. Wie Anthropic selbst berichtet, halluzinierte Claude und übertrieb Befunde häufig: Es behauptete, gültige Anmeldedaten gefunden zu haben, die in Wirklichkeit nicht funktionierten, oder stufte Befunde als hochkritisch ein, die sich dann als öffentlich zugängliche Informationen herausstellten. Dies verhinderte die Möglichkeit eines vollständig autonomen Angriffs in diesem Ausmass und zwang menschliche Operatoren, die Operation zu überwachen und die KI auf den vorgesehenen Kurs zurückzubringen. Eine Schlussfolgerung aus diesem Ereignis ist daher: Solange KI-Halluzinationen ein Problem bleiben, werden gross angelegte Cyberangriffe stets ein gewisses Mass an menschlicher Aufsicht erfordern.

CodeWalls vollautonomer Angriff

Der GTG-1002-Angriff zeigte, wozu KI mit menschlicher Unterstützung heute in der Lage ist. Aber wie gut ist sie, wenn sie auf sich allein gestellt ist? In anderen aktuellen Cybersicherheitsnachrichten berichtete das Sicherheits-Startup CodeWall, dass es vollen Lese- und Schreibzugriff auf eine Produktionsdatenbank der Unternehmensberatung McKinsey erlangt habe. Der CEO von CodeWall behauptete, der Angriff sei vollständig von einem KI-Agenten ohne menschliche Eingriffe durchgeführt worden. Der Agent schlug McKinsey offenbar sogar selbst als mögliches Ziel vor, nachdem er erfahren hatte, dass es kürzlich Aktualisierungen an McKinseys Infrastruktur gegeben hatte. CodeWalls Forscher richteten den KI-Agenten einfach auf McKinsey aus, und nur wenige Stunden später, ohne vorherige Anmeldedaten oder besonderen Zugang, gelang es ihnen, die Schwachstelle auf McKinseys Seite zu identifizieren und zu bestätigen.

Obwohl dies zeigt, dass vollautonome Exploits möglich sind, erkennt man bei näherer Betrachtung dieses Vorfalls, dass die Komplexität dieses Angriffs nicht sehr hoch war und der wichtigste Beitrag des KI-Agenten darin bestand, einen nicht authentifizierten, öffentlich zugänglichen API-Endpunkt zu identifizieren. Der Exploit selbst war eine einfache SQL-Injection, wobei der Server sogar SQL-Fehlermeldungen als Antwort auf fehlerhafte Anfragen zurückgab. Im Wesentlichen ermöglichte die KI dem Sicherheits-Startup, in kurzer Zeit eine sehr grosse Angriffsfläche abzudecken und mögliche Schwachstellen zu entdecken. Dies bestätigt ein Muster, das wir bei unseren Tests beobachtet haben: KI-Agenten sind bemerkenswert effektiv darin, die Breite einer Angriffsfläche abzudecken, haben jedoch Schwierigkeiten, wenn die Ausnutzung Tiefe erfordert, also bei mehrstufigen Angriffen, bei denen jede Aktion vom Ergebnis der vorherigen abhängt.

Was sagt die Forschung dazu?

Diese Erkenntnisse wurden auch durch ein Paper einer Gruppe von Sicherheitsforschern am AI Security Institute in Grossbritannien bestätigt. Sie testeten verschiedene Modelle mit zunehmendem Token-Budget gegen zwei simulierte Ziele ohne menschliche Aufsicht.

Zunächst bestätigten sie, was wir in den letzten Jahren alle beobachtet haben: Jede neue Modellgeneration übertraf ihre Vorgänger deutlich. Das leistungsstärkste Modell war eindeutig Anthropics Opus 4.6 (dasselbe, das von GTG-1002 bei den gross angelegten Angriffen verwendet wurde). Im besten Durchlauf löste es 22 von 32 Gesamtschritten in einer der beiden Zielanwendungen, mit einem Durchschnitt von 15,6 Schritten über fünf Durchläufe. Die hohe Varianz bei der Schrittabschlussrate ist kein positives Zeichen für die KI, da sie darauf hindeutet, dass die Ergebnisse selbst unter identischen Bedingungen erheblich variieren können. Obwohl das Paper dies nicht erwähnt, könnten KI-Halluzinationen eine mögliche Erklärung dafür sein, warum einige Durchläufe weniger erfolgreich waren. Ohne menschliche Führung konnte die KI Fehler nicht korrigieren und steckte letztlich fest.

Ein weiterer sehr interessanter Befund war, dass die Leistung des Agenten bis zu den getesteten 100 Millionen Tokens log-linear mit den Token-Kosten korrelierte. Die Studie ergab, dass eine Verzehnfachung der Tokens von 10 auf 100 Millionen einem Anstieg der gelösten Schritte von etwa 59% entspricht. Das bedeutet: Selbst wenn es keine Obergrenze für die Angriffskomplexität gäbe, die ein Modell bewältigen kann, skalieren die Kosten exponentiell. Einige Modelle hatten jedoch eine Obergrenze für die Anzahl der Schritte, die sie abschliessen konnten, unabhängig von der Anzahl der verbrauchten Tokens. GPT-4o beispielsweise kam unabhängig vom Token-Verbrauch nicht über Schritt 3 hinaus. Diese log-lineare Korrelation zwischen Angriffslänge und Token-Kosten bestätigt die Einschätzung, dass diese Modelle Schwierigkeiten haben, mehrere Schritte zu verketten, um lange Exploits durchzuführen.

Unsere Erfahrungen

Bevor wir die Agenten mit unserem Setup getestet haben, waren die Erwartungen nicht besonders hoch. Wir nutzten KI gelegentlich zur Unterstützung bei alltäglichen Aufgaben, doch häufig war sie entweder völlig nutzlos oder erforderte so viel Debugging und Aufwand unsererseits, dass es einfacher gewesen wäre, die Aufgabe ohne KI zu erledigen. Anfangs sah es so aus, als ob unser Instinkt richtig lag: Die KI steckte bei den grundlegendsten Dingen fest, erholte sich nicht von einfachen Fehlern und versuchte überkomplizierte Lösungen für relativ einfache Probleme. Zudem hatte sie erhebliche Schwierigkeiten im Umgang mit interaktiven Sitzungen und Befehlen, die keine Ausgabe lieferten. Obwohl sie die anfängliche Hauptarbeit wie das Identifizieren laufender Dienste, die Suche nach bekannten Schwachstellen und die Bereitstellung einer klaren, strukturierten Übersicht über das Ziel wirklich gut und schnell erledigte, hatte sie offensichtliche Probleme, wenn die Komplexität der Aufgaben zunahm. Durch etwas Unterstützung gelang es uns jedoch, ihre Ergebnisse deutlich zu verbessern.

Ein entscheidender Faktor für die Leistung der KI ist der verwendete System-Prompt. Indem wir ihr einen strengen Satz von Engagement-Regeln und eine Referenz für die Durchführung des Angriffs sowie den Umgang mit Fehlern und interaktiven Shell-Sitzungen zur Verfügung stellten, hörte die KI auf, Zeit (und Tokens) in endlosen Wiederherstellungsschleifen zu verschwenden, Dinge zu tun, die sie nie tun sollte, oder auf Befehle zu warten, die nie eine Ausgabe liefern würden. Das ist nicht so einfach, wie wir zunächst dachten, aber wir stellten fest, dass KI durchaus gut darin ist, ihre eigenen Prompts zu schreiben. Wir konnten ihre Leistung verbessern, indem wir sie baten, den System-Prompt nach jedem Durchlauf zu aktualisieren und so iterativ weiterzuentwickeln. Darüber hinaus fügten wir eine weitere Ebene hinzu: Wir wiesen die KI an, die gemachten Fehler und deren Lösungen in einem Dokument festzuhalten, das sie vor jeder Interaktion lesen musste. Dies verhinderte, dass sie immer wieder dieselben Fehler machte und stecken blieb.

Zu diesem Zeitpunkt war das Lösen leichter bis mittelschwerer Capture-the-Flag (CTF) Challenges recht unkompliziert. Wir wollten jedoch das KI-Koordinator/Arbeiter-Setup aus dem GTG-1002-Angriff ausprobieren. Dabei stellten wir fest, dass die Verwendung von Claude Code für diese Art von Experimenten weitaus effektiver war als die Desktop-Version. Die Code-Version kann längere Sitzungen ausführen und ist besser in die Werkzeuge der angreifenden Maschine integriert. Dieses Setup erleichterte die Verwaltung der Angriffe auf unserer Seite und beschleunigte die Durchführung, da mehrere KIs parallel verschiedene Dinge ausprobieren konnten. Es ermöglichte uns jedoch nicht, komplexere Challenges zu lösen. Am Ende des Tages galt: War eine Challenge für die KI allein zu schwer, war sie auch für mehrere KI-Instanzen zu schwer.

Beim Aufbau dieser Leader/Worker-Infrastruktur entdeckten wir auch einen kleinen Trick zur Verbesserung der Token-Effizienz: Das Opus-4.6-Modell für die koordinierende KI zu verwenden, aber Sonnet 4.6 für die Arbeiter. Aufgrund des nichtdeterministischen Charakters der KI liess sich nicht messen, um wie viel effizienter diese Konfiguration war, aber sie war schneller als der Einsatz eines einzelnen Agenten und kostengünstiger als der Einsatz mehrerer Opus-Instanzen. Aufgrund des Koordinationsaufwands zwischen den Agenten ist diese Konfiguration jedoch immer noch teurer als die Verwendung nur einer KI-Instanz. Da Sonnet über gute Cybersicherheitsfunktionen mit lockeren Token-Ratenbeschränkungen verfügt, ermöglichte uns diese Konfiguration schnellere Angriffe, die weiterhin vom überlegenen Opus-Modell orchestriert wurden, ohne an die strengeren Ratenbeschränkungen zu stossen, die Anthropic dafür vorschreibt. Gelegentlich musste Opus einspringen und die Exploits selbst versuchen, wenn die Aufgaben für Sonnet zu komplex wurden, aber grösstenteils erledigte Sonnet die Arbeit korrekt.

Es war definitiv lehrreich und interessant, all dies zu testen. Es sei jedoch darauf hingewiesen, dass dieser Trick zwar in unserem lokalen Setup bei CTF-Challenges und absichtlich verwundbaren Maschinen funktionierte, dies aber nicht bedeutet, dass es in einer realen Umgebung mit wesentlich komplizierteren Systemen und Nutzern in Echtzeit genauso funktionieren würde. Darüber hinaus fehlte bei unseren Experimenten jegliche Verteidigungsstrategie. Die Systeme wiesen absichtliche Schwachstellen auf, und es wurde keinerlei Einbruchserkennung oder -prävention durchgeführt. KI muss einen Weg finden, dieses Hindernis zu überwinden, wenn sie im offensiven Bereich der Cybersicherheit breiter eingesetzt werden soll.

Fazit — Wird KI die Cybersicherheit übernehmen?

Dies ist die ultimative Frage, die wir in den vergangenen Wochen zu beantworten versuchten. Nach allem, was wir gesehen und gelesen haben, scheint es so, dass die aktuellen Probleme der KI nicht so schnell verschwinden werden, selbst wenn die Modelle besser und die Tokens günstiger werden. Sowohl der GTG-1002-Fall als auch das Forschungspaper deuten darauf hin, dass KI beim Hacking nicht besser ist als ein menschlicher Angreifer, aber schneller sein und grosse Angriffsflächen effizienter abdecken kann. Wir glauben jedoch nicht, dass wir kurz davor stehen, dass sie Menschen in diesem Kontext ersetzt.

In unseren Experimenten war menschliche Führung entscheidend für das Lösen anspruchsvollerer Challenges. Darüber hinaus verhinderten Halluzinationen nicht nur gelegentlich, dass die KI in der Angriffskette vorankam, sondern gefährdeten manchmal sogar die Operation, indem sie versuchten, den Angriff auf andere, nicht autorisierte Ziele auszuweiten. Dies war ein grosses Warnsignal, das uns daran erinnerte, dass das Modell, mit dem wir sprachen, trotz seines Anscheins als intelligentes Wesen nur ein statistisches Modell war, das kein Konzept davon hatte, was passierte oder was es tat. Es erinnerte uns auch daran, dass KI letztlich nur ein (sehr mächtiges) Werkzeug ist, das von jemandem für etwas eingesetzt werden muss. Je erfahrener und kompetenter der Bediener, desto besser die Ergebnisse. Am Ende des Tages wird die Rolle, die KI in der Cybersicherheit spielen kann, von den Menschen definiert, die sie einsetzen, und von ihrer Fähigkeit, sie zu nutzen.

Wir werden zweifellos mehr KI-Einsatz bei Cyberangriffen sehen, aber wir glauben nicht, dass sich die Natur der Bedrohungen wesentlich verändern wird. Hauptsächlich wird KI die Geschwindigkeit und das Ausmass von Angriffen beeinflussen. KI-Agenten werden keine Schwachstellen finden, die ein erfahrener Mensch nicht auch finden könnte, sie werden sie lediglich schneller und über eine grössere Fläche hinweg entdecken. Wenn Ihre Systeme bereits abgesichert sind, wird KI daran nichts ändern. Wenn Sie jedoch Schwachstellen haben, mit denen Sie bisher unbemerkt durchgekommen sind, weil niemand die Zeit hatte, sie zu suchen, schliesst sich dieses Fenster.

Penetration Testing oder allgemein Security Testing ist die gezielte Suche nach Schwachstellen, um das Sicherheitsniveau einer IT-Umgebung einzuschätzen und entsprechend informierte Entscheidungen treffen zu können. Was so einfach und einleuchtend klingt, ist in der Praxis oft viel komplexer und häufig bei weitem nicht so klar definiert, wie es den Anschein machen kann.

Penetration Tests sind eine etablierte und bekannte Praxis im Gebiet der Informationssicherheit. In vielen Sicherheitsprogrammen sind sie ein fester Bestandteil und verschiedene Branchenstandards und Aufsichtsbehörden schreiben die regelmässige Durchführung von Penetration Tests vor. Dies ist erfreulich, weil damit ein sehr effektives Mittel zur Steigerung des Sicherheitsniveaus allgemeine Verbreitung gefunden hat, gleichzeitig besteht die Gefahr, durch einen Gewöhnungseffekt Penetration Tests nicht mit der nötigen Sorgfalt zu betrachten oder nur als reine Compliance-Aufgabe zu sehen.

Dieser Beitrag geht auf ein paar einfache, aber essenzielle Punkte ein, die massgeblich zum Erfolg und zum Nutzen von Security Tests beitragen. Im Bereich der offensiven Informationssicherheit sind viele Begriffe wie Penetration Testing, Ethical Hacking, Red Teaming usw. anzutreffen. Für diesen Beitrag wird der Begriff Security Testing allgemein verwendet und bezieht sich auf das ganze Spektrum des offensiven Sicherheitstestens.

Wozu Security Testing?

Einfach gesagt: Um das tatsächliche Sicherheitsniveau eines IT-Systems, einer IT-Umgebung oder gar einer ganzen Organisation zu bestimmen. Es geht darum, mit möglichst grosser Realitätsnähe herauszufinden, was bei echten Angriffen geschehen kann, wie weit ein Angreifer kommen könnte und was die daraus erwachsenden Schäden sein können. Es werden also die effektiv vorhandenen Sicherheitsmassnahmen einer Realitätsprüfung unterzogen, wodurch Schwachstellen und potenzielle Lücken ermittelt werden, die von echten Angreifern ausgenutzt werden könnten.

Mit den so gewonnenen Erkenntnissen können Risiken realistisch eingeschätzt werden und Entscheidungen über zu treffende Massnahmen werden unterstützt, womit eine Organisation ihr Sicherheitsniveau optimieren kann. Regelmässig durchgeführtes Security Testing kann einen wesentlichen Beitrag zur Reduktion der Gefahr von Sicherheitsvorfällen und Datenlecks leisten.

Man kann die Frage stellen, wozu es heutzutage angesichts der riesigen Zahl an Sicherheitsprodukten und Services überhaupt noch Security Testing braucht. Die Antwort ist einfach: Die Effektivität von Sicherheitsmassnahmen kann nicht ausreichend beurteilt werden, ohne sie getestet zu haben. Ausserdem ist die IT in besonderem Mass ständigem Wandel unterworfen, dementsprechend müssen Sicherheitsvorkehrungen laufend angepasst und geprüft werden. Die Redewendung “Vertrauen ist gut, Kontrolle ist besser!” gilt ganz besonders für die Informationssicherheit.

Hypothese und Experiment

Die klassische Vorgehensweise der wissenschaftlichen Methode mit den Definitionen von Hypothese und Experiment lassen sich sehr gut auf das Security Testing anwenden. Dies ist wertvoll, weil damit Voraussetzungen und Erfolgsfaktoren besser hervortreten.

Eine Hypothese ist eine unbewiesene Aussage oder Annahme von Tatsachen oder Gesetzmässigkeiten. Eine Hypothese ist meistens aus einer Theorie abgeleitet, im betrachteten Kontext beispielsweise: Sichere Entwicklungsprozesse bedeuten sichere Software, Best Practices funktionieren, Sicherheitsprodukte schützen ausreichend, Compliance bedeutet Sicherheit und so weiter. Entsprechende Hypothesen können sein: Es sind ausreichend Sicherheitsmassnahmen umgesetzt, deshalb ist die Umgebung sicher, das eingekaufte Produkt ist sicher, die Organisation ist sicher, weil sie compliant ist, das System ist so abgeschottet, dass es für Angreifer unerreichbar ist.

Ein Experiment ist eine methodisch angelegte Untersuchung zur empirischen Gewinnung von Informationen. Das ist genau der Anspruch eines Penetration Tests. Der Wert eines Experiments bemisst sich durch die Korrektheit, Verwendbarkeit und Nützlichkeit der gewonnenen Informationen. Mit diesen Informationen werden Fragen beantwortet, das heisst, sie bestätigen oder widerlegen die aufgestellte Hypothese. Damit wird unmittelbar klar, dass alles mit der geeigneten Fragestellung beginnt.

Geeignete Fragen im Zusammenhang mit Security Tests können sein:

• Kann sich ein Angreifer Zugang zu sensitiven Daten oder Systemen verschaffen?
• Existieren bekannte Schwachstellen in den eingesetzten Technologien?
• Wurde das Notwendige getan, um ein angemessenes Sicherheitsniveau zu etablieren?
• Sind die geltenden Sicherheitsvorgaben erfüllt?
• Wurde das Konzept richtig umgesetzt und funktioniert es in der Praxis?
• Kann ein vorhandenes Bedenken widerlegt oder bestätigt werden?
• Funktionieren die sicherheitsrelevanten Prozesse?
• Wie schwierig oder wie einfach ist es für einen Angreifer, erfolgreich zu sein?
• Sind die Detektions- und Reaktionsmechanismen ausreichend leistungsfähig?

Beim Planen von Penetration Tests wird dies gerne zu wenig berücksichtigt. Oft ist nicht ausreichend geklärt, welche Fragen ein Security Test beantworten soll und wozu die Antworten dienen sollen. Der Vorbereitungs- und Planungsphase hat deshalb beim Security Testing einen besonders hohen Stellenwert und darf nicht vernachlässigt werden. Es kann für einen Auftraggeber herausfordernd sein zu wissen, welche Möglichkeiten bestehen, welche Einschränkungen vorhanden sind und welche Punkte beachtet werden müssen. Wird dies zu wenig beachtet oder zu ungenau abgemacht, besteht die Gefahr, dass Geld für einen zu wenig nützlichen Test ausgegeben wird oder die Ressourcen nicht zielführend eingesetzt werden können oder der Test wiederholt werden muss. Ein erfahrener Dienstleister unterstützt und berät in dieser Phase neutral und sachlich und sorgt dafür, dass vor der Beauftragung gemeinsam geklärt ist, welche Fragen der Test beantworten soll und welche Mittel dafür angewendet werden.

Schliesslich ist ein Penetration Test nur ein Mittel zum Zweck, nämlich Erkenntnisse zu gewinnen, mit denen Entscheidungen getroffen werden können. Üblicherweise werden diese Erkenntnisse vom Dienstleister, soweit es für ihn möglich ist, interpretiert, d.h. mit Schweregraden bewertet und es werden geeignete Massnahmen empfohlen, um die mit den Feststellungen verbundenen Risiken zu begrenzen. Anschliessend ist der Auftraggeber gefordert und muss entscheiden, was die gewonnen Erkenntnisse für ihn bedeuten und wie er damit umgeht.

Die Wichtigkeit, sich über die zu beantwortenden Fragen klar zu sein, sei nochmals betont. In diesem Zusammenhang werden nachfolgend ein paar der gängigsten Ansätze im Security Testing einander gegenübergestellt, um aufzuzeigen, welche Fragestellungen damit beantwortet werden können.

Gegenüberstellung dreier häufiger Security Testing Ansätze

Untenstehend erläutern wir nun näher verschiedene Security Testing Ansätze, darunter Penetration Testing und Red Team Testing, wie auch die Hauptunterschiede zwischen Penetration Testing und einem Bug Bounty.

Penetration Testing und Red Team Testing

Penetration Tests werden üblicherweise durchgeführt, um die Sicherheit eines Prüfobjektes mit definiertem Scope aus Sicht eines realen Angreifers zu untersuchen. Es wird geprüft, ob die im Scope befindlichen Netzwerke, Plattformen, Anwendungen, Systeme, usw. für einen Angreifer ausnutzbare Schwachstellen aufweisen. Dabei wird darauf geachtet, im Rahmen des vereinbarten Aufwands eine möglichst vollständige Untersuchung des Prüfgegenstands durchzuführen. Beispielsweise wird für Webapplikationen meist der OWASP Testing Guide verwendet, der alle für die Sicherheit von Webapplikationen relevanten Themen beinhaltet. Damit wird eine umfassende Testabdeckung angestrebt, um Teilaussagen mit eingeschränktem Nutzen zu vermeiden. Penetration Tests dienen der breiten Untersuchung eines gegebenen Scope und sind normalerweise nicht darauf ausgerichtet, unbemerkt vonstattenzugehen oder die Detektionsmöglichkeiten eines SOC zu testen.

Im Rahmen von Red Team Tests wird versucht, ausgehend von einem vereinbarten Startpunkt ein definiertes Ziel zu erreichen, beispielsweise Zugriff auf sensitive Daten oder Systeme zu erlangen. Im Unterschied zu einem Penetration Test wird hier aber der Fokus darauf gelegt, einen Angreifer zu simulieren, der sich sämtlicher sachdienlicher Mittel und Methoden bedient, um das definierte Ziel zu erreichen und dabei möglichst unentdeckt zu bleiben. Es geht also nicht darum, möglichst alle Schwachstellen eines Scope zu identifizieren, sondern Schwachstellen zu finden, die dem Vorwärtskommen hinsichtlich Zielerreichung dienen. Dementsprechend wird bei Red Team Tests das SOC oder das Blue Team in der Regel nicht vorinformiert, womit auch Aussagen über das Detektions- und Reaktionsvermögen des Auftraggebers gegenüber fortgeschrittenen Angriffen getroffen werden können. Red Team Tests sind dann sinnvoll, wenn die getestete Organisation bereits über eine gewisse Maturität in der Informationssicherheit verfügt.

Die in Penetration Tests und Red Team Tests verwendeten Methoden und Werkzeuge sind in vielen Fällen ähnlich oder sogar gleich. Bei Red Team Tests steht die Widerstandsfähigkeit einer Organisation gegenüber realen, fortgeschrittenen Angriffen im Fokus während Penetration Tests sich in der Regel auf einzelne Systeme oder Bereiche beziehen.

Penetration Testing und Bug Bounty

In den letzten Jahren haben Bug Bounty Programme zunehmend an Popularität gewonnen. Richtig aufgesetzt, können dadurch mit definiertem Maximalaufwand und in vergleichsweise kurzer Zeit wichtige Erkenntnisse gewonnen werden. Die wichtigsten Unterschiede zwischen Penetration Tests und Bug Bounties sind einander in der folgenden Tabelle gegenübergestellt.

Bug Bounty Programme und Penetration Tests verfolgen beide das Ziel, Schwachstellen zu identifizieren, unterscheiden sich aber in ihren Beauftragungsmodellen, Anreizen und Schwerpunktbereichen. Bug Bounty Programme nutzen das Fachwissen einer Vielzahl von Testern, bieten finanzielle Belohnungen für die Meldung von Schwachstellen und können schnelle, aber vielleicht nicht immer umfassende Ergebnisse liefern. Penetration Tests folgen einem ganzheitlichen Ansatz, bieten einfachere Interaktionsmöglichkeit mit den Testern und werden durch wenige, dedizierte Experten durchgeführt.

Fazit

Ein Security Test ist ein Experiment, das Informationen liefert und damit Fragen beantwortet. Es ist deshalb sehr wichtig, dass für den Auftraggeber und für den Auftragnehmer vor Beginn eines Security Tests Klarheit darüber gewonnen wird, welche Fragen durch den Test beantwortet werden sollen und wozu die Ergebnisse verwendet werden sollen. Dies trifft als allgemeine Feststellung auf die verschiedenen Arten von Security Tests gleichermassen zu. Ein erfahrener Dienstleister unterstützt und berät in dieser Phase neutral und sachbezogen und sorgt dafür, dass geklärt ist, welche Fragen der Test beantworten soll und welche Mittel dafür angewendet werden.

• Team Mirai and Democracy (schneier.com)
• The Agent Trust gap: What Our Research Reveals About Agentic AI Security (blogs.cisco.com)
• Microsoft’s ‘unhackable’ Xbox One has been hacked by ‘Bliss’ (tomshardware.com)
• Your tax forms sell for $20 on the dark web (malwarebytes.com)
• Meta will move away from human content moderators in favor of more AI (engadget.com)
• OpenAI Cofounder Deletes Controversial Analysis of Which Jobs Are Getting Steam Engined by AI (futurism.com)
• Tech hobbyist makes shoulder-mounted guided missile prototype with $96 in parts and a 3D printer (tomshardware.com)
• The Defense Department reportedly plans to train AI models on classified military data (engadget.com)
• ‘I wish I could push ChatGPT off a cliff’: professors scramble to save critical thinking in an age of AI (theguardian.com)
• An iPhone-hacking toolkit used by Russian spies likely came from U.S military contractor (techcrunch.com)
• Hardening Firefox with Anthropic’s Red Team (blog.mozilla.org)
• AI as tradecraft: How threat actors operationalize AI (microsoft.com)
• Hands-On: Is The Smartlet One Watch Bracelet The Answer To Double-Wristing? (ablogtowatch.com)
• How AI can read our scrambled inner thoughts (bbc.com)
• People are selling your home address online. This privacy tool will help (bbc.com)
• Moltbook was peak AI theater (technologyreview.com)
• Large-Scale Online Deanonymization with LLMs (simonlermen.substack.com)
• Demographic differences in how teens use and view AI (pewresearch.org)
• Vibe Password Generation: Predictable by Design (irregular.com)
• Threat modeling AI applications (microsoft.com)
• Say please? The best way to talk to an AI (bbc.com)