Die Flotte, die sich selbst widerlegt hat

TL;DR: Ein Bug-Bounty-Ziel mit sechzehn Domains, ein sauberer erster Durchgang und drei Hypothesen, die nach Geld aussahen. Also liefen 55 Agenten-Einheiten in vier Wellen dagegen — jede Einheit ein Startpunkt auf einer gemeinsamen Karte, Befunde mit Hash in einem Ledger, ein Vorsitz-Agent entscheidet nach jeder Welle, was als nächstes geprüft wird. Die Tiefen-Einheiten haben alle drei Spuren getötet. Das hier ist, wie die Orchestrierung funktioniert — und warum die ehrliche Antwort mehr wert war als eine Einreichung.

Die Ausgangslage

Der erste Durchgang über das Ziel war unspektakulär, auf die Art, wie gute Technik meistens ist: Komponenten auf Patchstand, gehärtete Fehlerseiten, Authentifizierung auf jeder API, die zählte, und vier Befunde, die eigentlich Hygienenotizen waren. Die Regeln des Programms schließen genau diese Klasse aus — der Bericht war also wenig wert.

Aber es gab drei Fäden, die echt hätten sein können:

1. Eine Wiki-Engine, deren Version über „in Ordnung" oder „unauthisierte Remote-Code-Execution" entscheidet.
2. Ein CMS mit RCE-Historie — und einer öffentlichen CVE, deren betroffener Bereich aus unserer Sicht passen konnte.
3. Ein vergessenes VPN-Gerät auf einem Hostnamen, der nicht mehr auflöst, aber auf der gemeinsamen Edge weiter antwortet.

Jeder davon brauchte Evidenz, keine Intuition. Und jeder brauchte eine andere Art von Evidenz: eine Version, einen Patchstand, einen Build-String. Genau solche Arbeit lässt sich schlecht in einem Thread und gut über viele verteilen.

Die Flotte

Fünfundfünfzig Einheiten, vier Wellen, fünf gleichzeitig:

Welle 1 ist Breite: eine Einheit pro Domain plus vier Querschnitt-Sweeps für DNS und Mail, TLS und Certificate Transparency, Transport-Header und die Exposure-Klassiker. Welle 2 ist Tiefe nach Klasse: API-Fläche, CORS, ausgeliefertes JavaScript, Consent und Tracking, Lieferkette, Versions-zu-CVE-Abgleich. Welle 3 ist die Hypothesen-Schicht — eine Einheit pro Technologiefamilie, jede mit einer konkreten Behauptung zum Bestätigen oder Töten. Welle 4 ist gegnerisch: Repro-Verifizierer, Falsch-positiv-Killer, CVSS-Kalibrierer, Chain-Builder und eine Einheit für Evidenz-Integrität.

Jede Einheit schreibt denselben Vertrag: ein JSON-Objekt pro Befund, mit Zeitstempel, Schweregrad, Kategorie, Konfidenz, einem Beweisartefakt, einem SHA-256, einem einzigen Repro-Befehl, einem Impact-Satz und einem Fix-Satz. Kein Artefakt, kein Befund. Eine Vermutung ist erlaubt, muss aber als Hypothese gekennzeichnet sein und mitliefern, was sie bestätigen würde.

Die Karte ist das gemeinsame Gedächtnis

Agenten reden nicht miteinander. Sie reden mit einer Datei. Einheiten-Identität, Befund und die folgende Entscheidung werden zu Knoten und Kanten in einem Mermaid-Graph, der nach jeder Welle neu erzeugt wird:

• Einheiten farbcodiert nach Zustand — queued, running, done, failed
• Befunde hängen an der Einheit, die sie erzeugt hat, gefärbt nach Schweregrad
• Meetings als Knoten mit gepunkteten „reports"-Kanten von jeder beitragenden Einheit
• Entscheidungen als beschriftete Kanten des Vorsitzenden — was als nächstes läuft und warum

Nach Welle 1 zeigte die Karte 45 Befunde, eine echte Spur und eine Reihe unbeantworteter Fragen. Die Entscheidungskanten des Vorsitzenden zeigten dann auf die Einheiten, die diese Fragen beantworten konnten. Das ist der ganze Orchestrierungs-Trick: Die Karte ist kein Bild der Arbeit, sie ist die Arbeitsliste.

Drei Spuren, drei Urteile

Die Wiki-Engine: gepatcht. Die Version war lesbar, der CVE-Abgleich eindeutig — und sie lag exakt auf der Fixversion, aktuelle LTS. Kein Befund, Thread geschlossen. Das hat eine Einheit zehn Minuten gekostet.

Das CMS: Patch-Lag, aber die Tür fehlt. Das ist der interessante Fall, weil die Version nirgends veröffentlicht war. Also hat die Einheit sie deterministisch gefingerprintet: öffentliche Bundle-Assets hashen, mit den offiziellen Release-Tarballs vergleichen und Datei-Mtimes als Tiebreaker nehmen, wenn zwei Releases identische Dateien ausliefern. Das hat den Kern auf einen acht Monate alten Build festgenagelt — innerhalb des betroffenen Bereichs einer kritischen RCE.

