222 GitHub Repositories Linked to Fake Go Package Malware Operation


222 GitHub Repositories Linked to Fake Go Package Malware Operation

Pierluigi Paganini
July 10, 2026

Researchers uncovered 222 GitHub repositories spreading malware through fake Go packages, delivering loaders, stealers, RATs, and cryptominers.

Socket’s security research team started with the investigation of a single malicious Go module: github[.]com/kaleidora/dnsub-scanning-tool, which presented itself as a DNS and subdomain scanning utility. Pulling on that thread exposed something significantly larger: a network of 222 confirmed GitHub repositories across 190 accounts, all built to make malicious or deceptive software projects look active, recently maintained, and worth running.

Socket tracks the operation as Muck and Load, named after the Muck-themed infrastructure it runs on and the staged loading chain it uses to deliver malware.

The confirmed payload set found across these repositories includes trojan loaders, Vidar infostealer, dropper and spyware payloads, and Monero cryptominers tied to XMRig. This wasn’t a collection of empty lure pages. Some repositories directly distributed malware.

The dnsub-scanning-tool module impersonated a legitimate open-source subdomain enumeration project. Its README described real scanner functionality. Its code did something else. Before any scanner logic could run, the module’s main() function launched a hidden PowerShell command that downloaded content from muckcoding[.]com, saved it as api.db, decoded it using certutil, wrote the result as L.ps1, and executed it with execution-policy bypass and a hidden window. As Socket’s report describes it:

“The loader’s execution mode further reinforces malicious intent. It launches PowerShell with a hidden window and then invokes the decoded script with: -ExecutionPolicy Bypass.” reads the report published by cybersecurity firm Socket.

“That flag does not exploit PowerShell by itself, but it is commonly used by malware to avoid local script-execution policy restrictions. In this case, it is paired with hidden execution and a freshly decoded script from an external source, making the intent clear: the Go module is acting as a first-stage Windows loader.”

One more anomaly made the module stand out before anyone even ran it: it had over 1,200 published versions, more than 700 of them malicious, for a small scanner tool created only months earlier. The version volume wasn’t normal release engineering. It was the result of the threat actor’s own GitHub Actions workflow repeatedly generating timestamp commits to manufacture fake development activity.

L.ps1 is a multi-layer PowerShell loader that uses Base64 encoding and XOR decryption to peel through several stages before reaching its actual function. One of the intermediate layers contains a comment in Turkish: “Direkt calistir, baska adim gerekmez,” which translates as “Run directly, no other step is needed.” The final decoded script is a resolver that retrieves encrypted payload-location material from public platforms rather than hardcoding a direct download URL.

The dead-drop sources include Pastebin, a service called Rlim, Muck-themed infrastructure, and fallback locations on YouTube, Instagram, Telegram, Google Docs, and GitCode. The script searches content retrieved from these platforms for a marker string called LastW, extracts the encrypted blob following that marker, decrypts it with a hardcoded key, and resolves the actual payload URL. As Socket explains:

“Rather than hardcoding only the final payload URL, the loader retrieves text from these public locations and searches the returned content for the marker LastW. In the observed dead-drop material, LastW appears as a marker string appended to or placed after the encoded/encrypted blob.” continues the report. “The script uses that marker to identify and extract the encrypted payload-location data, then decrypts the recovered blob with the hardcoded key. The encrypted payload-location blob recovered from the dead-drop material has SHA-256 51cada347262d7b2bcde70552fcdae221625ad75435cee8a9c3e7b67cc47a807.”

The decrypted URL resolves to a GitHub release: a password-protected .7z archive called Quixo.7z. The loader downloads it, extracts it using a 7-Zip binary it stages under C:\ProgramData\zipathh\7zrr.exe, and drops the contents into C:\ProgramData\Windows.Microsoft.Photos, a directory name that mimics a legitimate Microsoft application path without being one. The main executable, Microsoft.exe, launches from that location with a hidden window. It’s signed by Exodus Movement, Inc., not Microsoft, which suggests the threat actor repackaged or renamed a signed Electron-style application component while relying on surrounding scripts for the malicious behavior.

The infrastructure pivot came from a single GitHub Actions workflow signature. Across all 222 confirmed repositories, the same workflow combined a threat actor-linked email address, ischhfd83@rambler[.]ru, with force-push automation, a schedule running every minute, and synthetic commit activity that repeatedly rewrote a timestamp or log file and pushed the result. The visible commit username changed with each repository owner, but the underlying email stayed constant.

“That split between email and username is the fingerprint. The visible commit name changes with each repository owner, but the underlying email remains constant across the cluster.” states the report. “This gives the threat actor owner-specific commit activity at scale while leaving a reusable pivot for defenders.”

The repositories don’t all need to host payloads to be useful to the operation. Their function is to look active and plausible long enough for a target to clone, build, or follow setup instructions. The lure themes were chosen to attract users already inclined to run untrusted code: cryptocurrency and Web3 tooling, wallet integrations, seed-phrase protection utilities, Telegram bots, game auto-farm tools, game cheats, crypters, and offensive automation. The same repository names appeared under multiple accounts, consistent with scripted generation rather than organic development.

Some repositories did host payloads directly. One Exodus-themed repository used a right-to-left-override character in a filename to disguise a Windows .scr executable as something else. One PUBG-themed repository hosted Loader.exe in the source tree, associated with Vidar infostealer. One Warzone-themed repository delivered its payload as a GitHub release asset rather than a source file. A single Loader.exe binary appeared byte-identically across four separate repositories.

