Quasar Linux (QLNX): A Developer-Targeted Linux RAT and Detection Strategy

Overview

Compromising a developer workstation is one of the highest-leverage moves an attacker can make on a Linux network. A single infected machine can expose source repositories, signing keys, package registry tokens, and production cloud credentials all at once. Recently identified by researchers at TrendMicro, Quasar Linux (QLNX) is a previously undocumented Linux Remote Access Trojan (RAT) purpose-built to exploit exactly that leverage while remaining almost entirely invisible to traditional file-based defenses. Despite the name, QLNX is not related to the Windows-based QuasarRAT commonly known as Quasar RAT.

QLNX is a full-featured Remote Access Trojan engineered specifically for Linux environments, with developer and DevOps workstations as its primary target. Built around a 58-command RAT framework, it combines fileless execution, an eBPF-based kernel rootkit, a Pluggable Authentication Module (PAM) backdoor, and a peer-to-peer (P2P) mesh network between infected hosts. The end goal is high-value credential theft including SSH private keys, NPM and PyPI tokens, Git Personal Access Tokens (PATs), AWS and Kubernetes configuration secrets, browser-stored credentials, and the contents of .env files.

What makes QLNX especially dangerous is the population it targets. A compromised developer workstation is rarely just a single endpoint, instead, it is an entry point into source repositories, build pipelines, package registries, and production cloud accounts. A successful infection is effectively a supply-chain incident waiting to happen.

Threat Summary

Affected Environments

As TrendMicro mentions it, QLNX has been observed primarily on Linux developer workstations and CI/CD build hosts running mainstream distributions (Debian, Ubuntu, RHEL, Fedora, Arch). Because the malware compiles its rootkit and PAM modules at runtime against the local kernel headers using the system's own gcc, it adapts to a wide range of kernel versions rather than depending on prebuilt binaries.

How the Attack Works

IoCs, sample hashes, and the embedded source artifacts are covered in standard threat-intel feeds like TrendAI Vision One, IBM X-Force Exchange, and SOC Prime (Active Threat Feed) tracking QLNX. Most Linux EDRs are turned to catch persistent binaries, suspicious corn jobs, and known malicious hashes. QLNX produces almost none of those, making it potent malware to look out for using SIEM solutions like Guardsix.

QLNX ships as a single self-contained Executable and Linkable Format (ELF) binary, but almost none of its runtime activity leaves a recognizable trace on disk. The chain unfolds in six stages:

• Fileless execution: On launch, the implant calls memfd_create to create a temporary file that exists only in memory, writes its real payload into it, and then runs that in-memory payload using execveat, a system call that can execute a program directly from a file descriptor. The original on-disk binary is unlinked shortly after, leaving the running process with no corresponding executable on disk.
• Process masquerading: The implant mimics legitimate kernel worker threads such as [kworker/0:0] or [migration/0] to blend into casual ps or top reviews. It does so by rewriting its own com and argv[0].
• Dynamic compilation of embedded source: Rather than carrying prebuilt rootkit and PAM modules, QLNX embeds their C source code inside the implant. At runtime, it drops the source into a hidden file or /dev/fd/ and invokes the local gcc to compile a kernel-version-specific shared object. This sidesteps static signature detection on the rootkit components, since the resulting .so is unique per host.
• System-wide injection: The compiled rootkit and PAM backdoors dropped in the above step are named libsecurity_utils.so.1, pam_security.so, and libpam_cache.so, and are registered via /etc/ld.so.preload and the PAM stack. As they are registered via /etc/ld.so.preload, every newly spawned process uses the malicious library, and every authentication event flows through the PAM hook.
• Credential capture: The PAM backdoor records cleartext passwords from local logins and sudo events into XOR-encrypted hidden files — typically /var/log/.ICE-unix, /var/log/.Test-unix, and /tmp/.pam_cache. In parallel, the implant walks ~/.ssh, ~/.npmrc, ~/.pypirc, ~/.aws, ~/.kube, and project-level .env files to harvest tokens and keys.
• P2P mesh communication: Infected hosts establish a peer-to-peer mesh over a custom TLS-wrapped protocol identifiable by a fixed magic value in the handshake. Commands from the operator can be relayed through any node in the mesh, so taking down a single C2 endpoint does not necessarily cut off the implant.

This design avoids most of the indicators that traditional Linux EDR rules look for. There are no obvious persistent binaries, the rootkit .so is recompiled per host, and the C2 traffic looks like ordinary outbound TLS until inspected closely.

MITRE ATT&ACK Framework Mapping:

Detection for QLNX with Guardsix SIEM

Required Log Sources

• Auditd
• Unix Default Logs
• UnixSysmon
• AgentX File Integrity Monitoring (FIM)
• Network telemetry (Zeek/NDR or firewall flow logs)

Not all of these are strictly required to detect QLNX. However, combining them dramatically improves coverage, because the implant deliberately splits its activity across kernel, userspace, authentication, and network layers.

Detection Strategy

