Onderzoekers van GitGuardian zagen in augustus een nieuwe variant van de Shai-Hulud infostealer worm. Waar eerdere varianten vooral gericht waren op een beperkt aantal locaties, zoekt deze variant nu naar credentials op 469 plekken binnen ontwikkelomgevingen, CI/CD-tooling, cloudconfiguraties en zelfs configuraties van AI-ontwikkeltools.
Die sprong is niet alleen een technisch detail. Ze laat vooral zien dat aanvallers hun strategie hebben verschoven: in plaats van telkens vertrouwen en relaties “te moeten breken”, grijpen ze de machtige toegang aan die al beschikbaar is in systemen en workflows.
Waarom de sprong naar 469 locaties ertoe doet
Volgens de onderzoekers was de voorganger van deze variant nog bezig met het doorzoeken van 189 paden. Dat is dus meer dan een kleine verbetering: de zoekradius is fors uitgebreid.
De onderliggende redenering blijft hetzelfde. Software supply chains draaien op vertrouwen: ontwikkelaars vertrouwen registries, organisaties vertrouwen maintainers en applicaties vertrouwen dependencies. Aanvallers ontdekten dat ze niet opnieuw hoeven te “hackeren” tot er ergens vertrouwen ontstaat. Ze hoeven alleen te vinden waar die vertrouwensketen al leunt op credentials.
Shai-Hulud credentials worden de verbindingslaag
In moderne omgevingen liggen referenties (tokens, sleutels en wachtwoordachtige secrets) vaak niet alleen in de code zelf. Denk aan plaatsen zoals:
- .env-bestanden
- shell-geschiedenis
- configuraties van pakketbeheerders
- CLI-caches
- CI/CD configuraties
- instellingen binnen ontwikkel-IDE’s
- toegangsmateriaal dat AI-ontwikkelingstools gebruiken
Het effect is dat gestolen Shai-Hulud credentials niet enkel “gegevenslekkage” betekenen. Tokens kunnen als springplank dienen: wat op een developer workstation begint, kan vervolgens toegang geven tot repositories, cloudresources en zelfs kanalen om software te verspreiden.
Van credential theft naar doorlopende supply chain-aanval
De onderzoekers plaatsen dit binnen een bredere categorie supply chain-aanvallen die zoeken naar reeds gecompromitteerde omgevingen met bruikbare referenties. Een simpel scenario: een token op een werkstation kan toegang geven tot broncode. Die code kan weer cloudcredentials bevatten. Vervolgens opent een cloudtoken de weg naar infrastructuur.
In zo’n keten worden credentials de “connectors” tussen componenten. Daardoor kan één besmetting zich voortzetten naar de volgende stap, omdat de gebruikte autoriteit al bestaat.
Publiceren als versneller: waarom publishing tokens extra tellen
Er is één type credential dat volgens de onderzoekers extra aandacht verdient: publishing credentials. Zodra een aanvaller die bemachtigt, verandert credential theft in een distributiekanaal.
Ontwikkelaars en organisaties vertrouwen op pakketpublicatie. Als een attacker via een token een package kan publiceren, dan krijgen buildsystemen en andere partijen die dezelfde trusted flow volgen, automatisch iets binnen. Daarmee wordt de aanval niet alleen verlengd, maar ook “verspreid”.
Wat je als eerste moet doen
De basisaanpak begint bij het verminderen van langdurige, herbruikbare publishing authority:
- Zoek waar publishing tokens in cleartext staan (niet alleen in repositories).
- Vervang waar mogelijk door kortlevende, geverifieerde authenticatie.
- Waar dat nog niet kan: behandel bestaande tokens als hoog-risico infrastructuur.
Daarnaast noemen de onderzoekers expliciet de richting van kortere vensters en identity-backed mechanismen zoals OpenID Connect (OIDC), en het gebruik van federated token services (bijvoorbeeld via STS-achtige benaderingen) waar tooling en cloudplatforms dat ondersteunen.
Credentials zijn niet één teamprobleem
Beveiligingsteams kijken vaak gestructureerd per domein: source control, CI/CD, cloud, endpoint en applicatie. Maar credentials lopen dwars door al die grenzen heen. Eén ontwikkelaar kan in één dag authenticeren richting GitHub, npm, cloudplatformen, Kubernetes en interne API’s.
Daarbij is het cruciaal om te beseffen dat “gevonden geheim” niet gelijk staat aan “zelfde impact”. Een credential die op een laptop staat kan ergens anders juist hoge privileges beheren, bijvoorbeeld in een cloudaccount of bij pakketpublicatie.
Daarom adviseren de onderzoekers om secretsdetectie om te zetten in credential risk management: niet alleen vinden, maar ook begrijpen wat het credential precies mogelijk maakt, welke identiteit erbij hoort en wie het moet remediëren.
Niet elk geheim is even urgent
Een lijst van enorme aantallen secret-findingen betekent niet automatisch dat elk item evenveel schade veroorzaakt. Sommige credentials zijn al ongeldig. Andere verwijzen naar disposable omgevingen. Maar een kleiner aantal kan toegang geven tot productie-infrastructuur of publishing.
De juiste volgorde start met de vraag: wat zou een aanvaller als eerste kiezen? Dat geeft een werkbare prioriteitenlijst in plaats van een backlog die vooral “ruis” produceert.
Praktische prioriteiten voor remediation
De onderzoekers benoemen drie concrete focuspunten. Je kunt ze gebruiken als raamwerk voor je eigen aanpak.
1) Verwijder publishing keys uit cleartext
Dit is de snelste manier om de doorlopende aanvalsketen te breken. Richt je op waar publishing tokens echt accumuleren: lokale configuraties, pipeline-omgevingen en andere plekken waar ontwikkelworkflows secrets parkeren.
Maak vervolgens een plan om herbruikbare publishing authority in de tijd te verminderen. Lukt vervanging nog niet? Dan hoort strakker beheer, ontdekbaarheid, validatie, monitoring en rotatie bij het minimum.
2) Pak blootgestelde production credentials aan
Zelfs als publishing keys zijn aangepakt, blijft er schade mogelijk. Vervolgens gaat de aandacht naar credentials die toegang geven tot kritieke productie-systemen. De onderzoekers noemen als voorbeeldcategorieën:
- product cloudaccounts
- databases met klantgegevens
- signing-infrastructuur
- Kubernetes-clusters
- deployment tooling
- administratieve interfaces
Ook hier helpt validiteit: een geheim dat niet meer geldig is of slechts beperkte scope heeft, weegt minder zwaar dan een credential met write- of admin-toegang richting productie.
3) Rangschik de rest op risico
Pas nadat publishing en de meest kritieke productie-toegang zijn aangepakt, kun je systematisch door de rest heen werken. Het doel is niet om alles willekeurig te roteren, maar om de meest bruikbare autoriteit voor aanvallers als eerste weg te halen.
Volgens de onderzoekers vormen hierbij meerdere contextfactoren het startpunt:
- is het credential nog geldig?
- heeft het toegang tot productie, staging of alleen dev?
- welke identiteit representeert het?
- welke privileges horen daarbij?
- welke resources kunnen het bereiken?
- waar wordt het nog gebruikt?
- wie is eigenaar en kan rotatie of intrekking uitvoeren?
Dit maakt van een “vondstenlijst” een remediatieplan dat je ook kunt auditen.
Maak het geen eenmalige opschoning
De onderzoekers waarschuwen dat je niet alleen moet reageren op de volgende golf. Credentials zullen blijven ontstaan: ontwikkelaars bouwen door, integraties groeien, pipelines veranderen en nieuwe tooling komt in omgevingen terecht.
Daarom heb je volgens hen een herhaalbaar programma nodig met drie onderdelen: zichtbaarheid, prioritering en preventie.
Wat preventie in de praktijk betekent
Preventie draait om het stoppen van het opnieuw opbouwen van de “attack path” in de credential layer. Dat betekent onder meer:
- voorkomen dat nieuwe hardcoded secrets worden toegevoegd
- waar mogelijk overschakelen op kortlevende credentials
- credentials in developer omgevingen beter beschermen
- nieuwe blootstelling vroeg detecteren en remediëren
Zo wordt detection, remediation en prevention een continu proces in plaats van een noodactie na incidenten.
Gerelateerd: waarom supply chain-aanvallen steeds vaker credentials mikken
Als je kijkt naar recente meldingen in de securitywereld, zie je dezelfde rode draad: aanvallers zoeken naar plekken waar autoriteit al aanwezig is. Dat zie je bijvoorbeeld terug bij malware die ontwikkel- en runtime-omgevingen misbruikt, zoals bij misbruik van Node.js runtime voor malwarelevering. Ook aanvallen met phishing gericht op management- of remote tooling passen in het patroon dat toegang vooraf “ergens” aanwezig is.
Verder is het zinvol om supply chain risico’s ook te benaderen vanuit credential- en secretbeheer, omdat infostealers precies die verwachte plekken doorzoeken waar teams nu eenmaal authenticatie configureren.
Conclusie
De uitbreiding van Shai-Hulud naar 469 vindplekken maakt één ding helder: moderne aanvallers jagen op herbruikbare autoriteit die al in ontwikkel- en releaseprocessen ligt. Je wint die race niet door enkel te hopen dat malware je “vertrouwen” niet kan breken, maar door de credential layer als afzonderlijk veiligheidsvraagstuk te behandelen.
Start met het wegnemen van publishing credentials uit cleartext, pak vervolgens productie-credentials met hoge impact aan en rangschik de rest op risico. Pas daarna wordt je aanpak schaalbaar—en voorkom je dat de volgende Shai-Hulud golf nog gemakkelijker credentials kan misbruiken.
Bron: https://thehackernews.com/2026/09/shai-huluds-reach-just-grew-to-469.html
