Fake GitHub security tools are delivering backdoors and information stealers to Windows computers. Projects advertised for scanning, security testing and log analysis carry hidden execution paths. In some cases, building a project starts the malicious code before compilation finishes.
The November 5, 2026 technical disclosure described more than 2,000 infected PCs at the time of the investigation. That figure covers the broader campaign, whose earlier lures targeted gaming and cryptocurrency enthusiasts.
A Build Event Starts The Chain
Malicious Visual Studio project files appear alongside Python and Go code in the repositories. One lure offers a utility for processing network scanner output. Long stretches of whitespace conceal malicious instructions in some source files, while project settings provide another execution route.
In affected .csproj files, a PreBuildEvent launches code before the project compiles. Build events legitimately run shell commands during development. As a result, a person can trigger a command while preparing an application, before choosing to run its finished executable.
This distinction explains the initial trust boundary. The downloaded project supplies instructions to the local build system, which executes them in the developer’s environment. Merely viewing a repository page is a different action. For the documented build route, an actual build must trigger the event; an up-to-date project that skips building does not run that event.
PowerShell Hands Control To A Loader
After the initial execution, a PowerShell script retrieves an encrypted string from a remote source. Decrypting that string reveals an archive download location. The archive then supplies an Electron-based loader, which retrieves further encrypted payloads and configuration data.
Because the first response contains a download instruction, the initial script and the final malware need not arrive together. The chain separates the repository lure, retrieval logic and payload delivery. An apparently small development utility can therefore lead to a substantially different program running locally.
Electron also explains why a desktop package can coordinate these steps. Its main process runs in a Node.js environment with access to operating-system functionality. Unlike code confined to an ordinary web page, that process can perform local application tasks within its available permissions. Here, the malicious application uses its desktop runtime to organize further loading and host changes.
Familiar Process Names Hide Different Code
The loader supports several deployment modes. Its default Mode3 combines attempts to obscure process ancestry, change security settings and interfere with monitoring before placing payloads inside legitimate processes.
For example, it makes explorer.exe appear as a parent and injects code into processes such as RegAsm.exe. These actions affect different evidence. Parentage changes the apparent launch relationship; injection changes the code executing inside the selected process. Consequently, a familiar process name alone does not explain what that process is doing.
Windows nevertheless applies access checks to process operations. Writing another process’s memory and creating a thread require relevant permissions. The disclosure describes privilege-elevation routines, but does not provide enough detail to establish one universal elevation path. Successful access to a repository does not itself grant administrator rights on the computer that downloads it.
The Loader Alters Monitoring Inside Processes
Another Mode3 operation compares the in-memory code of ntdll.dll with the library on disk. It restores original code where it identifies monitoring hooks. Meanwhile, direct system calls provide a separate route around interception points in ordinary library calls.
The loader also patches EtwEventWrite in the affected process. Event Tracing for Windows, or ETW, lets providers emit events that consumers read live or from recorded traces. Altering a process’s event-writing function targets that source of telemetry. It does not demonstrate that every Windows event source or external record disappears.
Separately, the malware patches AmsiScanBuffer, a function used to submit memory content for antimalware inspection. AMSI connects applications, including PowerShell, with antimalware scanning. By changing that function in memory, the loader interferes with a content-inspection path before further malicious activity proceeds. These are distinct attempts to reduce behavioral visibility and script inspection.
A Fallback Route Still Reaches The Payloads
If the main deployment mode fails, Mode2 uses a different sequence. It adds exclusions for selected processes, writes a temporary PowerShell script, decrypts payload files and injects them into RegAsm.exe. The loader then checks connectivity to its command infrastructure.
This fallback matters because one failed launch path need not end the infection attempt. Still, the alternatives do not prove that every technique succeeded on every affected computer. The report also identifies an unfinished component with routines for service-based persistence and downloading the loader again. Those routines describe possible future behavior, rather than a confirmed recovery mechanism already operating across the campaign.
Beyond loading payloads, the malware targets security software and Windows recovery features. Interference with the Volume Shadow Copy Service affects a framework that coordinates backups while applications continue writing data. That behavior adds a recovery concern to an intrusion whose immediate payloads focus on control and theft.
Remote Access And Data Theft Share The Host
The delivered components include the AsyncRAT backdoor, clipboard replacement malware and a separate information stealer. Their roles differ. Remote access enables ongoing control, whereas clipboard substitution changes cryptocurrency payment destinations. The stealer collects browser data, remote-access configuration, VPN settings and account information, then compresses the collection for transfer through a messaging bot.
Those files can extend the significance of a compromised workstation. For example, remote-access settings may reveal service destinations, while stolen browser data can expose account material. However, collecting configuration files does not establish successful access to every system they reference.
Conclusion: A Security Project Became An Execution Path
A project advertised for security work gained the ability to run commands on the computer evaluating it. In the build-event route, that authority took effect before compilation finished. The important decision therefore came when downloaded project instructions entered the local build process, before the promised utility produced a useful result.
After execution, the loader combined payload delivery with changes to security settings, process memory and monitoring functions. Its backdoor and stealer created separate control and data-exposure concerns. Because the monitoring interference operated through specific processes and functions, an investigation must connect the original build activity with later host changes and outbound transfers.
Why This Threat Matters
- Development steps execute code. A build can start malicious commands before anyone launches the finished application.
- Security work supplies the lure. Scanner helpers and analysis utilities offer a plausible reason to download unfamiliar projects.
- Fallback paths extend the attempt. An unsuccessful deployment mode can lead to another route for loading the payloads.
- Local files carry wider exposure. Browser material and remote-access settings can help identify accounts and services requiring investigation.
- Recovery faces deliberate interference. Changes to security software and backup functionality complicate the return to a trusted workstation.
Where Defensive Control Must Operate
Review downloaded build instructions before they execute, and separate evaluation of unfamiliar projects from workstations holding production access. Restrict the permissions and network reach available to evaluation environments. For example, running an unknown utility should not expose the same saved sessions and remote-access configuration used for daily administration.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, provides behavioral visibility, forensic evidence and response for suspicious activity on supported, managed Windows endpoints. Execution Governance restricts unknown executable activity under endpoint policy before it gains access to real resources. Process telemetry helps trace how a project build leads to script execution, loader activity and subsequent payload execution.
Recovery Must Cover The Workstation And Its Access
Isolate affected machines and preserve volatile evidence before rebooting or rebuilding them. Then investigate build commands, downloaded components, injected processes and unauthorized security-setting changes. Scope which browser data, remote-access files and credentials the stealer could reach. Where exposure warrants it, revoke sessions and replace affected secrets from a trusted system. Finally, verify restored endpoint protections and backup availability before reconnecting the workstation, and review account activity for signs that stolen material was used elsewhere.
