Beveiligingsonderzoekers melden een nieuwe aanval waarbij een GitHub CI secret stealer werd uitgevoerd vanuit gehackte GitHub-accounts. In plaats van traditionele malware draait deze campagne vooral op CI-workflows: zodra een workflow draait, kan de aanvaller de geheimen en cloudreferenties verzamelen waar die workflow normaal gesproken bij kan.
Volgens Aikido Security werd de aanpak ingezet met 4.837 gecompromitteerde GitHub-accounts en gestart in 1.806+ repositories. SafeDep bracht daarnaast in kaart dat veel meer repositories kwaadaardige commits ontvingen—wat betekent dat ook teams zonder zichtbare impact toch rekening moeten houden met misbruik.
Wat deed de aanvaller precies?
De aanval begon meestal met het openen van een pull request als test. Die testpulls hadden opvallend dezelfde opzet: een titel in de trant van “docs: dependency audit notes” en afkomstig van een specifieke branchnaam. Het doel was om te verifiëren of het (gecompromitteerde) account daadwerkelijk rechten had om in de repository te schrijven.
Wanneer die controle slaagde, volgde in een deel van de gevallen een payload: de secret stealer werd toegevoegd aan of gekoppeld aan workflows die in CI draaien. In veel gevallen verwijderde of wijzigde de aanvaller de veranderingen weer snel, waardoor sporen moeilijker te vinden zijn.
Waarom CI zo aantrekkelijk is
CI-workflows zijn gebouwd om te automatiseren, maar precies daarom hebben ze toegang tot gevoelige informatie. De stealer is ontworpen om alles te verzamelen wat workflows kunnen “zien”. Daarbij gaat het om onder andere GitHub Actions secrets en variabelen, tokens die workflows gebruiken, en ook referenties voor cloudplatforms en tooling.
De onderzoekers wijzen er bovendien op dat zelfs als logs zijn opgeschoond, of de uitvoering kort lijkt te zijn geweest, de impact groot kan zijn. Met andere woorden: als de stealer gedraaid heeft, moet je alle beschikbare workflow-secrets als gecompromitteerd beschouwen.
Welke repositories werden geraakt?
SafeDep rapporteert dat tussen 12:46 UTC op dinsdag en 04:36 UTC op de dag erna in totaal 8.093 repositories kwaadaardige commits ontvingen. Dat is het totaal voor repositories die minstens één kwaadaardige commit kregen, dus het werkelijke aantal met getroffen impact kan hoger liggen.
In 7.309 van die repositories werd de secret stealer aan een bestaande workflow toegevoegd. In nog eens 771 gevallen kwam de aanpak binnen via een npm postinstall hook, die tijdens npm install ook op de ontwikkelaarsmachine kan worden uitgevoerd.
Testpulls konden al genoeg zijn
Een belangrijk detail: Aikido stelt dat elk account dat een testpull request opende als gecompromitteerd moet worden gezien—ook als de stealer uiteindelijk niet is uitgevoerd. Dat betekent dat je niet alleen hoeft te zoeken naar “zichtbare” payload-uitvoering; de betrokken accounts en hun tokens kunnen al eerder zijn misbruikt.
Waarschuwingssignalen: zo herken je een mogelijke GitHub CI secret stealer
Zoek in repositories waar je kunt schrijven (of waar je organisatorische accounts rechten hebben) vanaf dinsdag in elk geval naar de volgende kenmerken. Meerdere punten tegelijk verhogen de kans dat je met deze campagne te maken hebt.
- Branches: wfx-docs; chore/[a-z0-9]{8} (kortlevend); ci-check-[0-9]{4}
- Pull request titel: “docs: dependency audit notes”
- Commitberichten: bijvoorbeeld “ci: refresh build cache” (met grote workflow-wijzigingen), “chore: add ci helper”, “chore: add dependency audit workflow”, “chore: initial commit” (voor een lege repo), “ci: restore” en “ci: cleanup”
- Specifieke indicator: SHA-256 van het stealer-script: 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf
- Exfiltratie-IPs: 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil en 153.75.82[.]159:8080
Let op: een repository kan “stil” ogen—bijvoorbeeld zonder duidelijke artefacten of stap-samenvattingen—en toch data hebben gelekt. Het ontbreken van een runnummer op een aanvallerscommit wordt door de onderzoekers juist als betrouwbaarder signaal gezien.
Wat werd er gestolen en waar kwam het naar buiten?
De secret stealer verzamelt gegevens uit meerdere bronnen op de runner. De onderzoekers noemen onder meer:
- GitHub Actions secrets en variabelen
- Het workflowgebruikerscontext-token, zoals de GITHUB_TOKEN
- OIDC- en runtime-tokens van Actions
- Sleutels/secret-waarden voor AI-diensten
- Credential files uit standaardlocaties voor AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH en meer
- De repository zelf en recente commits, plus relevante workflow-artifacts
Voor gegevensverzending zagen de onderzoekers vooral HTTP POST richting de genoemde doelen, en in een deel van de cases ook Telegram. In een steekproef van 200 payload-commits gebruikte ongeveer een vijfde Telegram.
Doorgroei naar cloudtoegang
Na het verzamelen van CI-geheimen is de volgende stap volgens SafeDep/Aikido het vergroten van toegang binnen cloudomgevingen. De stealer kan GitHub OIDC-tokens uitwisselen voor sessies voor AWS, GCP en Azure.
Voor AWS kan de aanpak bovendien langlopende toegang creëren door IAM-gebruikers toegangstoetsen te laten maken. Ook worden stappen genoemd om role-trust policies aan te passen, waardoor rollen openstaan voor meer AWS-accounts.
In Azure gaat het onder andere om federated identity credentials die via een herkenbare prefix aan toepassingen worden toegevoegd. Daardoor kunnen workflows later inloggen zonder dat er per se een opgeslagen secret nodig is—zelfs als je daarna tokens roteert.
Zo vind je mogelijke backdoors en tekenen van misbruik
Naast het zoeken naar commits en workflow-wijzigingen adviseren de onderzoekers om ook in cloud- en identity-logs te kijken. Richt je daarbij op indicatoren zoals de naamgeving van federated credentials, en acties die passen bij exchange/assume-role gedrag.
- Entra ID: federated credentials met een prefix die je niet zelf hebt aangemaakt (wfx-ci-*)
- AWS CloudTrail: calls zoals AssumeRoleWithWebIdentity of AssumeRole-sessies met namen die beginnen met wfx-*, gevolgd door CreateAccessKey of UpdateAssumeRolePolicy
- GCP: GenerateAccessToken en SignJwt-achtige calls vanuit je GitHub workload identity pool
- Vault: JWT-logins van de GitHub OIDC-issuer
Extra risico: pakketten en publicatietriggers
Onderzoekers vonden dat de campaign ook via softwaredistributie zijn weg probeerde te vinden. De stealer bereikte ten minste één Packagist package en een Go module via geautomatiseerde publishing-triggers.
Concreet wordt genoemd dat versie 3.14.3 van het Packagist package digitalelvis/neuronai-studio als kwaadaardig wordt beschouwd. Gebruikers wordt geadviseerd machines te behandelen als gecompromitteerd wanneer daar die versie is geïnstalleerd of geopend.
Verder adviseren de onderzoekers om ook bepaalde Go-moduleversies te blokkeren of te verwijderen. Daarbij werd benadrukt dat Go-builds normaal geen GitHub Actions workflowbestanden uitvoeren, waardoor niet elke gebruiker direct getroffen hoeft te zijn—maar veilig is het niet, dus de aanbeveling blijft: verwijder of blokkeer de genoemde versies.
Wat moet je nu doen? Snelle responstips
Als je vermoedt dat jouw repository is geraakt (of als een betrokken GitHub-account een van de testpulls heeft geopend), volg dan een aanpak die gericht is op het “verharden” van credentials en workflows.
- Intrekken en opnieuw opbouwen: revoke commit-author tokens, OAuth-app grants, SSH keys en actieve sessies van de betrokken accounts.
- Activeer extra verificatie: zet 2FA aan op accounts waarvan tokenmisbruik is vastgesteld of aannemelijk is.
- Roteren wat workflows kunnen lezen: roteer alle secrets en variabelen die de repository kan benaderen.
- Let op ontwikkelaarsmachines: als er npm install is uitgevoerd op een commit die door deze campagne geraakt kon zijn, behandel die machine als mogelijk gecompromitteerd en roteer de bijbehorende keys.
- Controleer cloud- en identitysporen: zoek naar federated credentials en assumptie-events volgens de log-indicatoren hierboven.
Interne controle: koppel dit aan je eerdere CI-incidenten
Deze campagne past in een bredere trend waarbij aanvallers niet alleen systemen, maar vooral de software supply chain en CI/CD-automatisering misbruiken. Als je team eerder al tegen vergelijkbare patronen aanliep, is het nuttig om je incidentrespons-checklist te herijken.
Ter vergelijking: in eerdere publicaties op deze site werd ingegaan op exploitatie via web- en applicatiecomponenten, zoals RCE via mod_http2. Hoewel de vector verschilt, blijft het kernprincipe hetzelfde: tijdige patching en snelle validatie van compromittatie zijn cruciaal.
Ook voor organisaties die hun supply chain-omgeving willen versterken, kan het helpen om te kijken naar hoe teams risico’s rond transparency en afhankelijkheden aanpakken, bijvoorbeeld met software transparency: SBOM, AI BOMs en VEX.
Conclusie
De gemelde campagne laat zien hoe krachtig een GitHub CI secret stealer kan zijn wanneer aanvallers via gestolen credentials workflows kunnen beïnvloeden. Het resultaat is dat geheimen en cloudreferenties beschikbaar komen voor de aanvaller, soms met snelle “cleanup” waardoor sporen verdwijnen.
Daarom is het advies helder: controleer op de benoemde branch-, commit- en workflowpatronen, behandel betrokken tokens en sessies als compromis, roteer secrets en variabelen, en onderzoek daarnaast identity- en cloudsporen. Met die combinatie verklein je de kans dat aanvallers na één aanval nog langdurig toegang houden.
Bron: https://thehackernews.com/2026/11/4837-hijacked-github-accounts-ran-ci.html
