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 (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.
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.
.webp)
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):-
| Type | Indicator | Description |
|---|---|---|
| File Name | quasar_linux.service | Systemd service file dropped under /etc/systemd/system/ and ~/.config/systemd/user/ for persistence |
| File Name | libsecurity_utils.so.1 | Malicious shared object compiled and deployed by QLNX rootkit |
| File Name | pam_security.so | Malicious PAM module deployed to intercept authentication |
| File Name | libpam_cache.so | Additional malicious PAM shared object registered via PAM stack |
| File Name | .libpam_cache.so | Hidden PAM module stored under /usr/lib/ |
| File Path | /etc/ld.so.preload | Modified by QLNX to achieve system-wide library injection |
| File Path | /var/log/.ICE-unix | Hidden XOR-encrypted file storing captured credentials |
| File Path | /var/log/.Test-unix | Hidden XOR-encrypted file storing captured credentials |
| File Path | /tmp/.pam_cache | Hidden file used to store intercepted cleartext passwords |
| File Path | /tmp/.X752e2ca1-lock | QLNX mutex lock file used to prevent duplicate infections |
| File Path | /etc/init.d/quasar_linux | RC script dropped for boot-time persistence |
| File Path | ~/.config/autostart/quasar_linux.desktop | XDG autostart entry for desktop logon persistence |
| File Name | /tmp/malicious_payload.c | Temporary C source file dropped at runtime for on-host compilation |
| File Name | /tmp/libsecurity.so | Compiled rootkit shared object produced from on-host compilation |
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.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
