Geleakte Cloud-Keys in GitHub Actions: weiter in die Cloud

Kurz gesagt. Sobald ein Cloud-Key GitHub verlassen hat (von einem Workflow ausgegeben, mit der Historie eines Repositories geklont, vom Secret Scanning gefunden), wird aus der GitHub-Untersuchung eine Cloud-Untersuchung. Deaktivieren Sie den Key, notieren Sie aber vorher seine ID und das genaue Zeitfenster. Durchsuchen Sie die Logs der Cloud selbst nach jedem Aufruf, der damit gemacht wurde: CloudTrail bei AWS, Cloud Audit Logs bei Google Cloud, Activity Log und Anmeldelogs von Entra ID bei Azure. Ersetzen Sie gespeicherte Keys durch OIDC-Föderation, damit die nächste Kompromittierung eines Workflows nur ein kurzlebiges, eng begrenztes Token liefert.

GitHub ist selten das eigentliche Ziel eines Angreifers. Repositories und Actions-Secrets enthalten die Zugangsdaten der Systeme, auf die es ankommt: Cloud-Konten der Produktion, Registries und Datenbanken. Der Analyzer kennzeichnet diese Übergabe als nächsten Schritt. Wenn die Regel actions-secret-exfil in einem Skript, das Secrets kodiert oder verschickt, Namen von AWS-, Google-Cloud- oder Azure-Zugangsdaten findet, oder wenn eine Secret-Scanning-Warnung Cloud-Zugangsdaten betrifft, verweist das Ergebnis auf das passende Cloud-Werkzeug.

Wo Cloud-Keys aus GitHub abfließen

Quelle	Beweise auf GitHub-Seite	Behandelt in
Workflow gibt Secrets aus oder verschickt sie	Protokollarchiv des Laufs: Encoder oder `curl` im Skript des Schritts, lange kodierte Zeichenkette in der Ausgabe	Actions-Secrets geleakt
Key in ein Repository committet und dann geklont	`git.clone`-Häufungen, Secret-Scanning-Warnung, umgangener Push-Schutz	Exfiltration von Repositories
Schutz einer Umgebung entfernt	`environment.remove_protection_rule` vor einem Lauf, der die Umgebung verwendet hat	Branch Protection deaktiviert
Self-hosted Runner kompromittiert	Runner-Host mit Instanzrolle oder zwischengespeicherten CLI-Zugangsdaten	Self-hosted Runner Sicherheit

Secret-Scanning-Warnungen (secret_scanning_alert.create, secret_scanning_alert.public_leak) und umgangener Push-Schutz (secret_scanning_push_protection.bypass) werden von den Regeln secret-leak-alert und push-protection-bypass gemeldet. Legen Sie das JSON der Secret-Scanning-Warnungen der Organisation neben das Audit-Log, damit sie berücksichtigt werden.

Zuerst: Key und Zeitfenster festhalten

Bevor Sie rotieren, dokumentieren Sie:

Die Kennung des Keys. Bei AWS die Access Key ID (AKIA… für langlebige Benutzer-Keys, ASIA… für temporäre Zugangsdaten). Bei Google Cloud die E-Mail-Adresse des Dienstkontos und die Key-ID im JSON. Bei Azure die Anwendungs-ID (Client-ID) des Service Principals und die ID des Secrets oder Zertifikats.
Den Beginn der Exposition. Den Zeitpunkt des bösartigen Laufs oder Pushs, des Klonens oder der Warnung. Der Befund im Analyzer nennt den Zeitpunkt des ersten Auftretens in UTC.
Wo der Key gültig war. Welches Konto, welches Projekt oder welches Abonnement, und welche Berechtigungen er hatte.

Deaktivieren oder löschen Sie den Key erst dann. Bei AWS können Sie einen deaktivierten Access Key wieder aktivieren, falls die Produktion ausfällt. Sobald Sie bestätigt haben, dass nichts Legitimes mehr davon abhängt, löschen Sie ihn.

AWS: CloudTrail

Durchsuchen Sie CloudTrail ab dem Beginn der Exposition nach der Access Key ID. Event History und CloudTrail Lake können nach dem Access Key filtern. Achten Sie auf:

