Übernahme einer GitHub-Organisation: Owner, 2FA, SSO

Kurz gesagt. Eine Übernahme zeigt sich im Audit-Log als kurze Abfolge von Änderungen an Kontrollen: ein neuer Owner (org.update_member / org.add_member mit permission: admin, business.add_admin), danach geschwächte Abwehr (org.disable_two_factor_requirement, org.disable_saml oder org.update_saml_provider_settings, ip_allow_list.disable, org.disable_oauth_app_restrictions, gelockerte personal_access_token.*-Richtlinie) und manchmal ein entfernter Stream zu Ihrem SIEM (audit_log_streaming.destroy). Jede einzelne dieser Änderungen durch einen unerwarteten Akteur oder von einer unerwarteten IP-Adresse ist ein Befund mit hoher Priorität. Zwei davon beim selben Akteur sind ein Vorfall.

Owner einer Organisation können jedes Repository, jedes Secret, jedes Mitglied und jede Sicherheitseinstellung ändern. Ein Angreifer, der Owner wird oder die Sitzung bzw. das Token eines Owners kontrolliert, muss nicht leise vorgehen. Er muss nur schneller sein als Ihre Prüfung des Audit-Logs. Dieses Playbook listet die Änderungen an Kontrollen auf, nach denen Sie suchen sollten, und die Reihenfolge, in der Sie sie rückgängig machen.

Die Anzeichen einer Übernahme

Anzeichen	Audit-Aktionen	Regel im Analyzer	Schweregrad
Owner hinzugefügt	`org.update_member` oder `org.add_member` mit `permission: admin`, `business.add_admin`	`owner-granted`	hoch
Admin-Rechte auf ein Repository für einen Collaborator	`org.add_outside_collaborator`, `repo.add_member`, `repo.update_member` mit Admin-Berechtigung	`collaborator-admin`	mittel
2FA-Pflicht deaktiviert	`org.disable_two_factor_requirement`, `business.disable_two_factor_requirement`	`two-factor-disabled`	hoch
SAML-SSO deaktiviert oder umgeleitet	`org.disable_saml`, `org.update_saml_provider_settings` (und die `business.`-Entsprechungen)	`sso-changed`	hoch
IP-Zulassungsliste deaktiviert	`ip_allow_list.disable`, `ip_allow_list.disable_for_installed_apps`, `ip_allow_list.disable_user_level_enforcement`	`ip-allowlist-disabled`	hoch
Einschränkungen für Drittanbieter-Apps deaktiviert	`org.disable_oauth_app_restrictions`	`oauth-restrictions-disabled`	mittel
Token-Richtlinie geschwächt	`personal_access_token.access_restriction_disabled`, `.expiration_limit_unset`, `.auto_approve_grant_requests_enabled`	`pat-policy-weakened`	mittel
Audit-Stream entfernt	`audit_log_streaming.destroy`, `audit_log_streaming.update`	`audit-stream-changed`	hoch

Die Regeln verwenden folgende ATT&CK-Zuordnungen: T1098.003 Additional Cloud Roles für vergebene Owner-Rechte, T1556 Modify Authentication Process für 2FA und SSO, T1562.007 Disable or Modify Cloud Firewall für die IP-Zulassungsliste und T1562.008 Disable or Modify Cloud Logs für das Streaming.

Nach der Urteilslogik führen zwei unterschiedliche Regeln mit hohem Schweregrad beim selben Akteur, Token oder derselben IP-Adresse zum Urteil Kompromittiert, auch ohne kritischen Befund. Das passt zu Übernahmen: owner-granted, gefolgt von two-factor-disabled aus demselben Konto, ist selten ein Admin, der nur aufräumt.

Jede Änderung einzeln lesen

Neue Owner

org.update_member zeichnet Rollenwechsel auf. Das Feld permission (und das Feld user für das betroffene Konto) zeigt, wer befördert wurde. Prüfen Sie drei Dinge. War der Akteur ein bestehender Owner, mit seiner üblichen IP-Adresse und seinem üblichen User-Agent? Ist das beförderte Konto neu in der Organisation (achten Sie auf ein org.add_member kurz davor)? Ist der neue Owner kurz danach aktiv geworden? Ein Konto, das befördert wird und sofort Tokens, Keys oder Runner anlegt, ist das klassische Muster.

