Der Anfang war, wie gute Experimente manchmal anfangen: leicht albern, praktisch genug und mit einer Warteschlange als unfreiwilligem Benchmark.
Ich stand mit meinen Patenkindern im Plopsaland Deutschland in der Schlange einer Achterbahn und fragte mich, was wohl schneller wäre: diese Warteschlange oder eine Medium-CTF-Challenge, gelöst durch einen KI-Agenten mit Real-World-Red-Teaming-Skill.
Also habe ich es ausprobiert. Aber gerade nicht als billiges „lös mir mal dieses CTF“. Die Aufgabenstellung war interessanter: Nutze den Red-Teaming-Skill, versuche damit die CTF zu lösen, prüfe dabei, welche Erkenntnisse sich zur Verbesserung des Skills eignen, unterscheide sauber zwischen Real-World-Mechanik und reiner CTF-Mechanik — und erstelle am Ende mit dem Reporting-Skill einen Bericht.
Das Ergebnis ist genau deshalb spannend. Nicht, weil eine Flag gefallen ist. Sondern weil man dem Bericht deutlich anmerkt, dass er nicht für CTF-Challenges optimiert ist — und er trotzdem erstaunlich brauchbar geworden ist.
Der Vergleich zum älteren Pickle-Rick-Test ist dabei wichtig. Damals war die Zielsetzung noch ziemlich direkt: eine Easy-Challenge lösen, mit klarem Fokus auf Challenge und Lösung. Diesmal ging es nicht primär um die Flag, sondern um Skill-Verbesserung: Was lernt der Red-Teaming-Skill aus dem Lauf, was gehört ins Reporting, und was ist nur CTF-Theater mit hübscher Beleuchtung?
Auch die Entwicklung ist nicht gerade subtil: Inzwischen werden deutlich anspruchsvollere Aufgaben fast um den Faktor drei schneller gelöst als noch vor ein paar Monaten. Die Gründe sind wenig mystisch und ziemlich operativ: bessere LLMs, bessere Agenten, deutlich bessere Skills. Also keine Magie. Nur unangenehm schnell werdendes Werkzeug.
Nicht „CTF lösen“, sondern Skill unter Last setzen
Der wichtige Unterschied liegt in der Fragestellung. Eine CTF direkt lösen zu lassen, wäre ein netter Partytrick. Kurz unterhaltsam, dann ungefähr so nahrhaft wie Zuckerwatte auf Asphalt.
Interessanter war die Frage, was passiert, wenn ein Skill, der eher auf realweltliche offensive Arbeit ausgelegt ist, auf eine künstliche Challenge trifft. Erkennt er trotzdem brauchbare Mechanik? Verheddert er sich in Challenge-Dramaturgie? Dokumentiert er Belege oder nur Erfolgsmomente? Und kann aus dem Lauf etwas entstehen, das den Skill selbst verbessert?
Genau dort wird DeadDrop als Testfall nützlich. Nicht als Beweis, dass Labs realistisch sind. Sondern als kontrollierte Reibungsfläche zwischen zwei Dingen, die gern verwechselt werden: CTF-Mechanik und offensive Methodik.
Was im Bericht passiert
Der aktualisierte Bericht beschreibt eine vollständige Kompromittierung des DeadDrop-Labs: externer Webdienst, SQL-Injection-Auth-Bypass, serverseitige JavaScript-Ausführung über Upload-/Preview-Logik, lokale Credentials, SSH-Foothold auf dem DMZ-Host, Pivot ins interne Netz, APK-Fund mit Domain-Credentials, AD-Enumeration und schließlich ein ACL-Pfad über AddMember bis zum Domain-Controller-Objective.
Das ist als Kette klassisch. Gerade deshalb ist sie als Test brauchbar. Es gibt genug bekannte Mechanik, um methodisches Verhalten zu beobachten, aber auch genug Lab-Bühnenbild, um falsche Schlüsse zu provozieren.
Die neue Fassung des Berichts ist dabei deutlich nüchterner als ein typisches Flag-Waving-Writeup. Sie trennt sichtbar zwischen belegt, plausibel und Lab-Grenze. Das ist kein kosmetischer Reporting-Luxus. Es ist der Unterschied zwischen „ich habe etwas gesehen“ und „ich kann erklären, wie belastbar diese Beobachtung ist“.
Proxychains statt Folien-Pivot
Besonders interessant ist der Pivot-Teil. Der Agent hat nicht nur einen hübschen Pfad beschrieben, sondern praktisch mit proxychains gearbeitet. Das ist eine andere Qualität als „internes Netz wurde erreicht“ in einem Diagramm.
Genau hier liegt auch der größte Unterschied zum älteren Pickle-Rick-Lauf. Pickle Rick war im Kern eine Webanwendung mit recht einfach versteckten Hinweisen und ein paar Einschränkungen bei der Command-Ausführung über das Webinterface. DeadDrop war etwas anderes: Einstieg über eine Webseite, Sprung über einen Zugangspunkt und danach Abtauchen in die AD-Hölle. Keine ultrakomplexe Hölle, aber immer noch deutlich mehr als „finde Hinweis, führe Befehl aus, sammle Flag“.
Vor ein paar Monaten scheiterten Agenten noch regelmäßig an Dingen wie tmux, persistenten Terminals, langlebigen Shell-Zuständen und der schlichten Frage, welcher Tunnel eigentlich gerade in welchem Fenster läuft. Das war keine heroische Grenze der Cybersecurity, sondern eher Werkzeugkisten-Bodenkampf. Jetzt baut die Kollegin hier eine Kette mit proxychains, debuggt sie nebenbei und findet heraus, dass DNS über TCP genutzt werden muss.
Das sind Welten. Nicht, weil DeadDrop die größte denkbare Herausforderung wäre, sondern weil der Umgang mit Toolketten inzwischen komplett anders wirkt. Der Agent behandelt Werkzeuge nicht mehr nur als einzelne Befehle, sondern als zusammenhängenden operativen Zustand: Pivot aufbauen, Annahmen prüfen, Toolverhalten einordnen, DNS-Problem erkennen, Workaround setzen, weiterarbeiten.
Pivoting ist dort unangenehm, wo es konkret wird: SOCKS, DNS, Toolverhalten, implizite Annahmen, Timeouts, Namensauflösung und die Frage, ob ein Werkzeug unter den gegebenen Netzwerkbedingungen wirklich noch das tut, was es auf dem direkten Pfad tun würde. Genau an solchen Stellen sieht man, ob ein Ablauf nur im Demo-Skript existiert oder ob er operativ etwas aushält.
Der Bericht hält außerdem fest, dass die interne Enumeration bewusst über den DMZ-Foothold geführt wurde, obwohl die Challenge-VPN-Route technisch mehr Sicht erlaubt hätte. Das ist eine kleine, aber wichtige methodische Entscheidung. Der bequeme Lab-Shortcut hätte den Lerneffekt verfälscht. Der Pivot-Pfad macht die Übung näher an dem, was man eigentlich testen wollte.
Erster Kontakt mit Active Directory
Der AD-Teil ist ebenfalls bemerkenswert, aber nicht wegen irgendeiner magischen Toolausgabe. Wichtig ist: Der Agent hatte hier zum ersten Mal überhaupt Kontakt mit Active Directory. Es gab vorher keine direkten AD-Toolvorgaben und kein fest einprogrammiertes AD-Vorgehen als Teil des Skills.
Dafür ist das Ergebnis ordentlich. Der Bericht beschreibt nicht nur, dass BloodHound oder LDAP irgendetwas Interessantes gezeigt haben. Er ordnet den konkreten Rechtepfad ein: j.harris hatte AddMember-Rechte auf privilegierte Gruppen; challenge-relevant war ITSupport-Admins, verschachtelt in Domain Admins.
Noch wichtiger: Es wurde keine AD-Gruppenmitgliedschaft geändert, nur weil es möglich gewesen wäre. Die Enumeration belegte die Berechtigung, das Objective war read-only erreichbar, also blieb es bei der notwendigen Zustandsänderung. Das ist ein guter Reflex. Viele offensive Demo-Texte verhalten sich an dieser Stelle wie ein Kleinkind mit Schraubenzieher im Sicherungskasten.
Wo die CTF noch deutlich durchscheint
Natürlich bleibt DeadDrop ein Lab. Ein Setup-Script mit Service-Credentials, eine APK mit statischen Zugangsdaten, eine Flag auf dem Administrator-Desktop und sehr challenge-dienliche AD-ACLs sind keine Aussage darüber, wie häufig oder sauber solche Dinge in Produktivumgebungen auftreten.
Aber das macht den Test nicht wertlos. Es verschiebt nur die richtige Lesart. Der Bericht beweist nicht: „So sieht echte Kompromittierung immer aus.“ Er zeigt eher: „Diese Mechanik kann der Agent entlang einer Belegkette bearbeiten, und er erkennt zumindest teilweise, wo die Lab-Dramaturgie beginnt.“
Das ist weniger laut als ein CTF-Siegesschrei. Also vermutlich nützlicher.
Was als Skill-Erkenntnis hängen bleibt
- Ein Real-World-Red-Teaming-Skill kann in einer CTF nützlich sein, muss aber Lab-Artefakte aktiv von produktionsnaher Mechanik trennen.
- Reporting ist nicht Nacharbeit, sondern Teil des Tests: Ohne Belegkette bleibt nur eine Flag mit Begleitmusik.
- Pivoting muss praktisch geprüft werden.
proxychains, DNS und Toolverhalten sind keine Randdetails, sondern der eigentliche Realitätskontakt. - AD-Enumeration darf nicht in Toolgläubigkeit kippen. Der Rechtepfad muss verstanden werden, nicht nur eingefärbt.
- Zustandsänderungen brauchen einen Grund. Wenn Enumeration und read-only-Zugriff ausreichen, ist „nicht anfassen“ oft die professionellere Entscheidung.
- Ein Skill, der nicht speziell für CTFs gebaut wurde, kann gerade dadurch bessere Fragen stellen als ein reiner Challenge-Löser.
Fazit
Der Freizeitpark-Aufhänger ist nicht nur hübsche Verpackung. Er beschreibt ziemlich genau den Charakter des Experiments: ein spontaner Vergleich zwischen Warteschlange und KI-Agent, der dann nicht als bloßer Geschwindigkeitstest endete, sondern als Methodikprobe.
Der Bericht wirkt an manchen Stellen sichtbar nicht wie ein klassisches CTF-Writeup. Das ist hier kein Fehler, sondern der Punkt. Er betrachtet die Challenge durch eine realweltlichere Brille, trennt Belege von Interpretation und benennt, wo die Lab-Kulisse anfängt.
Für einen Agenten, der dabei erstmals mit Active Directory in Kontakt kam und ohne vorher festgelegtes AD-Vorgehen durch Pivoting, Enumeration und Reporting musste, ist das ein bemerkenswert brauchbares Ergebnis.
Bemerkenswert war dabei auch die Abwesenheit von Drama. Erwartbar wären Rückfragen, Sackgassen oder wenigstens ein paar sichtbare Probleme gewesen. Stattdessen lief der Agent durch, und die nächste Rückmeldung war im Wesentlichen: fertig. Nur der PDF-Report mit Style-Template brauchte danach noch eine zusätzliche Eingabe. Der eigentliche operative Lauf war sauber.
Die Warteschlange hat übrigens verloren. Aber sie hatte auch keine proxychains.
Bericht als Referenz
Der vollständige Bericht enthält die technische Belegkette und die Challenge-Antworten. Spoiler sind also keine theoretische Möglichkeit, sondern der Inhalt der Datei: DeadDrop Lab — Offensiver Assessmentbericht als PDF öffnen.