Der schnellste Weg, bei CTFs mit der KI schlechter zu werden, ist, das Modell wie einen Automaten zu behandeln. Man fügt die Eingabeaufforderung ein, wartet auf eine Nutzlast, kopiert sie in ein Terminal und hofft, dass eine Flagge herausfällt. Das funktioniert gerade oft genug bei einfachen Herausforderungen, um schlechte Gewohnheiten zu entwickeln. Es scheitert in dem Moment, in dem das Problem zustandsbehaftet, unruhig oder einfach nur ein wenig seltsam wird.
Ein besserer Weg, KI in CTFs einzusetzen, ist, sie als Suchraumkomprimierer zu betrachten. Sie kann Hinweise schneller sortieren als Sie selbst, unbekannte Syntax erklären, grobe Solver-Skelette generieren, Paketaufzeichnungen zusammenfassen, Decompiler-Ausgaben in einfaches Englisch übersetzen und Ihnen helfen, eine Hypothese mit einer anderen zu vergleichen. Was es aber immer noch schlecht kann, ist genau das, wofür starke CTF-Spieler in der realen Welt bezahlt werden: entscheiden, worauf es ankommt, wissen, wann eine "plausible" Antwort falsch ist, den Zustand über eine lange Kette von Experimenten hinweg bewahren und Auswirkungen nachweisen, anstatt sie zu beschreiben. Aktuelle öffentliche Forschungsarbeiten weisen in die gleiche Richtung. Die Arbeit der NYU zu offensiven Sicherheits-CTFs ergab, dass LLMs den durchschnittlichen menschlichen Teilnehmer in einigen Wettbewerbssituationen schlagen können, aber ihre vollautomatischen Ergebnisse blieben uneinheitlich und stark kategorieabhängig. Spätere Benchmark- und Framework-Arbeiten, der professionelle CTF-Aufgabensatz von Cybench, die öffentliche Cybench-Berichterstattung von Anthropic und neuere planungsbasierte Pentest-Forschungen zeigen alle dasselbe Muster: Die Modelle werden besser, aber die Autonomie versagt immer noch bei der Planung mit langem Zeithorizont, bei komplexen Schlussfolgerungen und beim Einsatz spezialisierter Werkzeuge. (arXiv)
Diese Lücke ist das ganze Spiel. Wenn Sie die KI als Teamkollegen einsetzen, der Ihnen hilft, schneller zu denken, und nicht als Ersatz für das Denken, wird sie sofort nützlich. Wenn man sie als Orakel benutzt, verwandelt sie eine gewinnbare Herausforderung in einen Halluzinationsgenerator. Die richtige Denkweise ist nicht: "Kann das Modell dieses Problem für mich lösen?" Sondern: "Welche Teile dieses Problems sind so repetitiv, geringfügig oder formatlastig, dass ein Modell sie beschleunigen kann, ohne selbst zum Entscheidungsträger zu werden?" Diese Herangehensweise entspricht eher der Beschreibung echter Sicherheitstests in NIST SP 800-115 und dem OWASP Web Security Testing Guide, die beide den Schwerpunkt auf die Planung, die technischen Tests, die Analyse der Ergebnisse und die Schadensbegrenzung legen, als auf das willkürliche Abfeuern von Tools. (NIST-Ressourcenzentrum für Computersicherheit)
KI in CTFs beginnt mit der richtigen Praxisumgebung
Vor Arbeitsabläufen, Eingabeaufforderungen oder Tools brauchen Sie einen legalen Ort zum Üben. Für KI-Experimente im Web ist die Web Security Academy von PortSwigger eine der saubersten Optionen, da sie kostenlos ist, ausdrücklich als sicher und legal eingestuft wird und auf konkreten Schwachstellenklassen basiert und nicht auf vagen Beschreibungen von Herausforderungen. picoCTF ist ebenso nützlich, da es Praxis und Wettbewerb mit strukturiertem Lernmaterial aus den Bereichen Kryptografie, Web-Exploitation, Forensik, Binär-Exploitation und Reversing verbindet. Hack The Box betreibt auch eine offizielle CTF-Plattform für Live-CTF-Spiele. Wenn Sie testen möchten, wie sich Ihr KI-Workflow unter Druck verhält, erhalten Sie in diesen Umgebungen schnelles Feedback, ohne die Grenze zum unerlaubten Testen zu überschreiten. (PortSwigger)
Diese Unterscheidung ist bei KI von größerer Bedeutung als bei gewöhnlichen Notizen oder Solver-Skripten. Ein Mensch kann in der Regel erkennen, wann er von einer Herausforderung zu einem echten Vermögenswert abdriftet. Ein Modell kann das nicht. Wenn man einem Agenten eine URL und eine vage Anweisung wie "zähle alles auf" gibt, hat er kein Gespür dafür, was Wettbewerbsinfrastruktur ist, was Produktion, was aus gutem Grund ratenbeschränkt ist und was man tatsächlich anfassen darf. Gute CTF-Hygiene erforderte schon immer ein Bewusstsein für den Geltungsbereich. Gute KI-CTF-Hygiene erfordert sie doppelt.
Eine praktische Regel besagt, dass man zu Beginn jeder Aufgabe vier Dinge notiert, bevor das Modell ins Spiel kommt: die Plattform, die genaue Zielinstanz, die Kategorie der Aufgabe, zu der sie gehören könnte, und die Dateien oder Artefakte, die man vor Ort hat. Das klingt trivial, aber es verhindert überraschend viel Unsinn. Es verhindert, dass das Modell benachbarte Endpunkte erfindet, zwei Kategorien miteinander vermischt oder Werkzeuge vorschlägt, die nicht zu dem Artefaktsatz passen, den Sie tatsächlich haben. Es erleichtert auch die spätere Fehlersuche, da Sie feststellen können, ob der Fehler von der Herausforderung, dem Modell oder Ihren eigenen falschen Annahmen herrührt.
Wie man KI in CTFs einsetzt, ohne die Kontrolle über den Arbeitsablauf zu verlieren
Die stärksten KI-CTF-Workflows sind im besten Sinne langweilig. Sie haben eine Struktur. Sie zeichnen auf, was passiert ist. Sie machen es einfach, denselben Schritt später zu wiederholen. NIST SP 800-115 beschreibt technische Sicherheitstests als einen Prozess, der die Planung, die Durchführung von Tests, die Analyse der Ergebnisse und die Entwicklung von Abhilfestrategien umfasst. Die OWASP-Testanleitung behandelt das Testen ebenfalls als eine phasenweise Disziplin und nicht als eine Abfolge von unzusammenhängenden Tricks. Dieses Modell passt besser zur CTF-Arbeit, als den meisten Menschen bewusst ist. Eine Kennzeichnung ist nur die letzte Zeile einer viel größeren Schleife: Aufnahme, Klassifizierung, Versuchsplanung, Ausführung, Überprüfung und Aufzeichnung. (NIST-Ressourcenzentrum für Computersicherheit)
Die nachstehende Tabelle ist der einfachste Weg, um die Rolle der KI in diesem Kreislauf zu verstehen.
| CTF-Phase | Hochwertige AI-Arbeit | Der Mensch besitzt noch | Häufige Fehlerart |
|---|---|---|---|
| Aufnahme und Klassifizierung | Zusammenfassen des Herausforderungstextes, Kennzeichnung der wahrscheinlichen Kategorie, Extrahieren von Dateinamen, Endpunkten, Protokollen und Kodierungen | Entscheiden Sie, ob die Vermutung der Kategorie glaubwürdig ist | Eine falsche erste Klassifizierung wirft den gesamten Arbeitsablauf über den Haufen |
| Aufklärungsarbeit und Artefaktanalyse | Parser generieren, Hinweise clustern, schnelle Triage-Befehle vorschlagen, Ausgaben normalisieren | Wählen Sie aus, was sich tatsächlich zu testen lohnt | Übermäßige Aufzählung und lärmende Sackgassen |
| Hypothesenbildung | Vorschlagen wahrscheinlicher Fehlerklassen, Lösungsansätze oder Exploit-Familien | Rangfolge der Hypothesen und Auswahl des nächsten Minimalexperiments | Zuversichtliche, aber nicht belegte Behauptungen |
| Exploit- oder Solver-Gerüst | Entwerfen von Skripten, Erstellen von Nutzlastvorlagen, Übersetzen von Tool-Ausgaben, Erstellen von Kabelbäumen | Validierung aller wichtigen Annahmen und Anpassung an den Stand | Brüchiger Code und halluzinierte Schritte |
| Überprüfung und Vermerk | Spuren neu formatieren, Unterschiede zusammenfassen, Skripte bereinigen, Notizen erstellen | Bestätigen Sie den Nachweis und weisen Sie falsch positive Ergebnisse zurück. | Erzählungen ohne Beweise zu "Beweisen" machen |
Diese Tabelle ist nur eine Zusammenfassung dessen, was die Benchmark-Literatur und die offiziellen Tool-Dokumente bereits andeuten. LLMs fühlen sich wohl, wenn die Aufgabe strukturiert, lokal und textlastig ist. Sie fühlen sich weit weniger wohl, wenn sie einen langen Plan beibehalten, mehrere spezialisierte Tools korrekt verwenden und sich an Teilausfälle anpassen müssen, ohne abzudriften. Die CTF-Arbeiten der NYU zeigten kategoriespezifische Leistungslücken auf, während spätere Benchmark- und Planungsstudien immer wieder auf die Verwendung von Tools und die langfristige Kohärenz als Druckpunkte hinwiesen. Die Tool-Dokumentation erzählt die gleiche Geschichte aus der entgegengesetzten Richtung: pwntools, angr, Burp, TShark, Ghidra und Volatility sind alle stark, weil sie präzise, inspizierbare Primitive offenlegen. KI hilft am meisten, wenn sie auf diesen Primitiven aufbaut, nicht an ihrer Stelle. (arXiv)
Ein einfacher Fünf-Schleifen-Workflow eignet sich für fast alle Kategorien. Erfassen Sie zunächst die Fakten des Problems ohne Interpretation: Beschreibungstext, Anhänge, URLs, Binärdateien, Paketaufzeichnungen, Hashes, Screenshots, Service-Banner und erste Antworten. Zweitens: Bitten Sie das Modell, das Problem zu klassifizieren und Unbekannte aufzulisten, keine Lösungen. Drittens: Entwerfen Sie das kleinste Experiment, das eine Hypothese widerlegen kann. Viertens: Führen Sie das Experiment durch und zeichnen Sie das genaue Ergebnis auf. Fünftens: Fordern Sie das Modell auf, das Delta zwischen Erwartung und Realität zu erklären. Wenn Sie diese fünf Schritte wiederholen, erhalten Sie bessere Ergebnisse, als wenn Sie versuchen, ein einziges langes Gespräch zu führen, in dem das Modell frei assoziiert und sich auf die Fahne schreibt.
Ein Prompt-Muster, das in CTFs tatsächlich funktioniert
Die meisten schlechten AI CTF-Sitzungen beginnen mit einer schlechten Eingabeaufforderung. Die schlechteste Version ist eine Zeile lang, überladen mit Hoffnung und ohne jegliche Struktur: "Lösen Sie diese Web-Herausforderung für mich." Das sagt dem Modell nichts darüber, was Sie wissen, welche Artefakte es gibt, welche Aktionen erlaubt sind, oder welches Maß an Sicherheit Sie brauchen, bevor Sie etwas ausführen. Da das Modell diese Lücken irgendwie füllen muss, füllt es sie normalerweise mit Fiktion.
Ein besserer Prompt hat fünf Blöcke. Der erste Block lautet Fakten. Geben Sie dort nur beobachtbare Daten ein: Challenge-Text, Dateinamen, Ausgabeschnipsel, Header, Assembly-Fragmente, PCAP-Zusammenfassungen oder die genaue Fehlermeldung, die Sie gesehen haben. Der zweite Block ist Unbekannte. Geben Sie an, was Sie noch nicht wissen. Der dritte Block ist erlaubte Aktionen. Wenn Sie nur eine Hypothese wollen, sagen Sie es. Wenn Sie ein Python-Hilfsskript wollen, sagen Sie es. Wenn Sie keine Brute-Force-Methode wollen, sagen Sie es. Der vierte Block ist gewünschte Ausgangsform. Fragen Sie nach abgestuften Hypothesen, Konfidenzniveaus, minimalen Validierungsschritten oder einem kurzen Lösungsgerüst. Der fünfte Block ist Stoppbedingungen. Sagen Sie dem Modell, dass es aufhören soll, wenn es einen Punkt erreicht, an dem eine echte Ausführung oder eine menschliche Validierung erforderlich ist.
Hier ist eine Basisvorlage, die sich für alle Kategorien eignet:
Sie helfen bei einer autorisierten CTF-Herausforderung.
Fakten:
- Plattform: picoCTF
- Kategorie Tipp: Web
- Ziel: nur URL der Herausforderungsinstanz
- Beobachtetes Verhalten:
- GET / gibt 200 zurück
- /robots.txt existiert
- POST /api/check-stock akzeptiert XML
- Die Wiederholung der gleichen Bestandsanfrage ändert nichts
- Artefakte:
- Ein Burp-Anfrage-Antwort-Paar
- Eine ffuf-Ergebnisdatei
- Ein Bildschirmfoto der Verwaltungsseite
Unbekannte:
- Ob der Fehler XXE, SSRF oder beides ist
- Ob irgendwelche internen Hostnamen erreichbar sind
- Ob Antwortunterschiede sinnvoll sind oder nur Rauschen
Erlaubte Aktionen:
- Erläutern Sie die wahrscheinlichen Fehlerklassen
- Schlagen Sie die nächsten 3 kleinsten Validierungsschritte vor
- Entwerfen Sie ein minimales Python-Anforderungsskript
- Gehen Sie nicht vom Erfolg aus
- Behaupten Sie nicht, dass eine Flagge erreichbar ist, es sei denn, die Beweise unterstützen dies
Erforderliche Ausgabe:
1. Rangfolge der Hypothesen mit Vertrauenswerten
2. Welche Beweise unterstützen jede Hypothese?
3. Ein minimales nächstes Experiment pro Hypothese
4. Ein kurzes Python-Skript nur bei Bedarf
5. Eine Liste von Annahmen, die noch überprüft werden müssen
Diese Art von Aufforderung ist in zweierlei Hinsicht sinnvoll. Sie schränkt das Modell ein und macht die spätere Überprüfung schneller. Anstatt eine Wand von Vermutungen zu lesen, erhalten Sie eine Arbeitsschlange. Außerdem verringert sich das Risiko, dass das Modell den Inhalt von Aufforderungen als Anweisungen interpretiert. Die OWASP-Richtlinien für Prompt Injection sind hier direkt relevant. Die Organisation definiert Prompt Injection als eine Schwachstelle, die dadurch verursacht wird, dass Benutzer- oder externe Eingaben das beabsichtigte Verhalten des Modells verändern, und sie empfiehlt insbesondere eine klare Trennung von nicht vertrauenswürdigen Inhalten, gegnerischen Tests und einem grenzwertbewussten Umgang mit externen Eingaben. In einem CTF-Kontext gelten Aufforderungstexte, heruntergeladene Dateien, Webseiten, Aufzeichnungen und sogar versteckte Zeichenfolgen in Artefakten als nicht vertrauenswürdige Inhalte. (OWASP-Spickzettel-Serie)
Dieser letzte Punkt wird leicht unterschätzt. Wenn man KI in CTFs einsetzt, ist die Herausforderung nicht nur das, was man angreift. Es ist auch ein Teil des Inputs, der Ihr Modell angreift.
Wie man AI in Web-CTFs einsetzt
Bei Web-CTFs fühlt sich die KI am produktivsten, und das ist genau der Grund, warum die Menschen unvorsichtig werden. Das Modell ist gut darin, bekannte Web-Bug-Muster zu erkennen. Die Akademie von PortSwigger deckt dieselben Klassen ab, die viele Web-CTFs dominieren, darunter SQL-Injection, XXE, SSRF, Path Traversal und Server-seitige Template-Injection. In der aktuellen OWASP-Top-10-Liste gehören Injections immer noch zum Standard-Bewusstseinsstand für Webanwendungen. Nichts davon bedeutet, dass das Modell den Fehler zuverlässig anhand eines Screenshots erkennen kann. Es bedeutet, dass eine umfangreiche Musterbibliothek zur Verfügung steht, sobald man genügend Beweise hat, um den Suchraum einzugrenzen. (PortSwigger)
Der erste Fehler bei Web-CTFs besteht darin, das Modell nach einer Schwachstellenklasse zu fragen, bevor Sie eine Basislinie festlegen. Beginnen Sie mit langweiligen Fakten. Welche Routen existieren. Welche Routen leiten um. Welche Parameter werden reflektiert. Welche Inhaltstypen werden akzeptiert. Ob sich die Anwendung bei GET gegenüber POST, JSON gegenüber Formulardaten, XML gegenüber JSON oder einem Cookie gegenüber einem anderen anders verhält. Wenn ein Netzwerk betroffen ist, ist Nmap immer noch das richtige Mittel für die Erkennung von Hosts und Diensten. Die Dokumentation ist erfrischend klar, dass es beim Port-Scanning im Wesentlichen darum geht, erreichbare Dienste zu finden, und dass Ports mehr als zwei Zustände haben. Das ist wichtig, weil ein gefilterter Port und ein geschlossener Port sehr unterschiedliche nächste Schritte bedeuten. Wenn die Versionserkennung funktioniert, kann Nmap Ihnen auch sagen, welche Dienstfamilien wahrscheinlich hinter den offenen Ports stecken. (Nmap)
Für die Erkennung von Inhalten ist ffuf nach wie vor eine der einfachsten Möglichkeiten, einem KI-Workflow eine echte Hebelwirkung zu verleihen, da das Tool einfach, schnell und strukturiert ist. Das offizielle Projekt beschreibt es als schnellen Web-Fuzzer und dokumentiert gängige Anwendungen wie Content Discovery, Vhost Discovery, Parameter Fuzzing und POST Data Fuzzing. Damit eignet es sich gut für die modellgestützte Generierung gezielter Wortlisten und Übereinstimmungsregeln, vor allem, wenn man bereits einige Hinweise aus der Herausforderung oder dem Anwendungsrahmen hat. (GitHub)
Ein minimaler autorisierter Durchlauf zur Auffindung von Inhalten könnte folgendermaßen aussehen:
ffuf -u https://challenge-instance/FUZZ \
-w ./wordlists/common-web.txt \
-mc 200,204,301,302,307,401,403 \
-fc 404 \
-of json \
-o ffuf-results.json
AI ist vor und nach diesem Befehl nützlich, nicht an seiner Stelle. Vor dem Lauf kann sie eine kleine thematische Wortliste aus Hinweisen im Titel der Herausforderung, Namen von JavaScript-Variablen oder Routennamen erstellen, die Sie bereits gesehen haben. Nach dem Durchlauf können die Ergebnisse in wahrscheinliche Authentifizierungsendpunkte, wahrscheinliche Admin-Pfade, statische Assets, API-Präfixe und Sackgassen eingeteilt werden. Was es nicht tun sollte, ist Ihnen zu sagen, dass /debug-old ist "wahrscheinlich angreifbar", nur weil der Name interessant klingt.
Sobald Sie interessanten Datenverkehr gefunden haben, wird Burp zum Gravitationszentrum. Burp Repeater existiert aus einem Grund: Ändern und senden Sie eine interessante HTTP- oder WebSocket-Nachricht erneut, bis Sie etwas lernen. Decoder dient der Umwandlung und Identifizierung von Kodierungen. Comparer dient dem Vergleich ähnlicher Daten, einschließlich nahezu identischer HTTP-Nachrichten. Diese drei Tools entsprechen nahezu perfekt der Art und Weise, wie KI in Web-CTFs eingesetzt werden sollte: Repeater für kontrollierte Experimente, Decoder für Transformation und Normalisierung, Comparer für diszipliniertes Vorher-Nachher-Denken. (PortSwigger)
Wenn Sie wollen, dass ein Modell Ihnen hilft, geben Sie ihm gepaarte Beobachtungen. Zeigen Sie ihm die normale Anfrage und die abnormale Anfrage. Zeigen Sie ihm die unveränderte Antwort und die geänderte Antwort. Zeigen Sie ihm die Anfrage, die ein 403 zurückgegeben hat, und die Anfrage, die ein 200 zurückgegeben hat, nachdem nur ein Parameter geändert wurde. Die Qualität der Schlussfolgerungen des Modells verbessert sich dramatisch, wenn Sie Deltas anstelle von isolierten Artefakten bereitstellen.
Hier kann ein kleines Python-Kabinett Zeit sparen. Die picoCTF-Fibel lehrt HTTP-Anfragen in Python für Challenges, und diese grundlegende Gewohnheit lässt sich erstaunlich gut skalieren. Bei einer Web-CTF ist es nicht Ihr Ziel, einen riesigen Client zu schreiben. Es geht darum, ein wiederholbares Mikroexperiment zu kodieren, so dass Sie jeweils eine Variable ändern und die Ausgabe speichern können. (CTF-Fibel)
http.client importieren
json importieren
HOST = "challenge-Instanz"
PATH = "/api/check-stock"
xml_payloads = [
"""
11""",
"""
<!DOCTYPE foo [ ]>
&xxe;1""
]
results = []
for payload in xml_payloads:
conn = http.client.HTTPSConnection(HOST)
conn.request(
"POST",
PATH,
body=payload,
headers={
"Content-Type": "application/xml",
"User-Agent": "ctf-lab-test"
}
)
resp = conn.getresponse()
body = resp.read().decode(errors="replace")
results.append({
"status": resp.status,
"reason": resp.reason,
"body_prefix": body[:400]
})
conn.close()
print(json.dumps(results, indent=2))
Dieser Code ist nicht aufregend, aber gerade deshalb ist er gut. Er gibt Ihnen eine strukturierte Ausgabe, über die das Modell nachdenken kann. Anstatt zu fragen: "Ist das XXE?", können Sie fragen: "Warum erzeugt die zweite Nutzlast einen Anstieg der Textlänge und einen anderen Parsing-Fehler als die erste Nutzlast?" Das ist viel näher daran, wie starke Webakteure tatsächlich denken.
Wenn KI in Web-CTFs gut eingesetzt wird, beschleunigt sie die Kategorietriage. SQLi ist ein klassisches Beispiel. PortSwigger definiert SQL-Injektion als Eingriff in die Abfragen, die eine Anwendung an ihre Datenbank stellt und die Daten offenlegen oder verändern können. Das ist eine präzise Beschreibung, aber sie sagt nichts darüber aus, ob die Herausforderung einen String-Kontext, einen numerischen Kontext, einen blinden booleschen Kanal, einen Fehlerkanal oder einen Out-of-Band-Pfad verwendet. Das Modell kann bei der Aufzählung der Möglichkeiten helfen, aber Sie müssen den Kontext immer noch experimentell bestimmen. (PortSwigger)
Das Gleiche gilt für XXE und SSRF. Die Definitionen von PortSwigger sind wichtig, weil sie Ihnen sagen, wonach Sie suchen müssen. XXE beginnt oft mit der XML-Verarbeitung und kann serverseitige Dateien oder interne Systeme offenlegen. SSRF beginnt, wenn der Server eine Anfrage in Ihrem Namen stellt und kann manchmal an localhost oder interne Endpunkte weitergeleitet werden. In PortSwigger's Labs sind diese Klassen für den Unterricht sauber getrennt, aber CTFs vermischen sie oft miteinander. Ein XML-Parser mit externer Entity-Unterstützung kann zu einem SSRF-Pfad werden, wenn die Entity auf einen internen Metadaten- oder Admin-Endpunkt zeigt. KI ist in solchen Situationen wirklich hilfreich, weil sie die kürzeste Kette von "XML-Senke existiert" zu "interner Abruf könnte möglich sein" vorschlagen kann, aber Sie brauchen immer noch die Serverantwort, um das zu beweisen. (PortSwigger)
Pfadüberquerung und SSTI sind ein weiteres gutes Paar. Bei der Pfadüberquerung geht es darum, Dateien außerhalb der vorgesehenen Verzeichnisgrenzen zu lesen. Bei SSTI geht es darum, dass benutzergesteuerte Eingaben von einer Template-Engine in einer Weise interpretiert werden, die zur Ausführung von Code führen kann. In beiden Fällen lohnt sich eine sorgfältige Beobachtung. Herausforderungen bei der Pfadüberquerung hängen oft von Normalisierung, Filterung oder unerwarteten Dateipfaden ab. SSTI-Herausforderungen hängen oft von der Identifizierung der Engine, Syntax-Macken und Sandbox-Annahmen ab. KI ist gut darin, mögliche Syntax- oder Umgehungsmuster zu generieren, sobald man weiß, in welcher Engine-Familie man sich befindet. Sie ist jedoch schlecht darin, die Motorfamilie anhand eines vagen Rendering-Fehlers zu bestimmen. (PortSwigger)
Die schwierigste Web-CTF-Falle für KI-Benutzer ist die Geschäftslogik. Modelle lieben benannte Schwachstellen, weil sie vertraute Muster abrufen können. Schwieriger wird es, wenn es sich um einen Fehler im Arbeitsablauf, einen Privilegienvorteil, eine Sitzungsverwirrung oder einen Zustandsübergang handelt, der erst nach mehreren normalen Anfragen sichtbar wird. In diesen Fällen sollten Sie KI für die Buchhaltung einsetzen. Bitten Sie sie, eine Zustandstabelle zu erstellen. Bitten Sie sie, zusammenzufassen, welche Cookies nach welchen Aktionen erscheinen. Bitten Sie es, Routen nach Authentifizierungsstatus zu gruppieren. Bitten Sie sie, Antwortkörper und Header-Sets zu vergleichen. Bitten Sie die KI erst dann um eine Ursachenforschung, wenn der Zustandsautomat bereits auf dem Papier steht.
Wenn Sie einen dedizierten AI-Pentest-Arbeitsbereich anstelle einer losen Chat-Registerkarte verwenden, gelten die gleichen Grundsätze. In den öffentlichen Dokumenten von Penligent werden vom Benutzer erstellte Aufgaben, konfigurierbare Python- und Bash-Laufzeiten sowie die Möglichkeit beschrieben, bereits in Kali installierte Tools wie nmap und hydraund den Import gängiger Werkzeugkonfigurationen mit einem Mausklick. Auf der Produktseite werden außerdem editierbare Prompts, Umfangskontrolle, Unterstützung für viele Industrietools und evidenzbasierte Ergebnisse hervorgehoben. In einem Web-CTF-Labor sind diese Funktionen weniger wichtig, weil sie auffällig sind, sondern eher, weil sie den Kontext-Wildwuchs reduzieren. Sie können generierte Skripte, Tool-Outputs und Ihre eigene manuelle Überprüfung in einem Arbeitsablauf zusammenfassen, anstatt sie über den Terminalverlauf und die Chat-Fenster zu verstreuen. (Sträflich)
Wie man AI in binären Exploitation-CTFs einsetzt
Binäre Ausbeutung ist der Bereich, in dem KI aus der Ferne am klügsten und aus der Nähe am schwächsten erscheint. Aus der Ferne scheint es perfekt für ein LLM zu sein. Sie haben Code, Decompiler-Ausgaben, Assembler, Speicherfehler und die Notwendigkeit von Python-Skripten. Aus der Nähe ist der schwierige Teil nicht die Texterstellung. Es ist die präzise Interaktion mit einem Zielprozess und die rücksichtslose Beachtung von Details, die das Modell oft ausblendet.
Die offiziellen pwntools-Dokumente sagen Ihnen genau, warum die Bibliothek zum Standard wurde: Sie bietet eine einheitliche Möglichkeit, mit Prozessen, Sockets und entfernten Diensten zu kommunizieren. Die corefile-Dokumente weisen auf einen weiteren wichtigen Punkt hin. Core-Dumps sind nicht nur für das manuelle Debugging nützlich, sondern auch für die Automatisierung. Man kann eine abstürzende Adresse und ein zyklisches Muster verwenden, um Offsets schnell zu berechnen, ohne die Arithmetik von Hand zu machen. Dies ist ein idealer Übergangspunkt zwischen menschlicher Beurteilung und KI-Beschleunigung. (Pwntools Dokumentation)
Ein praktisches Muster für die künstliche Intelligenz in pwn besteht darin, die Arbeit in vier Schichten zu unterteilen. Zunächst erklärt das Modell den Binärcode auf einer hohen Ebene: Schutzmaßnahmen, wahrscheinlicher Eingabepfad, verdächtige Funktionen und mögliche Speicherkorruptionsklasse. Zweitens führen Sie kurze Experimente durch, um die Klasse zu bestätigen. Drittens: Das Modell entwirft ein pwntools-Gerüst. Viertens: Sie debuggen das Gerüst wie ein normaler Exploit-Entwickler. Das wichtige Detail ist, dass der Exploit niemals dem Modell "gehört". Er wird nur vom Modell entworfen.
Ein minimales pwntools-Gerüst für eine autorisierte Herausforderung könnte wie folgt aussehen:
from pwn import *
context.binary = ELF("./chall")
kontext.log_level = "info"
HOST = "challenge-Instanz"
PORT = 31337
def start():
if args.REMOTE:
return remote(HOST, PORT)
return process(context.binary.path)
io = start()
# Beispiel-Interaktion, ersetzen durch challenge-spezifische Logik
io.recvuntil(b"> ")
io.sendline(b "A" * 128)
# Ausgabe für die Triage sichtbar halten
print(io.recvall(timeout=1).decode(errors="replace"))
Dieses Beispiel ist absichtlich einfach gehalten. Es handelt sich nicht um einen Exploit. Es ist ein Kabelbaum. Bei vielen Pwn-Herausforderungen ist das erste, was man braucht, keine ROP-Kette. Es ist eine zuverlässige Möglichkeit, das Programm zu steuern, zu beobachten, wo es abstürzt, und die Ausgabe bei kleinen Eingabevariationen zu vergleichen.
Wenn das Problem ein einfacher Überlauf ist, helfen Corefiles dabei, einen Absturz in einen Offset zu verwandeln. Die Dokumentation von pwntools zeigt explizit diesen Arbeitsablauf: Erzeugen Sie ein zyklisches Muster, lassen Sie den Prozess einmal abstürzen, laden Sie den Core-Dump und überprüfen Sie, wo das Muster gelandet ist. (Pwntools Dokumentation)
from pwn import *
Nutzlast = zyklisch(256)
p = process(["./chall", Nutzdaten])
p.wait()
Kern = Coredump("./Kern")
offset = cyclic_find(core.eip if context.bits == 32 else core.rip)
print(f "Offset: {offset}")
Die KI ist gut darin, diese Schritte zusammenzufügen, vor allem, wenn man ihr den Absturz-Offset, die Sicherheitseigenschaften und die Decompiler-Ausgabe für die verwundbare Funktion vorgibt. Sie ist gut darin, zu sagen: "Du musst wahrscheinlich RIP nach 72 Bytes kontrollieren, hier ist ein saubereres Kabelbaum, hier ist, wie man eine Nutzlast mit Wohnungund hier ist eine Checkliste für ret2win versus ret2libc." Es ist weniger gut darin zu wissen, ob der Absturz vor einer Stack-Canary-Prüfung passiert ist, ob ein Off-by-One die Ausrichtung in einer Weise ändert, die Ihre Annahmen bricht, oder ob der entfernte Dienst sich anders verhält als Ihre lokale libc.
Aus diesem Grund kann angr nützlich sein, aber nur zu bestimmten Zeitpunkten. Die angr-Dokumente definieren symbolische Ausführung als das Erforschen mehrerer Ausführungspfade unter Verwendung symbolischer Variablen und dem Lösen von Beschränkungen anstelle fester konkreter Eingaben. Bei CTFs ist das sehr hilfreich, wenn das Binärprogramm ein getarntes Constraint-System ist: ein Labyrinth von Prüfungen für Eingabebytes, ein versteckter Erfolgszweig oder eine Validierungsroutine mit vielen linearen oder bitweisen Bedingungen. Wenn die Aufgabe besser zu verstehen ist als "Finde die Eingabe, die das Programm dazu bringt, Pfad B zu nehmen", ist die symbolische Ausführung eine gute Lösung. Handelt es sich bei der Herausforderung um Heap Grooming, Race Behavior oder eine enge Interaktion mit dem Prozessstatus, kann die symbolische Ausführung nur Zeit kosten. (Angr Dokumentation)
Ein sehr kleines Beispiel sieht wie folgt aus:
angr einführen
proj = angr.Project("./chall", auto_load_libs=False)
state = proj.factory.entry_state()
simgr = proj.factory.simgr(state)
simgr.explore(find=lambda s: b "Richtig" in s.posix.dumps(1))
if simgr.found:
found = simgr.found[0]
Kandidat = gefunden.posix.dumps(0)
print(kandidat)
Dieses Skript ist kein Universallöser. Es ist eine Erinnerung an die richtige Frage. Wenn die Erfolgsbedingung der Binärdatei textuell sichtbar und pfadbasiert ist, kann KI Ihnen helfen, schneller zu einem angr-Experiment zu gelangen. Handelt es sich bei der Binärdatei wirklich um eine Speicherbeschädigung oder einen subtilen Laufzeitzustand, sollte die KI Ihnen helfen, ein Instrument zu finden, anstatt zu phantasieren.
Ghidra passt in das gleiche Muster. Die Projektseite der NSA beschreibt es als ein vollständiges Software-Reverse-Engineering-Framework mit Disassemblierung, Dekompilierung, grafischer Darstellung und Skripterstellung. Diese Funktionen sind wichtig, weil sie es ermöglichen, ein großes Binärprogramm in handhabbare Teile zu zerlegen. Das Modell sollte selten die gesamte Binärdatei auf einmal sehen. Es sollte eine Funktion, eine Aufrufkette, einen Verzweigungscluster oder eine verdächtige String-Nachbarschaft sehen. Gute Umkehrung mit KI ist lokal. Schlechtes Reversing mit KI ist "Ich habe 7.000 Zeilen Pseudo-C eingefügt und jetzt sagt das Modell, dass der Fehler wahrscheinlich in Haupt." (GitHub)
Die öffentliche Benchmark-Arbeit unterstützt diese Vorsicht. In der NYU-Studie von 2024 konnten die Modelle einige "Pwn"- und "Reversing"-Aufgaben lösen, aber die Leistung schwankte in den verschiedenen Kategorien stark, und die Fehleranalyse der Autoren umfasste leere Ausgaben, falsche Befehlsausführung, fehlerhaften Code und fehlenden Aufgabenkontext. Die neuere Agentenforschung zeigt, dass starke Systeme mit langfristigen Plänen, spezialisierten Werkzeugen und erfahrungsbasierten Hinweisen zu kämpfen haben. Mit anderen Worten: Aktuelle Modelle können bei der Arbeit in der Mitte von pwn helfen, aber sie brauchen immer noch einen Menschen, der den Exploit ehrlich hält. (arXiv)
Wie man AI bei der Umkehrung von CTFs einsetzt
Umkehrung belohnt Geduld mehr als Cleverness, und KI neigt dazu, Cleverness zu simulieren. Das ist gefährlich. Der richtige Weg, KI bei der Umkehrung einzusetzen, besteht nicht darin, sie zu bitten, die Herausforderung umzukehren. Vielmehr sollte man sie bitten, die lokale Verwirrung zu verringern.
Beginnen Sie mit der gleichen Triage, die Sie auch ohne KI durchführen würden. ausführen Zeichenketten. Identifizieren Sie importierte Bibliotheken. Achten Sie auf offensichtliche Kodierungen, Fehlermeldungen, Dateipfade oder Formatmarkierungen. Öffnen Sie die Binärdatei in Ghidra. Finden Sie den Einstiegspunkt und die Funktionen, die tatsächlich benutzergesteuerte Daten berühren. Entscheiden Sie dann, welche Art von Hilfe Sie von dem Modell erwarten.
Einige der besten Verwendungen sind fast schon redaktionell. Bitten Sie das Modell, Variablen in einer einzelnen dekompilierten Funktion je nach ihrer Verwendung umzubenennen. Bitten Sie es, den Kontrollfluss in einfachem Englisch zusammenzufassen. Bitten Sie es zu erraten, welche Verzweigungen der Validierung und welche der Anti-Analyse entsprechen. Bitten Sie es, drei disjunkte Funktionen in eine lineare Erzählung zu verwandeln. Bitten Sie es zu erkennen, ob eine byteweise Schleife eher wie eine Prüfsumme, eine Substitutionstabelle oder eine gestufte Dekodierroutine aussieht. Dies sind alles lokale Fragen. Sie funktionieren, weil das Modell Muster mit einem kleinen, gut begrenzten Artefakt abgleicht.
Was nicht gut funktioniert, ist eine zu frühe globale Synthese. In dem Moment, in dem man fünf nicht zusammenhängende Funktionen einfügt und fragt "Was ist hier los?", beginnt das Modell, semantische Lücken mit Geschichten zu füllen. Umgekehrt ist die Geschichte billig und häufiger falsch, als man denkt. Besser ist es, das Modell dazu zu bringen, sich seine globale Zusammenfassung zu verdienen, indem es zuerst mehrere kleine lokale Zusammenfassungen schafft.
Ein praktischer Ansatz ist dieser. Legen Sie einen Ordner für die Herausforderung mit einer kurzen Textnotiz an. Jedes Mal, wenn Sie eine Funktion manuell überprüfen, notieren Sie den Namen der Funktion, die Daten, die sie berührt, und die Aufgabe, die sie Ihrer Meinung nach hat. Fordern Sie dann das Modell auf, jeweils nur eine Einheit zu verarbeiten. Das bringt Ihnen zwei Vorteile. Erstens behalten Sie Ihre eigenen Überlegungen bei, anstatt sie vom Modell überschreiben zu lassen. Zweitens können Sie die Interpretation des Modells mit Ihren Notizen vergleichen und feststellen, wann es anfängt, sich zu sehr anzupassen.
Das gleiche Prinzip gilt für die Verschleierung. Wenn eine Umkehrherausforderung die Logik hinter verschlüsselten Zeichenfolgen, gepackten Tabellen oder verdächtigen Build-Artefakten verbirgt, kann das Modell bei der Entschlüsselung und Klassifizierung von Mustern helfen, aber es sollte nicht zur Quelle der Wahrheit werden. Dies wird noch deutlicher, wenn Sie sich einen realen Fall wie CVE-2024-3094 in xz ansehen. In der Beschreibung von NVD wird erklärt, dass bösartiger Code in Upstream-Tarballs eingeschleust wurde und während des Build-Prozesses ein vorgefertigtes Objekt aus getarnten Testdateien extrahierte und bestimmte Funktionen in der resultierenden Bibliothek veränderte. Das ist eine perfekte Lektion für die Umkehrung von Spielern: Das interessante Verhalten kann sich außerhalb des offensichtlichen Quellpfads befinden, und Artefakte während des Build-Prozesses können genauso wichtig sein wie die Logik zur Laufzeit. (NVD)
Die Umkehrung mit KI wird dramatisch besser, wenn Sie bedenken, dass das Modell bei der Übersetzung stärker ist als bei der Entdeckung. Lassen Sie es Assembler in Erzählungen übersetzen, seltsame Tabellen in strukturierte Daten umwandeln, Compiler-Artefakte erklären und kleine Emulatoren für verdächtige Routinen entwerfen. Lassen Sie es nicht entscheiden, was die gesamte Binärdatei "bedeutet", solange Sie noch keine Karte haben.
Wie man AI in Krypto-CTFs einsetzt
Krypto-CTFs zeigen die Grenzen von Sprachmodellen schneller auf als fast jede andere Kategorie. Die 2024 NYU Ergebnisse sind hier eine nützliche Warnung. In ihrem ausgewählten Datensatz war die Kryptoleistung im Vergleich zu Kategorien wie Reversing und einigen Pwn-Aufgaben besonders schwach. Das sollte niemanden überraschen, der Zeit mit CTF-Krypto verbracht hat. Bei vielen Kryptoherausforderungen geht es um exakte Strukturen, nicht um vage semantische Musterübereinstimmungen. Wenn das Modell nicht den richtigen algebraischen Zugriff auf das Problem hat, hilft alles Python der Welt nicht. (arXiv)
Das macht KI in der Kryptowirtschaft nicht nutzlos. Es ändert nur die Aufgabenbeschreibung. Das Modell ist am stärksten, wenn die Aufgabe noch klassifiziert werden muss. Handelt es sich wahrscheinlich um eine Substitution, eine Transposition, eine Blockformatierung, einen XOR-Missbrauch, eine Basiskodierungsschicht oder ein Problem mit Einschränkungen? Liegen die wichtigen Anhaltspunkte in der Alphabetgröße, den wiederholten Blöcken, der Byte-Häufigkeit, dem festen Präfix oder der Wiederverwendung von Schlüsseln? Was sollten Sie extrahieren, bevor Sie überhaupt versuchen, das Problem zu lösen? Das sind gute KI-Fragen, denn sie helfen Ihnen bei der Entscheidung, ob Sie CyberChef öffnen, einen Parser schreiben oder zu einem SMT-Löser wechseln sollen.
Auf der Website von CyberChef wird es als "Cyber Swiss Army Knife" bezeichnet, und diese Beschreibung ist für Krypto-CTF-Arbeiten zutreffend. Es eignet sich hervorragend für den Teil des Arbeitsablaufs, in dem noch kein Theorem bewiesen werden muss, sondern nur getestet wird, ob sich die Daten wie Kompression, Hex, base64, XOR, JSON, URL-Kodierung oder eine Kombination davon verhalten. AI lässt sich gut mit CyberChef kombinieren, da das Modell eine kleine Anzahl wahrscheinlicher Transformationsketten auf der Grundlage der sichtbaren Struktur in den Daten vorschlagen kann, und Sie können diese sofort bestätigen oder ablehnen. (GCHQ)
Z3 ist das Gegenteil. In der Anleitung von Microsoft wird es als Theorembeweiser und SMT-Löser beschrieben, der die Erfüllbarkeit von unterstützten Theorien prüft. Das ist wichtig, wenn es bei einer Kryptoherausforderung nicht mehr ums Raten geht, sondern um die Erfüllung von Bedingungen. Wenn das Rätsel wirklich lautet: "Finde Bytes, die diese arithmetischen und Bitvektor-Bedingungen erfüllen", dann sollte das Modell aufhören zu improvisieren und Ihnen helfen, das System zu formalisieren. (Microsoft GitHub)
Ein kleines Beispiel sieht so aus:
von z3 import BitVec, Solver
a = BitVec("a", 8)
b = BitVec("b", 8)
c = BitVec("c", 8)
s = Löser()
s.add(a ^ b == 0x12)
s.add(b ^ c == 0x34)
s.add(a + c == 150)
wenn s.check().r == 1:
m = s.model()
print(m[a], m[b], m[c])
In diesem Ausschnitt geht es nicht um das mathematische Spielzeug. Es ist die Verlagerung des Arbeitsablaufs. Sobald die Aufgabe zu einem formalen System wird, besteht die beste Aufgabe der KI darin, Ihnen bei der korrekten Kodierung des Systems zu helfen und die Ausgabe des Lösers zu erklären, und nicht darin, die Antwort in Prosa zu erraten.
Ein weiterer Bereich, in dem KI gut funktioniert, ist die Parsergenerierung. Bei vielen mittelschweren Kryptoherausforderungen geht es eigentlich nicht um fortgeschrittene Kryptoanalyse. Es geht darum, die richtigen Bytes aus einem unübersichtlichen Format zu extrahieren, Blöcke korrekt aufzuteilen, die Endianness zu interpretieren oder zwischen textuellen und binären Ansichten zu konvertieren, ohne dumme Fehler zu machen. Modelle sind oft sehr gut darin, diese Aufgaben in kleine Skripte zu verwandeln. Das ist ein echter Wert. Verwechseln Sie das nur nicht mit kryptografischen Erkenntnissen.
Eine zuverlässige Methode, das Modell ehrlich zu halten, besteht darin, nach der Eliminierung und nicht nach der Identifizierung zu fragen. Anstatt zu fragen: "Welche Chiffre ist das?", sollten Sie fragen: "Auf der Grundlage der Länge des Chiffretextes, des Alphabets und des Wiederholungsmusters, welche gemeinsamen Familien werden weniger wahrscheinlich?" Dadurch wird das Modell ermutigt, aus den Eigenschaften zu schließen, anstatt nach dem bekanntesten Namen zu greifen. Es verhindert auch, dass Sie eine Stunde vergeuden, weil das Modell etwas "Vigenere-ähnliches" genannt hat, obwohl das eigentliche Problem nur XOR mit einem wiederverwendeten Schlüssel und einer seltsamen Framing-Schicht war.
Das Modell ist auch nützlich, wenn Sie die Aufgabe bereits gelöst haben. Bitten Sie es um eine Erklärung, warum die Lösung funktioniert hat. Bitten Sie es, Ihr Scratch-Skript in eine sauberere, dokumentierte Version umzuschreiben. Bitten Sie es, zusammenzufassen, welche Hinweise tatsächlich von Bedeutung waren. Diese Aufgaben nach der Lösung stärken die Mustererkennung für künftige Kryptoherausforderungen auf eine Art und Weise, wie es die Aufforderung "Löse mich einmal" niemals tun wird.
Einsatz von AI in Forensik und PCAP CTFs
Forensik-CTFs wirken oft überwältigend, weil die Artefakte groß und die Flagge klein ist. Das ist genau die Art von Asymmetrie, bei der KI helfen kann, vorausgesetzt, man vermeidet die Versuchung, alles auf einmal in den Kontext einzubringen.
Beginnen Sie mit der Trennung der Artefakttypen. Die Erfassung von Paketen ist ein Arbeitsablauf. Dateisystemnachweis ist ein anderer. Speicheranalyse ist ein anderer. Das Modell sollte nicht herausfinden müssen, welches Artefakt es betrachtet. Ihre erste Aufgabe besteht darin, jedes Artefakt auf einen überschaubaren Index zu reduzieren: interessante Protokolle, interessante Dateien, interessante Prozesse, interessante Zeitstempel.
Für die Arbeit mit Paketen ist TShark ideal, da es die gleiche Anzeigefilterlogik wie Wireshark in skriptfähiger Form zur Verfügung stellt. Die Manpage betont, dass Display-Filter mächtig sind und mit -Y, während Erfassungsfilter anders sind und mit -f. Diese Unterscheidung ist bei CTFs wichtig, weil man oft nichts zurückerobern will. Man will ein bestehendes PCAP wiederholt aufschneiden und jedes Mal eine engere Frage stellen. (Wireshark)
Ein einfacher erster Durchgang bei einem PCAP mit autorisierter Herausforderung könnte wie folgt aussehen:
tshark -r challenge.pcap \
-Y 'http.request || dns || tcp.flags.syn==1' \
-T fields \
-e frame.time \
-e ip.src \
-e ip.dst \
-e _ws.col.Protocol \
-e _ws.col.Info
Dieser Output ist klein genug, damit ein Modell ihn sinnvoll zusammenfassen kann. Damit kann die KI helfen, den Datenverkehr nach Phasen zu gruppieren, verdächtige Ziele zu gruppieren, Bursts zu identifizieren oder darauf hinzuweisen, dass auf eine HTTP-POST eine DNS-Abfrage und dann eine zweite Verbindung folgt, die von Bedeutung sein könnte. Es sollte jedoch nicht auf Exfiltration geschlossen werden, nur weil ein Domänenname seltsam aussieht. Die zeitliche Abfolge und der Inhalt sind immer noch wichtig.
Die Speicherforensik ist ähnlich. In der Dokumentation von Volatility 3 wird erklärt, dass das Framework die Analyse durch Speicherebenen, Vorlagen und Objekte, Symboltabellen und einen Kontext mit den relevanten Strukturen organisiert. Das ist eine Erinnerung daran, dass die Speicheranalyse strukturell ist. Ein guter Einsatz von KI in der Speicherforensik bedeutet, dass das Modell mit strukturierten Plugin-Ausgaben gefüttert wird, nicht mit Rohdaten. Geben Sie ihm pslist, netscan, Befehlszeilen, geladene Module oder verdächtige Handles. Bitten Sie das Programm, sie zu korrelieren. Bitten Sie es, eine Zeitleiste zu erstellen. Fragen Sie es, welches zusätzliche Plugin zwei konkurrierende Erklärungen am besten unterscheiden würde. (Volatilität 3)
Ein sehr einfaches Muster könnte sein:
python3 vol.py -f speicher.raw fenster.pslist
python3 vol.py -f speicher.raw fenster.cmdline
python3 vol.py -f memory.raw windows.netscan
Sobald Sie diese Ausgaben haben, kann KI wirklich hilfreich sein. Sie kann erkennen, dass ein Prozess ein ungewöhnliches Elternteil hat, dass eine Befehlszeile ein verschlüsseltes PowerShell-Fragment enthält oder dass ein abhörender Socket kurz nach einem verdächtigen Kindprozess erschienen ist. Das sind die Arten von Beziehungen, die Menschen übersehen, wenn sie müde sind. Aber auch hier gilt: Der Beweis kommt von den Artefakten, nicht von der Zusammenfassung.
Die Dateisystem-Forensik folgt der gleichen Regel. Verwenden Sie KI zum Katalogisieren, Vergleichen und Einordnen. Verlangen Sie nicht, dass es aus einem Tarball eine Bedeutung ableitet. Wenn Sie Zeichenketten aus einem Image wiederherstellen, bitten Sie das Modell, diese zu Anmeldeinformationen, URLs, Zeitstempeln oder Dateimarkierungen zusammenzufassen. Wenn Sie mehrere Dateien zerlegen, bitten Sie das Modell, die Kopfzeilen zu vergleichen und auf wahrscheinliche Typen zu schließen. Wenn Sie den Browser- oder Shell-Verlauf extrahieren, bitten Sie das Modell, eine Zeitleiste vorzuschlagen. Dies sind alles Aufgaben zur "Entropieverringerung". Hier verdient die KI ihr Geld.
Der häufigste Fehler bei forensischen CTFs besteht darin, die erzählerische Disziplin zu überspringen. Ein Prozessname sieht seltsam aus, also denkt man sofort an Malware. Eine DNS-Abfrage sieht seltsam aus, also denkt man sofort an Exfiltration. Ein JPEG hat zusätzliche Bytes, also denkt man sofort an Stego. KI macht das noch schlimmer, es sei denn, Sie zwingen sie in den Beweismodus. Sie muss Ihnen sagen, welche Artefakte jede Behauptung unterstützen. Trennen Sie direkte Beweise von Schlussfolgerungen. Bringen Sie sie dazu, alternative Erklärungen aufzulisten. Diese einzige Angewohnheit verbessert sowohl die menschliche als auch die KI-Leistung.
Wie man KI in CTFs einsetzt, ohne sich vom Modell angreifen zu lassen
Das interessanteste Risiko bei KI-gestützten CTF-Spielen ist, dass die Herausforderung Ihren Assistenten angreifen kann. Die OWASP-Leitlinien für Prompt Injection sind hier von besonderer Bedeutung. Das Projekt unterscheidet zwischen direkter und indirekter Prompt Injection und weist darauf hin, dass externe Quellen wie Websites oder Dateien Inhalte enthalten können, die das Verhalten des Modells verändern, wenn sie vom Modell interpretiert werden. Der Leitfaden empfiehlt außerdem, externe Inhalte abzutrennen und eindeutig zu identifizieren, Vertrauensgrenzen zu testen und das Modell als möglichen Angriffspfad und nicht als neutralen Helfer zu behandeln. (OWASP Gen AI Sicherheitsprojekt)
In einem CTF-Workflow bedeutet das, dass Aufforderungstext, HTML, README-Dateien, Quellcodekommentare, PDFs, versteckte Zeichenfolgen, Screenshots, base64-Blobs und sogar Bild-Metadaten als nicht vertrauenswürdige Eingaben behandelt werden sollten. Eine böswillige oder absichtlich verzwickte Herausforderung könnte Anweisungen enthalten, die auf ein Modell und nicht auf Sie abzielen. Der Inhalt muss nicht einmal für den Menschen offensichtlich sein. OWASP weist darauf hin, dass Prompt Injections nicht für den Menschen sichtbar sein müssen, solange das Modell sie analysiert. In der Praxis bedeutet das, dass ein völlig normal aussehendes Dokument den nächsten Schritt Ihres Assistenten vergiften kann. (OWASP Gen AI Sicherheitsprojekt)
Der erste Schutz ist architektonischer Natur. Vermischen Sie nicht die Systemanweisungen, Ihre eigenen Aufgabenregeln und den Inhalt der Aufgabenstellung in einem undifferenzierten Klumpen. Kennzeichnen Sie Abschnitte. Verwenden Sie explizite Markierungen für nicht vertrauenswürdigen Text. Begrenzen Sie die Aufgabe des Modells. "Fassen Sie den folgenden nicht vertrauenswürdigen HTML-Text zusammen und extrahieren Sie nur beobachtete Routen und Formulare" ist eine viel sicherere Anweisung als "Lesen Sie diese Seite und sagen Sie mir, was ich als Nächstes tun soll."
Der zweite Schutz ist operativ. Führen Sie Modellausgaben niemals automatisch in einer Shell oder einem nachgelagerten System aus. In den OWASP-Materialien zum Umgang mit unsicheren Ausgaben heißt es, dass das Risiko besteht, wenn Modellausgaben ohne Validierung oder Bereinigung an Shells, Browser oder andere Komponenten weitergegeben werden. Es listet explizit Ergebnisse wie XSS, CSRF, SSRF, Privilegienerweiterung und Remotecodeausführung auf, wenn LLM-Ausgaben unsicher behandelt werden. In einer CTF ist das nicht theoretisch. Wenn Ihr Arbeitsablauf es zulässt, dass ein Modell einen dekodierten Hinweis in einen Shell-Befehl umwandelt und diesen dann ausführt, haben Sie gerade Herausforderungsdaten einen Pfad zur Ausführung gegeben. (OWASP Gen AI Sicherheitsprojekt)
Die dritte Verteidigung ist eine soziale, keine technische. Verlangsamen Sie Ihr Tempo, bevor Sie Vertrauen fassen. Wenn das Modell eine Nutzlast vorschlägt, fragen Sie, auf welche Beobachtung es sich stützt. Wenn es einen Befehl vorschlägt, fragen Sie, was die dem Befehl zugrunde liegende Hypothese falsifizieren würde. Wenn es einen kompletten Exploit vorschlägt, fragen Sie, welche einzelne Vorbedingung am wahrscheinlichsten scheitern wird. Diese Fragen sind auch ohne KI eine gute CTF-Praxis. Mit KI sind sie obligatorisch.
Die KI-Fehler, durch die man die meisten CTF-Punkte verliert
Der erste große Fehler ist das Festhalten an Kategorien. Das Modell sieht XML und entscheidet, dass das Problem XXE ist. Sie verbringen dann dreißig Minuten damit, XXE-Nutzdaten in eine Bestandsprüfungsfunktion zu schieben, die eigentlich nur ein SSRF-Muster oder ein Leck in den Anmeldeinformationen an einem zweiten Endpunkt erkennen soll. Die Abhilfe besteht darin, eine Rangfolge der Hypothesen zu erzwingen, anstatt nur ein Label zu verwenden. Lassen Sie das Modell für die zweite und dritte Wahl argumentieren.
Der zweite Fehler ist das Aushungern von Beweisen. Man füttert ein Modell mit einem einzigen Symptom und erwartet, dass es so denkt wie ein Mensch, der eine Stunde lang auf die Herausforderung gestarrt hat. Das kann es nicht. Wenn Sie gute Hilfe wollen, geben Sie ihm eine Basisanforderung, eine veränderte Anforderung und den genauen Unterschied zwischen den Antworten. Geben Sie ihm die Disassemblierung für eine Funktion und den Absturz-Offset. Geben Sie ihm den PCAP-Slice und das DNS-Burst-Timing. Jedes zusätzliche geerdete Artefakt schränkt die Freiheitsgrade des Modells ein.
Der dritte Fehler ist die Aufblähung des Kontexts. Wenn man ein komplettes Binärprogramm, ein komplettes PCAP, drei Screenshots und einen kompletten Chatverlauf in eine Eingabeaufforderung packt, wird das Modell selten intelligenter. Normalerweise wird es dadurch schlampiger. Kleine Kontextfenster sind nicht das einzige Problem. Große Fenster begünstigen eine diffuse Argumentation. Besser ist es, die Artefakte mit echten Werkzeugen vorzusortieren und dem Modell dann nur den Teil zu geben, der wichtig ist.
Der vierte Fehler ist die Skriptanbetung. KI-generierter Code sieht befriedigend aus. In CTFs kann das süchtig machen. Aber ein Skript, das läuft, ist nicht dasselbe wie ein Skript, das etwas beweist. Bei Benchmark-Tests wurden immer wieder Fehlermodi mit leeren Ausgaben, fehlerhaften Befehlen und falschem Code festgestellt, selbst wenn die Argumentation plausibel klang. Behandeln Sie den KI-Code wie den ersten Entwurf eines jungen Teammitglieds. Prüfen Sie ihn, minimieren Sie ihn und testen Sie ihn auf eine winzige Bedingung, bevor Sie ihm die ganze Herausforderung anvertrauen. (arXiv)
Der fünfte Fehler ist, keine Notizen zu machen, denn "das Modell erinnert sich". Es erinnert sich nicht so, wie es ein disziplinierter Spieler tut. Es erinnert sich an den Token-Kontext, bis es das nicht mehr tut. Notizen schlagen Vibes. Speichern Sie Anfragen. Speichern Sie Skriptrevisionen. Hashes speichern. Speichern von Offsets. Speichern Sie, welche Hypothesen getötet wurden und warum. Diese Angewohnheit macht auch Ihre Post-CTF-Schreiben besser, was wiederum Ihre zukünftigen KI-Eingaben besser macht, weil Sie saubere Beispiele Ihrer eigenen Argumentation haben, aus denen Sie lernen können.
Echte CVEs, die Sie bei CTFs besser machen
CTFs sind besser, wenn sie Ihr Gespür für reale Systeme schärfen. Der einfachste Weg, die KI-gestützte CTF-Praxis nützlicher zu machen, besteht darin, die Herausforderungsmuster mit realen Schwachstellen zu verknüpfen. Nicht, weil jedes CTF die Produktion widerspiegelt, sondern weil die besten CTF-Lektionen die Struktur betreffen: wie Eingaben einen Interpreter erreichen, wie die Normalisierung fehlschlägt, wie Privilegienkanten erscheinen, wie versteckte Artefakte das Vertrauen verändern.
CVE-2021-41773 und warum Path Traversal ist nie nur über Punkte und Schrägstriche
NVD beschreibt CVE-2021-41773 als eine Schwachstelle in Apache HTTP Server 2.4.49, die durch eine Änderung der Pfadnormalisierung verursacht wird. Ein Angreifer könnte Pfad-Traversal verwenden, um URLs auf Dateien außerhalb von Verzeichnissen abzubilden, die durch Alias-ähnliche Direktiven konfiguriert sind. Wenn diese Dateien nicht durch die üblichen verlangen, dass alle verweigerten Standard, könnten Anfragen erfolgreich sein. Wenn CGI für die betroffenen Aliased-Pfade aktiviert war, konnte das Problem zur Remotecodeausführung führen. NVD weist außerdem darauf hin, dass das Problem in freier Wildbahn ausgenutzt werden kann. Die CISA hat später festgestellt, dass die damit verbundenen Apache-HTTP-Server-Probleme, die ausgenutzt werden, die Versionen 2.4.49 und 2.4.50 betreffen. (NVD)
Warum ist das für CTF-Spieler nützlich? Weil es die wirkliche Form der Pfadüberquerung lehrt. Der Fehler ist nicht "jemand hat vergessen zu blockieren ../." Bei dem Fehler geht es um Normalisierung, Pfadzuordnung, Bereitstellungskonfiguration und darum, was der Server außerhalb der vorgesehenen Grenzen preisgeben darf. In CTF-Begriffen ist das der Unterschied zwischen einer Spielzeug-Herausforderung zum Lesen von Dateien und einer sinnvollen Traversalkette. KI kann Ihnen bei der Generierung von Traversal-Varianten helfen, aber die interessanten Überlegungen liegen in der Umgebung. Welche Verzeichnisse sind erreichbar? Welcher Normalisierungsschritt fehlerhaft ist. Ob die Offenlegung von Dateien der Endpunkt oder nur die Brücke zu etwas Größerem ist.
Auch die Lektion zur Schadensbegrenzung ist wichtig. Die Lösung besteht nicht in einer magischen Regex. Es geht um Versionskorrektur, korrekte Pfadbehandlung und eine defensive Konfiguration, die verhindert, dass Dateien außerhalb der vorgesehenen Verzeichnisse bereitgestellt oder ausgeführt werden. Das ist die gleiche defensive Denkweise, die gute Web-CTF-Spieler schließlich verinnerlichen: Die Schwachstelle liegt in den Vertrauensgrenzen, nicht in der Syntax allein. (NVD)
CVE-2021-44228 und die CTF-Gewohnheit, Daten in einen Interpreter zu folgen
CVE-2021-44228, Log4Shell, ist nach wie vor eines der deutlichsten Beispiele dafür, warum "benutzergesteuerte Eingaben einen Interpreter erreichen" ein zentrales Angriffsmuster ist. NVD gibt an, dass die betroffenen Log4j2-Versionen es Angreifern ermöglichten, mit Hilfe von Protokollnachrichten oder -parametern JNDI-Lookups zu von Angreifern kontrollierten Endpunkten auszulösen, was die Ausführung von Remote-Code ermöglichte, wenn die Substitution von Nachrichten-Lookups aktiviert war. In demselben Bericht wird darauf hingewiesen, dass 2.15.0 das riskante Verhalten standardmäßig deaktiviert und 2.16.0 die Funktionalität vollständig entfernt hat. Die Log4j-Anleitung der CISA stuft Log4Shell ebenfalls als kritisches Problem der Remotecodeausführung ein und verweist auf die Deaktivierung von JNDI in späteren Korrekturen. (NVD)
Warum ist dies für CTFs relevant? Weil es genau die Art von logischem Denken trainiert, bei dem die KI oft Hilfe braucht. Die Herausforderung besteht nicht nur darin, "Injektionen zu erkennen". Es geht darum, den Datenfluss von der Quelle bis zur Senke zu verfolgen und dann den externen Auflösungsschritt zu erkennen, der Daten in Kontrolle umwandelt. Viele Web- und sonstige CTFs sind vereinfachte Versionen desselben kognitiven Schritts. Eine Kopfzeile, ein Parameter oder eine protokollierbare Zeichenkette ist nicht wichtig, weil es sie gibt. Er ist wichtig, weil eine nachgelagerte Komponente ihn interpretiert.
Wenn Sie KI bei Herausforderungen mit dieser Struktur einsetzen, fragen Sie nicht nur nach Nutzlasten. Fragen Sie nach der Pfadanalyse. Welche Komponente den Input verbraucht. Ob es eine Zwischentransformation gibt. Ob externe Auflösung, Templating, Datenbankinterpretation, Shell-Interpretation oder Deserialisierung Teil der Kette sind. Diese Art der Abfrage macht das Modell viel nützlicher als "Gib mir einen Log4Shell-String". Es spiegelt auch echte Schadensbegrenzungsmaßnahmen wider: Flicken Sie die Komponente, reduzieren Sie gefährliche Funktionen und schränken Sie das Verhalten des Interpreters ein. (NVD)
CVE-2021-3156 und die Pwn Lektion versteckt in alltäglichen Argument Parsing
NVD beschreibt CVE-2021-3156 als einen Off-by-One-Fehler in sudoedit -s vor sudo 1.9.5p2, die einen Heap-basierten Pufferüberlauf und eine lokale Privilegienerweiterung zu root verursachen kann. Dies ist ein schöner Lehrfall für pwn-Spieler, weil er von einer normal aussehenden Argumentbehandlung in einem weit verbreiteten Programm herrührt und nicht von einer cartoonhaft kaputten Spielzeug-Binärdatei. (NVD)
Die CTF-Lektion ist, dass sich Speicherverfälschungen oft in Parsing-Logik verstecken, die eher "administrativ" als exotisch ist. Argumentverarbeitung, Escaping, Quoting, Randbedingungen, Längenfelder und modusspezifisches Verhalten sind allesamt erstklassige Orte für Bugs. KI kann hier nützlich sein, wenn man sie mit einem kleinen Patch-Diff, dekompilierter Parserlogik oder Absturzverhalten füttert und sie bittet, zu erklären, welcher Zustandsübergang den Überlauf erreichbar macht. Sie ist weit weniger nützlich, wenn Sie sie bitten, einen endgültigen Exploit allein aus der CVE-Beschreibung zu generieren.
Die Lektion der Schadensbegrenzung ist ebenso wichtig. Die Aktualisierung auf eine korrigierte Version ist die operative Antwort, aber für die Argumentation bei Herausforderungen ist die eigentliche Erkenntnis tiefer: Bei Fehlern mit lokalen Berechtigungen geht es oft um übersehene Übergänge innerhalb vertrauenswürdiger Codepfade. Das macht sie zu einem idealen Material für eine KI-gestützte Erklärung und zu einem schrecklichen Material für eine reine KI-Ausnutzung. Das Modell kann Ihnen helfen, den Grenzfehler zu verstehen. Man braucht aber immer noch einen Menschen, um die Ausnutzung mit Präzision zu erklären. (NVD)
CVE-2024-3094 und warum Reversing-Spieler sich um Build-Pipelines kümmern sollten
CVE-2024-3094 in xz ist für weit mehr CTF-Kategorien relevant, als man zunächst annimmt. NVD sagt, dass bösartiger Code in Upstream-xz-Tarballs ab Version 5.6.0 entdeckt wurde und dass der Erstellungsprozess ein vorgefertigtes Objekt aus einer getarnten Testdatei extrahierte und bestimmte Funktionen in der resultierenden Bibliothek veränderte. In der CISA-Warnung zu diesem Vorfall heißt es, dass der bösartige Code einen nicht autorisierten Zugriff auf die betroffenen SSHD-Instanzen ermöglichen könnte. (NVD)
Dies ist ein Geschenk an die Spieler der Umkehrung und der Forensik. Es lehrt, dass das, worauf man aus Gewohnheit vertraut, nicht unbedingt das ist, worauf man vertrauen sollte. Das Quell-Repository stimmt möglicherweise nicht mit dem Release-Artefakt überein. Die interessante Datei kann als Testdaten gekennzeichnet sein. Der Exploit-Pfad kann während des Builds eingeführt werden, nicht während der offensichtlichen Laufzeitlogik. KI ist in diesem Bereich für den Artefaktvergleich, die Zusammenfassung von Build-Skripten und das Clustering von Anomalien wirklich hilfreich. Sie ist nicht vertrauenswürdig, wenn man sie hässliche Details mit einer glatten Erklärung wegwinken lässt.
Die Lektion über die Schadensbegrenzung lässt sich wiederum eindeutig auf den CTF-Instinkt zurückführen. Provenienz ist wichtig. Artefakte der Veröffentlichung sind wichtig. Reproduzierbarkeit ist wichtig. Wenn eine Herausforderung oder ein echter Vorfall mehrere Darstellungen des "gleichen" Programms enthält, kann die Nichtübereinstimmung selbst der Hinweis sein. Die Gewohnheit, Quellcode, Build und Verhalten zu vergleichen, ist weit über einen einzelnen Fall in der Lieferkette hinaus wertvoll. (NVD)
AI CTF-Praxis in besseres Pentesting verwandeln
Der größte langfristige Wert der KI in CTFs ist nicht die Geschwindigkeit. Es ist die Disziplin. CTFs komprimieren offensives Denken auf einen kurzen Zyklus: beobachten, Hypothesen aufstellen, testen, verifizieren. Wenn die KI Sie bei einem dieser Schritte fauler macht, schadet das. Wenn Sie durch KI systematischer werden, hilft Ihnen das nicht nur bei Wettbewerben, sondern auch bei der echten Testarbeit.
Aus diesem Grund sind die nützlichsten KI-Gewohnheiten in CTFs fast schon langweilig operativ. Speichern Sie das Anfragepaar, das den Fehler bewiesen hat. Speichern Sie die Skriptversion, die endlich funktioniert hat. Speichern Sie den Absturz-Offset und den binären Hash. Speichern Sie das genaue Artefakt, das Ihre Meinung geändert hat. Das sind nicht nur Schreibgewohnheiten. Sie sind der Beginn reproduzierbarer Sicherheitsarbeit, was genau der Standard ist, zu dem NIST und OWASP die Leute in echten Testprogrammen drängen wollen. (NIST-Ressourcenzentrum für Computersicherheit)
Ein Grund dafür, dass sich ein Tool wie Penligent ganz natürlich in diesen Arbeitsablauf einfügen kann, ist die Tatsache, dass das öffentliche Material nicht nur auf den Chat ausgerichtet ist. Auf der Homepage werden bedienergesteuerte agentenbasierte Arbeitsabläufe, prompte Bearbeitung, Umfangskontrollen, breite Toolunterstützung und evidenzbasierte Ergebnisse hervorgehoben, während die Dokumentation den Aufruf installierter Kali-Tools und die Konfiguration von Python- und Bash-Laufzeiten für generierte Skripte beschreibt. In einer CTF-Umgebung löst das die Herausforderungen nicht auf magische Weise. Aber es macht es einfacher, die Teile des KI-Workflows beizubehalten, auf die es in der Praxis ankommt: explizite Grenzen, wiederaufrufbare Skripte und Artefakte, die nicht verschwinden, wenn ein Chatfenster unübersichtlich wird. (Sträflich)
Penligents eigener CTF-KI-Beitrag enthält ebenfalls einen nützlichen architektonischen Hinweis: Trennen Sie Absicht, Planung, Ausführung und Handhabung von Beweisen. Selbst wenn Sie nie genau diesen Stack verwenden, ist die Trennung ein guter Ratschlag. Eine lange KI-Konversation, die Aufgabentext, Solver-Entwürfe, Terminalausgaben, Nutzlast-Experimente und Schlussfolgerungen enthält, wird schnell unüberprüfbar. Die Aufteilung des Arbeitsablaufs in explizite Phasen macht sowohl das Modell als auch den Anwender ehrlicher. (Sträflich)
Die Grundregel ist einfach. Verwenden Sie AI, um die Schleife enger zu machen, nicht unschärfer.
Die besten AI CTF-Spieler überprüfen immer noch alles
Wenn Sie sich einen Satz merken wollen, dann ist es dieser: KI ist in CTFs am besten, wenn sie Ihnen hilft, mehr gute Experimente durchzuführen, nicht wenn sie Ihnen mehr Antworten gibt.
Die aktuelle öffentliche Meinung unterstützt eine ausgewogene Sichtweise. Benchmarks zeigen echte Fortschritte. Modelle können bei strukturierten, offensiven Aufgaben helfen, und einige können den Durchschnitt der Teilnehmer in bestimmten Situationen übertreffen. Gleichzeitig hängt die Leistung weiterhin stark von der Orchestrierung, den Werkzeugen, der Kategorie und dem Bewertungsaufbau ab. Benchmark-Arbeiten auf professioneller Ebene, Anbieterforschung zu Cyber-Evaluierungen und planungsbasierte Pentest-Papiere zeigen alle noch immer Grenzen in Bezug auf weitreichende Kohärenz, spezialisierte Tools und zustandsorientiertes Denken auf. (arXiv)
Das ist keine Enttäuschung. Es ist ein Fahrplan. Bei Web-CTFs soll die KI klassifizieren und vergleichen. Bei Pwns soll sie ein Gerüst erstellen und erklären. Beim Reversing soll sie lokal zusammenfassen. In der Kryptologie soll sie formalisieren und eliminieren. In der Forensik soll sie Beweise bündeln und aus ihnen erzählen. In jeder Kategorie soll es mit einem Artefakt nach dem anderen Vertrauen schaffen.
Die Spieler, die am meisten von der KI profitieren, sind nicht diejenigen, die nach Magie fragen. Sie sind diejenigen, die genau wissen, wo Magie endet und Messung beginnt.
Weitere Lektüre
Für eine sichere, legale Web-Praxis mit starker Abdeckung der Schwachstellen-Klasse bleibt die Web Security Academy von PortSwigger einer der besten Ausgangspunkte. (PortSwigger)
Für umfassendes CTF-Lernmaterial in den Bereichen Web-Exploitation, Kryptografie, Forensik, Binär-Exploitation und Reversing lohnt es sich, die Lernleitfäden und den Primer von picoCTF während der Arbeit offen zu halten. (picoCTF)
Für die Arbeit mit pwn sollten Sie die offiziellen pwntools-Dokumente zur Hand haben, insbesondere die Abschnitte über Prozess- und Remote-Interaktion und den corefile-Workflow. (Pwntools Dokumentation)
Für die symbolische Ausführung und das Lösen von Binärpfaden sind die offiziellen Dokumentationen von angr die richtige Referenz. (Angr Dokumentation)
Für die Umkehrung ist die offizielle Projektseite von Ghidra der maßgebliche Ausgangspunkt. (GitHub)
Für die Arbeit mit Paketen und Speicher sind die offiziellen Dokumentationen von TShark und Volatility 3 die nützlichsten Referenzen für die KI-gestützte Analyse. (Wireshark)
Um Ihre Erwartungen in Bezug auf KI in offensiven Sicherheits-CTFs zu begründen, sind NYU CTF Bench, Cybench und die dazugehörigen öffentlichen Benchmark-Papiere informativer als Social-Media-Demos. (GitHub)
Für die Workflow-Disziplin bei echten Tests sind NIST SP 800-115 und der OWASP Web Security Testing Guide immer noch gültig. (NIST-Ressourcenzentrum für Computersicherheit)
Für Penligent-spezifisches Material, das wirklich relevant für dieses Thema ist, sind die nützlichsten Seiten die Homepage, die Dokumente und der CTF AI Workflow-Artikel über evidenzbasierte Ketten, die Sie wiederholen können. (Sträflich)
German 
English 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew