Fake GitHub Security Tools Target Windows Developers With Visual Studio Build Malware

Dr.Web says that at the time of Doctor Web's research into this matter, more than 2,000 PCs were infected. The company did not explain how it counted those infections. It also didn't say how many came from the newer security-tool lures and how many from the older crypto-themed repositories. Treat the figure as a vendor estimate, not an audited number.

From crypto cheats to security tools​

The campaign started small. The first samples appeared about two years ago and were disguised as projects for blockchain games, bots and cheats, according to SecurityLab's summary of the Dr.Web findings. The attackers even added beginner instructions for installing Visual Studio and cloning the repository, so people with little development experience could follow along.

Now the target is the security crowd. Dr.Web reports that the malware now lurks in projects related to scanning automation, security system testing, and log analysis, and the malicious payload also includes .go and .py files where malicious code concealed behind a large number of whitespaces. One example posed as a lightweight script that parses, cleans and formats output from the Fscan network scanner. Dr.Web's indicator list names that repository as Trivexqbk/FscanOutput-Beautify.

The choice of target makes sense. Security people clone unfamiliar tools from GitHub all the time, often in a hurry, often on machines that hold credentials, VPN profiles and SSH session configs. SecurityLab put it this way: even an experienced developer risks running someone else's code before the program is even built.

Section summary: The same operation moved from crypto and gaming lures to fake security utilities. Dr.Web counts more than 2,000 infected PCs but gives no method for that count.

How code runs before you compile anything​

The delivery tricks are worth understanding, because none of them need an exploit. Dr.Web found malicious code in the .suo, .csproj files, as well as in Python and Go source code files.

• The .csproj PreBuildEvent: MSBuild runs a project's pre-build event before compilation. Clicking Build is enough to run the attacker's command.
• .suo files: Dr.Web says these Visual Studio solution user-options files contained PowerShell commands. They are rarely committed on purpose and almost nobody reviews them.
• Whitespace padding in Python and Go: The bad code sits far to the right of the visible text, after a long run of spaces. Anyone skimming in an editor without word wrap won't see it. BleepingComputer called this an old technique that still works.

Once the files run, a PowerShell script lands on the system. Dr.Web gives example paths of C:\Users\Public\Pictures\t.ps1 and C:\Users\Public\Pictures\L.ps1. The script fetches an encrypted string from attacker servers or from legitimate services such as YouTube, Telegram, Google Docs, GitCode and Pastebin, which helps the traffic blend in. Decrypting the string gives a download link for an archive called Quixo.7z. That archive comes from attacker infrastructure or GitHub and is unpacked to C:\ProgramData\Windows.Microsoft.Photos. The folder name is meant to look like a harmless Windows component.

Inside "Microsoft.exe"​

The archive holds Microsoft.exe, an Electron-based loader that Dr.Web detects as Trojan.Loader.3261. Dr.Web says version 1.4.5 was the latest when it published. The loader downloads the file Nexara.7z, which contains encrypted payload, configuration information and some auxiliary files; collects system information and relays it to the intruders via a Telegram bot. It also sets itself to restart automatically and tries to raise its privileges.

The Russian outlet CISOClub described more of the loader's internals. It says the loader runs in three stages, uses marker files for persistence, and mutexes mutexone and mutex23, containing the process ID and creation time, ensure the first two stages execute only once. In the first stage it writes configuration to C:\Users\Public\Music\config, downloads the password-protected Nexara.7z archive, decrypts it using AES-256-CTR and extracts payloads into public Windows folders. CISOClub says the system profile sent to the attackers includes screenshots, IP address, geolocation, CPU and GPU details, RAM, Windows version, username, installed antivirus, Defender status and UAC status.

Then the loader starts taking protections apart. In CISOClub's account, the second stage disables or weakens Windows Defender and UAC protection, notifications, Windows Firewall notifications, Volume Shadow Copy and System Restore. It also adds executables and directories to Defender exclusions and deletes existing shadow copies.

Four deployment modes​

The operators call their deployment methods "modes". Dr.Web documents four of them: Mode3, Mode2, Mode3non and Handler. Some coverage mentions only two.

Mode3 is built to get past endpoint defenses. Dr.Web lists six techniques:

1. Parent process spoofing: explorer.exe is made to look like the parent of the malicious process.
2. Smart App Control bypass: the VerifiedAndReputablePolicyState registry value is changed to turn the feature off.
3. ntdll.dll unhooking: a clean copy of ntdll.dll is read from disk and used to overwrite hooks that EDR tools place in memory.
4. Halo's Gate direct syscalls: system calls are made directly, which makes them harder for EDR to intercept.
5. ETW patch: EtwEventWrite is altered in memory so the process stops sending event-tracing telemetry.
6. AMSI patch: AmsiScanBuffer is modified so scripts can run without antivirus scanning them.