Zwei-Faktor-Authentifizierung

Wenn eine Organisation 2FA verlangt, werden Mitglieder und externe Collaborators ohne 2FA entfernt. Wird die Pflicht abgeschaltet, können schwach gesicherte Konten beitreten oder bleiben, und oft ist das der Schritt, bevor ein vom Angreifer kontrolliertes Konto eingeladen wird. Wird sie später wieder aktiviert, fliegt jedes Konto ohne 2FA hinaus. Das ist eine nützliche Eindämmung, stört aber auch den Betrieb, also planen Sie sie.

SAML Single Sign-on

Mit SAML-SSO (GitHub Enterprise Cloud) entscheidet Ihr Identity Provider, wer auf die Ressourcen der Organisation zugreifen darf, und Tokens müssen für SSO autorisiert werden. org.update_saml_provider_settings ändert den Issuer, die SSO-URL oder das Zertifikat. Ein Angreifer, der diese Werte auf einen von ihm kontrollierten Identity Provider umleitet, kann sich anschließend als beliebige Person anmelden. Vergleichen Sie die neuen Werte mit den Metadaten Ihres IdP. Ist Ihr IdP betroffen, sind dessen eigene Logs die nächste Station: Die Schwesterwerkzeuge decken Okta, Microsoft Entra ID und Google Workspace ab.

IP-Zulassungsliste

Eine IP-Zulassungsliste (Enterprise Cloud) blockiert Web-, API- und Git-Zugriffe von außerhalb Ihrer Adressbereiche, auch Zugriffe mit Personal Access Tokens und SSH-Keys. Deshalb scheitern gestohlene Zugangsdaten, solange sie aktiv ist. Achten Sie auf ip_allow_list.disable und ebenso auf ip_allow_list_entry.create: Den VPS des Angreifers in die Liste aufzunehmen ist unauffälliger, als sie abzuschalten. Der Analyzer zeigt diesen Eintrag in der Zeitleiste an, erzeugt dafür aber keinen Befund.

OAuth-Apps und Richtlinie für Personal Access Tokens

Zugriffsbeschränkungen für OAuth-Apps verhindern, dass OAuth-Apps, die Mitglieder autorisieren, Daten der Organisation lesen, bevor ein Owner sie genehmigt hat. Werden sie deaktiviert, steht Consent Phishing die Tür offen. Die Richtlinie für Personal Access Tokens kann klassische Tokens sperren, die Lebensdauer von Tokens begrenzen und für Fine-grained Tokens eine Genehmigung verlangen. Wird sie kurz vor dem Erstellen und Verwenden eines Tokens gelockert, lohnt es sich, diese Abfolge zu rekonstruieren.

Audit-Log-Streaming

Wird der Stream entfernt oder umgeleitet (audit_log_streaming.destroy / .update), ist das SIEM blind, während das Audit-Log im Produkt weiter aufzeichnet. Es ist außerdem eine der wenigen Änderungen, die nur für jemanden Sinn ergeben, der mit einer Untersuchung rechnet. Siehe Audit-Log-Streaming.

Reihenfolge der Bereinigung

Sichern Sie den Audit-Log-Export, bevor Sie irgendetwas zurücksetzen. Jede Rücknahme erzeugt neue Ereignisse und macht die Zeitleiste schwerer lesbar.
Entfernen Sie unerwartete Owner und Admins und widerrufen Sie anschließend deren Sitzungen, Tokens, SSH-Keys und SSO-Autorisierungen.
Stellen Sie die Authentifizierungskontrollen wieder her: 2FA-Pflicht, SAML-Einstellungen (gegen den IdP verifizieren), IP-Zulassungsliste, OAuth-App-Beschränkungen, Token-Richtlinie.
Stellen Sie den Audit-Stream wieder her und ermitteln Sie, was verloren ging, während er abgeschaltet war. Die Pufferung hängt vom Ziel ab und davon, wie lange er pausiert war.
Suchen Sie nach Persistenz, die der neue Owner angelegt haben könnte: Deploy-Keys, Apps, Webhooks, Runner, externe Collaborators und Teams mit weitreichenden Rechten. Das Playbook zum geleakten Token enthält die Liste.
Prüfen Sie auch die Kontrollen auf Repository-Ebene. Owner können Branch Protection und Rulesets überall entfernen. Siehe Branch Protection deaktiviert.