EtherRAT Distribution Spoofing Administrative Tools via GitHub Facades

Our investigation further confirms that the malware is evolving, with several distinct variants and additional C2 infrastructure identified since the campaign’s inception. 

Find out the latest threat intelligence and adversary research insights on Atos Cyber Shield Blogs.

Malware Distribution

Visualisation below demonstrates the dual-stage distribution chain, where SEO-optimized facade repository redirects unsuspecting users to a secondary GitHub account hosting the malicious MSI. This modular architecture allows the threat actors to preserve their search engine rankings even if the individual payload delivery accounts are taken down.

The intrusion lifecycle begins with a search query via Bing (also Yahoo, DuckDuckGo, Yandex) for specialized IT administrative utilities. Through aggressive SEO poisoning, the threat actors ensure that the facade GitHub repository appears prominently among the top search results. In this instance, a user seeking Kusto Explorer – acritical tool for engineers and analysts querying Azure Data Explorer via KQL – is led toward a non-malicious storefront designed to build initial trust.

Bing search for “kusto explorer”

Bing search for “kusto explorer download”

The first repository the user opens is a storefront that impersonates the targeted administrative tool. This facade repo is intentionally clean of malware, acting only as a gateway to the second, malicious stage of the delivery process. Thanks to such a design, it maintains a high search engine ranking.
First GitHub repo – used only as a facade

First GitHub repo – used only as a facade

As we can see it’s the one that survives quite long time

By embedding a link in the README of a clean facade repository, Threat Actors effectively separate their search visibility from their malware distribution. This second repository hosts the actual malware, while the first remains untainted. This strategy allows for rapid recovery after a takedown, as the adversary only needs to update a single URL to restore their infection chain. This separation is key to the campaign’s longevity, as the initial landing page appears benign to both users and security tools.

Link to second GitHub repo that serves malware to the user

Historical Commits in facade GitHub: we can see changes of links to second GitHub repo

The redirection leads the user to a second GitHub repository where the malicious software is hosted. This secondary site acts as the final stage in the distribution chain, providing the direct download for the malware impersonating administrative tools.

Second GitHub used to host malware

Malware downloaded by user

The threat actor has successfully hijacked the search results for larger set of Windows administrative stack, placing malicious storefronts at the very top of Bing. This dominant search presence effectively masks the threat, as the facade repositories appear as the primary, verified download locations for essential IT tools. Such high visibility on the front page is the critical factor that could help campaign’s broader reach into corporate environments.

“ProcDump” Bing SEO poisoning and Threat Actors GitHub repo

“LAPS” Bing SEO poisoning and Threat Actors GitHub repo

“BgInfo” Bing SEO poisoning and Threat Actors GitHub repo

DuckDuckGo SEO poisoning and Threat Actors GitHub repo

Yandex SEO poisoning and Threat Actors GitHub repo

Yahoo SEO poisoning and Threat Actors GitHub repo

Between early December 2025 and April 1, 2026, the threat actor deployed 44 separate GitHub facades, each spoofing a different administrative or developer tool. This high-volume approach indicates a sustained effort to maximize search engine visibility and capture a diverse range of high-privilege victims.

Total 44 malicious GitHub repositories identified

Administrative Tools Impersonation

Identified Threat Actors campaign specifically targets the professional toolsets of enterprise administrators, systems engineers, and security practitioners. Unlike traditional malware campaigns that cast a wide net across general consumers, this activity is surgically focused on the “crown jewel” accounts of the enterprise. By leveraging Search Engine Optimization (SEO) poisoning, theadversary is distributing malicious MSI installers that mimic essential infrastructure management and diagnostic tools. The primary objective is the compromise of high-privilege credentials and the establishment of persistent backdoors within corporate environments, which can lead to large-scale breaches.

The current threat landscape is defined by the strategic impersonation of utilities foundational to modern IT operations, such as PsExec, AzCopy, Sysmon, and LAPS. The rationale for selecting these specific targets is rooted in an advanced victim profiling model. Because a standard user very rarely interacts with a debugger like WinDbg or a deployment kit like Windows ADK, the adversary ensures that every successful infection lands on a machine belonging to a user with elevated system or network permissions.

The psychological component of this campaign is also particularly aggressive. Many of these utilities are the tools defenders use to investigate malicious activity. This creates an “irony lure” where a security professional, attempting to diagnose a perceived issue using a tool like Process Explorer or TCPView, inadvertently introduces a threat. By delivering these via legitimate-looking MSI packages, the attackers bypass the initial suspicion often associated with raw scripts or standalone executables.

