GitHub-Organisation kompromittiert? So reagieren Sie
GitHub-Organisation kompromittiert? Audit-Log sichern, Tokens und Workflows eindämmen, Umfang mit Git-Events bestimmen und dann in die Cloud weiterermitteln.
Kurz gesagt. Eine kompromittierte GitHub-Organisation ist meist ein Supply-Chain-Vorfall im Frühstadium. Jemand besitzt ein Token, einen Schlüssel oder eine Owner-Sitzung, und Ihr Quellcode, Ihre CI/CD-Pipeline und Ihre Cloud-Zugangsdaten sind in Reichweite. Gehen Sie in dieser Reihenfolge vor: Beweise sichern (Audit-Log und Git-Events – Git-Events werden nur 7 Tage aufbewahrt), eindämmen (Zugangsdaten widerrufen, Workflows stoppen, Persistenz entfernen), Umfang bestimmen anhand der Beweise und dann in die Cloud weiterermitteln, zu den Konten, deren Schlüssel in Actions-Secrets lagen. Die Exporte können Sie mit dem kostenlosen Analyzer im Browser prüfen, der nichts hochlädt.
GitHub ist für Angreifer oft der erste Brückenkopf in die Cloud. Ein einziges gestohlenes Personal Access Token (PAT) öffnet die privaten Repositories, die Workflows, die in die Produktion deployen, und die Secrets, auf die diese Workflows zugreifen. Dieser Leitfaden ist der Einstieg in die Serie. Jeder Abschnitt fasst ein Szenario zusammen und verweist auf das Playbook, das es im Detail behandelt.
Wie GitHub-Organisationen kompromittiert werden
Fast jeder Vorfall, den ich sehe, beginnt mit einem dieser Einstiegspunkte:
| Einstiegspunkt | Typische Spuren im Audit-Log | Playbook |
|---|---|---|
| Personal Access Token von einem Infostealer gestohlen oder im Code geleakt | derselbe hashed_token aus einem neuen Land / von einer neuen IP, git.clone-Häufungen | GitHub-Token geleakt |
| Token einer OAuth-App oder GitHub App bei einem Drittanbieter gestohlen | API-Aktivität einer Integration, Repositories aufgelistet und heruntergeladen | GitHub-Token geleakt |
| Manipulierter Workflow oder kompromittierte Action eines Drittanbieters | workflows.created_workflow_run auf einem neuen Branch, kodierte Zeichenketten in Laufprotokollen | GitHub-Actions-Secrets geleakt |
| Fremder oder kompromittierter selbst gehosteter Runner | org.register_self_hosted_runner, Jobs auf unbekannten Runnern | Sicherheit selbst gehosteter Runner |
| Übernahme eines Owner-Kontos | org.update_member auf Admin, org.disable_two_factor_requirement | Übernahme der Organisation |
Das ist keine reine Theorie. Im April 2022 meldete GitHub, dass ein Angreifer gestohlene OAuth-User-Tokens, die an Heroku und Travis CI ausgegeben worden waren, genutzt hatte, um private Repositories Dutzender Organisationen aufzulisten und herunterzuladen. Im März 2025 veröffentlichte die CISA eine Warnung zur Kompromittierung von tj-actions/changed-files (CVE-2025-30066): Eine populäre Action war so verändert worden, dass sie CI-Secrets in die Workflow-Protokolle schrieb. Im September 2025 beschrieb die CISA-Warnung zum npm-Ökosystem Schadsoftware, die GitHub-PATs und Cloud-Schlüssel aus Entwicklerumgebungen abgriff.
Schritt 1: zuerst die Beweise sichern
Die Aufbewahrungsfristen bestimmen die Reihenfolge der Arbeit. GitHub bewahrt Audit-Ereignisse der Organisation 180 Tage auf, Git-Events jedoch nur sieben Tage. Actions-Protokolle werden standardmäßig 90 Tage aufbewahrt, und jeder mit Schreibzugriff auf das Repository kann die Protokolle eines Laufs löschen. Ein Angreifer, der Ihr Token besitzt, kann also genau die aussagekräftigsten Beweise vernichten.
Bevor Sie irgendetwas anfassen:
- Exportieren Sie das Audit-Log der Organisation als JSON für den gesamten verdächtigen Zeitraum, dazu einige Wochen davor als Vergleichsbasis.
- Unter GitHub Enterprise Cloud rufen Sie die Git-Events (
git.clone,git.fetch,git.push) über die REST-API mitinclude=allab oder nutzen das Enterprise-Menü „Export Git Events“. - Laden Sie das Protokollarchiv jedes verdächtigen Workflow-Laufs herunter.
- Wenn Sie das Audit-Log nach S3, Azure Blob oder GCS streamen, kopieren Sie die relevanten Ordner
YYYY/MM/DD/HH/MM/. - Legen Sie die Kopien schreibgeschützt ab und berechnen Sie ihre Hashwerte.
Der Leitfaden zum Export geht jede Quelle Schritt für Schritt durch und nennt den jeweils erforderlichen Plan.
Schritt 2: eindämmen
GitHubs eigenes Tutorial zur Reaktion auf Sicherheitsvorfälle empfiehlt, die Eindämmungsmaßnahmen an der Bedrohung auszurichten, statt alle blind umzusetzen. Diese Maßnahmen stoppen die meisten realen Vorfälle:
- Die beteiligten Zugangsdaten widerrufen. Liegt Ihnen das Token im Klartext vor, kann es jeder über die API zum Widerruf von Zugangsdaten widerrufen. Andernfalls widerruft es der Inhaber, oder ein Owner entzieht die SSO-Autorisierung. Prüfen Sie den Rechner des Entwicklers auf einen Infostealer, bevor Sie ein neues Token ausstellen.
- Die Pipeline anhalten. Brechen Sie laufende Workflows ab, löschen Sie die Branches des Angreifers und deaktivieren Sie Actions in den betroffenen Repositories, falls nötig.
- Persistenz entfernen. Suchen Sie nach Deploy-Keys, SSH-Schlüsseln, Webhooks, GitHub Apps, genehmigten OAuth-Apps, externen Collaborators und selbst gehosteten Runnern, die im Zeitraum des Vorfalls hinzugekommen sind.
- Jedes Secret rotieren, das die betroffenen Workflows lesen konnten, nicht nur diejenigen, die Sie im Protokoll gesehen haben.
Schritt 3: den Umfang mit dem Audit-Log bestimmen
Die Umfangsbestimmung beantwortet drei Fragen: welche Zugangsdaten, worauf wurde zugegriffen, was wurde verändert.
Welche Zugangsdaten
Per Token authentifizierte Ereignisse enthalten hashed_token, programmatic_access_type und token_scopes. GitHub dokumentiert, wie Sie Audit-Log-Ereignisse identifizieren, die von einem Access Token ausgelöst wurden. Gruppieren Sie nach hashed_token statt nach Akteur. Ein gestohlenes Token gehört einem legitimen Benutzer, seine Aktivität vermischt sich also mit dessen Aktivität – IP-Adressen und Länder des Angreifers unterscheiden sich jedoch.
Worauf zugegriffen wurde
Die Git-Events zeigen, welche Repositories wann geklont wurden. Zehn oder mehr verschiedene Repositories, die innerhalb einer Stunde von einer einzigen IP-Adresse geklont werden, sind kein normales Entwicklerverhalten. Die übrigen Exfiltrationswege – repo.download_zip, Änderungen der Sichtbarkeit und Übertragungen – behandelt der Artikel Repository-Exfiltration erkennen.
Was verändert wurde
Filtern Sie nach Aktionen, die eine Schutzmaßnahme schwächen oder Zugriff hinzufügen. Diese Tabelle nennt die Mindestauswahl:
| Bereich | Zu prüfende Aktionen |
|---|---|
| Owner und Admins | org.update_member / org.add_member mit permission: admin, business.add_admin |
| Authentifizierung | org.disable_two_factor_requirement, org.disable_saml, org.update_saml_provider_settings |
| Netzwerk | ip_allow_list.disable, ip_allow_list.disable_for_installed_apps |
| Protokollierung | audit_log_streaming.destroy, audit_log_streaming.update |
| Code-Integrität | protected_branch.destroy, repository_ruleset.destroy, protected_branch.policy_override |
| CI/CD | environment.remove_protection_rule, org.register_self_hosted_runner, *.create_actions_secret |
| Persistenz | public_key.create, hook.create, integration_installation.create |
Der Artikel zum Branch-Schutz und der Artikel zur Übernahme erklären, wie Sie jede dieser Aktionen lesen.
Schritt 4: den Secrets in die Cloud folgen
Actions-Secrets sind überwiegend Cloud-Zugangsdaten. Wenn sie geleakt sind, hat der Vorfall gerade erst begonnen. Die nächsten Beweise liegen in CloudTrail, in den Audit-Logs von Google Cloud oder in den Azure-Aktivitätsprotokollen. Der Artikel zum Weg in die Cloud behandelt diesen Schritt und verweist auf die Schwesterwerkzeuge für AWS, Google Cloud und Azure.
Wo der Analyzer auf dieser Website ins Spiel kommt
Das Werkzeug GitHub Forensics liest die oben beschriebenen Exporte: JSON / CSV aus der Oberfläche, Seiten der REST-API, Streaming-Dateien .json.log.gz, den Git-Events-Export, ZIP-Dateien mit Actions-Protokollen und Secret-Scanning-Warnungen. Es wertet 31 veröffentlichte Erkennungsregeln aus und liefert ein Urteil („Keine Anzeichen einer Kompromittierung“, „Verdächtige Aktivität“ oder „Kompromittiert“), Befunde mit ihren Beweisen und ATT&CK-Techniken, eine Zeitleiste und eine Maßnahmenliste. Alles läuft lokal in WebAssembly.
Die Regeln sind Heuristiken mit Schwellenwerten, und das Urteil „Keine Anzeichen einer Kompromittierung“ gilt nur für das, was der Export enthält. Der Artikel zu den Grenzen listet auf, was das Audit-Log nie protokolliert. Wenn Sie zuerst sehen möchten, wie eine fertige Analyse aussieht, geht die fiktive Fallstudie northwind-labs den Beispielvorfall Befund für Befund durch.
FAQ
Was ist der erste Schritt, wenn eine GitHub-Organisation kompromittiert wurde?
Sichern Sie die Beweise, bevor Sie irgendetwas ändern: das Audit-Log der Organisation (JSON) und unter Enterprise Cloud die Git-Events, die nur sieben Tage aufbewahrt werden. Laden Sie die Protokollarchive verdächtiger Workflow-Läufe herunter. Widerrufen Sie erst danach die beteiligten Tokens und stoppen Sie bösartige Workflows.
Protokolliert GitHub, welche Repositories geklont wurden?
Ja, als Ereignisse git.clone, git.fetch und git.push. Sie erhalten sie nur über die REST-API mit include=git oder include=all, über Audit-Log-Streaming oder über den Git-Events-Export des Enterprise, und nur unter GitHub Enterprise Cloud. Sie werden sieben Tage aufbewahrt.
Kann ich einen GitHub-Vorfall ohne SIEM untersuchen?
Ja. Der Audit-Log-Export, der Git-Events-Export und die Actions-Protokollarchive sind gewöhnliche JSON-, gzip- und ZIP-Dateien. Sie können sie mit jq auswerten oder in einen Offline-Analyzer wie den auf dieser Website ziehen, der vollständig im Browser läuft.
Weiterführende Links
- GitHub Docs: Common security incident investigation areas
- OWASP: Top 10 CI/CD Security Risks
- MITRE ATT&CK: T1213.003 Code Repositories, T1677 Poisoned Pipeline Execution
- Glossar: GitHub-Audit-Log, Personal Access Token, Audit-Log-Streaming