Quasar Linux RAT targets developer workstations with fileless execution and rootkit features

A newly documented Linux malware called Quasar Linux, or QLNX, is targeting developer and DevOps environments with fileless execution, credential theft, rootkit features, and peer-to-peer command infrastructure. The malware is dangerous because a compromised developer machine can expose source code, package registry tokens, cloud credentials, SSH keys, and CI/CD secrets.

Trend Micro first documented QLNX in May 2026, describing it as a previously undocumented Linux remote access trojan with rootkit, PAM backdoor, keylogging, and credential-harvesting capabilities. The malware focuses on high-value Linux systems used by developers, maintainers, and build infrastructure.

A later GuardSix analysis focused on how defenders can detect the threat through Linux logs, auditd, file integrity monitoring, and network telemetry. GuardSix also clarified that QLNX is not related to the older Windows-focused QuasarRAT family despite the similar name.

Why QLNX is a supply chain threat

QLNX matters because it targets people and systems that sit close to software delivery. A developer workstation can hold Git credentials, package registry tokens, cloud keys, Kubernetes configuration files, SSH private keys, and environment files.

If attackers steal those assets, they can move beyond one infected Linux endpoint. They may gain access to source repositories, publish malicious package versions, tamper with build systems, or pivot into cloud infrastructure.

The Hacker News report on the same Trend Micro research notes that QLNX includes broad post-compromise capabilities, including credential harvesting, keylogging, file manipulation, clipboard monitoring, network tunneling, and command execution.

Targeted asset	Why attackers want it
SSH private keys	They can unlock developer servers, repositories, and internal systems
NPM and PyPI tokens	They can allow attackers to publish malicious packages
AWS and Kubernetes credentials	They can provide access to cloud and production environments
Git credentials and PATs	They can expose private code and repository controls
.env files	They often contain API keys, database passwords, and service secrets

How QLNX runs without leaving a normal file trail

QLNX arrives as a Linux ELF binary, but it does not behave like a normal file-based implant after execution. It can move its main payload into memory and remove the original on-disk file, which makes simple disk scanning less effective.

The malware uses fileless execution techniques such as memfd_create and execveat. That allows it to run a payload from an anonymous memory-backed file descriptor instead of from a visible file path on disk.

QLNX also changes its process name to look like a legitimate kernel worker thread, using names such as [kworker/0:0] or [migration/0]. Defenders can catch this behavior by looking for fake kernel-style processes that have user-space parents or active network connections.

• Runs payloads from memory instead of a normal disk file
• Deletes the original implant after launch
• Masquerades as kernel worker threads
• Compiles host-specific components at runtime
• Uses rootkit behavior to hide files, processes, and network activity

Runtime compilation makes detection harder

One of QLNX’s strongest evasion features is runtime compilation. Instead of carrying only ready-made rootkit files, the malware embeds C source code and uses the victim’s own compiler to build components on the infected host.

The Trend Micro research says the malware carries embedded source for an LD_PRELOAD rootkit and a PAM backdoor, then compiles them locally with gcc. This makes the resulting shared objects unique to each host and weakens static hash-based detection.

GuardSix notes that suspicious gcc activity can become a useful detection signal. On many production, DevOps, and CI/CD hosts, a compiler should not generate hidden shared objects in system or temporary paths without a clear reason.

Component	Observed behavior
LD_PRELOAD rootkit	Loaded through /etc/ld.so.preload to affect new processes
PAM backdoor	Hooks authentication flows and captures cleartext credentials
eBPF rootkit	Can hide processes, files, and network ports from common userland tools
P2P mesh	Allows infected hosts to relay commands through other infected systems

What QLNX steals from Linux systems

QLNX is built to collect the credentials that developers and DevOps engineers use every day. That makes it more than a workstation threat. It can become a direct path into the software supply chain.

The malware searches for credentials across common developer and cloud tooling files. It can also capture credentials during authentication through PAM hooks and steal browser-stored credentials.

The Hacker News coverage highlights the same supply chain risk: once attacker-controlled QLNX runs on a package maintainer’s system, it can expose credentials that allow malicious package publishing or cloud access.

• ~/.ssh private keys
• .npmrc NPM tokens
• .pypirc PyPI credentials
• .git-credentials and GitHub CLI tokens
• .aws/credentials
• .kube/config
• .docker/config.json
• .vault-token and Terraform credentials
• Project-level .env files
• Browser-stored credentials

Why normal cleanup may not be enough

QLNX combines several persistence and stealth mechanisms, which makes partial cleanup risky. Removing one file may not remove the rootkit, PAM hooks, credential logs, or mesh connectivity.