The consequences of an infection might be devastating. Given the administrative nature of the victims, this often transitions into a “keys to the kingdom” scenario.

Find out the latest threat intelligence and adversary research insights on Atos Cyber Shield Blogs.

Malware Logic

Atos TRC has analyzed a number of .msi installers from identified malicious repositories. Since the malware evolved over time this analysis focuses on its latest variant. All paths, file names, extensions, and keys shown are specific to one single sample as they are randomly generated for each.

Latest versions of installers consist of four files. When the MSI is executed, these files are extracted, and a CMD batch script is run via a Custom Action, initiating the chain that leads to RAT deployment:

MSI content screenshot

It is important to note that file extensions differed among the analyzed samples, but “.cmd” was always the initiating file. The table contains a few examples:

File names, decryption keys, secrets, directory names, and extensions presented below are extracted from the latest installer version.

STAGE 0 – DROPPER

File: VW80IqXy.cmd (2,377 bytes)

Stage 0 code screenshot

The malware’s entry point is a heavily obfuscated Windows batch script (VW80IqXy.cmd), launched at SYSTEM privilege by the MSI CustomAction 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. To ensure execution in a hidden window regardless of how the MSI launched it, the script immediately re-launches itself as a minimized background process and exits, with the re-launched copy performing all actual work. That copy proceeds to create a build-specific staging directory under %LOCALAPPDATA%\, download the Node.js runtime from its official distribution endpoint to a temporary archive via curl, extract it into a build-specific runtime subdirectory within the staging directory, and delete the zip archive to minimize forensic artifacts on disk. With the environment prepared, the script hands off execution to Stage 1 by invoking the bundled node.exe against the first-stage payload file and terminates, carrying no persistence mechanism of its own and playing no further role in the infection chain.

Stage 0 simplified graph (link to detailed)

STAGE 1 – In-memory loader

File: ZOVTSc3WW9wotbj.bak (472 bytes)

Stage 1 code screenshot

A minimal Node.js script. Unobfuscated and fully readable. It is never saved onto the disk. Its main goal is to read the file containing the second-stage payload (in this example, “tQqoxkAJFhqWtg5.xml”), decrypt it using a hardcoded key and initialization vector (IV), and execute it in memory via “module._compile()”

AES-256-CBC credentials from example:

• Key : F4J/454U+W0+8y7L+L9MxSY15rB0KoSeQkPauifCTiQ=
• IV  : RXvUsgFBwDx9HuOhpkoiqQ==

Simplified Stage 1 graph (link to detailed)

STAGE 2 – Loader/Persistence

File: tQqoxkAJFhqWtg5.xml (2,096 bytes encrypted)

Stage 2 code screenshot

Stage 2 decrypted code screenshot

Decrypted and executed in-memory by Stage 1. It is an intermediary stage that decrypts the content of obfuscated stage 3 payload (0cZeeDPZMsxWtaK.cfg), writes this content into a new file (4S3HKjraAP.cfg) and then executes it via node.exe wrapped by “conhost.exe –headless”, which disguises the process in Task Manager as a standard console host. Additionally, it creates persistence via the registry Run key.

AES-256-CBC credentials from example:

• Key : m+wOc81aCEKfGEOpZsEr8WAN4O8mJnEoalp3LwZau0A=
• IV  : cOoXZ1ImLZ/V90MLhCpVJw==

Registry persistence from example:

• Key  : HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Name : <6-byte random hex, regenerated on every fresh install>
• Data : conhost.exe –headless 1FgUre\node.exe 4S3HKjraAP.cfg

Simplified Stage 2 graph (link to detailed)

STAGE 3 – RAT

File: 0cZeeDPZMsxWtaK.cfg (encrypted) / 4S3HKjraAP.cfg (plaintext, ~9.8 KB)

Stage 3 code screenshot

Stage 3 decrypted code screenshot

Stage 3 is the malware’s main payload – a JavaScript file that runs silently in the background on every system boot. It is written to disk under a randomly generated filename with a non-descriptive extension, making pattern-based file detection unreliable across different malware distributions. It runs inside conhost.exe, a legitimate Windows process, so it does not stand out in Task Manager. All strings inside the file – including server addresses and API names – are encrypted, making static analysis difficult.

When executed, the RAT first assigns to the infected machine a persistent identity. It reads a unique bot ID from a hidden file on disk or generates a fresh one if the file does not yet exist and stores it for use in all future communication. It also computes a working directory path derived from the machine’s username and computer name, making that path unique on every victim system.

