CTF-Training mit KI-Coach: erklärt statt verweigert

Capture-the-Flag-Challenges sind der Ort, an dem die meisten Security-Leute ihr Handwerk lernen. Am schnellsten wirst du besser mit einem geduldigen Coach, der weiß, wann er einen Hinweis geben und wann er schweigen sollte. Gängige Assistenten sind dafür schlechte Coaches: Frag, wie ein Padding Oracle auf einer CTF-Box funktioniert, und du bekommst oft eine Belehrung über unbefugten Zugriff statt einer Erklärung. Odin v1 beantwortet die Frage, sodass du deine Zeit mit Lernen verbringst statt mit Umformulieren.

Dieser Beitrag zeigt einen Workflow, mit dem du Odin v1 als Coach auf CTF-Plattformen und in Übungslabs wie picoCTF, Hack The Box, TryHackMe oder deinem eigenen Docker-Lab einsetzt. Alles hier gilt für Ziele, die du angreifen darfst: die Challenge-Infrastruktur, ein Lab, das du selbst gebaut hast, oder eine Maschine, die bei einem Event im Scope liegt. An dieser Regel ändert sich nichts.

Warum ein Coach besser ist als ein Löser

Du könntest eine Challenge einfügen und nach der Flag fragen. Dabei würdest du nichts lernen, und auf vielen Plattformen verstößt das Teilen oder Anfragen von Lösungen für laufende Challenges gegen die Regeln. Der Wert eines CTF liegt im Denken, das du dir aufbaust: den seltsamen Header bemerken, eine schwache Chiffre erkennen, wissen, zu welchem Tool du greifen musst. Ein guter Coach schützt genau das.

Das Setup unten leistet deshalb zwei Dinge:

• Es weist das Modell an, zu lehren statt zu lösen, es sei denn, du fragst ausdrücklich nach der vollständigen Antwort.
• Es strukturiert die Hilfe als Leiter, vom kleinen Anstoß bis zur vollständigen Erklärung, sodass du selbst entscheidest, wie viel du verrätst.

Die Hinweis-Leiter

Legt die Stufen vorab fest. Das Modell antwortet dann auf der Stufe, die du anforderst, und springt nie voraus.

Stufe 4 ist für die Zeit nach dem Event oder für retired Boxes gedacht. Bleib während eines laufenden Wettbewerbs bei den Stufen 1 bis 3 und halte dich an die Event-Regeln zu externer Hilfe.

Ein System-Prompt fürs Coaching

Leg die Regeln in einen System-Prompt, damit jede Antwort sie befolgt. Das funktioniert mit jedem OpenAI-kompatiblen Client:

import osfrom openai import OpenAI
client = OpenAI(base_url="https://api.interodin.com/v1", api_key=os.environ["INTERODIN_API_KEY"])
COACH = """You are a CTF coach. The user works on legal practice targets: CTF challenges and their own labs.Answer at the hint level the user asks for (1 nudge, 2 concept, 3 method, 4 walkthrough).Never go above the requested level. If no level is given, use level 1.Explain the reasoning behind every hint, and suggest one thing the user can try next and what result would confirm it."""
history = [{"role": "system", "content": COACH}]
def ask(level: int, text: str) -> str:    history.append({"role": "user", "content": f"[level {level}] {text}"})    resp = client.chat.completions.create(model="odin-v1", messages=history)    answer = resp.choices[0].message.content    history.append({"role": "assistant", "content": answer})    return answer
print(ask(1, "Web challenge: a login form. Wrong passwords say 'invalid', but a quote in the username gives a 500 error."))

Weil der Verlauf erhalten bleibt, erinnert sich der Coach daran, was du schon probiert hast, und der nächste Hinweis baut darauf auf, statt Grundlagen zu wiederholen.

Web-Challenges

Mit Web fangen die meisten an. Ein typischer Austausch bei einer Login-Challenge für Einsteiger läuft so:

• Stufe 1: Der Coach fragt, warum ein einfaches Anführungszeichen das Verhalten des Servers verändern könnte und welche Art von Code Benutzereingaben in etwas verwandelt, das an einem Anführungszeichen zerbricht.
• Stufe 2: Er benennt die Klasse, SQL-Injection, und erklärt, wie nicht parametrisierte Queries Daten und Code vermischen.
• Stufe 3: Er beschreibt, wie du sie im Lab gefahrlos bestätigst: Antworten für wahre und falsche Bedingungen vergleichen, die Anzahl der Spalten ermitteln und dann die Datenbank-Engine anhand von Fehlermeldungen oder Verhalten identifizieren.

Lass dir auch den Fix erklären. Wenn du aufschreibst, warum eine parametrisierte Query die Lücke schließt, wird aus einer Flag Wissen, das du am Montag im Code-Review nutzen kannst.

