Trend Micro’s research team has published a detailed analysis of a Linux implant they call Quasar Linux, internally tracked as QLNX, that is being actively deployed against software developers and DevOps infrastructure. The malware is not a repurposed commodity RAT. It is a purpose-built platform designed around one objective: harvesting the credentials that give access to cloud environments, software registries, and code repositories, while remaining invisible to the security tools developers typically rely on.

How QLNX hides itself

The implant deploys a two-layer stealth mechanism that operates at both userland and kernel level. The first layer is a traditional LD_PRELOAD rootkit that hooks libc functions to intercept calls from system utilities such as ls, ps, and netstat. Any file, process, or network connection associated with the malware is excluded from responses to these calls, making it invisible to standard inspection commands.

The second layer is an eBPF component that operates at the kernel level, hiding the same artefacts from the kernel’s own data structures. PIDs, file paths, and network ports used by the malware are filtered out before they reach any process that queries the kernel, including security tools that bypass libc by calling the kernel directly. This dual-layer approach closes the gap that LD_PRELOAD-only rootkits leave open for kernel-level inspection.

The implant also runs almost entirely in memory, using fileless execution techniques that avoid writing malware components to disk in forms that file-scanning tools can identify. At the time Trend Micro published its research, only four security solutions flagged the binary as malicious.

What it steals

QLNX’s credential harvester targets more than 20 files and directories that contain secrets commonly present on developer machines and in CI/CD environments. The target list maps directly to the credential surface of a typical DevOps workstation:

AWS credentials and configuration from .aws/credentials and .aws/config, which provide access to cloud infrastructure, S3 buckets, and management APIs. Kubernetes configuration from .kube/config, which gives cluster access including the ability to read secrets, deploy workloads, and modify cluster state. Container registry credentials from .docker/config.json, covering private image repositories. GitHub CLI tokens and .git-credentials files, covering repository read and write access and API access. Package registry tokens from .npmrc and .pypirc, covering npm and PyPI publishing credentials. Infrastructure-as-code credentials including .vault-token and Terraform credential files, covering secrets management and cloud provisioning. Environment variable files including .env and configuration files for tools such as kubectl and Helm.

This is the complete credential surface of a modern cloud-native development environment. An attacker holding all of these credentials from a single compromised developer machine can access the AWS environment, push malicious code to private repositories, publish compromised packages to npm or PyPI, modify Kubernetes workloads, and read secrets from Vault, all using authorised credentials that do not trigger anomaly detection based on authentication events.

How developers are being infected

Trend Micro’s analysis notes that QLNX is being distributed through the same channels developers habitually trust: package repositories, open-source project contributions, and build toolchain components. The implant has been encountered in environments using npm, PyPI, GitHub, AWS, Docker, and Kubernetes as part of normal development workflows.

The supply chain attack vector is consistent with the broader pattern of attackers targeting developer toolchains that was established by the 2024 XZ Utils incident and has accelerated since. Developers are high-value targets not because of who they are, but because of what they have access to. The credentials resident on a developer workstation typically provide more access to production infrastructure than the credentials held by a typical operations or IT user.

Why this is an acute risk for European cloud infrastructure

European organisations running cloud infrastructure on AWS, Azure, or Hetzner are directly in scope for the credential types QLNX targets. The AWS credentials harvested by the malware do not distinguish between regions or account types. Once exfiltrated, those credentials can be used from any location to query APIs, modify infrastructure, and exfiltrate data.

The Kubernetes configuration theft is particularly significant for teams running workloads on managed Kubernetes services. A stolen kubeconfig provides direct cluster access and, depending on RBAC configuration, may allow an attacker to read all secrets stored in the cluster, including database connection strings, API keys, and TLS certificates.

The low detection rate, four out of all major security tools tested, means that endpoint security products deployed on developer machines are not currently providing meaningful protection against this specific implant. Teams relying on EDR coverage to detect credential theft from developer workstations should treat that assumption as unreliable until their security vendor confirms detection capability against QLNX specifically.

Steps to reduce your exposure

Audit which developer machines in your organisation run Linux and what cloud credentials are present in user home directories. Where possible, eliminate long-lived static credentials from developer machines entirely by requiring short-lived credentials issued through identity-based access mechanisms such as AWS IAM Identity Center or Vault dynamic secrets. Short-lived credentials that expire within minutes or hours have a narrow window of usefulness even if they are exfiltrated.

For Kubernetes environments, review kubeconfig files on developer machines and restrict what roles those configurations can exercise. Developers rarely need cluster-admin access in production from their local machines. Constraining the RBAC role bound to developer kubeconfigs limits the blast radius if those configurations are stolen.

Enable logging and anomaly detection at the API level for AWS, GitHub, and container registries, so that credential use from unexpected geographic locations or at unexpected times triggers investigation. Because QLNX evades endpoint detection, the most reliable place to detect credential misuse is at the service that receives API calls, not on the machine from which the credentials were stolen.

For npm and PyPI publishing credentials specifically, enable two-factor authentication at the registry level and audit which packages your organisation publishes. Supply chain attacks that leverage stolen publishing credentials can affect every organisation that installs your packages downstream.

If your organisation wants an independent assessment of the credential surface on your developer machines, help implementing short-lived credential workflows on AWS or Kubernetes, or a review of your DevOps pipeline security posture, contact Excello Digital. We work with European engineering teams to reduce the credential attack surface that QLNX and similar implants are specifically designed to exploit.