Despite the sophistication of QLNX, its operational behavior follows a recognizable pattern:

1. Fileless execution via memfd_create and execveat.
2. Runtime compilation of embedded source code using the local gcc.
3. Modification of /etc/ld.so.preload to inject the rootkit and PAM modules.
4. Creation of hidden, high-entropy credential log files in /tmp and /var/log.
5. Outbound or lateral TLS traffic with a non-standard magic identifier.

Each of these steps maps cleanly to a different log source. Individually, several of them are noisy or benign; correlated together, they form a high-confidence signal.

Detection with Guardsix

A practical investigation flow is to follow the order of the implant's own actions rather than relying on a single alert.

1. Fileless Malware Execution:
   Start by identifying anonymous in-memory execution. Genuine memfd_create usage is rare on developer workstations outside of language runtimes such as the JVM:
2. 
   

   norm_id=Unix event_type= "SYSCALL" system_call=memfd_create
   -path IN["*java*", "*node*","*python*"]

We can obtain following primary evidence for fileless execution:

• In-Memory Execution: The path=/proc/self/fd/3 log proves a process was launched from an anonymous memory file descriptor rather than a physical file on the filesystem.
• QLNX Dropper Behavior: This mirrors the exact mechanism QLNX uses to deploy its primary payload. A minimal loader allocates a memory region (via memfd_create), writes the malicious binary into it, and executes it directly via the fd path.
• Forensic Evasion:
  Because the payload only exists in RAM and is referenced purely by a volatile process file descriptor, QLNX successfully bypasses static disk-based antivirus scans and File Integrity Monitoring (FIM) tools.

1. Dynamic Compilation to Suspicious Paths:
   QLNX's runtime compilation step is one of the highest-signal indicators. Legitimate gcc invocations on a developer machine almost always write output to a project directory, not to /dev/fd/, /tmp/, or a hidden shared object:

norm_id=Unix event_type="EXECVE" command IN ["*gcc*", "*cc1*", "*clang*", "*g++*"]
command IN ["*-o /tmp/*.so*", "*-o /tmp/lib*", "*libsecurity*"]

The logs confirm the malware dropped raw C source code (/tmp/malicious_payload.c) and compiled it locally into a shared object (/tmp/libsecurity.so) rather than downloading a pre-built binary.

1. Detecting Rootkit Injection:
   Any write to /etc/ld.so.preload on a developer endpoint should be treated as a high-priority alert. This file is rarely modified on properly managed systems and is the primary mechanism QLNX uses for system-wide library injection:

norm_id=Unix* ((event_type ="PATH" -name_type="NORMAL") OR event_id=11)
path IN ["*/etc/ld.so.preload", "*/etc/ld.so.conf*", "*/etc/ld.so.conf.d/*"]

We can see logs revealing QLNX's rootkit behavior as:

• System-Wide Library Injection: The interaction with path=/etc/ld.so.preload is the primary mechanism QLNX uses to establish its user-space rootkit. The malware writes the path of its malicious shared object into this file.
• Forced Execution: By modifying this file, QLNX forces the Linux dynamic linker (ld.so) to load the malicious payload into the memory space of every single new process launched on the system before the legitimate program even starts.
• Enabling the Illusion: This specific action is what allows QLNX to intercept and manipulate standard system functions (API hooking). It is the exact step that enables the malware to hide its files, spoof its process names (like mimicking kworker), and intercept authentication attempts in the PAM stack.

1. Detection of QLNX artifacts with auditd logs:
   Once QLNX establishes persistence, it leaves behind a small but highly distinctive set of artifacts tied to its rootkit and credential-harvesting components. The malware modifies /etc/ld.so.preload for system-wide library injection, deploys hidden shared objects such as libsecurity_utils.so and .libpam_cache.so under /usr/lib, and stores captured credentials in concealed files like .ICE-unix, .Test-unix, and .pam_cache under /var/log and /tmp. These files are rarely present on legitimate developer workstations, making auditd correlation against these paths a high-confidence method for identifying QLNX activity even after the original fileless implant has disappeared from disk.

A simple correlation query for auditd events targeting these artifacts would be:

norm_id=Unix event_type IN ["PATH", "SYSCALL", "CONFIG_CHANGE"]
path IN [
    "*/etc/ld.so.preload*",
    "*/usr/lib/libsecurity_utils.so*",
    "*/usr/lib/.libpam_cache.so*",
    "*/var/log/.ICE-unix*",
    "*/var/log/.Test-unix*",
    "*/tmp/.pam_cache*",
    "*/tmp/.X752e2ca1-lock*"
]   

1. Detection with Default Unix Logs for process Masquerading:
   In environments without auditd, partial visibility is still possible through kernel and syslog messages.
   QLNX's process masquerading depends on names that look like kernel threads. Genuine kernel threads should never have a parent PID other than 2 (kthreadd) or maintain user-space network connections. Hunt for processes whose comm field matches a kernel thread pattern but whose parent is a userspace process:

