Kurz gesagt. Exportieren Sie das Audit-Log als JSON (dazu Git-Events und Actions-Protokollarchive, falls vorhanden) und legen Sie alles im Werkzeug GitHub Forensics ab. Die Analyse läuft in Ihrem Browser, nichts wird hochgeladen. Lesen Sie zuerst das Urteil und die Hinweise zur Abdeckung, sichten Sie dann die Befunde nach Schweregrad, pivotieren Sie nach dem verdächtigen Token oder der verdächtigen IP-Adresse, prüfen Sie die Zeitleiste und arbeiten Sie die Liste der Maßnahmen ab. Planen Sie für einen ersten Durchgang bei einer typischen Organisation etwa 30 Minuten ein.

Dies ist die praktische Anleitung zum Analyzer auf dieser Website. Sie setzt voraus, dass Sie die Dateien bereits haben. Falls nicht, beginnen Sie mit GitHub-Audit-Log exportieren.

Schritt 1: Exporte zusammentragen

Das Minimum ist das Audit-Log der Organisation als JSON. Jede zusätzliche Quelle schließt einen blinden Fleck:

Sie ergänzen	Sie erhalten
IP-Adressen, vor dem Export aktiviert	Erkennung neuer IP-Adressen und neuer Länder pro Token und pro Akteur
Git-Events (`include=all`, Enterprise-Export oder Streaming)	Erkennung von Massen-Klonen (Häufungen von `git.clone`)
Protokollarchive verdächtiger Actions-Läufe	Secrets, die ein Workflow-Schritt kodiert oder verschickt
Secret-Scanning-Warnungen (REST-JSON)	geleakte Zugangsdaten und den nächsten Schritt in der Cloud

Exportieren Sie zusätzlich einige Wochen vor dem vermuteten Einbruch. Die Regeln für „neues Land“ und „neue IP-Adresse“ vergleichen jedes Token mit seiner eigenen Vorgeschichte und brauchen davon mindestens 24 Stunden.

Schritt 2: Dateien ablegen

Legen Sie einzelne Dateien, ganze Ordner oder ZIPs (bis zu drei Ebenen verschachtelt) im Werkzeug ab. Das Format wird am Inhalt erkannt, nicht am Dateinamen. Das Werkzeug akzeptiert die JSON-/CSV-Exporte aus der Oberfläche, REST-Seiten, Streaming-Dateien .json.log.gz, den Git-Events-Export export-*.json.gz, ZIPs aus „Download log archive“ in Actions und JSON mit Secret-Scanning-Warnungen.

Die Dateien werden in Blöcken von 4 MB gelesen, und gzip wird on the fly entpackt. Auch Streaming-Dumps mit mehreren Gigabyte funktionieren daher, ohne dass alles in den Arbeitsspeicher geladen wird. Jede übersprungene Datei wird mit Begründung aufgelistet („unbekanntes Format“, „Datei endet mitten in einem Datensatz“, „Datensätze sind keine Audit-Ereignisse“). Lesen Sie diese Liste. Ein abgeschnittener Export ist ein häufiger Grund für ein unauffälliges Ergebnis.

Wenn Sie die Ausgabe sehen möchten, bevor Sie eigene Daten verwenden, klicken Sie auf Beispiel testen. Das lädt einen deutlich gekennzeichneten fiktiven Vorfall, der in der Fallstudie northwind-labs analysiert wird.

Schritt 3: Urteil und Hinweise zur Abdeckung lesen

Das Banner zeigt eines von drei Urteilen. Die Logik ist in der Regeldatei und auf der Seite des Werkzeugs veröffentlicht:

Kompromittiert: mindestens ein kritischer Befund (zum Beispiel ein Workflow-Schritt, der Secrets kodiert) oder zwei oder mehr verschiedene Regeln mit hohem Schweregrad für denselben Akteur, dasselbe Token oder dieselbe IP-Adresse.
Verdächtige Aktivität: mindestens ein Befund mit hohem oder mittlerem Schweregrad.
Keine Anzeichen einer Kompromittierung: nichts oberhalb von niedrig.

Unter dem Banner listet Warum die Befunde auf, die zum Urteil geführt haben, und Abgedeckter Zeitraum zeigt den ersten und den letzten Zeitstempel. Prüfen Sie, ob der Zeitraum das Fenster enthält, das Sie interessiert.

Lesen Sie anschließend die Hinweise zur Abdeckung. Sie sagen Ihnen, was das Urteil nicht sehen konnte: keine IP-Adressen, keine Git-Events, keine Token-Metadaten (hashed_token), keine Workflow-Lauf-Ereignisse oder eine abgeschnittene Tabelle. „Keine Anzeichen einer Kompromittierung“ zusammen mit „Keine Git-Events“ bedeutet, dass Massen-Klonen nicht geprüft wurde – nicht, dass es nicht stattgefunden hat.

Schritt 4: Befunde sichten

