GitHub-Konten gekapert: wfx-loot stiehlt CI-Secrets

Was ist die GitHub-Kampagne wfx-loot?

wfx-loot ist eine Kampagne, bei der ein Angreifer mit gestohlenen GitHub-Zugangsdaten einen bösartigen Workflow in Repositories einschleust, auf die diese Konten schreibend zugreifen können, um GitHub-Actions-Secrets und Cloud-Zugangsdaten zu stehlen ^[1]. Aikido Security, das sie als Erstes meldete, benannte sie nach der eigenen Bezeichnung des Angreifers für die Malware („wfx“) und dem Wort für gestohlene Secrets („loot“) ^[1]. Auch SafeDep schreibt Aikido den ersten Bericht zu ^[5].

StepSecurity nennt denselben Stealer „wfx“ und betont einen entscheidenden Punkt: Der Angreifer nutzt keinen Fehler in GitHub Actions aus ^[2]. Stattdessen verwendet er gültige Tokens echter Entwickler- und Bot-Konten und eröffnet Pull Requests und pusht Commits so, wie es ein Entwickler tun würde ^[2][4].

Aikido geht davon aus, dass das Hauptziel CI-Secrets sind und nicht die Verbreitung über Software-Pakete, obwohl die Schadlast über automatisierte Veröffentlichungsauslöser mindestens ein Packagist-Paket und ein Go-Paket erreichte ^[1]. BleepingComputer berichtet unter Berufung auf die Analyse von Aikido, dass einige der kompromittierten Konten großen Organisationen gehörten ^[3].

Wie groß ist der Angriff wfx-loot?

Aikido zählt 4.837 kompromittierte Konten, die Sonden-Pull-Requests in 61.764 Repositories eröffneten, wobei der Stealer in mindestens 1.806 Repositories lief ^[1]. Die Zahlen unterscheiden sich zwischen den Forschern leicht, weil jeder GitHub zu einem anderen Zeitpunkt durchsuchte, während die Kampagne noch aktiv war.

• Aikido: 4.837 Konten, 61.764 Repositories; 10.431 Pull Requests gingen in Repositories, die dem Konto nicht gehören; 92 % noch offen; mindestens 50 kompromittierte Nutzer veröffentlichen Pakete auf npm, Go, Packagist, PyPI oder crates ^[1].
• Aikido (zusammenfassende Zahl): mindestens 1.835 Repositories führten die Schadlast aus, und Zugangsdaten wurden entwendet; BleepingComputer verwendet diese Zahl ^[1][3].
• StepSecurity: mehr als 63.000 Sonden-Pull-Requests Stand 07:40 UTC am 12. November, etwa 90 % noch offen ^[2].
• SafeDep: 8.093 Repositories erhielten zwischen dem 10. und 12. November bösartige Commits, eine Zahl, die laut SecurityWeek nicht zwingend bedeutet, dass der Stealer ausgeführt wurde ^[5][4].

Aikido warnt, dass seine Ausführungszahl die Auswirkungen womöglich unterschätzt, weil die Laufprotokolle in betroffenen Repositories gelöscht wurden ^[1].

Wie funktioniert der wfx-loot-Stealer?

Für jedes Repository, auf das ein gestohlenes Token schreibend zugreifen kann, sondiert der Angreifer, pusht die Schadlast und räumt innerhalb von etwa einer Minute wieder auf ^[1].

1. Sonde: Ein Pull Request mit dem Titel „docs: dependency audit notes“ aus einem Branch namens wfx-docs fügt eine winzige Notizdatei hinzu. „Der Pull Request tut für sich genommen nichts“, so StepSecurity; er zeigt nur, dass das Token Schreibzugriff hat ^[2][4].
2. Schadlast: Ein Shell-Skript mit rund 1.500 Zeilen kommt auf einem von drei Wegen an: in einen bestehenden Workflow eingeschleust („ci: refresh build cache“), als Skript plus npm-postinstall-Hook („chore: add ci helper“) oder als neuer Workflow auf einem Wegwerf-Branch chore/ („chore: add dependency audit workflow“) ^[1].
3. Aufräumen: Der Angreifer macht die Änderung rückgängig und löscht den Workflow-Lauf samt Protokollen ^[1]. Eine fehlende Laufnummer ist oft die einzige Spur ^[1].

