💻 computer science

Beyond Takedown: Measuring Malicious Go Module Persistence in the Wild

This paper reveals a large-scale Go supply chain attack where adversaries repackage legitimate modules with obfuscated malware, demonstrating that relying solely on GitHub searches fails to detect the full scope of the compromise because over 99% of removed malicious artifacts remain retrievable via Go proxies.

Original authors: Minjae Bae, Carter Yagemann

Published 2026-06-26

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Minjae Bae, Carter Yagemann

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of software development as a massive, bustling library where programmers borrow "modules" (pre-written code blocks) to build their own applications. In the Go programming language, this library has a very strict librarian: the Go Proxy.

Here is the story of a recent heist in this library, told simply.

The Heist: "The Fake Book Club"

Attackers decided to steal from the library, but they didn't break the doors down. Instead, they played a game of impersonation.

The Setup: They found popular, legitimate books (legitimate code modules) that everyone trusted.
The Forgery: They created fake copies of these books under their own names. Inside these fake books, they hid a tiny, invisible trap.
The Trap: In the Go world, when you "import" (borrow) a book, the library automatically runs a few setup tasks. The attackers hid a malicious instruction inside these setup tasks. It was like a book that, the moment you opened it, secretly whispered a command to your computer to download and run a virus.
The Hype: To make their fake books look real, the attackers used a "bot army" to give them thousands of "stars" (likes) on GitHub, tricking developers into thinking, "Oh, this must be popular and safe."

The Investigation: Two Ways of Looking

The researchers (Minjae Bae and Carter Yagemann) wanted to see how big this problem really was. They used two different flashlights to look for the thieves.

Flashlight 1: The GitHub Search (The "Shelf" View)
They manually searched the main hosting site (GitHub), looking for suspicious patterns and following the "star" connections between accounts.

What they found: They found 2,113 fake repositories.
The Problem: This flashlight only works if the fake book is still sitting on the shelf. If the library staff removes the book, or if the thief never put it on the main shelf to begin with, this flashlight sees nothing.

Flashlight 2: The Proxy Scan (The "Circulation" View)
They built a special scanner called GOAST (a robot that reads code without running it) to scan the Go Proxy. This is the library's backup system. It keeps a perfect, unchangeable copy of every book that has ever been borrowed, even if the original book is deleted from the shelf.

What they found: They found 2,289 malicious versions.
The Surprise: The Proxy flashlight found 83% more malicious books than the GitHub flashlight did. Many of these fake books were never even on the main shelf, or they had already been removed, but the Proxy still had them.

The Big Discovery: "Takedown" Doesn't Mean "Fixed"

This is the most important part of the story.

Usually, when security teams find a bad book, they ask the library to take it down. They delete the repository on GitHub. They think, "Great, the threat is gone."

The researchers proved this is wrong.

Because the Go Proxy keeps a permanent, unchangeable copy of every module, deleting the source on GitHub does not delete the virus from the ecosystem.

The researchers found that even after the attackers' repositories were deleted or suspended (making them "invisible" on GitHub), 99.4% of those malicious modules were still available and downloadable via the Go Proxy.
It's like the library staff throwing a fake book into the trash, but the library's automated delivery drone (the Proxy) still has a perfect copy in its warehouse and keeps delivering it to customers who ask for it.

The Result

The researchers told the library staff (GitHub and Google) about the problem.

GitHub removed 684 malicious repositories.
Google (the Proxy team) cleaned up 1,377 malicious module versions from their permanent storage.

The Lesson

You cannot fix a software supply chain problem just by cleaning up the "hosting" layer (GitHub). If the "distribution" layer (the Proxy) keeps the bad code, the threat lives on. To truly fix the problem, you have to clean up both the shelf and the warehouse.

Technical Summary: Beyond Takedown: Measuring Malicious Go Module Persistence in the Wild

Problem Statement

The Go ecosystem, a backbone for modern software infrastructure, is increasingly targeted by supply chain attacks. Unlike traditional ecosystems (e.g., npm, PyPI) where attacks are well-documented, Go presents unique challenges due to its execution model and distribution infrastructure. Attackers are repackaging legitimate Go modules under attacker-controlled accounts, embedding obfuscated code that triggers upon import.

A critical gap exists between hosting-layer takedowns (removing repositories from GitHub) and ecosystem remediation. Go's distribution model relies on proxy.golang.org and index.golang.org to ensure reproducibility. Once a malicious module version is published and cached by the proxy, it remains immutable and retrievable even after the original source repository is deleted or suspended. Consequently, relying solely on GitHub-centric visibility fails to capture the full extent of the compromise or ensure true remediation.

Methodology

The authors employed a two-stage, complementary measurement approach to capture the campaign's footprint across both the hosting layer and the distribution layer.

