EtherRAT Distribution Spoofing Administrative Tools via GitHub Facades

Introduction

A sophisticated, high-resilience malicious campaign was identified by Atos Threat Research Center (TRC) in March 2026. This operation specifically targets the high-privilege professional accounts of enterprise administrators, DevOps engineers and security analysts by impersonating administrative utilities they rely on for daily operations. By integrating Search Engine Order (SEO) poisoning, a dual-stage GitHub distribution architecture and decentralized blockchain based command-and-control (C2) resolving, Threat Actors have established a highly resilient delivery and persistence mechanism.

Creative Distribution via GitHub Facades

The campaign utilizes a multi-layered delivery chain designed to evade platform level takedowns and maintain a high search engine ranking. The attack begins with SEO poisoning on various search engines, including: Bing, Yahoo, DuckDuckGo and Yandex. That ensures that malicious results for niche IT terms rank at the top of search results. Users are initially directed to a primary “facade” GitHub repository. These repositories are optimized for SEO but contain no malicious code – just professional looking README file.

To maintain operational flexibility, the README contains a link directing a victim to a second, hidden GitHub repository. It serves as the true distribution point for the malware. By separating the SEO-optimized “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.

Strategic Tool Impersonation and Victim Profiling

The campaign is characterized by its focus on the administrative stack. By distributing malicious MSI installers disguised as tools like PsExec, AzCopy, Sysmon, LAPS and Kusto Explorer, Adversary performs automated victim profiling. These utilities are almost exclusively used by personnel with elevated network and system permissions. A successful infection on an administrator’s workstation may provide the “keys to the kingdom”, what can facilitate lateral movement inside the enterprise environment.

Decentralized Command and Control via Ethereum

The most technically significant aspect of the campaign is its implementation of Blockchain based Dead Drop Resolving (DDR). Once the malicious MSI is executed, the malware does not reach out to any hardcoded C2 server, which could be easily blocklisted. Instead, it repetitively initiates a query to a public Ethereum (ETH) RPC endpoint.

The malware is hardcoded with a specific Smart Contract address on the Ethereum blockchain. By querying this contract, malware dynamically retrieves the live C2 server address. This technique provides the adversary with extreme resilience:

• Infrastructure agility: The attacker can rotate C2 servers globally simply by updating the value stored in the blockchain contract.
• Robustness: As long as public Ethereum gateways are accessible, the malware can always find its “home,” making traditional domain takedown or blockage efforts ineffective.

Research analysis

This research provides a comprehensive technical analysis of the current campaign, based on long-term observation and active detonation within controlled environment. Our research moves beyond initial delivery vectors to examine the sophisticated infrastructure and post-exploitation behaviors.

The following data points represent the core operational mechanics of the campaign, including:

• Malware Distribution: breakdown of the dual stage GitHub repository architecture and the SEO-poisoning usage to manipulate search engine results.
• Administrative Tools Impersonation: detailed look at the specific administrative utilities being impersonated to ensure the compromise of high-privilege IT personnel.
• Malware Logic: malware analysis of the malicious MSI payloads, including their initial staging and persistent components.
• Decentralized C2 Infrastructure: investigation into the malware’s use of Ethereum Smart Contracts and public RPC gateways to dynamically resolve live Command and Control (C2) addresses.

NOTE: During the finalization of the research, we identified a preliminary alert from KISA&KrCERT/CC regarding this Threat Actors’ campaign – LINK. While their initial report provided early visibility, our longitudinal investigation confirms the campaign remains highly active and has undergone significant technical maturation.
Our investigation further confirms that the malware is evolving, with several distinct variants and additional C2 infrastructure identified since the campaign’s inception.

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 facade GitHub repository appears prominently among the top search results. In this instance, a user seeking Kusto Explorer – critical 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 design it maintains a high search engine ranking.

First GitHub repo – used only as a facade

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

By embedding 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 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

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, adversary 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, that can lead to large-scale breach.

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.

Malware Logic

Atos TRC has analyzed 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 for one single sample as they are randomly generated for each.

This malware is a multi-stage, fileless-style Remote Access Trojan (RAT) written in  JavaScript, delivered as a malicious MSI installer impersonating various IT administration and enterprise sysadmin tools. It uses layered AES-256-CBC encryption to conceal its payload, a blockchain-based dead-drop resolver for resilient C2 communication, and an AsyncFunction constructor engine for arbitrary remote code execution. Node.js is downloaded at runtime from nodejs.org rather than bundled, keeping the package small (~4.7 MB) at the cost of requiring internet access during infection. Ultimately Atos Researchers identified it to be an EtherRat malware, recently emerging threat using Ethereum to store C2 URL addresses, preventing takedown of the infrastructure.

Graph showing high level overview of the malware logic

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. Below table contains 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 second stage payload (int this example “tQqoxkAJFhqWtg5.xml”), decrypt it using 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”, that disguises the process in Task Manager as a standard console host. Additionally, it creates persistence via 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. Independently 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 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 complete operational trace of everything the RAT does.

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

The earlier versions of this malware had 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 were able to find had fallback C2 IP hardcoded inside the RAT logic to use when smart contract was unresponsive. This C2 IP was the same as first value set for 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 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 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 contract to distribute them is available for download and review at TRC GitHub repository.

Conclusions

As of 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 rather 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 probability that successful infections provide immediate pathways for lateral movement into 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 identify it as a 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 files 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 a 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 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 TRC GitHub repository.

⌃