ZXCHECKER Malware Exploits Cryptographic Seed Phrases

Capabilities and Behavior

The ZXCHECKER utility operates as a dedicated post-exploitation validator designed to verify balances across five major blockchain networks, specifically Bitcoin (BTC), Litecoin (LTC), Dogecoin (DOGE), Dash (DASH), and Ethereum (ETH). The threat actor developed this tool to process multiple forms of credentials, including mnemonic seed phrases, raw private keys, and public wallet addresses. When processing BIP-39 mnemonic seed phrases (which typically consist of 12 or 24 words), the tool performs local cryptographic calculations to derive the associated public keys offline. It supports multiple hierarchical deterministic wallet derivation paths, including BIP-32, BIP-44, BIP-49, and BIP-84. This programmatic flexibility allows the validator to construct and check several address variations, such as legacy, SegWit, and Taproot formats.

Infection Chain and Persistence

Because ZXCHECKER operates as a post-exploitation utility, it does not possess an inherent self-propagating infection routine. Instead, its execution relies on the pre-existing compromise of endpoints via primary malware distributions, such as info-stealers (for example, Lumma, RedLine, Vidar, or Raccoon). The typical execution sequence begins when an initial access vector, such as a phishing lure or a malicious browser extension, compromises an employee workstation. The infostealer scans the system for unprotected files, harvesting browser data, stored cookies, and text files. It specifically targets files containing strings like seed, wallet, or private-key.

Once these files are exfiltrated to the attacker's server, the attacker formats the raw logs and imports them into ZXCHECKER's input files. The threat actor then launches the Python script to run local cryptographic address derivations and check current balances against public blockchains. No local persistence mechanism is installed on the victim host by ZXCHECKER itself; rather, persistence is maintained by the initial infostealer payload to ensure continuous harvesting of logs and credential repositories.

Command and Control

ZXCHECKER does not use standard, remote command and control infrastructure to manage its tasks. Instead, all processing is orchestrated locally on the threat actor's control system. The program's operational behavior is dictated by local configurations, typically stored in files such as settings.ini or config.py. Through these files, the operator establishes the proxy type, the thread limit, and the input category. The outbound communication patterns of the tool are strictly directed at public blockchain explorers and RPC endpoint interfaces, such as etherscan.io, blockchain.info, blockcypher.com, and blockchair.com. This allows the tool to query balances without hosting its own full blockchain node. By utilizing rotating proxies, the attacker distributes these lookup queries across hundreds of IP addresses, neutralizing rate limits and obfuscating the origin of the scans.

Detection Logic and Indicators

Detecting the presence of this tool or the compromised state that feeds it requires a combination of host-based and network-based monitoring. Security teams should monitor internal filesystems for specific directory structures associated with wallet checkers. Standard configuration files like settings.ini, proxy.txt, input.txt, and results.txt, particularly when accompanied by dependencies such as hdwallet, mnemonic, rich, or simplebloomfilter, serve as strong host indicators. Furthermore, look for Python execution files initiating from non-standard user paths, such as AppData Local Temp or user profile roots.

From a network standpoint, analysts should flag volumetric bursts of outbound requests targeting public blockchain APIs from endpoints that have no operational business querying ledger databases. This is especially true if the traffic is routed through external SOCKS5 or residential HTTP proxies. If a compromise is suspected or if you need to evaluate your domain exposure, checking for leaked logs is a critical first step. Organizations can utilize FemtoSec's Dark Web Scanner to search for exposed corporate credentials, malware log signatures, and historical public breach indicators.

Removal and Recovery

Remediating a compromise involving cryptographic keys requires immediate and absolute credential rotation. Because blockchain transactions are immutable and irreversible, recovering assets that have already been drained by automated tools is rarely possible. The absolute priority must be the immediate transfer of remaining funds to newly generated addresses secured by hardware wallets or enterprise-grade Hardware Security Modules (HSMs). The host systems that stored the compromised text files must be isolated from the network to remove the underlying info-stealer malware. Security teams should execute thorough endpoint sweeps to detect persistent remote access tools or persistent registry keys.

To proactively identify hidden access points, misconfigurations, or active endpoint compromises before threat actors can exploit them, organizations should invest in comprehensive offensive testing. Scheduling a professional Penetration Testing engagement helps uncover system weaknesses and protects sensitive local databases from unauthorized extraction. Additionally, deploying proactive Dark Web Monitoring enables teams to receive automated alerts whenever corporate credentials, accounts, or keys appear in underground cybercriminal forums, allowing for swift containment before the data can be parsed by validators.