The downstream payload activity maps to AsyncRAT, Quasar, and Remcos-style remote access tools alongside infostealer-like behavior. The payload chain modifies Microsoft Defender and UAC settings, establishes persistence through scheduled tasks and services, accesses browser profile data, prepares screenshot collection, and communicates with Telegram or other public web services. API calls including WriteProcessMemory and SetThreadContext appear in dynamic analysis, supporting the assessment that this is a staged post-compromise environment with remote access and credential-theft capabilities.

Socket notes that this activity overlaps with previously reported repository-backdoor campaigns linked to the same ischhfd83 email address, documented earlier by Sophos researchers. The overlap isn’t defined by the email alone.

“We assess with high confidence that Operation Muck and Load is part of the same repository-backdoor activity cluster previously reported around ischhfd83. That assessment does not depend on one mutable indicator.” concludes the report. “The email address and Muck-themed domains are useful pivots, but the stronger basis is the repeated combination of repository automation, lure design, staging architecture, payload delivery, and post-execution behavior.”

The researchers pointed out that the email address, Muck-themed domains, and specific dead-drop URLs are all replaceable. The operational pattern is harder to change.

Socket reported the malicious Go module to the Go security team, which blocked it from the Go module proxy. The GitHub infrastructure was reported to GitHub’s security team. Neither action eliminates the underlying tradecraft, but both reduce the surface available to developers who encounter these repositories through normal search and discovery.

The 222-repository count is intentionally conservative and represents only repositories where the threat actor email and the synthetic GitHub Actions workflow appeared together in the same context, not every suspicious or lure-themed repository the investigation surfaced.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, GitHub Repositories)







Source link

Leave a Reply

Subscribe to Our Newsletter

Get our latest articles delivered straight to your inbox. No spam, we promise.

Recent Reviews


TL;DR

Meta stripped NameTag facial recognition code from its AI app one day after WIRED exposed it on 50 million phones. Meta says no decision has been made.

Meta removed nearly all traces of an unreleased facial recognition system from its smart glasses companion app on Friday, one day after WIRED reported that the software had been quietly embedded in an app installed on more than 50 million phones. The feature, which Meta internally called NameTag, was designed to convert faces captured by the company’s Ray-Ban smart glasses into unique biometric signatures and compare them against a database stored on the user’s device. WIRED also found that faces the system failed to recognise were cropped, indexed, and stored locally for future processing.

Andy Stone, Meta’s vice president of communications, told WIRED on Monday that the feature is “purely exploratory,” adding that no final decision has been made on what to do with it. That characterisation sits uneasily with the evidence WIRED documented. The version of Meta AI published the day of WIRED’s Thursday report contained several code libraries explicitly named for face recognition, a process for running the NameTag recognition pipeline, and a “Person recognised” alert the app would have shown if someone were identified.

Friday’s release stripped all of it out, along with a folder where the app would have stored the cropped images and biometric signatures of unrecognised faces. Meta did not answer WIRED’s questions about why the code was removed or whether the changes were planned before the story was published. A few fragments remain in the latest version, including an internal debug menu label and a dormant link meant to open a recognised person’s profile, pointing to parts of the system that are no longer there.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol’ founder Boris, and some questionable AI art. It’s free, every week, in your inbox. Sign up now!

The gap between Meta’s public statements and the code WIRED found is the central tension. Before the Thursday report, Stone dismissed the findings by writing that the company could not answer questions about how the system would work because “the feature does not exist.” Andrew Bosworth, Meta’s chief technology officer, called the reporting “incredibly misleading” and “absolutely dishonest.” Yet the code was functional enough to include three AI models, one to detect faces, another to crop them, and a third to encode them as biometric data, all embedded in the companion app for a product already at the centre of a mounting privacy crisis.

Meta declined to answer ten questions WIRED posed before publishing, including whether it had already created the database of face profiles NameTag uses, how long the app retains photographs and biometric data of unrecognised people, and whether that data would ever be sent back to Meta’s servers. The company also did not respond to questions about whether it was building NameTag for blind or low-vision users, or to criticism from privacy advocates who warned the system could let stalkers and abusers identify strangers in public.

NameTag first surfaced in February, when The New York Times, citing internal Meta documents, reported that the company was developing face recognition for its smart glasses and considering a launch as early as this year. One internal memo reportedly described releasing the feature during a “dynamic political environment” when privacy and civil liberties advocates would be distracted by other concerns. WIRED subsequently found that much of NameTag’s machinery had been built into the Meta AI app as early as January, months before any public acknowledgement, adding another layer to the company’s pattern of shipping first and disclosing later when it comes to its smart glasses.

Kade Crockford, director of the technology for liberty programme at the American Civil Liberties Union of Massachusetts, said the removal does not undo the original decision to ship the code and pointed to it as evidence that consumer privacy needs stronger legal protection than Congress has been willing to provide. The Massachusetts House of Representatives last week unanimously passed a consumer privacy bill that, if enacted as written, would impose strong enforcement provisions including a private right of action allowing aggrieved users to sue. “State lawmakers need to do their job and step up to protect consumer privacy,” Crockford said.

Meta’s sneaky tactics in slipping the face-recognition code into its smart glasses show exactly why data privacy bills need the teeth of strong enforcement,” Crockford added. “Companies like Meta prioritise their bottom line, so lawmakers need to speak in the only language its C-suite understands.” Whether a code removal prompted by investigative reporting constitutes a victory or merely a tactical retreat depends on what Meta does next, and on whether the regulatory pressure building on both sides of the Atlantic produces enforceable consequences before the feature quietly returns under a different name.



Source link