Dann die zweite Frage: Ist die verwundbare Route überhaupt ausgerollt? Der Angriffspfad der CVE verlangt eine Komponente, die auf der Instanz nicht existierte — der Endpunkt antwortete mit dem generischen 404 des Frameworks. Das Urteil lautete also Patch-Lag, nicht ausnutzbar: ein mittlerer Befund mit klarem Fix, kein Notfall.

Das Edge-Gerät: keine Version, keine Zuordnung. Das vergessene VPN-Gerät antwortete auf der gemeinsamen Origin, präsentierte ein abgelaufenes Fabrikzertifikat und verriet auf keiner erreichbaren Fläche etwas über seine Firmware. Ohne Build-String gibt es kein Advisory zum Abgleichen — die ehrliche Klassifikation blieb Exposure: unverwaltete Infrastruktur, keine CVE.

Zwei weitere Falsifikationen kamen aus derselben Schicht. Ein serverseitiger URL-Proxy im ausgelieferten Bundle sah aus wie ein SSRF-Primitiv; die Verifikationseinheit testete ihn nur mit einem Self-Fetch, nie gegen Dritte, und verwarf ihn — kein anonymer Abruf. Und ein alter DNS-Eintrag auf einer reallokierbaren Cloud-Adresse — klassische Takeover-Form — entpuppte sich als provider-verwaltete Elastic-Adresse ohne Übernahmemöglichkeit; die Einheit dokumentierte den sicheren Prüfweg für den Eigentümer und schloss die Hypothese.

Die Verifikationsschicht ist nicht optional

Zwei Dinge aus Welle 4 haben meine Meinung über solche Flotten geändert.

Der Falsch-positiv-Killer hat jeden behaupteten Befund nachgeprüft und zwei verworfen — darunter einen, bei dem das Beweisartefakt nicht zeigte, was die Zusammenfassung behauptete. Das ist der Fehlermodus paralleler Arbeit: eine selbstsichere Zusammenfassung, die ihrer eigenen Evidenz davonläuft.

Die Evidenz-Integritäts-Einheit hat alle 160 Ledger-Zeilen neu gehasht, geprüft, dass jeder Artefaktpfad existiert, der SHA-256 passt und der Repro-Befehl noch läuft. Sie hat die Zeilen markiert, deren Repro einen Arbeitsverzeichnis-Hinweis braucht, und die drei Zeilen, die Hypothesen statt Bestätigungen waren. Zwanzig Minuten Arbeit, die einen Haufen Behauptungen in etwas Prüfbares verwandelt.

Warum das negative Ergebnis das Ergebnis ist

Der Lauf endete mit 160 Befunden: 4 hoch, 16 mittel und rund 140 niedrig und informativ. Von den hohen hat keiner die Verifikation zu einem CVSS 7+ mit Proof of Concept überlebt. Von den drei Spuren, die die ganze Übung motiviert haben, sind alle drei unter der Evidenz gestorben.

Das ist kein Scheitern. Die Regeln des Programms schließen unverifizierte Hypothesen, Header-und-SSL-Best-Practice und Befunde ohne PoC aus — die drei Spuren einzureichen wäre also bestenfalls Rauschen und schlimmstenfalls Reputationsschaden gewesen. Was die Flotte gekauft hat, ist Gewissheit: eine geschriebene, gehashte, reproduzierbare Antwort auf „diese Route existiert in diesem Deployment nicht" und „für diesen Build findet sich kein passendes Advisory".

Die vier mittleren Befunde, die bleiben, sind ehrliche Arbeit: Patch-Lag bei einem CMS-Build, SPF- und DMARC-Lücken auf Subdomains, die Spoofing leicht machen, ein Drittanbieter-Ticketing-Iframe vor der Einwilligung und ein Analytics-Collector, der jeden Origin mit Credentials reflektiert.

Was ich beim nächsten Mal anders mache

• Welle-4-Einheiten von Anfang an einplanen. Verifikation ist, wo der Wert sitzt — ich habe sie spät ergänzt.
• Jeder Hypothesen-Einheit ein Kill-Kriterium in den Prompt geben. „Bestätigen oder ausschließen, und sag welches" erzeugt schärfere Arbeit als „untersuchen".
• Das Ledger als einzige Schnittstelle behalten. In dem Moment, in dem zwei Agenten über etwas anderes koordinieren, ist die Karte nicht mehr die Wahrheit.
• Erwarten, dass die Karte nach außen zeigt. Die nützlichsten Entscheidungskanten in diesem Lauf waren die, die Zweige geschlossen haben — nicht die, die welche geöffnet haben.

Fazit

• Eine Flotte ist eine Warteschlange und ein Ledger, keine Konversation — die gemeinsame Karte macht parallele Arbeit prüfbar.
• Versions-zu-CVE-Arbeit braucht einen exakten Build; Hash-und-Mtime-Fingerprinting schlägt Raten, wenn der Hersteller nichts veröffentlicht.
• Teste den Angriffspfad, nicht die Version: ein verwundbarer Build mit fehlender Route ist Patch-Lag, kein Einbruch.
• Verifikations-Einheiten (Repro, Falsch-Positive, Evidenz-Integrität) unterscheiden einen Bericht von einem Haufen Behauptungen.
• Ein rigoroses negatives Ergebnis ist ein Deliverable. Als Rauschen eingereicht würde es Glaubwürdigkeit verbrennen, die viel schwerer wiederaufzubauen ist, als 160 Befunde zu sammeln.