If those steps work, the loader injects into RegAsm.exe, dwwin.exe or dwm.exe.

Mode2 is the fallback when the payload modules fail to launch. It adds Defender exclusions for regasm.exe and dwm.exe, drops a randomly named PowerShell script into the temp folder, and decrypts the payloads into RegAsm.exe. Mode3non is similar to Mode3 but uses different bypass techniques. Handler relies only on hardcoded data, and Dr.Web thinks it may be a leftover legacy method.

Section summary: The loader blinds security tools first, then removes recovery options, then deploys its payloads. Its fallback modes give it several ways to get there.

What gets installed​

All four modes deliver three main payloads:

The stealer's target list is especially bad news for admins. Besides browser data, Discord tokens and game accounts, it takes VPN settings, FileZilla XML files, MobaXterm.ini and Total Commander's wcx_ftp.ini. Those files can hold saved hosts, sessions and sometimes credentials for infrastructure. A stolen browser profile is bad enough. A stolen MobaXterm config from a security engineer's laptop could lead straight into servers.

The malware also tries to remove ESET, McAfee and Malwarebytes, and it edits the hosts file to block antivirus vendor domains. Dr.Web also says it deletes everything in system32\drivers\etc except an allowlist (hosts, networks, protocol, services, lmhosts.sam), which it says can stop users from creating or using backups.

Still being developed​

Dr.Web found unused code for downloading another archive, Lodge.7z, which contains an unfinished Electron project called WUDFHost.exe. Based on that code, possible future features include an sc.exe-created service to keep Microsoft.exe running, re-downloading Microsoft.exe if it's deleted, controlling application startup, and self-updating. These features weren't active in what Dr.Web analyzed, but they show the operators are still adding to the malware.

What Windows users and admins should do​

Dr.Web's own advice is to update antivirus databases and scan downloads. Fair enough, but it doesn't cover much, and the report gives no cleanup procedure for infected machines. The checklist below comes from the techniques Dr.Web documented plus standard incident-response practice:

1. Read the project file before you build. Open every .csproj in a text editor and search for PreBuildEvent and PostBuildEvent. Treat any PowerShell, cmd, curl or encoded strings there as hostile until proven otherwise.
2. Be suspicious of committed .suo files. A public repository that ships Visual Studio user-options files is unusual on its own.
3. Turn on word wrap or a whitespace view before reviewing Python or Go files. Watch for unusually long lines or huge horizontal scrollbars.
4. Vet the maintainer, not just the repo. Throwaway accounts with names like Trivexqbk or Glyxoran, no history and keyword-stuffed repo names are red flags.
5. Build untrusted tools in a disposable VM, never on a workstation that has VPN profiles, SSH configs or admin credentials. Keep in mind that the stealer tries to detect VMs, so a VM is not a perfect trap.
6. Hunt for the indicators. Look for C:\ProgramData\Windows.Microsoft.Photos, t.ps1 or L.ps1 under C:\Users\Public\Pictures, C:\Users\Public\Music\config, unexpected Defender exclusions for regasm.exe or dwm.exe, antivirus domains in the hosts file, and traffic to the muck* domains (muckanthropic[.]com, muckcoding[.]com, muckdeveloper[.]com, muckduck.duckdns[.]org) or the IPs 130.12.182[.]172 and 130.12.182[.]209. Dr.Web's published IOC list also includes SHA-1 hashes for each stage.
7. If you find a hit, rebuild the machine. Don't just clean it. This malware turns off Defender, deletes shadow copies, uninstalls third-party antivirus and runs AsyncRAT. Assume everything on it is compromised. From a separate clean device, change every credential the stealer could have reached: browser-saved passwords, VPN, FTP/SFTP, MobaXterm sessions and Discord.

One caveat: the IOCs are specific to this campaign and reflect what Dr.Web saw at the time. Infrastructure changes, so a clean result is not proof of a clean machine.

The bigger picture​

Nothing here required a GitHub breach or a software vulnerability. These are malicious repositories planted on the platform, not a compromise of GitHub itself. The attack relies on how people actually work: clone it, open it, hit Build. Security professionals tend to assume they're too savvy to fall for it, and that confidence is exactly what the campaign relies on. If you're on WindowsForum's security and developer boards, it's worth asking whether your team has a policy for running third-party tools and whether anyone actually follows it.

Bottom line: For two years this group has been using GitHub as a malware delivery channel. It now targets the people who are supposed to catch it. Read the .csproj file before you build, and run tools you haven't vetted in a disposable VM.