Das Skript sammelt GitHub-Actions-Secrets und -Tokens, die gesamte Runner-Umgebung, Zugangsdatendateien für AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH und mehr, Shell-Verläufe sowie Schlüssel für KI-Anbieter und Entwicklerwerkzeuge ^[1][3]. Es liest sogar den Speicher laufender Prozesse auf dem Runner aus ^[1][4]. Aikido stellte fest, dass die von ihm analysierten Kopien die gestohlenen Daten nur per HTTP POST an vom Angreifer kontrollierte Server sendeten ^[1]. StepSecurity beobachtete später eine Änderung: Ab etwa 05:30 UTC am 12. November sendeten neue Kopien Daten nur noch über Telegram, sodass das bloße Sperren der veröffentlichten Serveradressen sie nicht mehr aufhält ^[2].

Warum reicht das Erneuern von Secrets nicht aus?

Weil der Stealer versucht, Hintertüren zu platzieren, die eine Erneuerung der Zugangsdaten überstehen ^[1][2]. Aikido beschreibt drei Persistenz-Tricks ^[1]:

• Gefälschte Status-Checks: Aikido zufolge postet er gefälschte „success“-Checks unter den Namen der erforderlichen Checks eines Repositorys, was Merge-Sperren des Branch-Schutzes aufheben kann ^[1]. StepSecurity fand diese Funktion in allen 101 untersuchten Proben abgeschaltet ^[2].
• Umschreiben der AWS-Vertrauensrichtlinie: Er kann die Vertrauensrichtlinie einer Rolle so setzen, dass jedes AWS-Konto zugelassen ist ^[1].
• Einschleusen einer föderierten Azure-Identität: Er kann föderierte Zugangsdaten mit dem Namen wfx-ci-… zu Azure-AD-Anwendungen hinzufügen, sodass sich Workflows im kompromittierten Repository ohne gespeichertes Secret authentifizieren können ^[1].

Er kann außerdem GitHub-OIDC-Tokens erzeugen und gegen AWS-, Google-Cloud- und Azure-Sitzungen eintauschen, sich in andere IAM-Rollen weiterverketten und langlebige AWS-Zugangsschlüssel anlegen ^[1][3]. Deshalb sagt StepSecurity, man solle „die Persistenz entfernen, denn die Erneuerung allein tut das nicht“ ^[2].

Wie prüfe ich, ob meine GitHub-Repositories betroffen sind?

Suchen Sie seit dem 10. November nach dem Sonden-Pull-Request und den Commit-Nachrichten des Angreifers und achten Sie dann auf Lücken in den Workflow-Laufnummern ^[2][1].

1. Durchsuchen Sie Pull Requests nach „docs: dependency audit notes“ und nach Branches namens wfx-docs oder chore/ gefolgt von acht Zeichen ^[1][2].
2. Durchsuchen Sie Commits seit dem 10. November nach „ci: refresh build cache“, „ci: restore“, „ci: cleanup“, „chore: add ci helper“ und „chore: add dependency audit workflow“ ^[2].
3. Öffnen Sie bei jedem Treffer den Reiter Actions und suchen Sie nach einer fehlenden Laufnummer direkt nach dem Commit; StepSecurity nennt dies das zuverlässigste Zeichen dafür, dass der Stealer lief ^[2].
4. Notieren Sie, welches Konto die Commits gepusht hat: Die Tokens dieses Kontos sind gestohlen ^[2]. Existiert ein Sonden-Pull-Request, ist das Konto kompromittiert, auch wenn keine Schadlast lief ^[1].

Verlassen Sie sich nicht auf fehlende Artefakte. Aikido erklärt, dass das Fehlen von wfx-loot-Artefakten, wfx--Cache-Einträgen oder besonderen Step-Zusammenfassungen nicht bedeutet, dass keine Daten entwendet wurden, weil diese Kanäle in dieser Kampagne abgeschaltet waren ^[1]. Aikido hält es außerdem für möglich, dass die Schadlast sowohl in privaten als auch in öffentlichen Repositories eingesetzt wird ^[1].

Was tun, wenn der Stealer lief?

Gehen Sie davon aus, dass jedes Secret und jede Cloud-Rolle, die dem betroffenen Workflow zur Verfügung standen, kompromittiert ist, erneuern Sie sie und suchen Sie dann nach Persistenz ^[1][2].

