ClipXDaemon Malware Targets Crypto Users in Linux X11 Sessions

ClipXDaemon is a new Linux malware family that hijacks cryptocurrency clipboard data in X11 sessions, operating fully offline without any command‑and‑control (C2) infrastructure.

It reuses a ShadowHS-style loader built with the public bincrypter framework but delivers a completely different, autonomous financial payload.

ShadowHS used an obfuscated shell loader to deploy an in‑memory hackshell for long‑term operator control over Linux systems, emphasizing stealthy post‑exploitation rather than immediate monetization.

In ClipXDaemon, that staging logic is reused purely as a delivery mechanism for an X11‑focused clipboard hijacker targeting cryptocurrency users on desktop‑style environments.

Cyble Research & Intelligence Labs (CRIL) first observed ClipXDaemon in early February 2026, delivered via a loader previously associated with the ShadowHS fileless Linux post‑exploitation framework.

Both ShadowHS and ClipXDaemon rely on bincrypter, an open‑source shell‑script encryption tool that combines AES‑256‑CBC and gzip to embed encrypted payloads inside bash wrappers.

Upon execution, the decrypted dropper writes a message to STDOUT for purely cosmetic purposes, thereby disguising itself as legitimate software.

However, CRIL notes there is no current evidence of shared authorship; the overlap reflects attackers independently weaponizing the same public obfuscation framework.

ClipXDaemon Malware

The campaign follows a compact three‑stage chain: an encrypted shell loader, a memory‑resident dropper, and a final on‑disk ELF daemon.

The bincrypter‑style wrapper stores an inline encrypted blob, base64‑decodes it at runtime, derives AES‑256‑CBC parameters, decompresses via gzip, and executes the decrypted stage directly from memory through /proc/self/fd, limiting forensic artifacts.

The intermediate dropper, also executed from memory, embeds a base64‑encoded ELF binary that it decodes to ~/.local/bin/, sets executable permissions, and launches in the background before adding a user‑level persistence line to ~/.profile.

This persistence model avoids systemd or cron and does not require root, aligning the targeting with user workstations rather than hardened servers.​

In observed samples, the high‑level loader logic remains stable while the embedded parameters ShadowHS malware and ClipXDaemon builds.

This pattern supports the view that the loader functions as a reusable staging framework, with payloads swapped at build time without altering wrapper behavior.

X11‑Only Daemon and Stealth

The final ELF is a 64‑bit userland binary dynamically linked against X11 libraries and, at the time of reporting, had negligible or no detection on common scanners like VirusTotal.

Execution starts with an environment check: if the WAYLAND_DISPLAY variable is present, the malware exits; otherwise, it proceeds, explicitly restricting itself to X11 where global clipboard scraping is feasible.​

After this gate, the payload performs a classic double‑fork sequence to daemonize, detaching from the terminal, creating a new session, closing standard file descriptors, and changing its working directory to root to blend into background activity.

It then uses prctl(PR_SET_NAME) and argv tampering to masquerade as a benign kernel worker thread (for example, kworker‑style naming), aiming to evade casual inspection via ps or top, while not attempting to withstand in‑depth forensic analysis.

Once daemonized and connected to the X server, ClipXDaemon enters a tight loop, polling the X11 CLIPBOARD selection roughly every 200 milliseconds to fetch UTF‑8 clipboard text via the standard selection protocol and a hidden helper window.

It processes the retrieved text and evaluates it against a set of regular expressions for popular cryptocurrency wallets, including Bitcoin, Ethereum, Litecoin, Monero, Tron, Dogecoin, Ripple, and TON formats.​

If a match is found, the daemon shifts from passive monitoring to active hijacking by taking ownership of the clipboard and responding to paste events with attacker‑controlled wallet addresses instead of the victim’s original address.

The configuration wallet regexes and replacement addresses is stored encrypted using a ChaCha20‑style construction with a static 256‑bit key and counter, decrypted in memory at runtime to frustrate simple static string inspection.

Observed samples show hard‑coded replacement wallets for several currencies, while others (such as TON and Ripple in some cases) are monitored without confirmed replacements, suggesting modular configuration.​

A key aspect of ClipXDaemon’s design is the complete absence of network communication: no DNS lookups, no HTTP beacons, and no embedded C2 domains or IPs were observed during analysis.

The implant operates entirely offline, with encrypted replacement addresses hardcoded and static. Upon detection, the clipboard is overwritten with attacker wallet addresses embedded in the binary (in encrypted form.

Monetization occurs entirely at the endpoint when a user pastes a hijacked wallet address and confirms a transaction, collapsing the traditional kill chain into a local clipboard‑abuse loop.

This infrastructure‑less approach reduces operational risk for attackers, as there is no server to seize or sinkhole and no traffic for network‑based tools to flag, forcing defenders to rely on host‑based telemetry, process analysis, and behavioral detection.

Combined with the reuse of public tooling such as bincrypter, ClipXDaemon exemplifies a broader shift toward specialized, financially motivated Linux malware that is autonomous, stealth‑leaning, and tightly aligned with user workflows in X11‑based crypto and developer environments.

Indicators of Compromise (IOCs)

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.