A new and well-planned malware campaign has been actively targeting enterprise administrators, DevOps engineers, and security analysts by hijacking their everyday search habits.
Rather than using mass phishing or broad spam waves, threat actors behind this operation have carefully crafted a delivery chain that puts dangerous software directly in front of high-privilege IT professionals when they search for routine administrative tools online.
The campaign works by poisoning search engine results across multiple major platforms, including Bing, Yahoo, DuckDuckGo, and Yandex.
When IT staff search for tools like PsExec, AzCopy, Sysmon, LAPS, or KustoExplorer, the search results surface fake, professional-looking GitHub repositories at the top of the page.
These repositories appear clean and legitimate, containing no malicious code on their surface.
They act purely as a gateway, quietly redirecting unsuspecting users to a secondary, hidden GitHub account where the actual malware is hosted and distributed.
Atos analysts identified this sophisticated, high-resilience malicious campaign in March.
Researchers confirmed that the campaign remains highly active and has undergone significant technical maturation since its inception, with several distinct variants and additional command-and-control (C2) infrastructure identified over time.
The malware at the center of this campaign is a multi-stage, fileless-style Remote Access Trojan (RAT) written in JavaScript.
Atos researchers confirmed it to be EtherRAT, a recently emerging threat that uses the Ethereum blockchain to store its live C2 server address, effectively preventing traditional domain takedown or IP-blocking efforts.
The malware is distributed through malicious MSI installers disguised as tools like PsExec, AzCopy, Sysmon, LAPS, and KustoExplorer, which are almost exclusively used by personnel with elevated network and system permissions.
A successful infection on an administrator’s workstation can provide threat actors with the keys to an entire enterprise environment.
The psychological element of this campaign is particularly aggressive. Many of the impersonated tools are the same ones security professionals use to investigate and respond to malicious activity.
This creates an ironic situation where a defender, trying to diagnose a perceived issue using a tool like Process Explorer or TCPView, inadvertently introduces the very threat they were trying to find.
Dual-Stage GitHub Delivery Chain
The campaign uses a carefully separated, two-stage delivery architecture designed to stay alive even when parts of it are taken down.
The first GitHub repository serves only as a clean-looking facade. It is SEO-optimized and contains a professional README file with no malicious code, building initial trust with both users and security tools.
Embedded within that README is a link pointing to a second, hidden GitHub account. This secondary repository hosts the actual malicious MSI payload.
By separating the SEO-visible storefront from the payload delivery account, the threat actors can rapidly rotate their distribution repositories if flagged, while the primary search-indexed facade remains active and untouched.
Between early December 2024 and April 2026, the threat actors deployed 17 separate GitHub facades, each spoofing a different administrative or developer tool, indicating a sustained effort to maximize search engine visibility and capture a diverse range of high-privilege victims.
When a victim downloads and runs the MSI, four files are extracted and a CMD batch script is launched via a Custom Action at SYSTEM privilege immediately after file extraction.
The entry point is a heavily obfuscated Windows batch script launched at SYSTEM privilege by the MSI Custom Action immediately after file extraction.
Its primary obfuscation mechanism splits all sensitive command names, including curl, tar, copy, start, and cmd, across multiple SET variable assignments that are silently concatenated at runtime, ensuring no recognizable keywords appear in the raw file and defeating simple string-based static analysis.
Stage 2 is a minimal Node.js script, unobfuscated and fully readable, that is never saved to disk.
.webp)
Its main goal is to read a file containing a second-stage encrypted payload, decrypt it using a hardcoded key and initialization vector (IV), and execute it in memory. It also creates persistence via a registry Run key.
.webp)
Stage 3 is the malware’s main payload, a JavaScript file that runs silently in the background on every system boot inside conhost.exe, a legitimate Windows process, so it does not stand out in Task Manager.
Organizations can take the following steps to reduce the risk posed by this campaign:
- Block access to the public Ethereum (ETH) RPC endpoints used by EtherRAT, listed in the Appendices section of the Atos TRC GitHub repository.
- Review historical network logs to identify any outbound communications with the listed RPC ETH endpoints and identified historical C2 domains.
- Increase awareness among IT personnel regarding the risks of sourcing critical utilities from search engine results; require use of verified internal software centers or direct, authenticated vendor portals for all administrative tools.
- Look for behavioral patterns in telemetry: repeated, high-frequency beacons (every ~500ms) to suspicious external domains, periodic outbound requests (every ~5 minutes) to public ETH RPC endpoints, and suspicious process trees involving node.exe processes executing shell commands.
- Treat any usage of conhost.exe with the headless argument as a potential indicator of the secondary stages of the EtherRAT payload.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