RAT’s next task is to find out where its command-and-control server is. Rather than hardcoding a server address directly, which could be blocked by defenders, the attacker stores the address inside an Ethereum smart contract on the blockchain. RAT queries nine public Ethereum API services in parallel and picks the answer that the majority return – this makes the lookup reliable even if some services are temporarily down. Because the address lives on the blockchain, it cannot be taken down by blocking a domain or an IP address; the attacker can update it at any time by sending a single transaction. Independent of everything else, a background timer re-runs this blockchain lookup every five minutes, so if the attacker publishes a new server address, the RAT switches to it automatically on its next contact attempt without needing to restart.

Once the C2 address is known, the RAT enters a continuous polling loop, repeatedly beaconing to the server to check for new commands. Each request is constructed to resemble an ordinary browser fetch for a static web asset — the URL path contains random hex segments, a randomly chosen common file extension (.png, .jpg, .gif, .css, .ico, or .webp), and a randomly selected query parameter name. While every beacon looks different to a network observer, each one also silently carries the bot’s unique ID and a campaign identifier baked into the build, allowing the attacker’s server to recognize and track each victim individually. RAT also sends its own source code to the server and receives back a freshly obfuscated replacement, which it writes over itself on disk, effectively re-encrypting itself once every execution, whether it was from “.msi” or a persistent Run registry key. Commands from the attacker arrive as JavaScript code and are executed directly inside the running Node.js process, giving the attacker full access to the file system, the ability to run any OS command, and the ability to exfiltrate data – all without ever dropping a traditional executable to disk.”

Every action that the malware makes, like startup, blockchain resolution, re-obfuscation, every poll request, task receipt, task execution, errors, URL updates are being written to %APPDATA%\\svchost.log, keeping a complete operational trace of everything the RAT does.

For all samples analyzed, the same 9 endpoints were queried to obtain the C2 address from the contract. 

