AnswersPublished25 sources
Hoe wfx-loot via gestolen GitHub-accounts CI-geheimen buitmaakte
wfx loot gebruikte gestolen GitHub inloggegevens — geen kwetsbaarheid in GitHub Actions — om schrijftoegang te testen in 61.764 repositories. Aikido meldde dat de payload in minstens 1.835 repositories draaide en daar inloggegevens buitmaakte; sommige eerdere berichten noemden 1.806.
Gepubliceerd doorBewerkt met GPT-6 LunaAfbeeldingen gegenereerd met GPT Image 2
Research answer
Key takeaways
- wfx loot gebruikte gestolen GitHub inloggegevens — geen kwetsbaarheid in GitHub Actions — om schrijftoegang te testen in 61.764 repositories.
- Aikido meldde dat de payload in minstens 1.835 repositories draaide en daar inloggegevens buitmaakte; sommige eerdere berichten noemden 1.806.
- Organisaties die mogelijk zijn geraakt, moeten onder meer pullrequests, workflows en cloudtoegang controleren en blootgestelde geheimen rouleren.
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: What was the wfx-loot GitHub credential-theft campaign reported by Aikido Security, when did it begin and how long was it active, how did at. Article summary: wfx-loot was a mass CI credential-theft campaign that used valid stolen GitHub credentials—not a GitHub Actions vulnerability—to place secret-stealing code in repositories the compromised accounts could write to. Aikido . Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
wfx-loot was een campagne voor het stelen van inloggegevens. De aanvallers gebruikten overgenomen GitHub-accounts om repositories te testen en, waar die accounts schrijftoegang hadden, code toe te voegen die geheimen uit CI-omgevingen kon buitmaken. CI staat voor continuous integration: geautomatiseerde processen die code bouwen en testen. Aikido meldde 4.837 gecompromitteerde accounts en pullrequests in 61.764 repositories. Volgens het gepubliceerde overzicht draaide de payload in minstens 1.835 repositories en werden daar inloggegevens weggesluisd.4
9
Wanneer speelde de campagne?
De activiteit begon rond 10 november 2026 om 12.45 uur UTC. Een rapport beschrijft pullrequests om toegang te testen tot 11 november om 15.00 uur UTC — een periode van ongeveer 26 uur en 15 minuten.6
7 Dit is het waargenomen tijdvenster van de tests, niet het bewijs dat alle payloads of het latere gebruik van gestolen gegevens toen stopten.
De genoemde aantallen slaan op verschillende stappen:
- 4.837 accounts werden als gecompromitteerd gemeld.
- In 61.764 repositories werden pullrequests geplaatst om toegang te testen. Dat betekent niet dat de schadelijke code in al die repositories is uitgevoerd.
- Aikido meldde dat de payload in minstens 1.835 repositories draaide en dat daar inloggegevens werden buitgemaakt.
9
Sommige berichten uit dezelfde periode noemden een lager aantal: 1.806 repositories.6
10 De beschikbare berichtgeving verklaart het verschil niet. Behandel de cijfers daarom als afzonderlijke gepubliceerde tellingen, niet als aantallen die bij elkaar moeten worden opgeteld. De beschikbare bronnen onderbouwen ook niet de latere claim van ongeveer 1.970 bevestigde openbare gevallen onder meer dan 66.000 doelwitten.
Hoe de aanvallers toegang testten
De aanvallers openden pullrequests met de titel docs: dependency audit notes, afkomstig van branches met de naam wfx-docs. Die pullrequests dienden als test: ze moesten uitwijzen of een gecompromitteerd account wijzigingen kon aanbrengen in de repository.3
4
9
Waar de rechten dat toelieten, voegden de aanvallers code toe die geheimen uit de CI-omgeving kon stelen. De campagne maakte gebruik van geldige, gestolen inloggegevens en was geen aanval via een kwetsbaarheid in GitHub Actions.4
9 OX Security beschreef de malware als één shellscript van ongeveer 1.500 regels.
31
Volgens berichten werden schadelijke wijzigingen en workflowlogs in sommige gevallen verwijderd, wat onderzoek achteraf bemoeilijkte.1
6 De beschikbare informatie ondersteunt het algemene patroon van toegang testen, de payload uitvoeren en sporen opruimen. Ze bewijst niet dat elke gemelde manier van installeren of elke commitmelding bij elke besmetting is gebruikt.
Welke gegevens waren het doelwit?
Het gedocumenteerde doel was het verzamelen van gegevens die beschikbaar waren voor CI-taken, waaronder GitHub Actions-geheimen en cloudinloggegevens. Ook pogingen om AI-diensttokens te bemachtigen zijn beschreven.3
9 OX Security noemt onder meer inloggegevens voor AWS, Azure en Google Cloud als doelwit.
31 Andere berichtgeving stelt dat de malware het geheugen van processen op de runner kon doorzoeken; de beschikbare fragmenten tonen niet hoe vaak dat lukte.
17
29
Een verzamelde samenvatting beschrijft pogingen om toegang uit te breiden via wijzigingen in AWS-vertrouwensbeleid en federatieve inloggegevens in Azure.5 Dat zijn gemelde technieken, geen bewijs dat elke getroffen repository of elk cloudaccount is aangepast. De beschikbare informatie wijst op diefstal van inloggegevens; ze toont niet aan dat broncode of klantendatabases zijn buitgemaakt.
9
15
Wat zeggen de signalen — en wat niet?
Volgens één bericht stond 92% van de 10.431 test-pullrequests via toegang als medewerker of organisatie nog open op het moment van controle.10
19 Dat wijst erop dat veel verzoeken toen nog niet waren afgehandeld. Het bewijst niet dat repositorybeheerders of beveiligingsteams ze niet hadden opgemerkt. Het percentage geldt bovendien niet noodzakelijk voor alle pullrequests.
Een onderzoeksdraaiboek meldde ook 173 test-pullrequests van 19 accounts met tokens via de GitHub App van Fly.io. Dat gegeven bewijst op zichzelf niet dat de infrastructuur van Fly.io is gehackt, of dat de payload draaide in elke repository die via die tokens werd bereikt.37
Wat kunnen organisaties controleren?
Maak in een incidentbeoordeling onderscheid tussen getest, payload toegevoegd, payload uitgevoerd en inloggegevens buitgemaakt. Dat zijn verschillende bevindingen.
- Zoek naar herkenbare signalen. Controleer repositories waar je accounts schrijftoegang hadden op pullrequests met de titel
docs: dependency audit notesen branches met de naamwfx-docs. - Controleer CI- en auditgegevens. Bekijk workflowruns, commits, branchactiviteit en beschikbare cloudlogs. Ontbrekende runnummers kunnen aanleiding zijn voor nader onderzoek, omdat verwijderde runs en logs zijn gemeld. Een ontbrekend nummer alleen bewijst geen besmetting.
1
24
- Trek verdachte toegang in. Trek vermoedelijk gecompromitteerde GitHub-tokens in en controleer account-, medewerker- en GitHub App-toegang.
- Vernieuw blootgestelde geheimen breed. Als de payload heeft gedraaid, behandel dan alle geheimen en cloudrollen waartoe die workflow toegang had als mogelijk gecompromitteerd — niet alleen gegevens die nog in logs staan.
3
- Controleer op blijvende toegang in de cloud. Onderzoek onverwachte wijzigingen in AWS-vertrouwensbeleid en wijzigingen aan Azure-applicaties of federatieve inloggegevens. Let ook op ongeautoriseerde sleutels en andere wijzigingen in toegangsrechten.
5
- Bewaar bewijsmateriaal. Sla beschikbare auditgegevens en logs op voordat je opruimacties uitvoert. Noteer vervolgens welke fase van de aanval door het beschikbare bewijs wordt ondersteund.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "Hoe wfx-loot via gestolen GitHub-accounts CI-geheimen buitmaakte"?
wfx loot gebruikte gestolen GitHub inloggegevens — geen kwetsbaarheid in GitHub Actions — om schrijftoegang te testen in 61.764 repositories.
What are the key points to validate first?
wfx loot gebruikte gestolen GitHub inloggegevens — geen kwetsbaarheid in GitHub Actions — om schrijftoegang te testen in 61.764 repositories. Aikido meldde dat de payload in minstens 1.835 repositories draaide en daar inloggegevens buitmaakte; sommige eerdere berichten noemden 1.806.
What should I do next in practice?
Organisaties die mogelijk zijn geraakt, moeten onder meer pullrequests, workflows en cloudtoegang controleren en blootgestelde geheimen rouleren.
Sources
bleepingcomputer.comHackers compromise 4,800 GitHub accounts to steal cloud credentials
al-ice.aiProbe, Payload, Vanish: 4,837 Hijacked GitHub Accounts Fed a CI Secret Stealer Across 61,764 Repositories
unbiasedheadlines.comStolen Logins for 4,837 GitHub Accounts Used to Run Secret Stealer in at Least 1,806 Repositories, Researchers Say