Trend Micro has detailed QLNX, a Linux-focused Quasar RAT variant built to stay quiet on developer and server systems. The campaign matters because the target is not only the infected host. A compromised Linux workstation, build runner, or server can expose SSH keys, cloud tokens, source-code access, and deployment credentials that attackers can reuse deeper in the software supply chain.
QLNX is useful to attackers because it combines several layers that are often investigated separately: RAT-style command execution, Linux persistence, LD_PRELOAD and eBPF-based hiding, PAM backdoor access, and credential collection. A newer case, PamDOORa, shows the same risk from the authentication layer itself: a compromised PAM path can preserve SSH access and capture credentials even after ordinary account changes. That combination means a responder who only checks running processes may miss the persistence layer, while a responder who only rotates one password may leave SSH keys or cloud credentials exposed.
Where defenders should look first
The practical triage path starts with Linux login and loader behavior. Check for unexpected PAM module changes, suspicious entries in /etc/ld.so.preload, unusual shared libraries placed near trusted binaries, recently modified shell startup files, new systemd services, and processes hidden from ordinary process listings. On developer machines, also inspect ~/.ssh, shell history, cloud CLI config directories, local Git credentials, package registry tokens, and CI/CD secrets cached in environment files.
The eBPF angle is important because it can move the investigation below the level many teams normally inspect. If a Linux host behaved strangely but process and file checks look clean, review loaded eBPF programs, kernel-facing tooling, and security telemetry that records module, hook, or tracing activity. The goal is not to hunt one filename; it is to verify whether the host is still a trustworthy place to build, sign, or deploy software.
This is adjacent to recent Gridinsoft coverage of PyPI ZiChatBot packages, where a developer environment became the useful target, and older Linux persistence cases such as Lightning Framework and Symbiote. The shared lesson is that Linux malware response cannot stop at deleting the visible payload. If credentials were present on the machine, rotate them from a clean system and assume downstream repositories, package registries, and cloud accounts may need review.
For small teams, the decision point is concrete: if QLNX-like activity is suspected on a developer workstation or build host, remove it from the release path first. Then preserve evidence, replace SSH keys, revoke cloud and repository tokens, check recent commits and package uploads, and rebuild trusted artifacts from a clean environment. A “cleaned” Linux host should not immediately return to signing, packaging, or deployment work until its trust boundary is re-established.
References
- Trend Micro, “Quasar Linux QLNX: A silent foothold in the software supply chain,” May 8, 2026. Analysis