The earlier versions of this malware had a lower number of stages used from the moment of execution until the C2 communications and followed the same file extension pattern: .msi -> .cmd -> .js -> obfuscated file with no clear extension. Additionally, the oldest sample Atos Researcher was able to find had fallback C2 IP hardcoded inside the RAT logic to use when the smart contract was unresponsive. This C2 IP was the same as the first value set for the smart contract from this oldest sample (hxxp[://]135[.]125[.]255[.]55).

Simplified Stage 3 graph (link to detailed)

Decentralized C2 Infrastructure

The campaign implements a decentralized C2 model that does not rely on fixed domains or attacker-controlled servers. Instead, the malware retrieves its C2 address from the Ethereum blockchain. Each sample contains the address of a specific Ethereum smart contract, which is queried periodically via multiple public Ethereum RPC services. In this context, a smart contract is a small piece of program logic stored on the blockchain that can hold data and return it on request in a consistent and verifiable way. This design enables centralized C2 changes without modifying or redeploying the malware, increasing resilience against takedown and blocklisting efforts.

For the purpose of this explanation, we used one of the contracts used by attackers (0xc12c8d8f9706244eca0acf04e880f10ff4e52522) and the wallet that funded it (0x37ef6e88425613564b2cf8adc496acff4b6481a9).

The smart contract used for C2 resolution is implemented as an on‑chain coordination mechanism and shows clear signs of operational use during its lifetime. Its blockchain record exposes a defined contract address, a fixed creation timestamp, and a sequence of transactions submitted over time. The observed activity indicates that the contract instance is actively used as part of a broader and persistent C2 resolution architecture, even though individual smart contracts may be replaced or rotated as the campaign evolves. 

Etherscan contract overview page

The contract can be directly associated with the Ethereum wallet that deployed it. Review of the wallet’s activity shows repeated interactions with the same contract during its operational period, demonstrating that control over C2 resolution is exercised through blockchain transactions. This confirms that changes to C2 distribution are performed independently of the malware already deployed on compromised systems.

Etherscan wallet page

Analysis of the contract’s transaction history reveals multiple state-changing calls used to update values stored on-chain. Each of these updates corresponds to a change in the C2 address retrieved by the malware during its regular resolution cycle. As a result, infected systems automatically redirect to the new backend infrastructure without requiring any additional payload delivery or local configuration changes.

Etherscan contract transaction list highlighting repeated state‑changing calls (Set String)

At the transaction level, a single state-changing operation is sufficient to redirect all active infections. Detailed inspection shows that one blockchain write operation, submitted from the operator’s wallet, modifies the contract state and is immediately reflected in subsequent C2 resolution attempts by the malware. This replaces traditional infrastructure management steps -such as domain registration, DNS updates, or server redeployment -with a single on-chain transaction.

Detailed Etherscan view of a single state‑changing transaction, including timestamp, sender, and input data

By anchoring C2 resolution to blockchain state and resolving it through widely available public Ethereum services, the campaign moves a critical dependency of its control infrastructure onto a decentralized network designed for high availability. This substantially limits the effectiveness of conventional disruption techniques based on domain seizure, IP blocking, or server takedown, and contributes to the operation’s overall resilience and longevity.

Full list of found malicious domains as well as wallets and contracts to distribute them is available for download and review at the TRC GitHub repository.

Conclusions

As of the day of writing this article, the Administrative Utility Spoofing campaign remains a highly active and technically resilient threat to enterprise environments. Our research confirms that this is not merely an opportunistic malware cluster, but a more sophisticated operation designed for specific victim profiling. By impersonating the specialized utilities required for infrastructure management, the adversary has “automated” the discovery of high-privilege IT personnel, increasing the probability that successful infections provide immediate pathways for lateral movement into the corporate environment.

The campaign’s operational longevity is rooted in two strategic factors: the dual-stage GitHub distribution architecture and the integration of decentralized blockchain-based C2 resolution. The use of SEO-optimized “facade” repositories allows the threat actors to maintain front-page visibility on search engines while isolating their malicious payloads on secondary accounts that can be rapidly rotated. Furthermore, the EtherHiding module’s reliance on Ethereum smart contracts creates an infrastructure that is particularly difficult to dismantle.

Malware analysis of the MSI payload distributed across this campaign identifies it as an EtherRAT, a modular Node.js backdoor distinguished by its high-resilience “EtherHiding” C2 module. The Sysdig Threat Research Team has previously linked this malware to the North Korean state-sponsored actor – Lazarus Group. They noticed significant overlaps in the tooling utilized during operations conducted with the usage of EtherRAT and the “Contagious Interview” campaign.

Furthermore, in March 2026, eSentire’s Threat Response Unit (TRU) investigated an open-directory web server attributed to Iranian state-sponsored group MuddyWater (APT34). During the engagement, TRU found on that server a malicious file with functionality to establish persistence and deploy the Tsundere botnet malware, which also integrates the “EtherHiding” C2 resolution logic. Their analysis documented extensive code commonalities between EtherRAT and the Tsundere malware.

Active Atos TRC monitoring confirms that this operation is not yet another high-velocity stealer campaign. While commodity malware often prioritizes immediate data exfiltration, these actors demonstrate a focus on operational patience and stealth. Following the initial breach, we have documented a transition to methodical hands-on-keyboard activities characterized by a deliberate approach to environmental discovery.

The adversary avoids aggressive, high-volume scanning that might trigger behavioural alerts, opting instead for quiet discovery to map the network’s high-privilege architecture. This measured pace indicates that the primary objective is sustained persistence and strategic access rather than a simple opportunistic extraction. By carefully profiling the environment before escalating their activity, the threat actors significantly increase their chances of remaining undetected within enterprise networks.

In alignment with our commitment to proactive defense, the Atos Threat Research Center has initiated formal takedown actions against the identified malicious scheme in order to neutralize distribution channels and disrupt the campaign’s operational resilience.

Recommendation

To mitigate the risks associated with the Administrative Utility Spoofing campaign, organizations should implement the following defensive measures:

• Restrict Decentralized Infrastructure Access: block access to the public Ethereum (ETH) RPC endpoints used by EtherRAT, attached in the Appendixes’ section. These gateways are the primary heartbeat for the decentralized C2 resolution mechanism.
• Retrospective Communication Review: review of historical logs to identify any outbound communications with the listed RPC ETH endpoints and identified historical C2 domains identified in this research.
• Tool Provenance & Administrative Awareness: increase awareness among IT personnel regarding using verified internal software centers or direct, authenticated vendor portals for all administrative tools. It is important to educate administrators on the potential risks of sourcing critical utilities from search engine results.
• Behavioural Threat Hunting: following behavioural patterns should be reviewed in the given for organization telemetry:
• repeated, high-frequency beacons (every 500ms) to suspicious external domains
• periodic outbound requests (every 30000ms or 5 minutes) to public ETH RPC endpoints
• suspicious process tree: node.exe processes executing shell commands, which may indicate the secondary stages of the EtherRAT payload
• usage of conhost.exe with the –headless argument, a common artifact of the malware’s attempts to maintain a silent background presence.

Appendixes

A complete list of Indicators of Compromise (IoCs), mapped TTPs, and detailed malware relationship graphs for this campaign are available for download and review at the TRC GitHub repository.

Find out the latest threat intelligence and adversary research insights on Atos Cyber Shield Blogs.