Key Takeaways
- Socket identified a Go module masquerading as a DNS/sub‑domain scanner that actually serves as a first‑stage Windows malware loader, tracked as “Operation Muck and Load.”
- The malicious module was distributed across a minimum of 222 GitHub repositories belonging to ~190 accounts, with over 1,200 versions published—more than 700 of them malicious.
- Abuse of Go’s pseudo‑versioning scheme and a GitHub Actions workflow that force‑pushes a rewritten log every minute inflated the release count and created a reusable fingerprint (email [email protected]).
- The loader launches a hidden PowerShell command that downloads, decodes (via certutil, Base64, XOR), and executes a multi‑stage payload from dynamically resolved URLs found on paste sites, social media, or document platforms.
- Final payloads are delivered as password‑protected 7‑Zip archives hosted as GitHub release assets, extracting to a folder mimicking a legitimate Microsoft Photos install and running Microsoft.exe (hidden).
- Decoded stages map to known remote‑access trojans (AsyncRAT, Quasar, Remcos) and infostealers such as Vidar, plus droppers, spyware, and XMRig cryptominers.
- Lure repositories masquerade as crypto‑wallet tools, automation scripts, Discord/Telegram bots, and game cheats (e.g., a PUBG cheat repo that hid a Vidar‑linked loader).
- Socket links the campaign to a previously reported Sophos cluster (June 2023) sharing the same email address and the “Muck” alias used in muckcoding.com and muckdeveloper.com domains.
- The Go security team blocked the module from the proxy; GitHub has not issued a public response, highlighting the need for vigilant monitoring of dependency sources and anomalous repository activity.
Overview of Operation Muck and Load and Its Discovery
Socket’s threat‑intelligence team uncovered a Go module that pretended to be a utility for scanning DNS records and subdomains but functioned as a first‑stage loader for Windows malware. The researchers traced the module to a sprawling network of at least 222 GitHub repositories spread across roughly 190 distinct accounts. The module’s initial version appeared on January 24 of the current year, and since then it has amassed more than 1,200 released versions, over 700 of which were confirmed to be malicious. Socket coined the campaign “Operation Muck and Load” and reported the offending module to the Go security team, which promptly blocked it from the official Go module proxy to prevent further consumption by developers.
Version Inflation via GitHub Actions Workflow
Go derives a pseudo‑version from the commit timestamp and hash whenever a commit lacks a formal semantic version tag. Socket attributes the enormous version count to the threat actor’s own GitHub Actions workflow, which automatically creates timed commits that each resolve to a distinct pseudo‑version. The workflow performs three actions on each compromised repository: it sets the Git author email to the constant address [email protected], it assigns the visible commit username to the current repository owner, and it force‑pushes a rewritten log file every minute. By counting only repositories where both the distinctive email and the periodic force‑push workflow were present, Socket established a conservative minimum of 222 malicious repos, illustrating how automation can be abused to inflate release histories and obscure attribution.
Technical Details of the First‑Stage Loader
The malicious module’s entry point (main.go) launches a concealed PowerShell process. This command retrieves a blob from the domain muckcoding.com, decodes it using the Windows utility certutil, and then executes the resulting script with an execution‑policy bypass to evade local security restrictions. The decoded script is a multi‑layer loader that employs Base64 encoding followed by XOR decryption. Embedded within one layer is a Turkish‑language comment that translates to “run directly, no other step is needed,” indicating the actor’s confidence in the loader’s self‑sufficiency. This initial stage does not contain any hard‑coded payload URLs; instead, it relies on a resolver mechanism to locate the next stage at runtime.
Dynamic Payload Retrieval Mechanism
Rather than embedding a static download address, the loader’s resolver fetches text from a variety of public platforms—including paste sites, video‑sharing services, social networks, and document hosts—and searches that content for the marker string “LastW.” Once the marker is located, the trailing blob is decrypted with a hard‑coded key to reveal the actual download location for the next stage. Primary dead‑drop locations identified by Socket are Pastebin and a lesser‑known paste service called Rlim. Should those become unavailable, the actor can fall back to YouTube, Instagram, Telegram, Google Docs, or GitCode. Importantly, because the resolver logic resides outside the first‑stage loader, defenders who delete a specific paste or block a final archive URL can be circumvented simply by updating the resolver content on the public platforms, leaving the initial Go module untouched.
Execution and Payload Delivery
The resolved URL points to a password‑protected 7‑Zip archive that is hosted as a GitHub release asset. After downloading the archive, the loader extracts its contents into a directory deliberately named to resemble a legitimate Microsoft Photos installation (e.g., Microsoft Photos\). From this folder it launches an executable named Microsoft.exe in a hidden window, thereby masquerading as a benign system process. Subsequent analysis of the extracted payloads revealed multiple stages that map to well‑known malware families: AsyncRAT, Quasar, and Remcos‑style remote access trojans, alongside infostealer behavior characteristic of Vidar. The use of a concealed Microsoft‑named binary helps the malware blend into normal system activity and evade casual inspection.
Malware Variants and Observed Payloads
Across the analyzed repository set, Socket confirmed at least 14 distinct malware files. These included various Trojan loaders and downloaders, the Vidar infostealer, additional dropper and spyware payloads, and several XMRig‑based Monero cryptominers. Notably, a single Loader.exe file appeared byte‑identically in four separate repositories, suggesting the actor reuses a proven binary across multiple lures to maximize efficiency. The diversity of payload types indicates that the operation is not limited to a single objective; instead, it seeks to harvest credentials, enable persistent remote access, and monetize compromised hosts through cryptocurrency mining.
Lure Themes and Repository Examples
The malicious repositories were crafted to appeal to specific developer or user communities. Common themes included MetaMask and Trust Wallet integrations, seed‑phrase utilities, Binance and PayPal automation scripts, Telegram and Discord bots, and game‑cheat tools for popular titles such as PUBG, Valorant, and Escape from Tarkov. One illustrative example is the repository nrevv1lad/Pubg-DESYNC-Menu, which presented itself as an external cheat for PUBG, complete with an installation guide, while actually harboring a Vidar‑linked Loader.exe in its source tree. By aligning the malware with high‑interest topics, the actor increases the likelihood that developers will unwittingly incorporate the compromised Go module into their projects, thereby widening the infection surface.
Attribution to Earlier Sophos Findings
Socket assesses with high confidence that Operation Muck and Load belongs to the same threat cluster previously documented by Sophos researchers Matt Wixey and Andrew O’Donnell in June 2023. Sophos had traced 141 GitHub repositories, 133 of which were backdoored, to the same email address [email protected] and identified “Muck” as one of the actor’s aliases—a label now embedded in the muckcoding.com and muckdeveloper.com domains used by the campaign. The convergence of email, alias, infrastructure, and tactical patterns strongly suggests a single, persistent operation that has evolved and scaled over time rather than a collection of unrelated incidents.
Response and Remediation
Following Socket’s disclosure, the Go security team blocked the malicious module from the official Go module proxy, preventing new downloads via the standard dependency‑resolution mechanism. As of the time of writing, neither GitHub nor the Go team has issued further public comments regarding the campaign or the underlying abuse of their platforms. This silence underscores the importance of proactive defenses: developers should audit dependencies for unexpected version spikes, monitor GitHub Actions workflows for abnormal force‑push behavior, and consider employing software‑bill‑of‑materials (SBOM) tools to detect anomalous or unsigned modules. Additionally, security teams ought to watch for the telltale signs described—hidden PowerShell calls, certutil usage, and the presence of password‑protected 7‑Zip archives masquerading as legitimate software—to detect and block the loader before it can deploy its downstream payloads.
Conclusion and Significance
Operation Muck and Load illustrates how threat actors can weaponize legitimate development ecosystems—leveraging Go’s versioning semantics, GitHub’s automation features, and public content hosts—to distribute malware at scale while evading simple signature‑based detections. The campaign’s use of diversified lures, dynamic payload resolution, and reusable binaries demonstrates a mature, adaptive approach to supply‑chain attacks. For the broader software‑development community, the findings reinforce the necessity of rigorous dependency vetting, continuous monitoring of repository activity, and the adoption of layered defenses that extend beyond traditional antivirus to include behavioral analysis and provenance verification. By staying vigilant and applying the lessons uncovered by Socket and Sophos, organizations can reduce the risk of falling victim to similarly sophisticated, multi‑stage malware campaigns.