Stage 1: Manual Discovery (Dataset M)

Scope: A manual search across GitHub repositories conducted between March and June 2025.
Technique: The researchers started with a seed set of known malicious repositories and expanded via "stargazer-based pivoting," identifying accounts that coordinatedly starred multiple malicious modules.
Verification: Candidates were filtered using keyword-based pre-filters (e.g., exec.Command, /bin/sh, .Start()) and manually verified to ensure they contained obfuscated strings that reconstructed fetch-and-execute commands (e.g., wget or curl followed by execution).
Result: A high-confidence baseline of 2,113 malicious repositories ( $|M| = 2,113$ ).

Stage 2: Automated Distribution-Layer Measurement (Dataset G)

Scope: A large-scale scan of the Go distribution infrastructure using index.golang.org and proxy.golang.org.
Tool: The authors developed GOAST (Go AST-based Scanner for Threat), a static analysis engine designed to detect specific campaign signatures rather than general malware.
- GOAST parses Go source files into Abstract Syntax Trees (ASTs).
- It identifies process-spawning calls (exec.Command combined with Start, Run, or Output).
- It performs lightweight intra-procedural value propagation to reconstruct obfuscated string arguments.
- It flags a module as malicious only if a reconstructed execution call is paired with a download instruction (e.g., wget/curl to an HTTP(S) URL).
Data Collection: The team collected a chronological feed of 12.3 million index entries from July 2024 to July 2025. After deduplication and filtering for name-sharing behaviors (cloning legitimate module names), they scanned 60,232 suspicious candidates.
Result: 2,289 confirmed malicious module versions ( $|G| = 2,289$ ).

Key Findings

1. Campaign Characterization (RQ1)

The campaign operates via a rigid, automated pipeline with two distinct waves:

Wave 1 (March 2025): Targeted Linux, using slice indexing to reconstruct commands.
Wave 2 (May 2025): Expanded to Windows, utilizing a mix of literal concatenation and slice indexing.
Execution Vector: Both waves exploit Go's global variable initializers, executing malicious code immediately upon package import.
Infrastructure: The campaign relies on a narrow footprint of 20 distinct domains. Linux payloads serve static ELF stagers, while Windows payloads rotate unique PE binaries on a strict 31-day cycle.

2. The Limitations of GitHub-Centric Views (RQ2)

Comparing the manual GitHub set ( $M$ ) with the proxy set ( $G$ ) revealed two critical blind spots:

Discovery Reach Gap (Miss #1): 83.0% of the malicious modules found in the proxy ( $G \setminus M$ ) were never discovered by the GitHub-centric manual workflow. These modules circulated in the proxy without the social signals (stars) required for manual discovery.
Hosting-Layer Volatility (Miss #2): By the time of analysis, 69.3% of the modules in the proxy footprint ( $G$ ) were already "GitHub-unobservable" (repositories deleted or suspended).
Double Miss: 64.3% of the total proxy footprint fell into both categories: they were missed by manual discovery and their hosting repositories were already gone.

3. The Takedown–Remediation Gap (RQ3)

The study quantified the persistence of threats after source removal:

Evidence A (Overlap): For the 74 modules in the intersection ( $M \cap G$ ) that were confirmed dead on GitHub during the June snapshot, 100% remained retrievable via the Go proxy in July.
Evidence B (Scale): Among the 1,586 modules in the proxy set ( $G$ ) that were GitHub-unobservable by August, 99.4% (1,577 modules) were confirmed retrievable via the proxy in July logs.
Conclusion: Simply removing a repository from GitHub does not remediate the threat; the malicious module versions persist in the distribution layer.

Contributions and Significance

The paper makes three primary contributions:

Ecosystem-Scale Measurement: It provides the first comprehensive measurement of an active Go supply chain campaign, characterizing its automation, two-wave evolution, and the rigid structure of its obfuscation.
Quantification of Visibility Gaps: It demonstrates that GitHub-centric views systematically under-scope the actual threat footprint due to discovery reach limits and hosting-layer volatility.
Evidence of the Remediation Gap: It empirically proves that "takedown $\neq$ remediation" in the Go ecosystem, showing that proxy-cached modules remain available long after their source repositories are removed.

Significance:
The authors argue that incident response and remediation in the Go ecosystem cannot rely solely on hosting-layer signals. Because the proxy infrastructure ensures reproducibility, it inadvertently sustains malicious artifacts. Effective remediation requires coordination across both the hosting layer (GitHub) and the distribution layer (Go Proxy/Index). Following responsible disclosure, GitHub removed 684 repositories, and the Google Go team remediated 1,377 module versions, validating the necessity of this cross-layer approach.