Die Befunde sind nach Schweregrad sortiert. Jeder zeigt die Regel, ihre ATT&CK-Techniken, den ersten und letzten Zeitpunkt, die Anzahl (bei Schwellenwertregeln auch die Anzahl verschiedener Werte), die beteiligten Entitäten und die Beweiszeilen.

Sichten Sie Frage für Frage:

Ist der Akteur zu erwarten? Ein Owner, der während der Bürozeiten den Branch-Schutz ändert, ist normal. Dieselbe Änderung um 3 Uhr nachts mit einem Token von einem VPS ist es nicht.
Sind es die üblichen Zugangsdaten? Vergleichen Sie hashed_token, programmatic_access_type und user_agent mit den übrigen Ereignissen des Akteurs. curl/8.x, wo der Entwickler normalerweise git/2.x verwendet, ist ein starkes Signal.
Passt es zu anderen Befunden? Ein einzelnes token-new-ip ist oft ein Laptop im Hotel-WLAN. Löst dasselbe Token zusätzlich git-clone-burst aus, ist es ein Vorfall.

Manche Regeln sind von Natur aus laut. workflow-new-branch schlägt beim ersten Lauf jedes Feature-Branches an, und actions-secret-created bei routinemäßiger CI-Arbeit. Deshalb sind sie als niedrig eingestuft. Relevant werden sie, wenn sie einen Akteur betreffen, den andere Befunde bereits markiert haben.

Schritt 5: nach Entitäten pivotieren

Der Tab Entitäten listet Akteure, Tokens (per Hash), IP-Adressen, Repositories, Workflows, Runner und Apps auf. Mit Ereignisse zeigen filtern Sie bei jedem Eintrag die Ereignistabelle.

Der nützlichste Pivot ist das Token. Sobald Sie entschieden haben, dass ein hashed_token gestohlen ist, gilt jedes Ereignis mit diesem Hash bis zum Beweis des Gegenteils als Aktivität des Angreifers – auch Ereignisse, die keine Regel ausgelöst haben. Pivotieren Sie dann nach der IP-Adresse des Angreifers, um weitere Zugangsdaten zu finden, die vom selben Ort aus verwendet wurden. Das Playbook zu geleakten Tokens zeigt, wie Sie einen Hash einem realen Token zuordnen.

Der Tab Ereignisse bietet Freitextsuche (Aktion, Akteur, IP, Repository, beliebiges Feld), Kategoriefilter, einen Schalter Nur markierte sowie die Anzeige in UTC oder Ortszeit. Klicken Sie auf eine Zeile, um alle ihre Felder zu sehen und welche Regeln sie zitieren.

Schritt 6: Zeitleiste lesen, Maßnahmen umsetzen, exportieren

Die Zeitleiste mit „Nur Befunde“ liefert den Hergang des Vorfalls in chronologischer Reihenfolge. Zusammengefasste Zeilen (zum Beispiel 38 Klonvorgänge) halten sie lesbar. Schalten Sie den Filter aus, um die Kontextereignisse drumherum zu sehen: Änderungen an Mitgliedschaften, SAML-Aktualisierungen, Runner-Registrierungen.

Der Tab Maßnahmen ist eine nach Dringlichkeit sortierte Checkliste, abgeleitet aus den Regeln, die angeschlagen haben. Sie beginnt immer mit der Beweissicherung und behandelt dann den Widerruf von Tokens, die Rotation von Actions-Secrets und Cloud-Schlüsseln, das Entfernen von Persistenz und das Wiederherstellen von Schutzmaßnahmen. Die Häkchen werden nur auf der Seite gespeichert.

Zum Schluss exportieren Sie:

Ereignisse CSV: die Ereignisse, die zu Ihren aktuellen Filtern passen (filtern Sie also zuerst, oder setzen Sie die Filter zurück, um alles Aufgelistete zu exportieren). Zellen, die mit =, +, - oder @ beginnen, werden maskiert, um Formel-Injection zu verhindern.
Befunde CSV: eine Zeile pro Befund.
Bericht JSON: das vollständige Ergebnis, für Ihre Fallakte oder ein anderes Werkzeug.

Was das Werkzeug Ihnen nicht abnimmt

Die Regeln sind Heuristiken mit festen Schwellenwerten: 10 verschiedene Repositories, die innerhalb von etwa einer Stunde von einer IP-Adresse geklont werden, und eine 24-stündige Vergleichsbasis für neue IP-Adressen und Länder. Sie sind auf eine mittelgroße Organisation abgestimmt, nicht auf Ihre. Das Audit-Log enthält außerdem keine Dateiinhalte; ein veränderter Workflow wird daher aus seinen Läufen erschlossen, nicht aus dem Diff. Lesen Sie Grenzen des GitHub-Audit-Logs, bevor Sie „keine Hinweise auf eine Kompromittierung“ in einen Bericht schreiben.

GitHub-Audit-Log-Analyse: Schritt für Schritt im Browser