Identitätsprüfungen, mit denen Angreifer typischerweise beginnen (GetCallerIdentity), gefolgt von Enumeration (List*, Describe*, Get* in Schüben).
Aufrufe von IP-Adressen und User-Agents, die nicht zu Ihrer CI passen (GitHub-hosted Runner kommen aus den von GitHub veröffentlichten Adressbereichen. Eine aws-cli eines Laptops von einem VPS aus gehört nicht dazu).
Persistenz: CreateUser, CreateAccessKey, CreateLoginProfile, AttachUserPolicy, neue Rollen oder Änderungen an Trust Policies.
Datenzugriffe: S3-GetObject in großem Umfang, Lesezugriffe auf Secrets Manager oder SSM Parameter Store.

Das Schwesterwerkzeug AWS Forensics analysiert CloudTrail-Exporte auf dieselbe Weise, wie diese Website GitHub analysiert: im Browser, ohne dass etwas hochgeladen wird.

Google Cloud: Cloud Audit Logs

Bei einem geleakten Dienstkonto-Key filtern Sie die Cloud Audit Logs auf das Dienstkonto als Principal und sehen sich die Admin-Activity-Logs und, sofern aktiviert, die Data-Access-Logs an. Achten Sie auf neue Dienstkonto-Keys, IAM-Policy-Bindings und Zugriffe auf Cloud Storage oder Secret Manager. Weiter geht es mit GCP Forensics.

Azure: Activity Log und Entra ID

Bei einem Secret eines Service Principals prüfen Sie zuerst die Anmeldelogs für Service Principals in Entra ID zur Anwendungs-ID und dann das Activity Log daraufhin, was geändert wurde: Rollenzuweisungen, neue Zugangsdaten für Anwendungen und Zugriffe auf Key Vault. Weiter geht es mit Azure Forensics.

Keys durch OIDC-Föderation ersetzen

Die meisten dieser Vorfälle gibt es nur, weil ein langlebiger Key in einem GitHub-Secret liegt. GitHub Actions kann für jeden Job ein kurzlebiges OIDC-Token anfordern, und AWS, Google Cloud und Azure können ihm direkt vertrauen. Siehe GitHubs Dokumentation zu OpenID Connect und den Glossareintrag zur OIDC-Föderation. GitHubs Referenz zur sicheren Nutzung empfiehlt sie für Deployments in die Cloud.

Was sich für einen Angreifer ändert:

	Gespeicherter Access Key	OIDC-Föderation
Lebensdauer	Bis jemand ihn rotiert	Minuten bis eine Stunde (Sitzung auf Cloud-Seite)
Außerhalb des Workflows nutzbar	Ja, von überall	Nur bis zum Ablauf
Umfang	Alles, was der Benutzer des Keys darf	Eine Rolle, deren Trust Policy ein bestimmtes Repository, einen Branch oder eine Umgebung verlangen kann (`sub`-Claim)
In Logs sichtbar	Key-ID	Rollensitzung, verknüpft mit den GitHub-Claims

OIDC ist kein Allheilmittel. Ein manipulierter Workflow, der auf einem zugelassenen Branch läuft, erhält während des Laufs trotzdem ein gültiges Token. Aber das Zeitfenster schrumpft von „bis zur Rotation“ auf „solange der Job läuft“, und Vertrauensbedingungen wie repo:ORG/REPO:environment:production blockieren Tokens, die von Branches des Angreifers angefordert werden.

Checkliste

Dokumentieren Sie Key-ID, Konto und Expositionsfenster. Deaktivieren Sie dann den Key.
Holen Sie die Cloud-Logs für das Zeitfenster. Suchen Sie nach Identitätsprüfungen, Enumeration, Persistenz und Datenzugriffen.
Rotieren Sie jedes andere Secret, das derselbe Workflow lesen konnte (siehe den Artikel zu Actions-Secrets).
Entfernen Sie, was der Angreifer in der Cloud angelegt hat: Benutzer, Keys, Rollen, Funktionen, Instanzen.
Stellen Sie Deployments auf OIDC um, mit Vertrauensbedingungen für Repository und Umgebung.