Quasar Linux RAT Targets Developers with Fileless Execution and eBPF Rootkit

A newly discovered Linux malware known as Quasar Linux, or QLNX, is actively targeting software developers and DevOps engineers with a level of sophistication rarely seen in Linux-focused threats. Unlike most malware that relies on files stored on disk, QLNX runs almost entirely in memory, making it very difficult for traditional security tools to detect. The threat has raised serious concerns because of who it targets and what it is ultimately built to steal.

QLNX arrives as a single self-contained binary, but that is where ordinary behavior ends. Once executed, it shifts its payload into memory and leaves no trace on the file system, then plants itself into the operating system to harvest SSH keys, cloud credentials, package registry tokens, and browser-stored passwords. A compromised developer workstation is not just one infected machine; it is a backdoor into source repositories, build pipelines, and cloud environments.

Analysts at GuardSix identified the malware and noted it was originally discovered by researchers at TrendMicro. GuardSix said in a report shared with Cyber Security News that QLNX is built around a 58-command remote access framework engineered to bypass conventional Linux endpoint defenses. The malware targets systems running Debian, Ubuntu, RHEL, Fedora, and Arch, with developer and CI/CD build hosts as the primary focus.

What sets QLNX apart is its ability to adapt to almost any Linux system it infects. Rather than carrying pre-built components, it embeds raw C source code and uses the target machine's own compiler to build a custom rootkit at runtime. Since the resulting files are unique to each host, static signature detection fails, and the malware blends into normal-looking activity. The damage extends well beyond a single endpoint. A successful infection positions an attacker inside the development supply chain, with access to everything needed to tamper with code, publish malicious packages, or pivot into cloud infrastructure.

QLNX's infection chain unfolds in six carefully sequenced stages designed to avoid leaving evidence. On launch, it creates a file that exists only in memory, writes its real payload into it, executes that payload, then removes the original file from disk. The running process has no associated file on the filesystem, so disk-based antivirus tools find nothing to scan. To avoid attracting attention, QLNX rewrites its own process name to mimic legitimate kernel worker threads like kworker/0:0 or migration/0. Genuine kernel threads should never maintain user-space network connections or have a regular user-space parent process, but most routine system checks would overlook this masquerade entirely.

The malware then compiles its embedded rootkit and PAM backdoor source against local kernel headers using the victim's own gcc, producing a unique shared object file per host that sidesteps signature-based detection. The compiled rootkit loads system-wide by modifying a file that forces every newly spawned process to load the malicious library. A peer-to-peer mesh connects infected hosts so removing one command node does not cut off the attacker.

GuardSix is clear that standard cleanup is not enough. A full wipe and OS reinstall from a verified clean image is the only fully reliable fix, as partial cleanup leaves residual risk because the eBPF rootkit can survive unless removed completely at the kernel level. For teams that cannot immediately reimage, GuardSix recommends isolating all suspected hosts from the network at once, since removing them one by one allows surviving mesh nodes to re-infect cleaned peers. On the prevention side, restricting the C compiler on systems that do not require it blocks QLNX from building its rootkit. Segmenting developer workstations from one another breaks the peer-to-peer mesh. Organizations should monitor low-level system configuration files closely and rotate all credentials enterprise-wide following any confirmed detection.