💻 computer science

Beyond Takedown: Measuring Malicious Go Module Persistence in the Wild

Dit artikel onthult een grootschalige Go supply chain attack waarbij aanvallers legitieme modules herverpakken met geobfusceerde malware, wat aantoont dat uitsluitend vertrouwen op GitHub-zoekopdrachten faalt om de volledige omvang van de compromittering te detecteren omdat meer dan 99% van de verwijderde kwaadaardige artefacten via Go-proxies nog steeds ophaalbaar blijft.

Oorspronkelijke auteurs: Minjae Bae, Carter Yagemann

Gepubliceerd 2026-06-26

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Minjae Bae, Carter Yagemann

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je de wereld van softwareontwikkeling voor als een enorme, drukke bibliotheek waar programmeurs "modules" (vooraf geschreven codeblokken) lenen om hun eigen applicaties te bouwen. In de programmeertaal Go heeft deze bibliotheek een zeer strikte bibliothecaris: de Go Proxy.

Hier is het verhaal van een recente diefstal in deze bibliotheek, eenvoudig verteld.

De Roof: "De Nep Boekenclub"

Aanvallers besloten te stelen uit de bibliotheek, maar ze braken niet de deuren in. In plaats daarvan speelden ze een spel van impersonatie (identiteitsfraude).

De Voorbereiding: Ze vonden populaire, legitieme boeken (legitieme codemodules) die iedereen vertrouwde.
De Vervalsing: Ze maakten valse kopieën van deze boeken onder hun eigen namen. Binnenin deze nepboken verstopten ze een piepkleine, onzichtbare valstrik.
De Valstrik: In de Go-wereld voert de bibliotheek automatisch een paar voorbereidende taken uit wanneer je een boek "importeert" (leent). De aanvallers verstopten een kwaadaardige instructie binnen deze voorbereidende taken. Het was als een boek dat, op het moment dat je het opent, je computer stiekem een commando fluistert om een virus te downloaden en uit te voeren.
De Hype: Om hun nepboken er echt uit te laten zien, gebruikten de aanvallers een "botleger" om ze duizenden "stars" (likes) op GitHub te geven, waardoor ontwikkelaars werden misleid met de gedachte: "Oh, dit moet wel populair en veilig zijn."

Het Onderzoek: Twee Manieren van Kijken

De onderzoekers (Minjae Bae en Carter Yagemann) wilden zien hoe groot dit probleem werkelijk was. Ze gebruikten twee verschillende zaklampen om de dieven op te sporen.

Zaklamp 1: De GitHub Zoekopdracht (De "Schap"-weergave)
Ze zochten handmatig op de belangrijkste hostingwebsite (GitHub), zoekend naar verdachte patronen en het volgen van de "star"-verbindingen tussen accounts.

Wat ze vonden: Ze vonden 2.113 valse repositories.
Het Probleem: Deze zaklamp werkt alleen als het nepbok nog op het schap staat. Als de bibliotheekpersoneel het boek verwijdert, of als de dief het nooit op het hoofdschap heeft geplaatst, ziet deze zaklamp niets.

Zaklamp 2: De Proxy Scan (De "Circulatie"-weergave)
Ze bouwden een speciale scanner genaamd GOAST (een robot die code leest zonder deze uit te voeren) om de Go Proxy te scannen. Dit is het back-upsysteem van de bibliotheek. Het houdt een perfecte, onveranderlijke kopie bij van elk boek dat ooit is geleend, zelfs als het originele boek van het schap is verwijderd.

Wat ze vonden: Ze vonden 2.289 kwaadaardige versies.
De Verrassing: De Proxy-zaklamp vond 83% meer kwaadaardige boeken dan de GitHub-zaklamp deed. Veel van deze nepbeken stonden nooit eens op het hoofdschap, of waren al verwijderd, maar de Proxy had ze nog steeds.

De Grote Ontdekking: "Takedown" Betekent Niet "Opgelost"

Dit is het belangrijkste deel van het verhaal.

Normaal gesproken, wanneer beveiligingsteams een slecht boek vinden, vragen ze de bibliotheek om het te verwijderen (takedown). Ze verwijderen de repository op GitHub. Ze denken: "Geweldig, de dreiging is weg."

De onderzoekers bewezen dat dit onjuist is.

Omdat de Go Proxy een permanente, onveranderlijke kopie bijhoudt van elke module, verwijdert het verwijderen van de bron op GitHub niet de virus uit het ecosysteem.

