Hudson Rock telt 2.488 getroffen bedrijven in gestolen data van LiteLLM-aanval

Beveiligingsbedrijf Hudson Rock heeft de buitgemaakte data van de LiteLLM-aanval in handen en telt daarin 118.829 gedumpte CI/CD-runners, te herleiden tot 2.488 bedrijfsdomeinen.

Daarmee verschuift deze zaak van "mogelijk geraakt" naar een geteld incident. Wie in maart de AI-gateway LiteLLM in een build, container of op een ontwikkelmachine had staan, kan nu op domeinniveau nagaan hoe groot de blootstelling was. De omgekeerde conclusie gaat alleen niet op: een fors deel van de gestolen bestanden bevat wel actieve wachtwoorden en cloudsleutels, maar geen enkel herleidbaar bedrijfskenmerk. Niet op een lijst staan bewijst dus niets.

Wat de cijfers wel en niet zeggen

Er circuleren twee getallen en ze meten iets anders. Onderzoeksbureau CloudSEK publiceerde op 11 augustus een gereconstrueerde dataset en komt uit op ruim 2.500 bedrijven en 434.000 mogelijk blootgestelde CI/CD-pijplijnen. Het bureau zet er zelf een rem op: die cijfers beschrijven blootstelling, geen bewezen inbraak, en de publieke formulering hoort "mogelijk blootgesteld" te blijven.

Hudson Rock telt met een andere meetlat. Het bedrijf zegt het RAR-archief van 153 GB met 433.909 bestanden zelf te hebben bemachtigd en koppelde daarin 118.829 runner-dumps aan 2.488 bedrijfsdomeinen. Dat is geteld uit de daadwerkelijk weggesluisde data, niet gemodelleerd. Het verschil tussen 434.000 en 118.829 is dus geen tegenspraak, maar het verschil tussen mogelijke blootstelling en bevestigde dumps.

Beide partijen hebben een commercieel belang bij een groot getal. Hudson Rock verkoopt threat intelligence en hangt een gratis domeinzoektool aan het onderzoek, CloudSEK verkoopt monitoring van AI-infrastructuur. De onderliggende aanval is in maart wel onafhankelijk uitgeplozen, onder meer door Snyk.

Twee Nederlandse namen op de lijsten

Op de lijst met hoge-zekerheidsmatches van CloudSEK staat Philips, met 5 secrets over 6 pipeline-runs. Hudson Rock noemt TomTom in zijn overzicht van opvallende getroffen organisaties. Beide staan er tussen namen als Amazon Web Services, Cisco, Samsung, Siemens, Volkswagen, Thales en Deloitte.

De aantallen per bedrijf lopen ver uiteen. Orange komt bij CloudSEK uit op 5.642 runs, X Corp op 3.459 secrets, Cisco op 1.900 runs. De zes runs van Philips vallen daarbij in het niet, maar één runner met een geldige cloudsleutel is genoeg om een cloudaccount open te zetten.

Van een kort venster naar een incident van maanden

LiteLLM is nooit direct aangevallen. De CI-pijplijn van het project installeerde beveiligingsscanner Trivy ongepind via de pakketbeheerder van het besturingssysteem, waardoor de al gekaapte scanner vanzelf de build in liep en het PyPI-publicatietoken meenam. Met dat token zette aanvalsgroep TeamPCP op 24 maart de versies 1.82.7 en 1.82.8 op PyPI.

De payload zat in een .pth-bestand in site-packages, dat afgaat zodra de Python-interpreter start, ook als niemand LiteLLM importeert. Daarmee omzeilde het de --ignore-scripts-bescherming waar teams op leunen. De schattingen van het venster lopen uiteen van ongeveer veertig minuten tot bijna drie uur. Geautomatiseerde builds hebben aan minder genoeg.

Wat de stealer meenam staat los van dat venster: SSH-sleutels, AWS-, GCP- en Azure-credentials, Kubernetes-tokens, .env-bestanden en de API-sleutels van de modelleveranciers waar de gateway naartoe routeert. CloudSEK beschrijft dat de malware zelfs de waarden uitlas die GitHub Actions probeert te maskeren, rechtstreeks uit het procesgeheugen. Lukte het wegsluizen niet, dan maakte de malware een publieke repository aan in het GitHub-account van het slachtoffer zelf en zette de buit daar als release-bestand neer.

Wat er nu te doen valt

Het advies van beide onderzoeksbureaus gaat verder dan de LiteLLM-sleutel. Alles wat het besmette proces kon lezen geldt als gelekt: cloud-IAM-sleutels, Kubernetes-serviceaccounts, GitHub- en GitLab-tokens, publicatietokens voor npm en PyPI, database-URL's en de sleutels van je modelleverancier. Hudson Rock adviseert de CloudTrail- en Kubernetes-auditlogs terug te lezen tot 24 maart 2026, site-packages te controleren op onbekende .pth-bestanden en te zoeken naar een systemd-service die zich voordoet als "System Telemetry Service".

Zijn die sleutels al vervangen, dan blijft de vraag welke ervan sinds maart zijn gebruikt vanaf een IP, apparaat of land dat niet klopt. Structureel draait het om versies pinnen tot op de hash, een SBOM bijhouden en installatiescripts uitzetten.

Waarom deze zaak anders ligt

De FBI waarschuwde begin juli al voor TeamPCP en kwam met een opvallend laagdrempelige maatregel: installeer een open-source pakket pas na een minimale leeftijd van zeven dagen. De cijfers van deze week laten zien waarom die wachttijd loont. De besmette versies stonden hooguit uren online en werden in die tijd al door honderdduizenden pijplijnen opgehaald.

Wat deze zaak onderscheidt van de rij eerdere pakketvergiftigingen is de plek in de stack. Een AI-gateway zit per definitie op het kruispunt van je modelsleutels, je cloud en je clusters, en eerder dit jaar bleek dezelfde LiteLLM ook via drie kwetsbaarheden een gewone gebruiker admin-rechten en code-uitvoering te kunnen geven. De aanvalswaarde zit niet in het pakket, maar in alles waar het pakket bij mag. Dat is precies waarom een component van veertig minuten oud een onderzoek van maanden oplevert.