Security researchers disclosed an active malware distribution network using approximately 200 GitHub repositories as command-and-control dead drops — storing obfuscated resolver data that infected Windows systems fetch from GitHub’s own infrastructure to locate the malware’s actual command-and-control server, making the C2 communication appear as legitimate GitHub API traffic to every network security control in the victim’s environment.
How a Malicious Go Module Chains to GitHub-Hosted C2 Resolver Data
The attack begins at the developer supply chain level. A malicious Go module — the infected entry point — is available for developers to import into their Go projects. When a developer includes the compromised module in their code and runs it, the module executes a PowerShell chain that reaches out to the 200-repository GitHub dead drop network. The dead drop repositories do not host the malware payload directly; they store obfuscated resolver data that points the infected system toward the actual command-and-control server where the malware receives its instructions.
The multi-hop chain — Go module to PowerShell to GitHub resolver to live C2 — is architecturally deliberate. Each stage uses a component that is individually explainable: Go module imports are routine developer behavior; PowerShell execution can have legitimate uses; GitHub API requests are expected from development environments. The combination chains those individually plausible components into a covert infection and communication path.
Repository-Stored Resolver Data and the Allowlisted Traffic Problem
The core detection problem is that GitHub.com traffic is broadly allowlisted in enterprise network security. Organizations cannot block GitHub at the firewall or proxy without disrupting legitimate developer workflows — GitHub connectivity is a production dependency for any organization where developers use the platform. Threat actors building C2 infrastructure on GitHub inherit that allowlist privilege for free.
From the perspective of a next-generation firewall, proxy appliance, or network detection system, the malware’s dead drop lookup is indistinguishable from a developer’s routine GitHub API call. Both generate HTTPS requests to GitHub.com domains with valid certificates. Both appear in access logs as normal web traffic. The difference — that one request is fetching resolver data for criminal command-and-control — is not visible at the network layer without understanding the specific repository content being fetched.
200-Repository Redundancy and Why Takedowns Cannot Neutralize the Network Alone
The 200-repository pool provides operational resilience against individual repository removals. When GitHub’s trust and safety team identifies and removes a repository that the dead drop network includes, the malware can reference the remaining repositories to re-establish C2 connectivity. A network with 200 redundant resolver endpoints can absorb significant takedown pressure without losing the ability to direct infected systems to the live C2 server.
This resilience model requires automated detection of the specific dead drop pattern — not individual repository reporting — to effectively neutralize the network. Manual identification and removal of malicious repositories is inherently slower than the attacker’s ability to create or restore alternative dead drops within the pool. Researchers identified the full 200-repository network, which provides the specific infrastructure detail that GitHub would need to conduct an effective coordinated removal.
Why GitHub Infrastructure Is Effective as Criminal C2
The allowlisting advantage is one property of GitHub infrastructure that makes it attractive for C2 purposes. Others include the platform’s high availability, global CDN-backed content delivery, API-level access that does not require the attacker to maintain server infrastructure, and the built-in rate limiting and authentication features that provide the attacker with legitimate infrastructure management tools.
Dead drop C2 techniques using public internet platforms are not new — attackers have previously used social media platforms, cloud storage services, and code repositories for similar purposes. GitHub’s combination of developer-allowlisted status, API access, and content persistence makes it a particularly effective venue for this approach.
How This Campaign Differs From the GitHub Dormant Account Enumeration Attack
The GitHub-based dead drop C2 network and the dormant GitHub account enumeration campaign disclosed separately affect different phases of the attack lifecycle. The dormant account campaign uses GitHub accounts to conduct organizational reconnaissance — mapping employee rosters and repository access before an attack begins. The C2 dead drop network uses GitHub repositories to maintain communication with systems that are already infected — supporting command-and-control after a successful compromise.
The two techniques are distinct in victim profile, attack phase, and mechanism. An organization’s response to the dormant account reconnaissance threat focuses on GitHub organization visibility settings and access controls. The response to the dead drop C2 threat focuses on detecting the malicious Go module before or after execution, identifying PowerShell activity contacting GitHub for resolver data, and auditing Go module dependencies for compromised packages.
