GitHub-Supply-Chain-Angriff untersuchen: ein Fallbeispiel

Kurz gesagt. Dieses Fallbeispiel verwendet den fiktiven Vorfall hinter der Schaltfläche „Beispiel testen“ des Werkzeugs (Organisation northwind-labs; Personen, Repositories, Tokens und IP-Adressen sind allesamt erfunden). Das klassische PAT eines Entwicklers wird um 01:58 UTC von einem VPS in den Niederlanden aus wiederverwendet. Es klont in etwa 18 Minuten 38 private Repositories, pusht einen Workflow auf einen neuen Branch, der die AWS-Deploy-Keys doppelt base64-kodiert ausgibt, fügt einen Deploy-Key mit Schreibrecht hinzu und entfernt die Branch Protection auf main. Der Analyzer liefert Kompromittiert mit 10 Befunden. Im Folgenden sehen Sie, wie Sie diese lesen und in welcher Reihenfolge Sie handeln.

Fiktives Szenario. Alles in diesem Artikel stammt aus scripts/make-samples.py. Das Skript erzeugt das Beispiel, das die Schaltfläche „Beispiel testen“ des Werkzeugs lädt. Die IP-Adressen stammen aus Dokumentationsbereichen (RFC 5737), und das AWS-Schlüsselpaar ist das Dokumentationsbeispiel von AWS selbst. Ähnlichkeiten mit einer realen Organisation sind zufällig.

Die Ausgangslage

northwind-labs ist eine kleine Entwicklungsorganisation: ein Owner (c-okafor) und drei Entwickler (m-hernandez, j-lindqvist, a-nowak), die überwiegend aus Frankreich und Schweden und zu Bürozeiten arbeiten. Die Beweise sind die drei Dateien, die ein Ermittler realistischerweise sammeln würde, jeweils im echten Exportformat:

Die Vergleichsbasis umfasst drei Wochen (2026-08-24 bis 2026-09-13). Das ist wichtig, denn die Regeln für neue Länder und neue IP-Adressen brauchen eine Historie, mit der sie vergleichen können.

Schritt 1: das Urteil

Ziehen Sie die drei Dateien in das Werkzeug (oder klicken Sie auf Beispiel testen). Das Banner zeigt Kompromittiert. Unter Warum stehen die vier Befunde, die zu diesem Urteil geführt haben: actions-secret-exfil (kritisch) sowie token-new-country, git-clone-burst und branch-protection-removed (hoch). Die Hinweise zur Abdeckung sind leer. IP-Adressen, Git-Events und Token-Metadaten sind vorhanden, keine Regel war also blind.

Die vollständige Liste, wie der Analyzer sie ausgibt:

Die letzten beiden sind das ehrliche Grundrauschen jeder echten Organisation: Routine-Administration, die die Regeln melden, weil sie relevant sein könnte. Sie haben weder Akteur noch Token noch IP-Adresse mit dem Rest gemeinsam, Sie können sie also beiseitelegen.

Schritt 2: welche Zugangsdaten?

Öffnen Sie token-new-country. Die zugehörigen Entitäten sind der Akteur m-hernandez, ein hashed_token und die IP-Adresse 203.0.113.66. Pivotieren Sie über das Token (Entitäten → Tokens → Ereignisse zeigen). Es ist ein Personal access token (classic) mit den Scopes repo, workflow, read:org. Drei Wochen lang wurde es tagsüber von 198.51.100.23 (FR) mit dem User-Agent git/2.39.5 (Apple Git-154) verwendet. Ab 01:58 UTC am 2026-09-14 taucht es von 203.0.113.66 (NL) mit git/2.43.0 auf, später mit curl/8.5.0.

Dieselbe Person, dasselbe Token, eine andere Maschine, ein anderes Land, mitten in der Nacht: Das Token wurde wiederverwendet. Der Scope workflow erklärt, wie der Angreifer eine Workflow-Datei pushen konnte. Im Szenario ist die Quelle ein Infostealer auf dem Laptop des Entwicklers. Diesen Teil können die GitHub-Logs nicht zeigen, und genau deshalb besteht das Playbook zum geleakten Token darauf, den Endpunkt zu prüfen.

Schritt 3: was wurde abgegriffen?

git-clone-burst zählt 38 verschiedene Repositories. In den Git-Events laufen die Klonvorgänge von 02:14:00 bis 02:31:53, etwa einer alle 29 Sekunden. Dieser gleichmäßige Takt ist geskriptet. m-hernandez arbeitet normalerweise mit vier Repositories (payments-api, billing-worker, ledger, web-app). Die Häufung umfasst infra-terraform, secrets-rotation, kyc-service und terraform-modules, Repositories, in die diese Person nie gepusht hat.

