A sophisticated Linux remote access trojan has been quietly operating in developer environments since at least early 2026. Researchers at Trend Micro, who named it Quasar Linux (QLNX), describe it as a modular platform that combines rootkit functionality, persistent remote access, and targeted credential harvesting from the specific files developers rely on daily. It is not a general-purpose infostealer. Its authors have studied how developers work and designed the tool to extract exactly the credentials that enable supply chain compromise.
How QLNX gets in and stays hidden
Initial infection vectors follow established supply chain patterns: malicious packages distributed through npm, PyPI, and similar registries, and trojanised development tools distributed through less-scrutinised channels. Once running on a developer’s machine, QLNX uses a technique that makes it particularly resistant to conventional detection.
Rather than shipping a pre-compiled rootkit binary that endpoint security tools might recognise, QLNX dynamically compiles its rootkit shared object and PAM backdoor module directly on the infected host using the gcc toolchain, which is available on virtually every Linux development machine. The compiled components are injected via /etc/ld.so.preload, a mechanism that causes the rootkit to be loaded before nearly every process on the system. The result is system-wide interception capability that persists across reboots and operates below the visibility level of most security monitoring tools.
The malware runs primarily in memory and actively erases evidence of its presence by clearing log files and altering its own process names to blend with legitimate system processes. Traditional file-based scanning is not well suited to detecting a threat that compiles its most dangerous components on the fly and operates largely without touching disk.
What it steals and why it matters
The credential harvesting targets a specific set of files that represent high-value access for an attacker interested in supply chain compromise:
.npmrcand.pypircfiles containing package registry authentication tokens.git-credentialsand GitHub CLI tokens.aws/credentialsand AWS configuration files.kube/configfor Kubernetes cluster access.docker/config.jsonfor container registry credentials.vault-tokenand Terraform credential files.envfiles, which routinely contain database passwords, API keys, and service credentials
The pattern is consistent: QLNX is designed to collect everything needed to impersonate a developer across the build and deployment pipeline. Credentials stolen from a single developer workstation can provide access to package registries to publish trojanised versions of legitimate packages, cloud infrastructure to pivot into production environments, and container registries to inject malicious images into deployment pipelines.
The LiteLLM supply chain compromise in March 2026, in which stolen credentials were used to trojanise a Python package with 3.4 million daily downloads, illustrates exactly how this kind of credential theft translates into downstream harm at scale.
The DevOps environment as an attack surface
Developer workstations have historically received less security attention than servers and network perimeters, partly because they are not directly internet-facing and partly because the friction of security controls on developer machines has been considered bad for productivity.
QLNX represents a direct challenge to that reasoning. A developer’s laptop running Linux with a full DevOps toolchain installed is, from an attacker’s perspective, a highly privileged node with authenticated access to source code repositories, cloud environments, container registries, and package distribution systems. The credentials it holds are often more powerful than those held by the servers those same developers manage.
The malware’s design – targeting Linux specifically, using the gcc toolchain as a living-off-the-land resource, and focusing on the credential files most relevant to software supply chains – makes clear that its authors understand the DevOps environment thoroughly.
Reducing exposure
Several controls reduce the risk that QLNX or similar tools present to development teams:
Credential isolation. Credentials for production environments, package registries, and cloud accounts should not be stored as static files on developer workstations where possible. Short-lived credentials issued through identity-aware access systems, AWS IAM Roles Anywhere, or vault-based secret injection at build time significantly reduce the value of compromising a developer machine.
Package registry controls. npm and PyPI packages should be pulled from an internal mirror or proxy that evaluates packages before making them available to the development team. This adds a layer of scrutiny between upstream registries and developer environments.
Workstation endpoint monitoring. Detection of QLNX specifically requires monitoring for unusual use of gcc to compile shared objects, unexpected modifications to /etc/ld.so.preload, and anomalous process behaviour on developer machines. This is not standard configuration on most endpoint detection platforms but can be implemented through eBPF-based tools such as Falco.
Minimal permissions at the workstation layer. Developer machines should hold the minimum credentials necessary for day-to-day work. Long-lived AWS access keys, static Kubernetes admin credentials, and stored package registry write tokens are higher-risk than scoped, short-lived alternatives.
If you want to assess how your DevOps environment is exposed to supply chain credential theft, review your current credential management practices, or design a developer security architecture that reduces the blast radius of a compromised workstation, contact Excello Digital. We help engineering teams build security controls that work with how developers actually work rather than against it.