wfx-loot var en kampanje for å stjele påloggingsinformasjon fra CI-miljøer – systemene som automatisk bygger og tester programvare. Angriperne brukte kompromitterte GitHub-kontoer til å undersøke kodearkiver og, der kontoene hadde skriverettigheter, legge inn kode som kunne hente ut hemmeligheter fra byggeprosessene. Aikido oppga at 4 837 kontoer ble kompromittert og at prøveforespørsler ble sendt til 61 764 kodearkiver. Ifølge selskapets publiserte tall kjørte skadevaren og sendte fra seg påloggingsinformasjon fra minst 1 835 av dem.
4
9
Når skjedde kampanjen – og hvor lenge varte den?
Aktiviteten startet rundt kl. 12.45 UTC 10. november 2026. En rapport angir at perioden med prøveforespørsler varte til kl. 15.00 UTC 11. november – omtrent 26 timer og 15 minutter.
6
7 Dette er det observerte tidsrommet for sonderingen, ikke en bekreftelse på at all kjøring av skadevaren eller senere bruk av stjålne opplysninger stanset da.
Tallene beskriver ulike deler av angrepet:
- 4 837 kontoer ble rapportert kompromittert.
- 61 764 kodearkiver mottok prøveforespørsler. Det er antallet arkiver som ble undersøkt, ikke antallet der skadevaren er kjent for å ha kjørt.
- Minst 1 835 kodearkiver inngår i Aikidos publiserte tall for kjøring av skadevaren og uthenting av påloggingsinformasjon.
9
Noen samtidige rapporter oppga et lavere tall: 1 806.
6
10 Kildene som er tilgjengelige her forklarer ikke forskjellen, så tallene bør behandles som separate rapporterte opptellinger – ikke slås sammen. De underbygger heller ikke den senere påstanden om rundt 1 970 bekreftede offentlige tilfeller blant over 66 000 mål.
Slik testet angriperne tilgangen
Angriperne opprettet pull requests med tittelen docs: dependency audit notes fra grener kalt wfx-docs. Forespørslene fungerte som sonder: De testet om en kompromittert konto kunne skrive til kodearkivet.
3
4
9
Der tilgangene tillot det, la angriperne inn kode i CI-miljøet som skulle stjele hemmeligheter. Kampanjen bygget på gyldige, stjålne påloggingsopplysninger – ikke på en sårbarhet i GitHub Actions.
4
9 OX Security beskriver skadevaren som ett skallskript på omtrent 1 500 linjer.
31
Rapporter beskriver også tilfeller der ondsinnede endringer og arbeidsflytlogger ble fjernet, noe som gjorde etterforskningen vanskeligere.
1
6 Det tilgjengelige materialet støtter det overordnede mønsteret med sondering, kjøring av skadevare og opprydding, men dokumenterer ikke at alle rapporterte innsettingsmetoder eller commit-meldinger ble brukt i hvert enkelt tilfelle.
Hva forsøkte skadevaren å hente ut?
Det dokumenterte målet var påloggingsinformasjon som CI-jobber kunne få tilgang til, blant annet GitHub Actions-hemmeligheter og skytjenesteopplysninger. Rapporteringen omtaler også forsøk på å hente AI-tjenestetokener.
3
9 OX Security lister blant annet opplysninger for AWS, Azure og Google Cloud som mål.
31 Enkelte rapporter sier dessuten at skadevaren kunne lete etter hemmeligheter i minnet til prosesser på en runner-maskin, men utdragene som foreligger, viser ikke hvor ofte dette lyktes.
17
29
En oppsummering beskriver forsøk på å utvide tilgangen gjennom endringer i AWS-tillitspolicyer og Azure-federerte legitimasjonsopplysninger.
5 Dette er rapportert atferd, ikke bevis for at hvert berørte kodearkiv – eller hver skykonto – ble endret. Dokumentasjonen dreier seg om tyveri av påloggingsinformasjon; den viser ikke at kildekode eller kundedatabaser ble stjålet.
9
15
Hva viser sporene – og hva viser de ikke?
Én rapport oppga at 92 prosent av 10 431 prøveforespørsler sendt via tilgang som samarbeidspartner eller organisasjon fortsatt var åpne da de ble undersøkt.
10
19 Det tyder på at mange forespørsler ikke var blitt håndtert på det tidspunktet, men viser ikke at ingen eiere eller sikkerhetsteam hadde oppdaget dem. Prosentandelen gjelder ikke nødvendigvis alle forespørslene.
En veiledning for etterforskning rapporterte også 173 prøveforespørsler fra 19 kontoer med tokener gjennom Fly.io GitHub App. Dette funnet alene viser ikke at Fly.io sin infrastruktur ble kompromittert, eller at skadevaren kjørte i alle kodearkivene som ble nådd via tokenene.
37
Dette bør forsvarere undersøke
Hvis organisasjonen din kan være berørt, skill mellom undersøkt, skadevare lagt inn, skadevare kjørt og påloggingsinformasjon hentet ut i vurderingen. Dette er ulike funn.
- Søk etter tegn på sondering. Se etter pull requests med tittelen
docs: dependency audit notes og grener kalt wfx-docs i kodearkiver kontoene deres kunne skrive til.
9
- Gå gjennom CI- og revisjonslogger. Kontroller arbeidsflytkjøringer, commits, grenaktivitet og tilgjengelige skytjenestelogger. Manglende nummer i arbeidsflytkjøringer kan være et spor, siden rapporter omtaler slettede kjøringer og logger. Et nummerhull alene beviser likevel ikke at et system er kompromittert.
1
24
- Trekk tilbake mistenkt tilgang. Tilbakekall GitHub-tokener som kan være kompromittert, og gå gjennom tilgangene til kontoer, samarbeidspartnere og GitHub-apper.
- Roter alle eksponerte hemmeligheter. Hvis skadevaren kjørte, bør hemmeligheter og skyroller som arbeidsflyten hadde tilgang til, regnes som potensielt kompromittert – ikke bare opplysninger som fortsatt synes i logger.
3
9
- Se etter vedvarende skytilgang. Undersøk uventede endringer i AWS-tillitspolicyer og Azure-applikasjoner eller fødererte legitimasjonsopplysninger, i tillegg til uautoriserte nøkler og andre tilgangsendringer.
5
- Sikre bevis. Ta vare på gjenværende revisjonsdata og logger før dere rydder opp, og dokumenter hvilket stadium av angrepet sporene faktisk underbygger.