Quasar Linux (QLNX) is a new, stealthy Linux Remote Access Trojan that quietly turns developer and DevOps workstations into high‑value beachheads for software supply‑chain attacks, using fileless execution, an eBPF rootkit, PAM backdoors, and a P2P C2 mesh to evade conventional defenses.
Despite its name, it is unrelated to the Windows‑focused QuasarRAT family. It is purpose‑built for modern Linux developer environments.
The malware has been observed primarily on Linux developer workstations and CI/CD build hosts running common distributions such as Debian, Ubuntu, RHEL, Fedora, and Arch, where access usually includes source repositories, build pipelines, package registries, and cloud accounts.
The strategic objective is clear: harvest high‑value credentials like SSH private keys, Git personal access tokens, NPM and PyPI tokens, AWS and Kubernetes configuration secrets, browser‑stored passwords, and project‑level .env files to enable code tampering and cloud compromise across the software supply chain.
QLNX arrives as a single ELF binary but quickly pivots to almost pure in‑memory execution to avoid traditional file‑based detection.
On launch, it uses Linux syscalls such as memfd_create to create an anonymous in‑memory file, writes its real payload into that descriptor, and executes it via execveat, then unlinks the original on‑disk binary so the running process no longer has a visible executable on disk.
To stay hidden in process listings, the malware rewrites its own comm and argv fields to impersonate kernel worker threads like [kworker/0:0] or [migration/0], making it easy to miss during casual ps or top reviews.
Trend Micro said in a report shared with GBhackers, describe QLNX as a full‑featured Linux RAT with 58 command handlers that span remote shell access, file and process management, credential harvesting, rootkit control, and SOCKS proxying.
At the same time, it dynamically compiles its rootkit and PAM backdoor components from embedded C source using the host’s own gcc, targeting paths such as /dev/fd/ or /tmp and producing per‑host unique shared objects that are difficult to flag via static signatures.
Fileless Linux Attacks
QLNX uses a two‑tier rootkit design that combines a user‑space LD_PRELOAD rootkit with a kernel‑level eBPF controller.
The user‑space component is registered via /etc/ld.so.preload as libsecurity_utils.so.1 (and related names), forcing every dynamically linked process to load the malicious library and enabling the malware to hide files, processes, and other artifacts from standard tools.
The eBPF layer uses BPF maps and programs to conceal selected process IDs, file paths, and network ports at the kernel level, further degrading the visibility of defenders relying on normal command‑line utilities.
For credential access, QLNX deploys malicious PAM modules (for example, pam_security.so and libpam_cache.so) that integrate into the PAM stack to both backdoor authentication and record cleartext passwords from local logins and sudo events.
These credentials are stored in XOR‑encrypted hidden files under locations such as /var/log/. ICE‑unix, /var/log/.Test‑unix, and /tmp/.pam_cache, alongside harvested SSH keys, browser credentials, and tokens collected from ~/.ssh, ~/.npmrc, ~/.pypirc, ~/.aws, ~/.kube and project .env files.
Instead of a single centralized command‑and‑control server, QLNX builds a peer‑to‑peer mesh where compromised hosts relay operator commands for each other over a custom protocol wrapped in TLS.
The protocol uses a fixed magic value in the handshake, but to most monitoring systems the traffic initially appears as ordinary encrypted outbound TLS, complicating simple block‑list‑based defenses.
Mitigations
Because QLNX intentionally minimizes persistent artifacts and lives primarily in RAM, effective detection requires correlating signals across syscall telemetry, file integrity monitoring, authentication logs, and network flows.
High‑value indicators include anonymous executions from memfd paths, suspicious gcc compilations writing .so files into /tmp or /dev/fd, any modification of /etc/ld.so.preload, creation of hidden high‑entropy files in /tmp and /var/log, and unusual TLS sessions matching QLNX’s custom handshake identifiers.
Trend Micro and other vendors recommend treating any confirmed QLNX compromise as grounds for full OS wipe and reinstall from a verified clean image, given the combination of eBPF rootkit, PAM hooks, library injection, and P2P persistence.
In parallel, defenders should isolate affected hosts, remove all QLNX persistence artifacts, tightly monitor /etc/ld.so.preload and PAM configuration paths, and place strict FIM and alerting on known QLNX file paths and mutex files across developer fleets.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
