Between early December 2025 and April 1, 2026, the threat actor deployed 44 separate GitHub facades that impersonated administrative and developer utilities, according to a March 2026 analysis by the Atos Threat Research Center (TRC).
How the dual-stage GitHub facades work
Atos TRC describes a deliberate two-repository distribution architecture that combines aggressive SEO poisoning with a clean, searchable storefront and a hidden payload host. Search queries on Bing, Yahoo, DuckDuckGo, and Yandex are manipulated so a professionally written README in a first-stage, non‑malicious GitHub repository appears at the top of results for niche IT terms. That facade contains a link to a second, hidden GitHub account that hosts the malicious MSI installer. By separating search visibility from payload delivery, the adversary can preserve high search rankings while rotating or replacing the actual delivery accounts when they are flagged or removed.
Administrative tools targeted: crown‑jewel impersonation
The campaign specifically impersonates high‑privilege administrative utilities to “automate” victim profiling. Atos TRC found malicious MSI installers masquerading as tools such as PsExec, AzCopy, Sysmon, LAPS, and Kusto Explorer — utilities primarily used by administrators, DevOps engineers, and security analysts. The report notes an “irony lure”: security practitioners using tools like Process Explorer or TCPView to investigate issues may instead download and execute the compromised MSI packages, increasing the chance that the infection lands on a machine with elevated permissions.
EtherRAT: multi‑stage logic, fileless behavior, and persistence
The malicious payload family is identified by Atos TRC as EtherRAT, a Node.js‑based Remote Access Trojan that relies on staged, largely fileless execution. In the analyzed samples a CustomAction in the MSI immediately launches an obfuscated batch dropper (example filename VW80IqXy.cmd) at SYSTEM privilege. That script downloads Node.js at runtime, prepares a staging directory under %LOCALAPPDATA%, and invokes an in‑memory loader (example ZOVTSc3WW9wotbj.bak) which decrypts and compiles a second-stage payload.
Stage 2 (example tQqoxkAJFhqWtg5.xml) decrypts an obfuscated Stage 3 payload (example 0cZeeDPZMsxWtaK.cfg), writes a plaintext payload file (example 4S3HKjraAP.cfg), executes it under node.exe wrapped by conhost.exe --headless, and establishes persistence via a Run registry key in HKCU. Stage 3 is the persistent RAT stored as a randomly named file (~9.8 KB in the example) that assigns a unique bot ID, computes a per‑host working directory, and logs every action to %APPDATA%\\svchost.log.
Decentralized C2: resolving command servers from Ethereum
A distinctive technical feature is the malware's use of on‑chain C2 resolution. Rather than hardcoding a domain or IP, EtherRAT is hardcoded with a specific Ethereum smart contract address (Atos TRC used 0xc12c8d8f9706244eca0acf04e880f10ff4e52522 in its analysis) and queries nine public Ethereum RPC services in parallel. The malware reads the contract state to obtain a live C2 address; a background timer repeats that lookup every five minutes so operators can change the backend by submitting a single state‑changing transaction. Atos TRC also identified the wallet that funded the contract in its example (0x37ef6e88425613564b2cf8adc496acff4b6481a9) and noted that earlier samples contained a fallback C2 IP (hxxp://135[.]125[.]255[.]55) matching an initial on‑chain value.
What this means for administrators, security teams, and incident responders
- Administrators and DevOps engineers: the report highlights the risk of sourcing critical tools from search results rather than verified vendor portals or internal software catalogs; the attack explicitly targets tools those personnel use daily.
- Security teams and incident responders: Atos TRC recommends reviewing historical logs for outbound queries to the listed public ETH RPC endpoints and identified C2 domains, hunting for characteristic telemetry such as conhost.exe launched with --headless, node.exe processes executing shell commands, repeated high‑frequency beacons (every 500 ms) to suspicious domains, and periodic RPC calls every ~30,000 ms (5 minutes).
- Network operations and enforcement teams: the TRC advises restricting access to the public Ethereum RPC endpoints used by EtherRAT (the specific gateways are referenced in the TRC appendixes) and pursuing takedown actions on identified distribution channels — steps Atos TRC has begun.
The Atos TRC analysis also links code overlap in other research: Sysdig’s Threat Research Team previously connected EtherRAT tooling to the North Korean‑linked Lazarus Group, and eSentire’s Threat Response Unit found Tsundere botnet code with the same “EtherHiding” C2 logic on an open directory attributed to the Iranian group MuddyWater (APT34). Atos TRC characterizes the operation as deliberate and patient: rather than noisy fast exfiltration, the campaign emphasizes stealth, hands‑on‑keyboard exploration, and strategic persistence.
Atos TRC has published IoCs, wallets, contracts, and a fuller technical breakdown at its TRC GitHub repository and has initiated formal takedown actions against the identified distribution scheme. The technical choice to anchor C2 in blockchain state — and to rotate distribution repositories while preserving search visibility — gives the adversary a compact, resilient mechanism to maintain and redirect access with a single on‑chain transaction. That design leaves defenders with a narrower set of effective mitigations: telemetry‑driven detection, constrained RPC access, and stronger provenance controls for administrative tooling.
Read the original Atos TRC summary at: https://thehackernews.com/2026/04/etherrat-distribution-spoofing.html