De onderzoekers ontdekten dat zelfs nadat de repositories van de aanvallers waren verwijderd of opgeschort (waardoor ze "onzichtbaar" waren op GitHub), 99,4% van die kwaadaardige modules nog steeds beschikbaar en downloadbaar waren via de Go Proxy.
Het is alsof de bibliotheekmedewerkers een nepboek in de prullenbak gooien, maar de automatische bezorgdrone van de bibliotheek (de Proxy) nog steeds een perfecte kopie in zijn magazijn heeft en deze blijft bezorgen aan klanten die erom vragen.

Het Resultaat

De onderzoekers hebben de bibliotheekmedewerkers (GitHub en Google) op de hoogte gesteld van het probleem.

GitHub verwijderde 684 kwaadaardige repositories.
Google (het Proxy-team) heeft 1.377 kwaadaardige moduleversies opgeruimd uit hun permanente opslag.

De Les

Je kunt een probleem in de software supply chain niet oplossen door alleen de "hosting"-laag (GitHub) op te schonen. Als de "distributie"-laag (de Proxy) de slechte code behoudt, leeft de dreiging voort. Om het probleem echt op te lossen, moet je zowel het schap als het magazijn opruimen.

Technische Samenvatting: Voorbij de Takedown: Het Meten van Malicieuze Go-module Persistentie in het Wild

Probleemstelling

Het Go-ecosysteem, een ruggengraat voor moderne software-infrastructuur, wordt steeds vaker het doelwit van supply chain-aanvallen. In tegenstelling tot traditionele ecosystemen (bijv. npm, PyPI), waar aanvallen goed gedocumenteerd zijn, biedt Go unieke uitdagingen vanwege het executiemodel en de distributie-infrastructuur. Aanvallers verpakken legitieme Go-modules opnieuw onder door de aanval beheerde accounts, waarbij geobfusceerde code wordt ingebed die wordt getriggerd bij import.

Er bestaat een kritische kloof tussen hosting-laag takedowns (het verwijderen van repositories van GitHub) en ecosysteem-remediatie. Het distributiemodel van Go vertrouwt op proxy.golang.org en index.golang.org om reproduceerbaarheid te garanderen. Zodra een malicieuze moduleversie is gepubliceerd en gecached door de proxy, blijft deze immuun en ophaalbaar, zelfs nadat de oorspronkelijke bron-repository is verwijderd of geschorst. Daarom faalt het vertrouwen op enkel GitHub-gecentreerde zichtbaarheid om de volledige omvang van de compromittering te vatten of werkelijke remediatie te waarborgen.

Methodologie

De auteurs hanteerden een twee-fasen, complementaire meetaanpak om de voetafdruk van de campagne te vangen over zowel de hosting-laag als de distributie-laag.

Fase 1: Handmatige Ontdekking (Dataset M)

Scope: Een handmatige zoekopdracht naar GitHub-repositories uitgevoerd tussen maart en juni 2025.
Techniek: De onderzoekers begonnen met een seed-set van bekende malicieuze repositories en breidden dit uit via "stargazer-gebaseerd pivoteren", waarbij accounts werden geïdentificeerd die gecoördineerd meerdere malicieuze modules hadden gestarred.
Verificatie: Kandidaten werden gefilterd met behulp van keyword-gebaseerde pre-filters (bijv. exec.Command, /bin/sh, .Start()) en handmatig geverifieerd om te verzekeren dat ze geobfusceerde strings bevatten die fetch-and-execute commando's (bijv. wget of curl gevolgd door executie) reconstrueerden.
Resultaat: Een betrouwbare baseline van 2.113 malicieuze repositories ( $|M| = 2.113$ ).

Fase 2: Geautomatiseerde Distributie-laag Meting (Dataset G)

Scope: Een grootschalige scan van de Go-distributie-infrastructuur met behulp van index.golang.org en proxy.golang.org.
Tool: De auteurs ontwikkelden GOAST (Go AST-based Scanner for Threat), een statische analyse-engine ontworpen om specifieke campagne-signatures te detecteren in plaats van algemene malware.
- GOAST parseert Go-bronbestanden naar Abstract Syntax Trees (ASTs).
- Het identificeert process-spawning calls (exec.Command gecombineerd met Start, Run, of Output).
- Het voert lichte intra-procedurale waarde-propagatie uit om geobfusceerde string-argumenten te reconstrueren.
- Het markeert een module pas als malicieus als een gereconstrueerde executie-call gepaard gaat met een download-instructie (bijv. wget/curl naar een HTTP(S) URL).
Dataverzameling: Het team verzamelde een chronologische feed van 12,3 miljoen index-entries van juli 2024 tot juli 2025. Na deduplicatie en filtering voor naam-delen gedrag (het klonen van legitieme module-namen), scanden zij 60.232 verdachte kandidaten.
Resultaat: 2.289 bevestigde malicieuze moduleversies ( $|G| = 2.289$ ).