Fazit für den Bericht: Quellcode und vollständige Historie von 38 Repositories befinden sich in den Händen des Angreifers. Daraus folgt die Maßnahme „Geklonten Code als geleakt behandeln“: Durchsuchen Sie diese Historien nach Secrets und rotieren Sie, was Sie finden. Der Artikel zur Exfiltration von Repositories beschreibt, wie Sie den Umfang bestimmen.

Schritt 4: was wurde verändert?

Lesen Sie die Zeitleiste mit Nur Befunde:

1. 02:39:21 git.push auf payments-api vom VPS aus.
2. 02:39:40 workflows.created_workflow_run: Workflow CI, Ereignis push, Branch ci/cache-fix. Das ist der erste Lauf auf diesem Branch, also schlägt workflow-new-branch an.
3. 02:40:08 Im Protokollarchiv des Laufs 4412 führt der Schritt Restore build cache echo "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" | base64 -w0 | base64 -w0 aus und gibt eine lange Zeichenkette aus. Die Maskierung greift nicht, weil der Wert kodiert war. Zweimal dekodiert ergibt sich das Schlüsselpaar (hier das Dokumentationsbeispiel von AWS). actions-secret-exfil schlägt als kritisch an, mit AWS als nächstem Schritt, und actions-encoded-output schlägt bei der Zeichenkette an.
4. 02:52:03 public_key.create auf infra-terraform: Titel backup-sync, read_only: false, User-Agent curl/8.5.0. Ein Deploy-Key mit Schreibrecht ist Persistenz, die den Widerruf des PAT übersteht.
5. 03:05:44 protected_branch.destroy auf payments-api / main. Die Regel verlangte zwei zustimmende Reviews.
6. 03:06:30 git.push auf payments-api, eine Minute nachdem der Schutz entfernt wurde.
7. 07:48:10 protected_branch.create durch c-okafor aus dem Büro: Der Owner hat es bemerkt und die Regel wiederhergestellt.

Schritt 6 sollte Ihnen die größten Sorgen machen. Etwas wurde ohne Review auf main gepusht. Das Audit-Log enthält den Diff nicht, der Commit muss also im Repository geprüft werden (siehe Branch Protection deaktiviert).

Schritt 5: Bereinigung in der Reihenfolge des Werkzeugs

Der Tab Maßnahmen sortiert die Checkliste nach Dringlichkeit:

1. Beweise sichern: Audit-Log und Git-Events erneut exportieren und das Protokollarchiv des Laufs aufbewahren, bevor jemand die Protokolle von Lauf 4412 löscht.
2. Alle erreichbaren Actions-Secrets rotieren: sämtliche Secrets, die Workflows in payments-api lesen können, nicht nur die beiden AWS-Secrets.
3. Cloud-Zugangsdaten rotieren und die Cloud untersuchen: den AWS-Key deaktivieren und CloudTrail ab 02:40 UTC durchsuchen. Siehe Geleakte Cloud-Keys in GitHub Actions und AWS Forensics.
4. Workflow-Änderungen und -Läufe prüfen: .github/workflows auf ci/cache-fix vergleichen, den Branch löschen und CODEOWNERS-Reviews für Workflow-Dateien verlangen.
5. Das Token widerrufen und das Konto zurücksetzen, nachdem der Laptop neu aufgesetzt wurde.
6. Geklonten Code als geleakt behandeln: die Historie der 38 Repositories durchsuchen.
7. Branch-Schutz wiederherstellen und Eingänge prüfen: den Push um 03:06.
8. Persistenz entfernen: den Deploy-Key backup-sync löschen und nach allem suchen, was sonst noch von 203.0.113.66 aus angelegt wurde.

Was dieses Beispiel nicht zeigt

Echte Vorfälle sind unübersichtlicher. Hier gibt es keine Übernahme durch einen Owner, keinen Self-hosted Runner und keinen entfernten Audit-Stream. Der Angreifer hat seine Aktivität auch nicht über Tage verteilt, um unter den Schwellenwerten zu bleiben. Wenn eine Regel bei Ihren Daten nicht angeschlagen hat, prüfen Sie die Hinweise zur Abdeckung und lesen Sie, was das Audit-Log nicht aufzeichnet, bevor Sie Schlüsse ziehen.

Verwandte Artikel

• GitHub-Audit-Log-Analyse: Schritt für Schritt
• GitHub-Organisation kompromittiert? So reagieren Sie
• GitHub-Actions-Secrets geleakt: Exfiltration untersuchen