109 Fake GitHub Repositories Used to Deliver SmartLoader and StealC Malware

Developer discovering fake GitHub repository with malicious ZIP and download button

A large-scale campaign recently uncovered shows how attackers abused the trust developers place in open-source hosting to distribute two dangerous malware families, SmartLoader and StealC. By cloning legitimate projects and burying malicious ZIP archives deep inside repository structures, the threat actor made harmful downloads look like routine releases. For many victims the repository looked authentic at a glance: real source files remained intact, but documentation and release links silently pointed to attacker-controlled archives.

The scope and tactics of the campaign

Hexastrike investigators identified 109 malicious repositories distributed across 103 GitHub accounts. The campaign appears to have been active for at least seven weeks and continued to generate new repositories as of April 12, 2026. Repositories were updated in coordinated batches whenever the attacker rotated the hosted ZIP archives, a pattern that suggests centralized control and partial automation. The actor even stuffed unrelated SEO keywords into repository descriptions to improve visibility and lure more victims.

How the fake repositories were constructed

The attacker copied known open-source projects and republished them under different accounts. Rather than changing source code significantly, the operator swapped out the README or added prominent download buttons that pointed to ZIP files stored inside the repository tree. These archives were placed deep in the folder hierarchy so that a casual reviewer might miss them while trusting the project based on name or familiar files. Because the visible source code often remained unchanged, the malicious repositories blended easily with legitimate results in GitHub search.

Technical behavior of SmartLoader and delivery chain

Once a victim downloads and extracts one of the planted ZIP files, execution is simple: a single-line batch script launches a LuaJIT interpreter, which executes a heavily obfuscated Lua payload called SmartLoader. The malware immediately hides its console via Windows API calls and performs anti-debug checks using native shellcode copied into executable memory—techniques designed to frustrate analysis.

Instead of hardcoding a command-and-control address, SmartLoader implements a blockchain “dead drop resolver.” It queries a Polygon smart contract through a JSON-RPC call to polygon.drpc.org to retrieve the current C2 IP address from an on-chain value. This approach lets the operator change infrastructure by updating a single blockchain entry rather than touching every staged sample.

After resolving its active server, SmartLoader sends multipart POST requests containing host fingerprinting data and screenshots to a bare-IP C2. The server responds with encrypted instructions. For persistence, the malware creates two scheduled tasks with benign-sounding names (examples observed include AudioManager_ODM3 and OfficeClickToRunTask_7d7757). One task executes a locally cached Lua stage while the other fetches a fresh encrypted stage from an attacker-controlled GitHub repository—giving the operator a resilient dual-path persistence mechanism.

StealC and follow-on credential theft

SmartLoader’s staging repository also hosted an encrypted payload for StealC, an information-stealing component. SmartLoader was observed decrypting StealC and loading it directly into memory without writing to disk, reducing forensic traces and complicating detection.

Why developers and analysts were deceived

Several factors made the campaign effective. Developers often rely on GitHub’s reputation and project names when selecting code to reuse; cloned projects with intact source files can appear trustworthy at a glance. Deeply nested archives and replaced documentation reduced the chance that a quick scan would reveal malicious artifacts. The use of legitimate-looking scheduled task names and staged, encrypted payloads further hid malicious activity in plain sight.

Detection and defensive recommendations

Based on the investigation, security teams and individual users should consider the following mitigations:

Verify project provenance: Prefer official release mechanisms (GitHub Releases, vendor websites) over ZIPs buried in repository folders. Confirm repository ownership and check commit history before executing downloaded artifacts.
Monitor blockchain RPC usage: Alert on outbound JSON-RPC calls to endpoints like polygon.drpc.org originating from non-browser processes; this can indicate dead drop resolver behavior.
Watch for suspicious script launches: Flag unsigned interpreters or batch-launched executables that reference script files with unusual extensions (.txt, .log) running from user-writable locations such as Downloads or %TEMP%.
Network indicators: Inspect multipart POST requests to bare IP addresses—especially those with URI paths beginning with /api/ or /task/—as they mirror observed SmartLoader exfiltration patterns.
Enforce application control: Block unsigned interpreters and unknown script launchers from executing outside standard installation directories. Limit what can run from user-writable paths.
Schedule-task monitoring: Alert on creation of scheduled tasks that point to executables under %LOCALAPPDATA% or that include raw.githubusercontent.com in command-line arguments.

Conclusion

This campaign highlights the risk of treating GitHub search results and familiar project names as an implicit trust signal. Attackers will continue to exploit platform credibility and simple social-engineering techniques—cloning projects, hiding malicious releases, and leveraging resilient C2 mechanisms like blockchain dead drops—to scale distribution. Strong source verification, behavioral monitoring, and strict execution controls are the best practical defenses against this evolving threat.