Een nieuwe aanvalsmethode laat zien hoe snel Gheist GitHub tokens kunnen leiden tot het lekken van vertrouwelijke data. In een geautomatiseerde campagne worden gestolen GitHub-tokens gebruikt om workflows te plaatsen die alle secrets die een repository kan lezen, in GitHub Actions-logbestanden afdrukken. Vervolgens downloaden aanvallers de loginhoud en worden de runs kort daarna weer verwijderd.
Onderzoeker Wiz beschrijft dat de aanpak al private repositories en GitHub Enterprise-omgevingen heeft geraakt. De schade is extra lastig te stoppen omdat de secrets via GitHub zelf naar buiten komen, zonder dat aanvallers een eigen server of uitgaande verbinding hoeven te gebruiken.
Wat is Gheist en hoe werkt het precies?
De kern van de campagne is dat aanvallers met gestolen tokens workflow-branches laten aanmaken. Elke workflow komt op een nieuwe branch met een naam die begint met ci-sync- gevolgd door zes willekeurige tekens. Het verwijderen van die branch of de run ongedaan maken blijkt niet te werken: als de loginhoud eenmaal is gedownload, is het incident in feite al gebeurd.
Per repository waar de gestolen token toegang toe heeft, commit de aanvaller een bestand in .github/workflows met een specifieke naam: sync-check.yml. Het commitbericht is daarbij kenmerkend: ci: sync config. Zodra die commit wordt gepusht, start GitHub automatisch de betreffende workflow.
Waarom komen secrets toch in logbestanden terecht?
De workflow draait en print vervolgens de jobomgeving en alle secrets die de job kan lezen. Wiz meldt dat GitHub secrets wel kan maskeren in logs, maar dat het masking niet gegarandeerd is zodra waarden worden omgezet of ingekapseld (bijvoorbeeld via codering). In dit geval wordt de output zodanig verwerkt dat de tekst niet meer overeenkomt met de oorspronkelijke secret, waardoor de logregels alsnog de waarde volledig tonen.
Dat is precies het probleem: zelfs als aanvallers geen aparte exploit nodig hebben om secrets uit te lezen, kan het systeem zichzelf verraden door wat het in logs zichtbaar maakt. En doordat het uitvoeren via GitHub Actions loopt, wordt het exfiltratiepad “ingebouwd” in de workflow.
Welke GitHub beveiligingen helpen wel en welke niet?
GitHub heeft een safeguard die verdachte workflow-runs kan pauzeren totdat een collaborator met write-toegang goedkeurt. Wiz rapporteert dat deze beveiliging elke public repository run die zij bekeken wel stopte. Daardoor bleef de payload daar meestal afwachten en kwam het lek niet door.
Maar de bescherming dekt niet alles: volgens Wiz stopt de safeguard niet voor private repositories en ook niet voor GitHub Enterprise Server. In die omgevingen konden de workflow-runs wél afronden en daarna snel worden verwijderd.
De boodschap is helder: “aan de beveiliging hoeven we niet te twijfelen” geldt niet universeel. Vooral bij private data en enterprise-installaties moet je ervan uitgaan dat een gestolen token alsnog workflows kan laten draaien.
De sporen: zo herken je een Gheist-campagne
Wiz geeft concrete indicators die je kunt gebruiken om te controleren of er ci-sync-branches en bijbehorende runs zijn aangemaakt. Let vooral op branches waarbij de enige wijziging vrijwel uitsluitend neerkomt op het toevoegen van .github/workflows/sync-check.yml met het typische commitbericht.
Branch- en commitpatronen
- Branches met naam ci-sync- gevolgd door zes karakters (matching op ^ci-sync-[0-9a-z]{6}$).
- Commitbericht: ci: sync config.
- Wijziging beperkt tot het toevoegen van .github/workflows/sync-check.yml.
Audit logs en tijdsverloop
- Workflow-runs op ci-sync-* branches die binnen ongeveer een minuut na afronding weer worden verwijderd.
- Activiteit van de user agent gheist in de context van die runs.
OIDC en cloud-verificatie
Als je workflows met OIDC inloggen bij een cloudprovider, kun je ook zonder GitHub-logverzameling toch signalen terugvinden in cloud audit logs. Wiz adviseert te zoeken naar rol-aannames of token exchanges waarbij de subject-identifier een ci-sync--branchnaam bevat.
Self-hosted runners: extra verdachte bestanden
Voor omgevingen met self-hosted runners waarschuwt Wiz dat er in joblogs naar specifieke strings en bestandsnamen gekeken moet worden. Daarbij worden onder meer de volgende bestanden genoemd:
- .gdmp_pat
- .gdmp_patg
- .gdmp_sweep
Daarnaast wordt gezocht naar een string die begint met gdmp-pivot in de logcontext. Wiz geeft aan dat een variant van de self-hosted job buggy leek en geen succesvolle run aantoonde, maar het blijft belangrijk om je infrastructuur te checken.
Wat te doen als je een ci-sync-branch vindt?
Wanneer je een mogelijk getroffen repository ontdekt, is snelheid cruciaal. Wiz adviseert een aanpak die draait om rotatie, intrekken en containment.
1) Rotatie van secrets
Rotatie is niet beperkt tot één secret. Je moet elke repository-, organisatie- en omgevingsecret roteren die door die repository (en de betreffende job) gelezen had kunnen worden. Dat geldt ook voor secrets die alleen gelden voor specifieke environments.
2) Tokens intrekken en herkomst checken
Intrek de tokens waarmee de commits zijn gepusht. Controleer daarna de toestellen/devices van de token-eigenaren, met extra aandacht voor signalen van token-diefstal.
3) Zelf gehoste runners: behandel het als gecompromitteerd
Als de kwaadaardige workflow op een self-hosted runner gedraaid heeft, adviseert Wiz om zowel de machine als de cloud instance role als gecompromitteerd te behandelen. Dat betekent: niet alleen “de repo schoonmaken”, maar ook je runtime-omgeving isoleren en opnieuw opbouwen indien nodig.
4) Niet goedkeuren, niet opnieuw uitvoeren
Tot slot: keur geen “helden” workflow-runs goed die van het verdacht ogende sync-checktype lijken afkomstig. Ook moet je geen code uitvoeren vanaf ci-sync-branches.
Hoe maak je gestolen tokens minder schadelijk?
Wiz noemt maatregelen die de impact van Gheist GitHub tokens beperken. De gedachte daarachter is: zelfs als een token wordt misbruikt, moeten aanvallers zo weinig mogelijk “leesrechten” en “go-to” mogelijkheden krijgen.
- Beperk reviewer-toegang voor environments met productie-secrets, zodat een job niet automatisch overal bij kan.
- Beperk OIDC-trust policies tot protected branches of tot specifieke environments.
- Werk waar mogelijk met GitHub Apps of met short-lived fine-grained tokens in plaats van personal access tokens.
- Voer self-hosted runners uit als kortlevende machines en vermijd extra toegang: bijvoorbeeld geen Docker socket en beperk toegang tot cloud metadata.
GitHub’s documentatie zegt bovendien dat een job environment-secrets pas kan lezen na vereiste reviewer-approval. Dat geeft je dus een extra “gate” als je die zorgvuldig inricht.
Gerelateerde aandachtspunten: tokens en workflow-risico’s
Deze campagne sluit aan bij een bredere trend: aanvallen proberen niet alleen accounts te plunderen, maar vooral workflow-automatisering als datakanaal te misbruiken. Heb je te maken met token-gerelateerde incidenten, dan zijn de volgende onderwerpen relevant om naast Gheist te bekijken:
- Token replay-aanvallen in Microsoft 365 en wat dat betekent voor token-hygiëne.
- AI-agent risico’s in ransomwareketens, omdat geautomatiseerde tooling ook misbruikt kan worden om stappen te versnellen.
- Malicious AGENTS.md in downloads: een voorbeeld van hoe extensies en opslaglocaties soms de keten vormen.
Conclusie
Gheist laat zien dat gestolen GitHub tokens niet alleen “inloggen” betekenen, maar ook het vermogen om de eigen CI/CD-keten te laten lekken. Doordat de aanval draait via GitHub Actions logs én vervolgens runs snel verwijdert, moet je meer dan alleen “events terugkijken” doen.
Check daarom systematisch op ci-sync-branches en het kenmerkende sync-check workflowbestand, controleer audit logs met de gheist user agent en roteer alle secrets die potentieel gelezen konden worden. Door reviewers, beperkte OIDC-trust en kortlevende tokens in te zetten, verlaag je bovendien de kans dat één gestolen token direct tot volledige datadiefstal leidt.
Bron: https://thehackernews.com/2026/10/gheist-uses-stolen-github-tokens-to.html
