New Quasar Linux RAT Targets Developers With Fileless Execution, eBPF Rootkit

Key Takeaways

• A sophisticated new Linux Remote Access Trojan (RAT), dubbed Quasar Linux (QLNX), is actively targeting software developers and DevOps engineers.
• QLNX employs fileless execution and builds a custom eBPF rootkit on the victim’s system, making it exceptionally difficult for traditional security tools to detect.
• The malware aims to steal critical credentials, including SSH keys, cloud credentials, package registry tokens, and browser passwords.
• Successful infection of a developer workstation can lead to widespread compromise across source repositories, build pipelines, and cloud environments.
• A full operating system reinstallation from a verified clean image is the most reliable remediation for QLNX infections.

Advanced Linux RAT Targets Developer Ecosystems with Stealthy Tactics

A potent new Linux malware, identified as Quasar Linux or QLNX, poses a significant threat to software developers and DevOps professionals. This advanced Remote Access Trojan (RAT) employs highly evasive techniques, including fileless execution and an eBPF rootkit, a combination rarely observed in Linux-focused attack campaigns, according to a recent analysis.

Unlike most malicious software that leaves traces on disk, QLNX operates predominantly in memory. This characteristic makes it notoriously difficult for conventional endpoint security solutions to detect and analyze. The malware’s specific targeting of development environments and its objective to exfiltrate critical credentials have raised alarm among cybersecurity experts.

QLNX’s Multi-Stage, Fileless Infection Chain

QLNX is initially delivered as a single, self-contained binary. Upon execution, it deviates sharply from typical malware behavior. The initial binary creates a temporary file that exists solely in memory, into which it writes its primary payload. This payload is then executed, and the original on-disk file is immediately deleted, leaving no persistent footprint for disk-based antivirus scanners to find. To further evade detection, QLNX rewrites its process name to mimic legitimate kernel worker threads, such as [kworker/0:0] or [migration/0].

Analysts at GuardSix, who identified the malware (initially discovered by TrendMicro researchers), detailed that QLNX is built around a robust 58-command remote access framework engineered to bypass standard Linux endpoint defenses. This framework allows attackers extensive control over compromised systems. The malware primarily targets systems running popular Linux distributions like Debian, Ubuntu, RHEL, Fedora, and Arch, with a particular focus on developer workstations and CI/CD build hosts.

A key differentiator for QLNX is its adaptability. Instead of deploying pre-compiled malicious components, the RAT embeds raw C source code. It then leverages the target machine’s own compiler (gcc) to build a custom rootkit and PAM backdoor at runtime, using local kernel headers. This on-host compilation generates a unique shared object file for each infected system, effectively neutralizing static signature-based detection methods and allowing the malware to blend in with legitimate system activity.

The compiled rootkit achieves system-wide persistence by modifying the /etc/ld.so.preload file, which forces every newly launched process to load the malicious library. Furthermore, infected hosts are connected via a peer-to-peer mesh network, ensuring that the attacker maintains control even if individual command nodes are taken offline.

The implications of a compromised developer workstation extend far beyond a single machine. A successful QLNX infection grants attackers a foothold within the development supply chain, potentially providing access to source code repositories, build pipelines, and critical cloud infrastructure. This level of access could enable code tampering, the publication of malicious packages, or a broader pivot into an organization’s cloud environment, leading to severe and far-reaching consequences.

What You Should Do

• Immediate Reinstallation: For any confirmed QLNX infection, a full wipe and reinstallation of the operating system from a verified clean image is the only fully reliable remediation. Partial cleanup efforts may leave residual eBPF rootkit components active at the kernel level.
• Network Isolation: Immediately isolate all suspected hosts from the network simultaneously. Removing hosts one by one may allow surviving mesh nodes to re-infect cleaned peers.
• Forensic Collection: Collect encrypted credential logs from locations like /var/log/.ICE-unix and /var/log/.Test-unix, and clear preload library configurations for forensic analysis.
• Restrict Compiler Access: Limit the availability of C compilers (e.g., gcc) on systems that do not explicitly require them. This prevents QLNX from compiling its custom rootkit on the victim’s machine.
• Network Segmentation: Implement robust network segmentation, particularly for developer workstations, to break the peer-to-peer mesh connectivity QLNX relies on.
• Monitor System Configuration Files: Implement strict file integrity monitoring (FIM) and continuous auditing for critical low-level system configuration files, especially /etc/ld.so.preload and PAM modules.
• Credential Rotation: Following any confirmed detection or suspected compromise, initiate an enterprise-wide rotation of all credentials, including SSH keys, cloud credentials, and API tokens.

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.