Belangrijkste Bevindingen

1. Campagne Karakterisering (RQ1)

De campagne opereert via een rigide, geautomatiseerde pipeline met twee duidelijke golven:

Golf 1 (maart 2025): Gericht op Linux, gebruikmakend van slice indexing om commando's te reconstrueren.
Golf 2 (mei 2025): Uitgebreid naar Windows, gebruikmakend van een mix van literal concatenatie en slice indexing.
Executie Vector: Beide golven exploiteren de globale variabele initializers van Go, waardoor malicieuze code direct bij package import wordt uitgevoerd.
Infrastructuur: De campagne leunt op een smalle voetafdruk van 20 verschillende domeinen. Linux payloads dienen statische ELF stagers, terwijl Windows payloads unieke PE binaries roteren op een strikte cyclus van 31 dagen.

2. De Beperkingen van GitHub-gecentreerde Views (RQ2)

Het vergelijken van de handmatige GitHub-set ( $M$ ) met de proxy-set ( $G$ ) onthulde twee kritieke blinde vlekken:

Ontdekkingsbereik Kloof (Miss #1): 83,0% van de malicieuze modules gevonden in de proxy ( $G \setminus M$ ) werd nooit ontdekt door de GitHub-gecentreerde handmatige workflow. Deze modules circuleerden in de proxy zonder de sociale signalen (stars) die nodig zijn voor handmatige ontdekking.
Hosting-laag Volatiliteit (Miss #2): Op het moment van analyse waren 69,3% van de modules in de proxy-voetafdruk ( $G$ ) al "GitHub-onwaarneembaar" (repositories verwijderd of geschorst).
Dubbele Miss: 64,3% van de totale proxy-voetafdruk viel in beide categorieën: ze werden gemist door handmatige ontdekking en hun hosting-repositories waren al verdwenen.

3. De Takedown–Remediatie Kloof (RQ3)

De studie kwantificeerde de persistentie van dreigingen na bronverwijdering:

Bewijs A (Overlap): Voor de 74 modules in de intersectie ( $M \cap G$ ) die tijdens de juni-snapshot als dood op GitHub werden bevestigd, bleven 100% van hen in juli nog steeds ophaalbaar via de Go-proxy.
Bewijs B (Schaal): Onder de 1.586 modules in de proxy-set ( $G$ ) die in augustus GitHub-onwaarneembaar waren, was 99,4% (1.577 modules) in juli-logs bevestigd ophaalbaar via de proxy.
Conclusie: Het simpelweg verwijderen van een repository van GitHub herstelt de dreiging niet; de malicieuze moduleversies blijven persistent in de distributielaag.

Bijdragen en Significantie

Het paper levert drie primaire bijdragen:

Ecosysteem-brede Meting: Het biedt de eerste uitgebreide meting van een actieve Go supply chain campagne, waarbij de automatisering, de evolutie over twee golven en de rigide structuur van de obfuscatie worden gekarakteriseerd.
Kwantificering van Zichtbaarheids-kloven: Het demonstreert dat GitHub-gecentreerde views de werkelijke dreigingsvoetafdruk systematisch onderschatten door beperkingen in het ontdekkingsbereik en volatiliteit in de hosting-laag.
Bewijs van de Remediatie-kloof: Het bewijst empirisch dat "takedown $\neq$ remediatie" in het Go-ecosysteem, waarbij wordt aangetoond dat door de proxy gecachte modules beschikbaar blijven lang nadat hun bron-repositories zijn verwijderd.

Significantie:
De auteurs stellen dat incident response en remediatie in het Go-ecosysteem niet uitsluitend kunnen vertrouwen op hosting-laag signalen. Omdat de proxy-infrastructuur reproduceerbaarheid garandeert, houdt deze onbedoeld malicieuze artefacten in stand. Effectieve remediatie vereist coördinatie over zowel de hosting-laag (GitHub) als de distributie-laag (Go Proxy/Index). Na verantwoorde openbaarmaking heeft GitHub 684 repositories verwijderd, en het Google Go-team heeft 1.377 moduleversies geremedieerd, wat de noodzaak van deze cross-layer aanpak valideert.