De supply-chain dreiging GhostAction neemt een nieuwe vorm aan: niet alleen het saboteren van GitHub Actions-workflows, maar ook het lokken van open-source ontwikkelaars via een gecompromitteerde login bij ETS. In de nieuwste variant wordt een stealer verstopt in een “fake font” die in een phishingflow wachtwoorden en 2FA-codes probeert te verzamelen. Daarmee gaat het risico verder dan een tijdelijke workflow-compromitatie: het doelwit kan uiteindelijk een herbruikbare toegangstoken verliezen en indirect meerdere repositories besmetten.
In dit artikel zetten we de belangrijkste elementen van de aanval op een rij, inclusief de gebruikte domeinen, de phishingtechniek en de manier waarop een tweede fase op ontwikkelaarsmachines kan blijven hangen.
Wat GhostAction toevoegt: van workflowmisbruik naar credential theft
Eerder lag de nadruk op het injecteren van kwaadaardige GitHub Actions-workflows in projecten die al gecompromitteerd waren. Nu blijkt de aanvaller slimmer te reageren op beschermingsmaatregelen van GitHub. Waar workflows worden geblokkeerd, verschuift de campagne naar een traject dat draait om het stelen van inloggegevens en het omzeilen van controlemomenten.
OpenSourceMalware beschrijft dat de aanvaller een “credential stealer” lanceert die zich voordoet als een fontbestand. De misleiding richt zich op maintainers en ontwikkelaars die software en tooling beheren voor open-source ecosystemen.
Phishing met GitHub-alerts: het domein als lokmiddel
Een opvallend onderdeel is het gebruik van code-hosting-geïnspireerde domeinen. De campagne registreerde onder meer een domein my-github[.]com, dat werd gekoppeld aan hetzelfde IP-adres dat fungeert als exfiltratiepunt. Dat exfiltratiepunt is dus niet alleen bedoeld om data te ontvangen, maar speelt ook een rol in de phishingflow.
Volgens de waarnemingen is het domein gebruikt in een phishingmail die zich voordoet als een GitHub security alert. De mail is gestuurd vanaf noreply@my-github[.]com en waarschuwt voor een nieuwe login op het account vanuit Moskou. Vervolgens wordt het slachtoffer gevraagd om via een link “de accountactie te beveiligen”.
Reverse-proxy phishing: 2FA en wachtwoorden worden ‘meegenomen’
De nep-pagina werkt niet simpelweg als een pagina waar de gebruiker zelf zijn code moet intypen en vervolgens handmatig toestemming geeft. In plaats daarvan wordt de flow beschreven als een reverse proxy die het slachtoffer in een geautomatiseerde keten trekt.
Concreet claimt OpenSourceMalware dat de pagina een password en een 2FA-code probeert te verzamelen en daarbij JavaScript gebruikt om een OAuth-app heimelijk te autoriseren. Het effect hiervan is dat de aanvaller permissies krijgt die lijken op het resultaat van een echte koppeling, maar dan zonder dat de gebruiker bewust het gehele proces doorziet.
De phishing ondersteunt bovendien een apparaat-achtige OAuth flow: er worden een device code en user code verwerkt, waarna een autorisatieformulier automatisch wordt ingevuld en goedgekeurd via een geauthenticeerde proxied sessie.
OAuth device flow: waarom dit zo schadelijk is
Het uiteindelijke doel van de OAuth-stap is het verkrijgen van een toegangstoken van GitHub. Dat token is niet alleen “eenmalig”; het wordt beschreven als een repository-scoped API-credential. Met zo’n credential kan de aanvaller API-acties uitvoeren die passen bij het GhostAction-gedrag: repositories bekijken en workflowbestanden aanpassen onder .github/workflows/.
Belangrijk detail: de autorisatie wordt uitgevoerd met brede scopes, waaronder permissies om repositories te lezen en te schrijven, Actions-workflows te wijzigen en ook informatie over organisatie-lidmaatschap te kunnen ophalen. Dat vergroot de schaal: één slachtofferaccount kan toegang geven tot meerdere projecten en downstream gebruikers.
Fontbestand als drager: stealerpayload in VS Code automatisering
Naast de phishing is er een tweede, technische laag: een fontbestand dat als payload wordt gebruikt. Volgens de analyse wordt een font geplaatst op een pad als public/fonts/fa-solid-400.woff2. De bestandsnaam komt overeen met een naam die ook voorkwam in een eerdere North Korea-achtige campagne (PolinRider).
Het materiaal in die fontfile is ontworpen om allerlei soorten gevoelige credentials te oogsten. De omschreven lijst bevat onder meer AWS keys, PyPI- en npm-tokens, Git login-informatie, Kubernetes-clustercredentials, SSH private keys en gegevens voor AI-provider diensten zoals Anthropic Claude en Google Gemini.
Daarbovenop wordt een VS Code tasks.json gebruikt met een trigger die draait op het openen van de map in de editor. Het doel: zodra de ontwikkelaar de repository in VS Code bekijkt, kan de credential stealer automatisch starten zonder extra handelingen.
Deze persisterende aanpak verklaart waarom het risico blijft doorlopen, ook nadat de kwaadaardige workflow uit de repository is verwijderd.
Tweede fase via extra workflow: 94 repositories met componenten
Verder beschrijft OpenSourceMalware dat de campagne ook een tweede GitHub Actions workflow meeneemt die geactiveerd wordt als de infostealer niet draait. Die workflow heeft verschillende mogelijke namen (zoals lint.yml, ci-check.yml, audit.yml en code-review.yml, afhankelijk van het scenario), maar de intentie is dezelfde: een fallback die alsnog probeert bevindingen te verzamelen en door te sturen.
In totaal zijn 94 gecompromitteerde repositories geïdentificeerd met deze tweede-staged component. Ze horen bij 66 eigenaren; een deel van de repositories is inmiddels verwijderd, hernoemd of privé gezet. Onder de resterende projecten lijkt het merendeel bovendien langdurig inactief.
Wat ontwikkelaars kunnen doen: tokens intrekken en credentials roteren
De kern van de mitigatie is dat je niet alleen naar de workflow zelf kijkt, maar naar de toegang die ermee is verkregen. De aanbevelingen richten zich op snelle account- en credentialhygiëne:
- Intrek GitHub-toegang en tokens vanaf een ‘schone’ machine (geen geïnfecteerde omgeving of browserprofiel).
- Wijzig wachtwoorden direct en controleer of er verdachte sessies of OAuth-koppelingen actief zijn.
- Audit je repositories op ongebruikelijke workflowwijzigingen, met extra aandacht voor .github/workflows/.
- Roteer elke credential waar de workflows toegang toe zouden kunnen hebben (denk aan cloudkeys, package-tokens en AI-provider accounts).
- Waarschuw gebruikers die de betreffende repositories hebben gekloond of gebruikt, zodat zij hun eigen omgeving kunnen controleren.
Ook in het licht van eerdere incidenten rond gecompromitteerde login bij ETS is het essentieel om te beseffen dat een inlogincident vaak meer is dan “een hack”: het draait om ongeautoriseerde toegang die je inrichtingen kan veranderen of tokens kan uitbuiten.
Extra aandacht: controle op persistence buiten GitHub
Een valkuil bij dit type supply-chain aanval is dat teams alleen wachten tot de workflow is uitgezet. Hier is expliciet beschreven dat een tweede fase kan blijven draaien via een launcher op developer-machines (met VS Code automatisering). Daarom is het zinvol om ook lokaal te controleren op onverwachte scripts, configuratiebestanden en scheduler-achtige taken.
Daarbij is het raadzaam om in je incidentrespons-proces ook te kijken naar: welke tools gebruikten ontwikkelaars recent (zoals VS Code), welke mappen werden geopend, en of er verdacht gedrag optrad kort na het binnenhalen van de repository.
Waarom dit soort aanval groeit: blokkades omzeilen
De analyse suggereert dat de aanvaller zich aanpast wanneer GitHub de kwaadaardige workflows begint te blokkeren. Als secrets niet meer worden geëxtraheerd via workflowuitvoering, wordt de aanval verplaatst naar een kanaal waar de verdediging minder direct kan ingrijpen: de menselijke laag en OAuth/autorisatie.
Dat maakt het risico voor open-source communities groter. Eén gecompromitteerde maintainer of beheerder kan vervolgens toegang geven tot projecten, organisaties en downstream registries en gebruikers.
Snelle checklist voor dit specifieke scenario
Wil je de kans op schade minimaliseren? Gebruik dan deze korte volgorde:
- Controleer of je ooit een phishingmail hebt gekregen die verwijst naar een “nieuwe login” en of je hebt geklikt op een my-github-achtig domein.
- Verwijder of revok e OAuth-apps en tokens die je niet herkent.
- Zoek in repositories naar fonts/paden die niet logisch zijn binnen je normale broncode (zoals fontbestanden met ongebruikelijke payload).
- Check CI-workflows én VS Code configuraties (zoals tasks.json) op triggers die automatisch gedrag starten.
- Rotate credentials: packages, cloud, registries en secrets die door dev-omgevingen worden gebruikt.
Met deze aanpak pak je zowel de gecompromitteerde login bij ETS-achtige impact (tokenverlies en misbruik van machtigingen) als de technische persistence die buiten GitHub kan aanhouden.
Conclusie
GhostAction laat zien dat supply-chain aanvallen kunnen evolueren van “alleen” workflowmanipulatie naar een combinatie van phishing, OAuth-autorisatie en persistence via developer tools. De fake font drager en de reverse-proxy autorisatie maken dat slachtoffers niet alleen data verliezen, maar ook toegangstokens kunnen afstaan die herbruikbaar zijn voor verdere besmettingen.
Door direct toegang te revoken, credentials te roteren en zowel GitHub als lokale ontwikkelconfiguraties te controleren, verklein je de kans dat deze geavanceerde keten nog verder wordt doorgetrokken.
Bron: https://thehackernews.com/2026/10/ghostaction-attackers-plant-credential.html
