Alisina NawabiDe wfx-loot-campagne gebruikt 4.837 gestolen GitHub-accounts om 61.764 repositories op schrijftoegang te testen, meldt Aikido; 10.431 pull requests gingen naar repositories die de accounts niet bezaten.
Een buildjob kan via zo’n repository meer prijsgeven dan broncode: GitHub-tokens, cloudtoegang en sleutels voor AI-diensten. Als de payload draait, moeten geheimen en cloudrollen die de workflow kan bereiken als blootgesteld gelden. Voor Nederlandse teams met GitHub Actions die aan AWS, Azure, GCP of AI-API’s zijn gekoppeld, raakt dit productie- en factureringstoegang.
Een gestolen token test schrijfrechten
De activiteit begon rond 12:45 UTC op 10 november met pull requests getiteld docs: dependency audit notes, vanaf een wfx-docs-branch. De PR testte schrijftoegang, maar bevatte zelf nog geen malware. Aikido zag dat 92 procent ervan openstond. BleepingComputer meldde dat enkele betrokken accounts verbonden waren aan Fortune 100-organisaties, de Amerikaanse General Services Administration, de Franse overheid, Nextcloud en WebdriverIO. Dat zijn accountverbanden, geen bewijs dat die organisaties payloads draaiden.
Waar de token kon schrijven en de CI-inrichting het toeliet, volgde een van drie varianten: ongeveer 1.500 regels in een bestaande Actions-workflow, een nieuw workflowbestand op een korte branch, of een shellscript via een npm-installatiehaak. De aanvaller draaide de wijziging binnen ongeveer een minuut terug en verwijderde de run en logs. De PR-titel, wfx-docs-branches en gaten in opeenvolgende Actions-runnummers zijn daardoor bruikbare sporen. Een open probe-PR bewijst niet dat de payload draaide.
De runner zoekt ook naar AI- en cloudtoegang
Het script van ongeveer 1.500 regels richtte zich op alles wat de runner kon lezen: Actions-secrets en variabelen, de ingebouwde GITHUB_TOKEN, OIDC- en runtimetokens, omgevingsvariabelen, sleutelbestanden, shellgeschiedenis en procesgeheugen. Aikido vond zoekroutines voor OpenAI, Anthropic, Gemini, Hugging Face, Cursor en Copilot. Die namen staan in de code als doelwitten; ze bewijzen niet dat van elk van die diensten een sleutel is buitgemaakt.
Via OIDC, de tijdelijke aanmelding waarmee GitHub-jobs cloudrollen kunnen aannemen, probeerde het script tokens uit te wisselen voor AWS-, Azure- en GCP-toegang. Aikido vond ook code om AWS-sleutels aan te maken, een AWS-rol open te zetten voor andere accounts en Azure-apps een nieuwe vertrouwde GitHub-aanmelding te geven. Dat kan toegang laten bestaan na sleutelrotatie. De functies waren instelbaar; het rapport zegt niet dat elke organisatie ze zag draaien.
De campagne bereikte ook pakketregisters. Aikido noemt Packagist-pakket digitalelvis/neuronai-studio versie 3.14.3 en Go-versies docker-env 1.0.278 en 1.0.280. SafeDep traceerde later ook redock/docker-env 1.0.282 met een Telegram-variant. Een Go-download of -build voert een Actions-workflowbestand niet uit. Een besmet workflowbestand in een pakket is dus niet hetzelfde als een payload die automatisch op iedere machine van een gebruiker draait.
De route naar buiten en de telling veranderen
Aikido beschrijft voor de onderzochte payload een HTTP-post naar twee externe servers. StepSecurity telde op 12 november om 07:40 UTC meer dan 63.000 probe-PR’s en trof in latere samples alleen Telegram als uitgaande route aan; het onderzoek schrijft de aanval toe aan gestolen, geldige tokens en niet aan een kwetsbaarheid in GitHub Actions. De waarnemingen zijn op verschillende tijdstippen gedaan. Een blokkade op alleen de eerder genoemde IP-adressen dekt de latere variant dus niet af.
De aantallen slaan op verschillende stappen. SafeDep vond 8.093 repositories met kwaadaardige commits en traceerde ook redock/docker-env 1.0.282, met een Telegram-variant. De commits kwamen tussen 10 november 12:46 UTC en 12 november 04:36 UTC binnen; het cijfer telt geen bevestigde payloaduitvoeringen. OX Security rapporteerde minstens 1.806 repositories waar geheimen waren geëxfiltreerd.
Aikido’s artikel noemt bovenaan 1.835 repositories waarin de payload draaide en gegevens zijn buitgemaakt, maar later 1.806 repositories met aanwijzingen voor uitvoering en vermoedelijk buitgemaakte gegevens. De Cloud Security Alliance wijst op die niet toegelichte afwijking en op verschillen in meetmoment en methode tussen onderzoekers. De beschikbare rapporten ondersteunen dus geen splitsing waarbij 1.835 het aantal uitvoeringen en 1.806 het aantal exfiltraties zou zijn. Aikido legt niet uit of het om een latere correctie of een andere telling gaat.
GitHub-incidenten hebben verschillende ingangen
De wfx-campagne gebruikt gestolen accounttokens om zelf code in repositories te plaatsen. Microsoft beschreef een andere route: een AI-agent zocht naar openbaar gelekte geheimen en kwam in één waargenomen keten binnen vijf minuten bij Azure Key Vault-data uit. De agent paste na een mislukte aanvraag binnen 28 seconden haar Key Vault-verzoeken aan; Microsofts analyse van die GitHub-scan en cloudtoegang dateert van vóór wfx-loot.
Ook de richting van een eerder softwareketenincident verschilde. Bij LiteLLM leidde een openbare beheersleutel die ruim vier maanden niet was ingetrokken op 10 oktober tot een GitHub-token met eigenaarsrechten. LiteLLM beschrijft hoe de achtergebleven sleutel de aanvaller toegang gaf tot die owner-token. Met dat token volgden tijdelijke workflows die CI-geheimen verzamelden, waaronder twee tokens van LiteLLM-maintainers.
GitHub adviseert de ingebouwde GITHUB_TOKEN alleen de minimale workflowrechten te geven. Dat beperkt wat een kwaadaardige run met die token kan doen, maar trekt andere gestolen credentials niet in en herstelt geen gewijzigde cloudrechten. Als een run is verdwenen, blijven GitHub-auditlogs en cloudidentiteitslogs nodig om te zien wat de runner kon bereiken.
De buildrunner is in deze campagne onderdeel van het identiteitsvlak van een organisatie. Eén korte workflow kon geheimen lezen en cloudrollen proberen te bereiken voordat de zichtbare wijziging verdween. Hoeveel toegang werkelijk is buitgemaakt, blijft afhankelijk van wat de runner kon lezen en van de sporen in GitHub- en cloudlogs.
Veelgestelde vragen
Toegang begint in het ontwerp
Een workflow moet precies toegang hebben tot wat het werk vraagt. Ik denk mee, ontwerp en realiseer automatiseringen end-to-end, self-hosted waar dat kan.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
