How to check a GitHub repo before you build it: build hooks, hidden whitespace and a sandbox

In short

Building a project is running its author's code. Visual Studio lets a project run commands before a build starts, and MSBuild's Exec task hands commands to the system shell, so opening and building a stranger's solution on your main machine is no safer than running a downloaded program. Before you build a repository you do not trust, search it for build hooks and for code hidden behind long runs of whitespace, and then build it inside a disposable environment with no access to your credentials. This guide shows how, using the recent Dr.Web report on fake GitHub security tools as the worked example.

Why a build can be an attack

Most people treat "clone, open, build" as a safe way to read code. It is not, because the build is part of the program.

Microsoft's documentation says Visual Studio lets you "specify custom build commands to run automatically before a build starts or after it finishes". The example it gives is running a .bat file before a build. Those commands follow the Windows command prompt syntax, so anything a command prompt can do, a build event can do, with your user's permissions.

The same is true one level down. MSBuild's Exec task, per Microsoft's reference, "runs the specified program or command" and, instead of starting a process directly, calls cmd.exe on Windows or sh elsewhere. It accepts system commands, executables, batch files and even installers (setup.msi) as its command.

None of that is a flaw. It is how builds copy files, generate code or sign binaries. The risk is that the project you cloned decides what runs.

The case that prompted this guide

On 5 November 2026 Doctor Web published research on infected GitHub repositories (we covered it in our report on Trojan.Loader.3261). It reports that the malicious code sat in .suo and .csproj files of Visual Studio projects and in Python and Go source files, and that at the time of research more than 2,000 PCs were infected. In the .csproj file a PreBuildEvent routine runs the malicious code before the project is compiled; the .suo files contained a PowerShell command; in .py and .go files the code was hidden behind a large number of whitespace characters.

The lures were scanning automation, security testing and log analysis tools, which is an audience that clones small utilities all day. One example Dr.Web shows is a fake helper that claims to parse, clean and format output from the Fscan network scanner.

Step 1: read before you open

Do this on a machine where nothing is at stake, or at least do it in a plain text editor rather than an IDE that may act on project files.

1. Look at the repository itself. Check how old it is, who owns it, whether the code does what the README says and whether it is only a few files. A tiny "helper" with an elaborate installation guide deserves caution. Dr.Web notes the attackers even supplied instructions for installing Visual Studio and cloning the repository.

2. Search for build hooks. In a .NET project, search the project files for PreBuildEvent, PostBuildEvent and <Exec:

   grep -rniE 'PreBuildEvent|PostBuildEvent|<Exec ' .
   

   On Windows PowerShell the equivalent is:

   Get-ChildItem -Recurse -Include *.csproj,*.vbproj,*.props,*.targets,*.suo | Select-String -Pattern 'PreBuildEvent|PostBuildEvent|<Exec '
   

   Not every hit is malicious, because honest projects use build events, but you should be able to read and explain every command it finds. Be wary of anything that starts PowerShell, downloads something, or decodes a string.

3. Search for code hidden behind whitespace. Code pushed far to the right, past the visible edge of your editor, looks like an empty line. This command lists lines in which a long run of spaces or tabs is followed by text:

   grep -rnE '[[:space:]]{100,}[^[:space:]]' .
   

   We tested it on a file with 300 spaces followed by code and it flagged the line. Turn on "show whitespace" and word wrap in your editor, and open the flagged files. The threshold of 100 is our choice; legitimate files rarely need it, but alignment in generated files or data can trigger it.

4. Open the binary files with suspicion. An executable in a "source only" repository is a reason to stop. In Dr.Web's case the heavy lifting was done by Microsoft.exe, an Electron application downloaded by a PowerShell script after the infected file ran, so the repository's own files looked small.

Step 2: if you must run it, use a disposable machine

If you still want to build the project, do it where an infection costs nothing.

On Windows Pro, Enterprise, Pro Education or Education editions (not Home), Microsoft's Windows Sandbox gives you a disposable virtual machine. Microsoft's documentation says that closing the sandbox deletes all software, files and state, that each launch is a fresh instance, and that it uses hypervisor-based virtualization to isolate it from the host. Two details matter for this use:

• Windows Sandbox enables networking by default, and Microsoft warns that this can expose untrusted applications to the internal network. It can be disabled in the Windows Sandbox configuration (.wsb) file.
• For untrusted files, Microsoft suggests opening a sandbox with networking disabled and mapping the folder with the application into the sandbox in read-only mode.

Remember that the Dr.Web malware uses the network: it fetches its next stage from remote hosts and sends data to a Telegram bot. Cutting networking is therefore protective, though it will also stop your build from downloading its dependencies. For a build that needs the network, a separate virtual machine with no saved logins, no shared folders and no VPN to your work networks is the next best choice.

Step 3: keep secrets away from the machine

Dr.Web's stealer collects browser data, FileZilla and MobaXterm configuration, Total Commander FTP settings, VPN settings, messenger files, game account data and Discord tokens. That list is a map of what attackers expect to find on a developer's PC. You reduce the damage of a mistake by not having those things on the machine where you test unknown code:

• Do not sign in to your browser, password manager or chat apps inside the test environment.
• Keep SSH keys, cloud credentials and VPN profiles off it.
• Do not keep crypto wallets there. The same campaign delivers a clipper that swaps wallet addresses in the clipboard.

Step 4: know the signs of a compromise

If you ran something and you are unsure, compare against what Dr.Web published. It reports a PowerShell script written to paths such as C:\Users\Public\Pictures\t.ps1 and L.ps1, an archive unpacked to C:\ProgramData\Windows.Microsoft.Photos with an executable named Microsoft.exe, and Microsoft Defender exclusions for regasm.exe and dwm.exe. It also lists the domains muckanthropic[.]com, muckduck.duckdns[.]org, muckcoding[.]com and muckdeveloper[.]com and the address 130.12.182[.]172. These are specific to that campaign, so a clean result says nothing about other malware.

If any match, treat the machine as compromised: rebuild it from a clean image, and from another device rotate the passwords, tokens and keys that were on it. Our guide on how to rotate leaked environment variables and API keys covers the mechanics for credentials used by services.

What this does not cover

These checks reduce risk; they do not prove a repository is safe. A determined author can hide behaviour in dependencies, in code that looks normal, or in files this guide does not mention, and every language and package manager has its own hooks that run code during installation or build. For each ecosystem you work in, read its documentation for what runs automatically. Our guide to auditing the plugins, hooks and MCP servers your AI coding agent loads applies the same reasoning to tools that act on your behalf.

A short checklist

• Is the project small, new or oddly eager to help? Slow down.
• Search for PreBuildEvent, PostBuildEvent and <Exec and explain every hit.
• Search for long whitespace runs and open the flagged files with whitespace visible.
• Look for executables in a source-only repository.
• Build in a disposable environment, with networking off if the build allows it.
• Keep browsers, keys, VPN profiles and wallets off that environment.

Sources

• Microsoft Learn, "Specify custom build events in Visual Studio"
• Microsoft Learn, "Exec task (MSBuild)"
• Microsoft Learn, "Windows Sandbox"
• Dr.Web, "Insolence beyond belief. Threat actors target information security developers on GitHub" (5 November 2026)
• BleepingComputer, "Fake security tools on GitHub push backdoors and infostealers"