An infected developer workstation is not just an endpoint incident. It can become a publishing account, a cloud admin session, a Kubernetes foothold, and a CI/CD compromise all at once.

Trend Micro’s May 4, 2026 analysis of Quasar Linux (QLNX) is a useful example of that shift: a Linux remote access trojan designed less like noisy commodity malware and more like a quiet access broker for software supply chain environments.

TL;DR

  • QLNX is a previously undocumented Linux RAT reported by Trend Micro with rootkit, PAM backdoor, credential theft, keylogging, proxying, and P2P mesh capabilities.
  • Its highest-value target is the developer and DevOps credential set: npm, PyPI, Git, AWS, Kubernetes, Docker, Vault, Terraform, GitHub CLI tokens, SSH keys, browser data, and .env files.
  • It can use /etc/ld.so.preload for user-space rootkit behavior and persistence, and it can compile PAM-related modules on the target when tooling is available.
  • Detection should focus on behavior: suspicious gcc shared-object builds, changes to /etc/ld.so.preload, hidden credential logs, unusual systemd or autostart entries, and developer-token access by unexpected processes.
  • Treat any confirmed QLNX infection as a supply chain incident, not just a Linux cleanup task.

Why This Matters

Most supply chain writeups focus on the registry: npm, PyPI, container images, package maintainers, GitHub Actions, and release pipelines. QLNX starts one step earlier.

It assumes the developer workstation is the soft center of the environment. That is a good attacker bet. Developer machines often hold long-lived credentials, local cloud profiles, deploy keys, package registry tokens, Git remotes, SSH keys, kubeconfigs, browser sessions, and .env files. A single compromise can give an operator multiple paths into production or downstream users.

That changes the incident response model. If a normal workstation stealer finds a browser password, you rotate passwords and hunt for reuse. If a DevOps workstation stealer finds npm tokens, PyPI credentials, AWS profiles, kubeconfigs, and SSH keys, you also need to ask what could have been published, built, deployed, or signed while the attacker had access.

What QLNX Does

Trend Micro describes QLNX as a full-featured Linux implant with a large command set. The reported capabilities include host profiling, process enumeration, file upload and download, command execution, screen capture, keylogging through /dev/input or X11, TCP tunneling, SOCKS proxying, SSH-based lateral movement, log clearing, timestamp modification, inotify monitoring, P2P routing, and in-memory module loading.

That breadth matters because QLNX is not only a credential grabber. It can observe, persist, hide, pivot, and turn the compromised host into infrastructure for the next step.

The most important cluster of capabilities for defenders is:

CapabilityDefensive significance
Credential harvestingPulls developer, cloud, registry, browser, SSH, and local secret files in one operator-triggered sweep
LD_PRELOAD persistenceUses dynamic linker behavior so malicious shared libraries can be loaded broadly across processes
PAM backdoor behaviorTargets authentication flow for password capture and potential bypass
Rootkit behaviorHides process, file, and network artifacts from ordinary userland tools
P2P meshAllows implants to relay through each other, complicating eradication
Proxy and tunnelingTurns a developer endpoint into an internal pivot point

Mapped to MITRE ATT&CK, the core defensive themes align with Dynamic Linker Hijacking (T1574.006), Systemd Service persistence (T1543.002), Cron persistence (T1053.003), Unsecured Credentials (T1552), Keylogging (T1056.001), and Masquerading (T1036).

The Supply Chain Angle

The credential list is the real story.

Trend Micro reported that QLNX looks for high-value developer and infrastructure files including .npmrc, .pypirc, .git-credentials, AWS credentials, Kubernetes kubeconfig, Docker’s config.json, Vault tokens, Terraform credentials, GitHub CLI tokens, SSH key material, browser databases, shell history, /etc/shadow when root, and .env files in the user’s home directory.

Those are not random secrets. They map directly to operational leverage:

Stolen materialWhat an attacker may be able to do
.npmrc, .pypircPublish malicious package versions or access private registries
Git credentials and GitHub CLI tokensPull private source, modify repositories, tamper with workflows
AWS credentialsAccess cloud resources, secrets, storage, workloads, and IAM paths
Kubernetes kubeconfigDeploy containers, read secrets, exec into pods, pivot inside clusters
Docker configPull or push container images, access private registries
SSH keys and configMove laterally through servers already trusted by the developer
.env filesHarvest database, SaaS, API, and internal service credentials