• Erneuern: jedes Repository-, Umgebungs- und Organisations-Secret, das der Job erreichen konnte, nicht nur die vom Workflow genannten; npm-, PyPI- und andere Veröffentlichungs-Tokens; und als Secrets gespeicherte Cloud-Schlüssel ^[2].
• Pakete prüfen: nach Paketversionen suchen, die nach dem bösartigen Commit veröffentlicht wurden ^[2].
• AWS: nach Vertrauensrichtlinien suchen, die jeden AWS-Principal zulassen, nach seit dem 10. November angelegten IAM-Zugangsschlüsseln und nach CloudTrail-Sitzungen, die mit wfx- beginnen ^[2].
• Azure: föderierte Identitätsanmeldedaten mit dem Namen wfx-ci-* in App-Registrierungen löschen ^[2].
• Google Cloud, Vault, Kubernetes: die Token-Erzeugung und Anmeldungen mit GitHub-Actions-Anmeldetokens überprüfen ^[2].
• GitHub: übrig gebliebene Branches löschen, Sonden-Pull-Requests schließen, prüfen, dass nichts über einen gefälschten Check gemergt wurde, und die Tokens, OAuth-Freigaben und SSH-Schlüssel des Kontos widerrufen ^[2].
• Tokens laut GitHub-Dokumentation: Prüfen Sie Ihre persönlichen Zugriffstokens unter Settings, Developer settings und löschen Sie alle, die Sie nicht kennen oder nicht brauchen; GitHub empfiehlt feingranulare Tokens, nur die minimal nötigen Berechtigungen und ein Ablaufdatum, weil ein klassisches Token auf jedes Repository zugreifen kann, auf das Sie zugreifen können ^[6].

Der npm-Hook läuft auch auf Entwicklerrechnern: Wer in dem kurzen Zeitfenster npm install ausführte, hat den Stealer lokal ausgeführt und sollte auch die eigenen Zugangsdaten erneuern ^[2]. SecurityWeek fasst den Rat mehrerer Sicherheitsfirmen zusammen: kompromittierte Tokens widerrufen, offengelegte Secrets erneuern und auf nicht autorisierte Cloud-Änderungen prüfen ^[4]. Bei Bot-Konten schlägt StepSecurity außerdem vor zu prüfen, ob sie überhaupt die Berechtigung benötigen, den Branch-Schutz zu umgehen ^[2]. Ein starker Anmeldeschutz erschwert Kampagnen mit gestohlenen Konten; siehe Two-Factor Authentication Explained: Which 2FA Method Is Safest?.

Welche Pakete waren betroffen?

Aikido nennt ein Packagist-Paket und ein Go-Modul, die die Schadlast über automatisierte Veröffentlichung aufgenommen haben ^[1].

• Packagist: digitalelvis/neuronai-studio Version 3.14.3; Aikido rät, jeden Rechner, der es installiert oder geöffnet hat, als kompromittiert zu betrachten ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 und v1.0.280; die Schadlast steckt nur in einer GitHub-Actions-Workflow-Datei, der Go-Quellcode und die Binärdateien sind unverändert, und Go-Builds führen nie Workflow-Dateien aus, doch Aikido empfiehlt dennoch, diese Versionen zu entfernen ^[1].

Die Zahlen weichen ab: SafeDep nennt drei Pakete auf Packagist und im Go-Modul-Proxy, die die Schadlast enthalten, und SecurityWeek erwähnt Versionen von zwei Go-Modulen ^[5][4]. SafeDep ergänzt, dass die Schadlast für typische Nutzer, die diese Pakete mit composer require oder go get installieren, nicht ausgeführt wurde ^[5]. Prüfen Sie die aktuelle Liste jedes Forschers, bevor Sie sich auf eine einzelne verlassen.

Wer steckt hinter wfx-loot und wie kam er an die Tokens?

Keiner der hier genannten Berichte identifiziert den Angreifer, und StepSecurity erklärt, nicht geklärt zu haben, wie die Tokens beschafft wurden ^[2][4].

StepSecurity fand 173 Sonden-Pull-Requests von 19 Konten, die mit Tokens der Fly.io-GitHub-App erstellt wurden; es konnte nicht feststellen, wie diese beschafft wurden, und hatte keine Belege dafür, dass die Infrastruktur von Fly.io gehackt wurde ^[2][4].

Aikido fand Überschneidungen mit Konten, die von der GhostAction-Welle im Oktober getroffen wurden, und sah wfx-loot in mehr als 100 Repositories in GhostAction-Workflow-Dateien eingeschleust, bewertete beide aber als getrennte Kampagnen, die wahrscheinlich von verschiedenen Akteuren betrieben werden, da gestohlene Zugangsdaten oft bei mehreren Gruppen landen ^[1]. Außerdem fielen Kommentare in indonesischer Sprache in einigen neueren Malware-Versionen auf ^[1]. Der sorgfältige Umgang mit Tokens ist hier wichtig; Password Managers Explained: How They Work and Whether They Are Safe behandelt die Grundlagen.