The malware can create systemd services, user-level systemd services, init scripts, XDG autostart entries, cron persistence, and shell startup modifications. It also uses /etc/ld.so.preload to load malicious shared objects into new processes.

The GuardSix analysis recommends a full wipe and OS reinstall from a verified clean image for confirmed infections. It also warns that isolating infected hosts one by one may leave room for surviving mesh nodes to reconnect or reinfect peers.

Indicator	Meaning
/etc/ld.so.preload	Modified to force malicious library loading
/usr/lib/libsecurity_utils.so.1	QLNX rootkit shared object
/usr/lib/.libpam_cache.so	Hidden PAM credential hook
/var/log/.ICE-unix	Hidden credential log file
/var/log/.Test-unix	Hidden credential log file
/tmp/.pam_cache	Captured authentication data
/tmp/.X752e2ca1-lock	Mutex file used to prevent duplicate infections

Detection signals defenders should watch

Defenders should not depend only on malware hashes. QLNX’s runtime compilation and fileless execution reduce the value of static indicators. Behavior-based detection gives teams a stronger chance of finding it.

High-value signals include memfd_create and execveat execution, suspicious gcc use, writes to /etc/ld.so.preload, PAM configuration changes, hidden credential files in /tmp or /var/log, and process names that look like kernel threads but behave like user-space malware.

Security teams should also watch for direct workstation-to-workstation communication. Developer machines rarely need broad east-west TCP connectivity. Unusual peer-to-peer traffic between Linux developer endpoints should trigger investigation.

• gcc compiling shared objects into /tmp, /usr/lib, or hidden paths
• Writes or changes to /etc/ld.so.preload
• New or modified files under /etc/pam.d/ and PAM library paths
• Hidden files such as .ICE-unix, .Test-unix, or .pam_cache
• Processes named like kernel threads with unexpected parent processes
• Kernel-style process names that maintain user-space network connections
• Unexpected systemd, cron, init, or autostart persistence entries

How teams should respond to suspected QLNX infections

Teams that find confirmed QLNX indicators should isolate suspected hosts at the same time rather than one at a time. This helps reduce the chance that the malware’s mesh capability keeps the campaign active inside the environment.

For confirmed infections, a clean rebuild is the safest path. Teams should preserve forensic evidence first, then reinstall from trusted media or a verified image. They should also rotate credentials because QLNX focuses heavily on secrets and authentication data.

Credential rotation should include SSH keys, Git tokens, package registry tokens, cloud keys, Kubernetes credentials, Docker credentials, Vault tokens, Terraform credentials, browser sessions, and any secrets stored in .env files on compromised systems.

1. Isolate all suspected systems from the network at once.
2. Collect forensic evidence, including hidden credential logs and persistence files.
3. Check /etc/ld.so.preload and PAM configuration files for tampering.
4. Reimage confirmed infected hosts from a verified clean image.
5. Rotate all developer, cloud, registry, and CI/CD credentials exposed on those hosts.
6. Audit source commits, build artifacts, and package uploads from affected accounts.

Prevention steps for developer and DevOps fleets

Organizations can reduce exposure by limiting unnecessary compilers on systems that do not need them. QLNX relies on local compilation for some components, so restricting gcc access can make the malware less effective on certain hosts.

Teams should also monitor /etc/ld.so.preload, PAM paths, systemd directories, cron changes, and hidden files under /tmp and /var/log. These areas rarely change on well-managed developer workstations without a clear reason.

Network segmentation also matters. Developer workstations should not have unrestricted lateral connectivity to one another. Segmenting endpoints can weaken the peer-to-peer mesh and limit post-compromise movement.

Control	Recommended action
Compiler access	Remove or restrict gcc where local compilation is not required
File integrity monitoring	Watch /etc/ld.so.preload, PAM files, systemd paths, and hidden credential logs
Audit rules	Log memfd_create, execveat, PAM changes, and suspicious shared object creation
Credential hygiene	Use short-lived tokens, scoped access, and hardware-backed SSH keys where possible
Network segmentation	Limit east-west communication between developer workstations

Bottom line

QLNX is a serious Linux threat because it aims directly at developer and DevOps systems, not just ordinary endpoints. Its fileless execution, rootkit behavior, PAM backdoors, and credential harvesting create a direct risk to source code, build pipelines, and cloud environments.

The malware also shows why developer workstations need the same level of monitoring and response planning as production servers. A stolen package token, SSH key, or cloud credential can turn one infected laptop or build host into a wider software supply chain incident.

Organizations should treat confirmed QLNX activity as an incident that requires host rebuilding, broad credential rotation, supply chain review, and stronger monitoring across Linux developer fleets.

FAQ