This is why a QLNX case should trigger a package and release integrity review. If the infected user could publish packages, push tags, approve releases, deploy to cloud, or sign artifacts, assume those actions need verification during the exposure window.

Detection Priorities

Do not rely on ps, ls, or netstat alone. QLNX includes hiding behavior, so ordinary local triage can underreport the compromise. Collect telemetry from endpoint sensors, auditd, EDR, file integrity monitoring, shell history where trustworthy, package registry logs, cloud logs, Git provider logs, and network controls.

Start with the artifacts and behaviors Trend Micro highlighted:

/etc/ld.so.preload
/usr/lib/libsecurity_utils.so.1
/usr/lib/.libpam_cache.so
/tmp/.pam_cache
/var/log/.Test-unix
/var/log/.ICE-unix
/tmp/.X752e2ca1-lock
~/.config/systemd/user/quasar_linux.service
~/.config/autostart/quasar_linux.desktop
/etc/systemd/system/quasar_linux.service
/etc/init.d/quasar_linux
/tmp/.hide_src_*.c
/tmp/.pcs_*
/tmp/.pam_src_*

Useful behavioral hunts:

gcc AND "-shared" AND "-fPIC" AND ("-lpam" OR "ld.so.preload")
write OR modify on /etc/ld.so.preload
new files under /usr/lib/ with hidden or security-themed names
new systemd units containing unexpected ExecStart paths
new crontab @reboot entries from developer accounts
process names resembling kernel threads but owned by userland paths
access to .npmrc, .pypirc, .aws/credentials, .kube/config, .docker/config.json by non-interactive processes
network sessions from developer hosts to unfamiliar TLS endpoints followed by token access

For Linux auditd, a narrow starting point is:

Terminal window
auditctl -w /etc/ld.so.preload -p wa -k ld_preload_change
auditctl -w /etc/pam.d/ -p wa -k pam_config_change
auditctl -w /usr/lib/ -p wa -k usr_lib_write
auditctl -w /etc/systemd/system/ -p wa -k systemd_persistence
auditctl -w /etc/init.d/ -p wa -k initd_persistence

Tune this before broad production use. /usr/lib/ writes can be noisy during package updates, but they should not be routine on developer workstations outside managed software installation windows.

Response Playbook

If QLNX is suspected, do not treat process termination as cleanup. With LD_PRELOAD persistence, killing the visible process before removing the loader path can cause re-execution when normal commands run.

  1. Isolate the host from untrusted networks while preserving volatile evidence where possible.
  2. Collect memory, process, network, file, and audit telemetry before rebooting.
  3. Inspect /etc/ld.so.preload, PAM-related paths, systemd units, crontabs, shell startup files, XDG autostart entries, and init scripts.
  4. Compare local process and port listings with EDR, kernel telemetry, and external network observations.
  5. Rotate credentials from a clean system: npm, PyPI, GitHub, Git, cloud, Kubernetes, Docker registry, Vault, SSH, database, SaaS, and CI/CD tokens.
  6. Review package registry publishing history, Git pushes, release tags, CI workflow changes, container pushes, and cloud API activity for the suspected access window.
  7. Rebuild the workstation from a trusted image if persistence or rootkit behavior is confirmed.

The key discipline is sequencing. Remove or neutralize persistence first, preserve evidence where the business impact allows, and rotate credentials only from clean infrastructure.

What You Can Do Today

For developer workstations:

  1. Remove long-lived package publishing tokens where trusted publishing or short-lived credentials are available.
  2. Move cloud access toward SSO, short sessions, scoped roles, and device posture checks.
  3. Alert on access to developer secret files by unexpected binaries.
  4. Forward Linux audit, systemd, shell, EDR, and network telemetry from engineering endpoints, not only servers.
  5. Inventory who can publish packages, push release tags, approve CI workflows, deploy to production, and access Kubernetes clusters.

For incident responders:

  1. Add /etc/ld.so.preload, PAM module paths, systemd unit paths, XDG autostart, and developer credential files to Linux triage checklists.
  2. Build a “compromised developer workstation” response path that includes source control, package registry, cloud, container registry, and CI/CD review.
  3. Validate package releases by artifact hash, source commit, signer, build workflow, and publication actor.
  4. Practice credential rotation at dependency speed. A token rotation plan that takes three days is too slow for a package publishing compromise.

Sources