Weitere Web-Themen, die Odin v1 gut erklärt: Server-Side Request Forgery, unsichere Deserialisierung, JWT-Fehler (alg-Verwechslung, schwache Secrets), Path Traversal und Template Injection. Bei jedem davon ist die Anschlussfrage „Wie würde ich das in meinen eigenen Logs erkennen?“ hilfreich. Der Beitrag zu Detection-Regeln geht darauf näher ein.

Crypto-Challenges

Bei CTF-Crypto geht es meist darum, den Fehler zu finden: eine wiederverwendete Nonce, ein kleiner Exponent, ECB-Modus, eine selbst gebastelte Chiffre. Füge den Quellcode der Challenge und die Ausgabe ein und arbeite dich dann die Leiter hinauf.

Gute Prompts:

• „Stufe 2: Hier ist das Verschlüsselungsskript. Welche Eigenschaft dieser Konstruktion sollte mich misstrauisch machen?“
• „Stufe 3: Ich glaube, der RSA-Exponent ist klein und die Nachricht kurz. Erklär mir Schritt für Schritt, warum das wichtig ist und wie ich es prüfe.“
• „Erklär die Mathematik hinter diesem Angriff an einem Spielzeugbeispiel, das ich von Hand nachrechnen kann.“

Der letzte ist der wertvollste. Lass dir kleine Zahlen geben, prüf sie in einer Python-Shell, und du verstehst den Angriff für immer.

Reversing

Füge beim Reversing Disassembly oder Decompiler-Ausgabe ein (Odin akzeptiert Text, keine Binärdateien oder Screenshots). Nützliche Anfragen:

• „Erklär Zeile für Zeile, was diese Funktion macht, und benenne die Variablen sinnvoll um.“
• „Welcher Vergleich entscheidet, ob die Eingabe akzeptiert wird?“
• „Diese Schleife sieht nach einem eigenen Hash aus. Was bräuchte ich, um ihn umzukehren?“

Mit einem Kontextfenster von 1.000.000 Tokens kann odin-v1 ein großes dekompiliertes Listing in einer Nachricht aufnehmen und so Aufrufe über Funktionen hinweg verfolgen, statt aus einem Fragment zu raten.

Forensik

Forensik-Challenges geben dir einen Packet Capture, ein Speicherabbild oder ein Disk-Image. Odin kann diese Dateien nicht direkt öffnen, liest aber Tool-Ausgaben sehr gut. Führe die Tools selbst aus und füge dann den Text ein:

• tshark-Zusammenfassungen von Conversations oder Listen von HTTP-Objekten
• volatility-Prozesslisten und Kommandozeilen
• strings-Ausgabe, Dateimetadaten, Timeline-Einträge

Frag dann: „Stufe 1: Was fällt hier auf?“ Das Modell zeigt dir den seltsamen Elternprozess, den Base64-Blob in einer DNS-Anfrage oder den User-Agent, der nicht dazugehört. Einen genaueren Blick auf die Triage verdächtiger Skripte wirft der Beitrag zur Malware-Analyse.

Den Writeup schreiben

Im Writeup setzt sich das Gelernte fest, und er ist gute Übung für spätere Berichte. Wenn du eine Challenge gelöst hast, gib Odin deine Notizen und bitte um einen Writeup-Entwurf mit diesen Abschnitten: Zusammenfassung, Recon, die Schwachstelle, die Exploitation-Schritte, die Flag (geschwärzt, falls das Event das verlangt) und wie man sie behebt. Überarbeite ihn dann in deinen eigenen Worten.

Diese Fähigkeit überträgt sich direkt auf die professionelle Arbeit. Der Beitrag zum Schreiben von Pentest-Berichten zeigt, wie aus Projektnotizen ein Bericht wird, den du dem Kunden übergeben kannst.

Praktische Tipps

• Nutze odin-flash für schnelle Fragen. Nachschlagefragen wie „Was macht dieser tshark-Filter?“ brauchen nicht das größere Modell. Wechsle für langen Code oder mehrstufiges Denken zu odin-v1.
• Setz ein monatliches Ausgabenlimit auf den Key, den du zum Üben nutzt, damit dich ein langes Lab-Wochenende nie überrascht.
• Führe eine Notizdatei. Füge deine Notizen zu Beginn einer neuen Session wieder ein, damit der Coach dort weitermacht, wo du aufgehört hast.
• Prüfe alles. Das Modell kann sich irren. Bestätige jeden Hinweis am Ziel, bevor du darauf aufbaust.

Loslegen

Erstelle einen API-Key in der Konsole und folge dann dem Quickstart, um deinen ersten Request zu senden. Übe auf CTF-Plattformen und in deinen eigenen Labs, halte dich an die Event-Regeln und bleib innerhalb der Acceptable Use Policy.