QLNX Linux RAT Harvests Developer Credentials to Enable Malicious Package Publishing on npm and PyPI

Trend Micro researchers have published analysis of QLNX — an alias for what they track as the Quasar Linux RAT — a Linux-focused remote access trojan with a specific focus on developer workstations. Unlike commodity infostealers that target browser credentials and cryptocurrency wallets, QLNX’s primary objective is the exfiltration of developer authentication tokens used to publish software packages — with the explicit goal of enabling malicious package releases on npm and PyPI under the compromised developer’s identity.

What QLNX Targets

QLNX performs systematic credential harvesting on Linux developer workstations, targeting:

Package registry credentials:

• .npmrc files (containing npm login authentication tokens and registry configurations)
• .pypirc files (containing PyPI username/password and API token credentials)
• ~/.config/pip/pip.conf configurations

Cloud provider credentials:

• ~/.aws/credentials (AWS IAM access keys and secret keys)
• ~/.config/gcloud/application_default_credentials.json (Google Cloud credentials)
• ~/.kube/config (Kubernetes cluster access tokens)
• Terraform state files and .terraform directories (which may contain provider credentials)

Container and repository credentials:

• ~/.docker/config.json (Docker registry authentication tokens)
• ~/.git-credentials (Git authentication credentials for GitHub, GitLab, Bitbucket)
• ~/.config/gh/ (GitHub CLI authentication tokens)
• SSH private keys in ~/.ssh/

IDE and tool credentials:

• VS Code settings and extension authentication tokens
• JetBrains IDE authentication keychains
• Environment files (.env) in home directory and common project paths

The Supply Chain Attack Chain

QLNX’s credential theft is not the end goal — it is the enabler for a second-stage supply chain attack. The harvested npm and PyPI credentials allow the attacker to:

1. Publish a new malicious version of any package the compromised developer has publish rights to
2. Retroactively compromise historical packages if the developer’s token has permission to manage previous versions
3. Create and publish new packages under the compromised developer’s identity — exploiting the trust that a developer’s existing reputation generates

This transforms a single developer workstation compromise into a potential downstream compromise of all users of the developer’s packages — which, for active maintainers of popular libraries, could represent millions of download events per week.

Delivery and Persistence

QLNX is delivered via multiple vectors identified in this campaign:

• Trojanised package management utilities distributed via fake documentation sites
• Malicious Makefile targets in open-source projects designed to be executed during local build processes
• SSH brute-force against developer workstations with exposed SSH ports

Once installed, QLNX establishes persistence via a systemd user service (~/.config/systemd/user/) that survives user logout. The C2 protocol uses HTTPS to attacker-controlled infrastructure with a beacon interval of 15–45 minutes to avoid rate-based detection.

Mitigations for Developer Environments

For individual developers:

• Use hardware security keys (FIDO2) for GitHub, npm, and PyPI authentication rather than long-lived tokens stored in files
• Enable two-factor authentication on npm and PyPI accounts — this prevents the harvested token alone from being used to publish packages (npm requires 2FA confirmation for publish operations when the account’s 2FA setting is enabled)
• Rotate all developer credentials on a regular basis and immediately upon any indication of workstation compromise

For organisations:

• Enforce package signing for published packages — npm’s provenance attestation and PyPI’s Trusted Publishers mechanism tie package publications to verified CI/CD pipeline runs, blocking publications from compromised developer credentials
• Implement alerts on package publish events from developer credentials outside of expected CI/CD pipeline runs
• Review which team members have publish rights to which packages — minimise the population with publish access to reduce the blast radius of a developer credential compromise

The QLNX campaign represents the industrialisation of a threat vector that has been growing for three years: developer credentials as a supply chain attack entry point. Protecting developer workstations with the same rigour applied to production systems is no longer optional in environments where developers maintain packages with large downstream user populations.