1. Detection of PAM Activity with auditd logs:
   The PAM (Pluggable Authentication Module) backdoor must register itself in the authentication stack to capture credentials. This activity remains highly visible through auditd because the malware must modify PAM configuration files and deploy malicious shared objects into PAM library paths. Monitoring EXECVE and PATH events targeting /etc/pam.d/ and PAM-related shared objects provides a reliable method to detect authentication stack tampering and credential interception attempts associated with QLNX.

norm_id=Unix   
(  
  (event_type IN ["EXECVE", "PATH"]   
   AND (path IN ["*/etc/pam.d/*", "*/lib/security/*.so*"]   
        OR command IN ["*/etc/pam.d/*", "*/lib/security/*.so*", "*pam_*.so*"] ))  
)   

Evidences these logs reveal regarding QLNX's authentication backdoor behavior:

• Malicious Module Deployment: The execution targeting /lib/security/ mirrors QLNX dropping its custom-compiled Pluggable Authentication Module (PAM) payload onto the filesystem, disguising it as a standard system library.
• Authentication Hijacking: The modification of files within /etc/pam.d/ (specifically targeting services like SSH) represents the malware reconfiguring the system's authentication stack. This forces the OS to load the malicious module whenever a user attempts to log in.
• Credential Harvesting: By completing these two steps, QLNX successfully positions itself as a "man-in-the-middle" within the local authentication process. This allows the rootkit to intercept, log, and exfiltrate cleartext passwords (like

Remediation

The QLNX infection chain is unusually resistant to partial cleanup because it combines an eBPF kernel rootkit, library injection, PAM hooks, and a peer-to-peer mesh. A standard "remove the binary and reboot" response is not sufficient.

The most reliable remediation is a full wipe and OS reinstall from a verified clean image for every host that shows confirmed indicators. Anything short of that leaves residual risk that an eBPF program or a rebuilt rootkit .so survives.

If immediate reimaging is not possible, the following short-term containment steps reduce ongoing damage:

• Isolate all suspected hosts from the network simultaneously. Because of the P2P mesh, isolating hosts one at a time can allow surviving nodes to re-establish persistence on cleaned peers.
• Empty /etc/ld.so.preload to stop further injection of the rootkit and PAM modules into newly spawned processes.
• Remove all known persistence artifacts: /etc/systemd/system/quasar_linux.service, ~/.config/systemd/user/quasar_linux.service, /etc/init.d/quasar_linux, ~/.config/autostart/quasar_linux.desktop, the @reboot cron entries, and any QLNX modifications to .bashrc.
• Delete the mutex lock file /tmp/.X752e2ca1-lock.
• Collect the XOR-encrypted credential logs from /var/log/.ICE-unix, /var/log/.Test-unix, and /tmp/.pam_cache for forensic analysis before deletion. These files indicate which credentials were captured and over what time window.

These containment steps reduce active credential capture but do not remove the eBPF component, which is why reimaging remains the only fully reliable remediation.

Mitigation

Beyond responding to an active infection, several preventive controls significantly reduce QLNX's effectiveness on developer fleets:

• Enforce strict monitoring of /etc/ld.so.preload. This file is rarely modified on a properly managed system. Any change should generate a high-priority alert and ideally be blocked by an EDR or MAC policy.
• Setting up AgentX (FIM) for detection

• /etc/ld.so.preload
• /usr/lib/libsecurity_utils.so.1
• /usr/lib/.libpam_cache.so
• /var/log/.ICE-unix
• /var/log/.Test-unix
• /tmp/.pam_cache
• /tmp/.X752e2ca1-lock

You can use the Configuration for AgentX FIM below by adding it to the ossec.conf in /opt/logpoint/ossec/etc/ossec.conf: 

• Restrict runtime compilation on production and DevOps hosts. On systems where developers do not need a local C compiler, removing or restricting gcc access prevents the dynamic compilation of QLNX's rootkit and PAM modules.
• Apply a baseline auditd ruleset that captures memfd_create, execveat, and writes to PAM and ld.so.preloadconfiguration files. These rules have low overhead and high signal for fileless Linux malware in general, not just QLNX.
• Rotate sensitive credentials regularly and prefer hardware-backed SSH keys, short-lived cloud tokens, and scoped Personal Access Tokens. This reduces the value of any credentials QLNX manages to capture before detection.
• Segment developer workstations from each other. There is rarely a legitimate need for direct TCP connectivity between developer endpoints. East-west segmentation breaks the QLNX P2P mesh and removes one of its key resilience properties.
• Mandate credential rotation across the enterprise following any confirmed QLNX detection: SSH keys, authorized_keys entries, NPM/PyPI/Git PATs, AWS and Kubernetes credentials, all .env secrets, and browser session cookies for any account that authenticated on a compromised host.
• Audit the supply chain.

These mitigations do not substitute for reimaging an actively infected host, but together they significantly raise the cost of a successful QLNX campaign and shorten the window between initial compromise and detection.