Researchers uncovered a massive GitHub malware campaign that cloned more than ten thousand repositories with fake commit history to silently deliver SmartLoader and StealC malware through hidden ZIP archives.

Have you ever search your own project name and found a repo that looks exactly like yours? It has the same name, same description same commits and even lists you as a contributor. But just an hour ago someone had added a new file with a link to a zip archive in the README file. That single moment caused an independent security researcher uncovering a hidden threat that now serves as a dire warning to millions of developers worldwide.

GitHub Repository Cloning Malware Distribution Campaign Explained

This story begins with a security researcher and his own GitHub project. While searching on Bing he found an exact copy of his repository. It had the same commits, the same contributors and the identical project structure. The only difference was a new commit that added a link to download a zip file in the README.

When the researcher started monitoring these repositories he noticed a clear pattern. Every few hours, the previous commit would be deleted and replaced with the same commit titled Update README.md. Over time, this activity turned into a large-scale pattern. The researcher then began tracking it scientifically using data from GH Archive.

The researcher downloaded around sixteen million commit push events in just five days. In the initial scan he found only three thousand repositories that were being updated every few hours. After manual checking it became clear that the real pattern was much wider.

Once the filters were adjusted and the time range was expanded from one to twenty-four hours, the sample increased to forty thousand repositories. Out of these ten thousand repositories were following the exact pattern seen in the actual attack. This meant that twenty-five percent of the total sample was malicious in its original form.

Each of these repositories contained a hidden zip archive. This archive typically included four files a batch launcher file named Application.cmd or Launcher.bat, a renamed LuaJIT interpreter executable (usually loader.exe, luajit.exe or another generic name), a lua51.dll file, and a heavily obfuscated Lua script hidden behind a .txt or .log extension.

The most clever aspect is that scanning only the zip link on VirusTotal shows zero detections but when the actual zip file is downloaded and scanned, the Trojan inside is clearly detected.

The real malware behind this is called SmartLoader which runs through the LuaJIT engine. The script is heavily obfuscated using a tool called Prometheus so each file is compressed into a single line of nearly three lakh bytes. In this line constants strings and variable names are all encoded.SmartLoader directly calls native Windows APIs using the Foreign Function Interface (FFI).

This means it does not need to write any extra files to disk. It hides its own console window, runs anti-debug checks, takes a fingerprint of the host system, and captures a screenshot.The most impressive engineering part is how SmartLoader resolves its command-and-control server. Instead of hardcoding the server address, it calls a smart contract on the Polygon blockchain network.

This contract returns an encoded string that contains the actual C2 IP address. This technique allows the attacker to change the entire infrastructure simply by updating one value on the blockchain without recompiling the malware or touching any DNS records. It makes traditional takedown efforts extremely difficult because shutting down one server has almost no impact on the overall operation.

Once SmartLoader finds its server it sends the collected information and screenshots directly to the bare IP server using multipart form data. The server then replies with encrypted instructions and a task list. For persistence, the malware creates two scheduled tasks with legitimate-sounding names such as AudioManager or OfficeClickToRun.

One task runs the local cached copy while the other downloads a fresh encrypted stage from GitHub every time. This ensures the infection survives even if the local file is deleted. Researchers also found a second encrypted file in the same staging repository. When decrypted it revealed StealC a well-known information stealer famous for stealing data from browsers and crypto wallets.

SmartLoader StealC Detection Indicators and Mitigation Guide

This entire campaign succeeds because it hides behind the appearance of legitimate developer activity. The first important detection signal is unusual outbound requests to raw.githubusercontent.com and github.com that fall outside normal developer behavior.

Another strong signal is cmd.exe running an unsigned executable with the start command and a .txt or .log file as an argument, especially from temp or downloads folders.Loading lua51.dll from a non-standard path is also a reliable indicator as legitimate software always loads it from proper paths like Program Files.

Any non-browser process communicating with Polygon or other blockchain RPC endpoints is a major red flag, since normal developer tools do not generate such traffic. The highest fidelity indicator is the specific smart contract address and function selector that SmartLoader uses to resolve its C2 server. Multipart POST requests to bare IP addresses starting with /api are also clear signs of data exfiltration.

For mitigation the most important step is source verification. Developers should always download from official releases and be suspicious of any zip file hidden deep inside the repository tree especially if it appears instead of proper GitHub releases or tagged source packages. Organizations should enable traffic inspection at the proxy or TLS layer to catch staged payload retrieval and bare IP exfiltration. Application control policies should block unsigned interpreters and script launchers from running out of user-writable paths.

Network teams should block or monitor egress traffic to Polygon and other blockchain RPC endpoints to neutralize the dead-drop resolver. Restricting raw GitHub downloads also helps stop second-stage staging. Finally project maintainers should regularly search for fake repositories using their project name as these impersonations are very easy to recreate with new names even after old ones are taken down.

This incident once again proves that today’s most dangerous attacks do not come from underground forums but from the very platforms where millions of developers work every day. Until we become more careful about what we trust and this threat will keep returning in new forms.