Security researchers have identified a new Linux malware strain called ClipXDaemon, a stealthy threat designed to target cryptocurrency users by manipulating copied wallet addresses.
Cyble’s Research & Intelligence Labs (CRIL) found the malware delivered through a loader structure previously associated with ShadowHS activity. Despite that structural overlap, researchers say there is no evidence that ClipXDaemon and ShadowHS share the same operators or malware authors.
Instead, both threats appear to rely on bincrypter, an open-source shell-script encryption framework hosted on GitHub.
ClipXDaemon: A Cryptocurrency-Focused Linux Threat
Unlike traditional Linux malware that depends on remote infrastructure, ClipXDaemon operates as a fully autonomous cryptocurrency clipboard hijacker. It contains no command-and-control (C2) functionality, performs no beaconing, and does not require instructions from remote servers.
Instead, the malware monetizes victims directly. Once installed on a Linux system running an X11 graphical environment, ClipXDaemon monitors clipboard activity and replaces copied cryptocurrency wallet addresses with attacker-controlled ones in real time. If a victim pastes the altered address into a transaction field, funds are unknowingly transferred to the attacker.
Researchers noted that the malware checks the runtime environment before execution. If it detects a Wayland session, where global clipboard scraping is restricted, the program terminates immediately.
Links to ShadowHS Through a Shared Loader
The initial loader used in the campaign resembles one previously observed in ShadowHS malware samples. However, the similarity appears to stem from both threats using the same open-source bincrypter framework.
In January, ShadowHS was documented as a malware family that deployed encrypted shell loaders to execute a weaponized hackshell payload targeting server environments for post-exploitation activities. In contrast, ClipXDaemon delivers a completely different payload: a Linux-based cryptocurrency clipboard hijacker.
Multi-Stage Infection Chain
The ClipXDaemon campaign uses a three-stage infection process:
- Encrypted Loader: A bincrypter-generated script containing an encrypted payload blob.
- Memory-Resident Dropper: Decrypted in memory using AES-256-CBC and gzip decompression.
- On-Disk ELF Payload: A clipboard-hijacking daemon written to disk.
The loader stores encrypted data inline, decodes it from base64, strips non-printable characters, and derives AES-256-CBC parameters before executing the decrypted stage directly from memory. Variable naming conventions and the use of OpenSSL commands match bincrypter’s typical output.
When the loader decrypts the intermediate dropper, it executes the script through /proc/self/fd, avoiding the creation of visible files and minimizing forensic artifacts.
Persistence and Installation
The decrypted dropper embeds a base64-encoded ELF binary, which it writes to the path:
~/.local/bin/
The filename is randomly generated between eight and nineteen characters with a numeric suffix. After writing the binary, the dropper marks it executable and launches it in the background.
To maintain persistence, the ClipXDaemon appends an execution line to the user’s ~/.profile file. This ensures the malware runs during future login sessions without requiring root privileges, systemd services, or scheduled tasks. The design suggests that attackers are targeting desktop Linux environments rather than servers.
Stealth Techniques and Process Masquerading
Once running, ClipXDaemon performs a double-fork daemonization sequence to detach from the controlling terminal. It creates a new session, closes standard file descriptors, and resets the file mode mask.
The malware then calls prctl(PR_SET_NAME, …) to rename the process, disguising itself as a kernel worker thread. Specifically, it mimics the process name “kworker/0:2-events.”
This technique is meant to reduce suspicion during casual inspection using tools like ps or top, as Linux administrators frequently encounter kernel worker processes and may overlook them.
Clipboard Monitoring and Cryptocurrency Hijacking
After daemonization, ClipXDaemon connects to the X server using standard X11 APIs. If the connection fails, execution stops. Otherwise, the malware begins monitoring clipboard content every 200 milliseconds.
Using the X11 selection protocol, the malware retrieves clipboard data in UTF-8 format through XConvertSelection, XNextEvent, and XGetWindowProperty. Clipboard contents are copied into memory and analyzed for cryptocurrency wallet patterns.
The malware contains encrypted regular expressions for several major cryptocurrency formats, including:
- Ethereum: ^0x[0-9a-fA-F]{40}$
- Bitcoin: ^(bc1|[13])[a-km-zA-HJ-NP-Z1-9]{25,34}$
- Monero: ^[4][0-9AB][1-9A-HJ-NP-Za-km-z]{93}$
- Dogecoin: ^D{1}[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32}$
- Litecoin
- Tron
- Ripple (XRP)
- TON
When a match is detected, ClipXDaemon replaces the clipboard content with a malicious wallet address. The replacement happens quickly enough to occur before a typical paste operation.
Observed attacker wallets include:
- Ethereum: 0x502010513bf2d2B908A3C33DE5B65314831646e7
- Monero: 424bEKfpB6C9LkdfNmg61pMEnAitjde8YWFsCP1JXRYhfu4Tp5EdbUBjCYf9kRBYGzWoZqRYMhWfGAm1N5h6wSPg8bSrbB9
- Bitcoin: bc1qe8g2rgac5rssdf5jxcyytrs769359ltle3ekle
- Dogecoin: DTkSZNdtYDGndq1kRv5Z2SuTxJZ2Ddacjk
- Litecoin: ltc1q7d2d39ur47rz7mca4ajzam2ep74ccdwvqre6ej
- Tron: TBupDdRjUscZhsDWjSvuwdevnj8eBrE1ht
While the malware also monitors TON and Ripple wallet formats, researchers did not observe replacement addresses for those assets.
Configuration Encryption and C2-Less Malware Model
To obscure its configuration, ClipXDaemon encrypts wallet patterns and replacement addresses using the ChaCha20 stream cipher. A static 256-bit key and counter decrypt these values at runtime before compiling the regular expressions in memory.
Although this method prevents simple static analysis, researchers say it provides only limited protection against dynamic analysis.
One of the most notable characteristics of ClipXDaemon is the absence of any network communication. During analysis, the binary performed no DNS queries, HTTP requests, or socket connections and contained no embedded domains or IP addresses.
This C2-less architecture changes the traditional malware lifecycle. Without remote infrastructure, attackers do not need to maintain servers or communicate with infected machines. Instead, monetization occurs directly when a victim unknowingly sends cryptocurrency to the attacker’s wallet.
