Quasar Linux RAT Targets Developers via Fileless eBPF

A newly discovered Linux malware, dubbed Quasar Linux or QLNX, has emerged as a significant threat, actively targeting software developers and DevOps engineers. This sophisticated Remote Access Trojan (RAT) distinguishes itself by employing fileless execution and an eBPF rootkit—an advanced combination rarely observed in Linux-focused campaigns, as detailed in a recent report.

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 (CSN) 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.

Defenders who miss the initial compromise may face consequences reaching far beyond the machine first infected.

Quasar Linux RAT Targets Developers

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. 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.

Remediation and Mitigation Steps for QLNX

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.

Removing known persistence files, clearing the preload library configuration, and collecting encrypted credential logs for forensic review are all essential.

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.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.