De Australische politie (AFP) heeft twee mannen uit West-Australië aangeklaagd in verband met TeamPCP, een vermeende cybercrimegroep die in maart 2026 verschillende open-source componenten zou hebben gecompromitteerd. Het gaat om supply chain aanvallen waarbij aanvallers niet “direct” binnendringen, maar vertrouwensketens misbruiken: publishing-authenticatie, build-pipelines en distributiekanalen.
Volgens de politie en meldingen van internationale instanties is de impact mogelijk groot geweest: van het stelen van publicatie- en CI/CD-gegevens tot het verspreiden van gemanipuleerde releases. In dit artikel zetten we de hoofdlijnen op een rij, inclusief wat organisaties nu concreet kunnen doen.
Wat TeamPCP volgens de aanklacht heeft gedaan
De AFP beschrijft een campagne waarin twee verdachten, Louis Michael Gaebler (23) en Ruben Ian Thomson (21), samen verantwoordelijk zouden zijn voor meerdere strafbare feiten. De zaak kwam rond 27 augustus 2026 voor bij de Perth Magistrates Court, nadat er eerder door de AFP en de Western Australia Police Force doorzoekingen waren uitgevoerd in onder meer Cottesloe, Hamilton Hill en Mandurah.
De kern van de beschuldiging: TeamPCP zou via manipulatie van release- en distributiemechanismen open-source security scanners hebben geraakt en daarna die toegang hebben gebruikt om verderop in de keten schade te veroorzaken. De aanklachten noemen daarbij geen specifiek project dat is gecompromitteerd, maar wel een patroon dat past bij supply chain aanvallen.
Van Trivy en KICS tot LiteLLM: een keten van vertrouwen
Volgens de berichtgeving draaide de aanval om meerdere componenten en een opeenvolging van misbruik. In het kort ziet het scenario er zo uit:
- Trivy en Checkmarx KICS werden in verband gebracht met het compromis van publishing-processen en acties binnen hun eigen ecosystemen.
- Daarnaast zou LiteLLM betrokken zijn, omdat het build- en releaseverkeer gebruikt dat gevoelig kan zijn voor verontreinigde afhankelijkheden.
- De aanvallers zouden publishing-tokens hebben bemachtigd uit één fase en vervolgens later opnieuw hebben ingezet om volgende stappen in dezelfde keten mogelijk te maken.
Een belangrijk detail uit de beschrijving: de build-pipeline van LiteLLM zou Trivy hebben geïnstalleerd zonder het resultaat te vast te pinnen aan een geverifieerde versie. Daardoor kon een “poisoned” scanner vervolgens een publishing-token bemachtigen die daarna werd gebruikt om releases met een achterdeur te pushen.
Waarom CI/CD geheimen zo’n groot risico vormen
De FBI benadrukt in een advies dat organisaties die geraakt zijn in de campagne rekening moeten houden met persistente risico’s. Dat betekent: ook als de initiële compromisfase is gestopt, kunnen gestolen gegevens en tokens nog worden misbruikt zodra een aangesloten omgeving er nog toegang toe heeft.
Concreet adviseert de FBI om, waar van toepassing:
- CI/CD-secrets te roteren (ook continu gebruikte credentials),
- publishing tokens aan te passen of opnieuw te genereren,
- en cloud credentials die tijdens blootstellingsvensters beschikbaar waren opnieuw in te richten.
Ook relevant: het advies noemt dat gecompromitteerde data en credentials “lang na” de eerste inbraak kunnen worden omgezet in wapenbare toegang. Dat sluit aan op het idee achter supply chain aanvallen: je richt je niet alleen op een systeem, maar op een keten van vertrouwen.
Distributiekanalen die in de campagne worden genoemd
De beschrijving van de campagne vermeldt dat het misbruik werd doorgezet via meerdere distributie-ecosystemen. Daarbij gaat het om bekende plaatsen waar software wordt gepubliceerd en waar automatisering vaak leunt op publiek of semi-publiek verifieerbare processen.
In de berichtgeving worden vijf omgevingen genoemd:
- GitHub Actions
- Docker Hub
- npm
- PyPI
- OpenVSX
De aanpak lijkt dus sterk op het “doorvertellen” van toegang: een project levert de tokens voor het volgende project, waardoor de impact kan toenemen zonder dat aanvallers telkens opnieuw vanaf nul hoeven te beginnen.
Omvang en cijfers: wat weten we wel (en wat niet)
De AFP stelt dat het kwaadaardige codewerk mogelijk meer dan 1.000 organisaties wereldwijd heeft beïnvloed. Er wordt bovendien gesproken over het stelen van meer dan 500.000 credentials en minstens 300 gigabytes aan data die is geëxfiltreerd.
Andere partijen publiceerden in maart vergelijkbare getallen, maar met een voorbehoud: wat precies is weggenomen, is niet altijd 1-op-1 te bevestigen. CloudSEK en Hudson Rock kwamen later met eigen reconstructies voor blootstelling en aantallen CI/CD-pipelines.
Daarbij is een nuance belangrijk: credential theft is niet automatisch bewijs dat een specifieke organisatie daadwerkelijk is gecompromitteerd. TeamPCP zou volgens de berichtgeving op een leak-site eind maart een beperkt aantal bevestigde slachtoffers hebben gepubliceerd.
Tot slot: Unit 42 en andere onderzoekers koppelden verschillende exposure-gegevens en karakteristieken aan dezelfde campagne, inclusief overlappende infrastructuur en paden voor malware-installatie.
Wat organisaties nu kunnen doen tegen supply chain aanvallen
Hoewel strafrechtelijke vervolging natuurlijk geen directe technische mitigatie is, laat deze casus wel zien welke maatregelen in de praktijk het verschil maken. Denk daarbij niet alleen aan “patchen”, maar aan het harden van de keten rondom builds, releases en authenticatie.
Op basis van de genoemde FBI-aanpak en de extra aandacht voor release-integriteit, zijn dit de meest zinvolle vervolgstappen:
- Rotatie van tokens en secrets die betrokken waren bij CI/CD en publishing. Ga daarbij niet uit van “we waren toch niet geraakt”.
- Pin dependencies aan geverifieerde versies in build-pipelines, zodat een gemanipuleerde update niet zomaar kan doorwerken.
- Werkflows vastzetten op traceerbare commit-hashes in plaats van zwevende tags, zoals ook in de berichtgeving wordt geadviseerd voor GitHub Actions.
- Zoek op artefacten die in de campagne worden genoemd. De FBI noemt bijvoorbeeld repository-namen die de worm zou creëren, zodat teams gerichter kunnen controleren.
- Behandel exfiltratie-data als “actief risico”. Zet monitoring en toegangsbeheer door, ook nadat packages of releases zijn verwijderd.
De casus laat bovendien zien dat het voor aanvallers voordelig is wanneer build- en releaseprocessen afhankelijk zijn van vertrouwen op pakketindexen en automatische workflows. Door die vertrouwenspunten strakker te maken, verklein je de aanvalsvlakken van supply chain aanvallen.
Praktijkpunt: packages kunnen verdwijnen, maar caching blijft bestaan
Een opvallend detail uit de berichtgeving: zelfs nadat twee gemanipuleerde LiteLLM-builds in de releasegeschiedenis van PyPI zouden zijn verwijderd, bleken ze via directe pakket-URLs nog lange tijd HTTP-antwoorden te geven via het CDN.
Dat betekent dat “verwijderen uit de index” niet automatisch betekent dat alle distributiepunten meteen zijn gewist. Voor verdedigers is het daarom verstandig om ook te controleren welke versies in omgevingen draaien en welke artefacten nog onder de radar kunnen blijven.
Relatie met andere beveiligingsonderwerpen op de site
Als je wilt doorpakken op het bredere thema rond incident response bij moderne aanvallen, is het zinvol om ook te kijken naar hoe teams AI en SOC-processen inzetten, of hoe zij bewijs en vervolgstappen borgen in plaats van alleen alerts te verzamelen. Lees bijvoorbeeld:
- AI SOC zonder alertqueue: van backlog naar bewijs
- Security operations klaar voor AI-aanvallen: zo pak je het aan
- Frontier AI en vulnerability management: wat verandert
Conclusie: harden van de hele softwareketen is geen optie meer
De aanklacht tegen TeamPCP onderstreept hoe ernstig supply chain aanvallen kunnen zijn wanneer aanvallers publishing credentials stelen en vervolgens “via de normale weg” gemanipuleerde componenten in omgevingen laten belanden. Het is niet alleen een kwestie van één scanner patchen; het gaat om de complete keten: build pipelines, afhankelijkheden, authenticatie en distributie.
Wie deze campagne serieus neemt, draait niet alleen op de technische fix, maar richt ook herstel opnieuw in: roteer secrets, pin dependencies, controleer integriteit en behandel gestolen credentials als een langdurig risico. Zo voorkom je dat één compromis meteen kan doorwerken naar de volgende stap in de software supply chain.
Bron: https://thehackernews.com/2026/08/alleged-teampcp-hackers-charged-in.html
