A new implant is stalking Linux developer workstations, and it is unlike anything most teams have prepared for. Dubbed Quasar Linux RAT (QLNX) by Trend Micro researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim, this previously undocumented malware does not bother with traditional smash-and-grab tactics. Instead, it quietly harvests the credentials that let developers push code to npm, PyPI, Docker Hub, and AWS — then uses those tokens to poison the software supply chain from the inside.
If your team ships code from Linux machines (and statistically, most do), this one deserves your full attention.
TL;DR
- Quasar Linux RAT (QLNX) is a fileless implant targeting developer workstations to steal supply chain credentials (.npmrc, .pypirc, .git-credentials, .aws/credentials, and more)
- It uses a two-tiered rootkit (LD_PRELOAD userland + eBPF kernel) to hide processes, files, and network activity from standard monitoring tools
- The malware masquerades as kernel threads (kworker, ksoftirqd), persists via seven different mechanisms, and supports 58 distinct C2 commands
- Stolen developer tokens can be used to push malicious packages to public registries — exactly the pattern seen in the LiteLLM supply chain compromise earlier this year
- Development teams must treat workstation security as a supply chain control, not just an IT hygiene issue
What Makes QLNX Different
We have covered supply chain attacks on this blog before — the TanStack GitHub Actions compromise, the JavaScript supply chain crisis, and the Trivy incident. Those attacks targeted build pipelines, CI/CD infrastructure, or package registries directly.
QLNX takes a different approach. It targets the developer — the human being whose laptop holds the keys to everything.
Think about what lives on a typical developer workstation:
.npmrcwith npm publish tokens.pypircwith PyPI credentials.git-credentialsfor GitHub or GitLab.aws/credentialsfor cloud infrastructure.kube/configfor Kubernetes clusters.docker/config.jsonfor container registries.vault-tokenfor HashiCorp Vault- Terraform state credentials, GitHub CLI tokens, and
.envfiles scattered across dozens of project directories
That is not just a developer machine — it is a skeleton key to the entire software delivery pipeline. And QLNX is purpose-built to collect every one of those keys without the developer ever noticing.
How It Works: Fileless, Rootkit-Protected, Persistent
QLNX executes entirely from memory. There is no binary sitting on disk for your antivirus to flag. Once loaded, it masquerades as legitimate kernel threads — process names like kworker or ksoftirqd that blend seamlessly into any Linux process listing.
The Two-Tiered Rootkit
This is where QLNX gets genuinely sophisticated. It deploys a dual-layer concealment strategy:
- Userland rootkit via LD_PRELOAD — intercepts system calls to hide files, processes, and network connections from standard tools like
ls,ps, andnetstat - Kernel-level eBPF component — hooks into the kernel to conceal activity even from tools that bypass userland libraries
This combination means that standard monitoring tools see nothing. The implant is invisible to top, absent from /proc listings, and its network traffic does not appear in connection tables. You would need dedicated eBPF-aware detection or memory forensics to spot it.
Seven Persistence Mechanisms
QLNX does not rely on a single persistence method. It installs itself via systemd services, crontab entries, .bashrc shell injection, PAM (Pluggable Authentication Module) backdoors, and at least three additional undisclosed methods. Kill one, and the others bring it back.
The PAM backdoors are particularly concerning — they intercept plaintext authentication data during SSH login events and forward session information to the command-and-control server. Every time someone SSHs into a compromised machine, the attacker gets a copy of their credentials in real time.
Command and Control
The implant supports 58 distinct C2 commands over raw TCP, HTTPS, and HTTP, including shell execution, file management, process injection, screenshot capture, keystroke logging, SOCKS proxy setup, and TCP tunnel creation. It can also execute Beacon Object Files (BOFs) and manage a peer-to-peer mesh network between compromised hosts.
In short, this is not a simple credential stealer. It is a full-featured implant platform that happens to specialise in developer environments.
The Supply Chain Multiplier Effect
Why does this matter beyond one compromised laptop? Because stolen developer tokens do not just give access to a machine — they give access to the trust infrastructure of the entire software ecosystem.
With a valid npm publish token, an attacker can push a malicious version of a legitimate package. With PyPI credentials, they can inject a backdoor into a library that thousands of projects depend on. With AWS credentials, they can access production infrastructure, exfiltrate data, or deploy cryptominers.
This is not theoretical. The LiteLLM supply chain compromise in March 2026 followed precisely this pattern — stolen credentials from a developer tool were used to trojanise a Python package with 3.4 million daily downloads. QLNX is purpose-built to enable exactly this kind of downstream attack at scale.
What Your Development Team Must Do Now
Treating developer workstations as disposable commodity hardware is no longer an option. Every developer machine is a supply chain node, and it needs to be secured as one.
1. Audit Credential Storage Immediately
Run a sweep of developer machines for plaintext credentials in home directories. Tools like TruffleHog and gitleaks can scan for exposed secrets. If credentials are stored in flat files, migrate them to a secrets manager — HashiCorp Vault, AWS Secrets Manager, or even a properly configured password manager.
2. Enforce Short-Lived Tokens
Long-lived npm tokens, PyPI API keys, and AWS access keys are exactly what QLNX harvests. Switch to short-lived, scoped credentials wherever possible. npm supports granular access tokens with expiry. AWS supports temporary credentials via STS. Use them.
3. Implement Endpoint Detection That Understands eBPF
Traditional antivirus and even most EDR solutions will not detect QLNX’s eBPF rootkit. You need detection tools that monitor eBPF programme loading and can identify suspicious kernel-level hooks. Tools like Falco, Tetragon, or Tracee are built for this.
4. Monitor for Anomalous Package Publishes
Set up alerts for package registry activity from your organisation’s accounts. If a package is published from an unexpected IP, at an unusual time, or without a corresponding CI/CD pipeline run, investigate immediately.
5. Segment Developer Access
Not every developer needs publish access to npm. Not every developer needs production AWS credentials. Apply the principle of least privilege ruthlessly. Use CI/CD pipelines as the only authorised path to publish packages or deploy infrastructure.
6. Harden SSH and PAM
Given QLNX’s PAM backdoor capabilities, audit your PAM configuration for unexpected modules. Enforce certificate-based SSH authentication rather than passwords, and monitor /etc/pam.d/ for unauthorised changes.
The Bigger Picture
QLNX represents an evolution in supply chain attacks. Rather than targeting the infrastructure (CI/CD pipelines, package registries, build systems), it targets the people who have the keys to that infrastructure. It is a recognition by threat actors that the weakest link in the software supply chain is often the developer’s own workstation.
For development teams, the lesson is clear: workstation security is supply chain security. The two are no longer separable.
At REPTILEHAUS, we help development teams build secure-by-default workflows — from CI/CD pipeline hardening and secrets management to DevSecOps consulting and security audits. If QLNX has you rethinking your team’s security posture, get in touch. We would rather help you lock things down now than clean up after a breach later.
📷 Photo by Markus Spiske on Unsplash
