What Happened
Trend Micro researchers identified Quasar Linux RAT (QLNX), a remote access trojan targeting developer workstations. The malware seeks out credential files like .npmrc, .pypirc, .git-credentials, and .aws/credentials, which store authentication tokens and API keys. Once installed, QLNX provides attackers with 58 commands for full host control, turning a compromised developer machine into a launchpad for supply chain attacks.
This is not a hypothetical threat. With access to these credential files, attackers can publish malicious packages to npm registries, push backdoored code to private repositories, or infiltrate cloud infrastructure, all while posing as legitimate developers.
Timeline
The timeline for QLNX is limited to Trend Micro's discovery and analysis. There are no confirmed incident dates or victim disclosures. What matters for your security is that this malware is active, and its credential-harvesting capabilities make early detection challenging. By the time unauthorized package publishes or unexpected AWS API calls are noticed, the attacker has likely established persistence.
Which Controls Failed or Were Missing
Three control failures allow QLNX to succeed:
Endpoint protection gaps. Standard antivirus focuses on known signatures. QLNX's architecture suggests a modular design that can evade signature-based detection. If your developer endpoints only use traditional AV without behavioral monitoring, you won't catch credential exfiltration in progress.
Credential storage practices. Storing plaintext credentials in dotfiles is a core vulnerability. Files like .npmrc with //registry.npmjs.org/:_authToken=npm_xxxx are readable by any process running as that user. This is true for .pypirc, .git-credentials, and AWS credential files as well. There's no file-level encryption or secure enclave, and tokens are not short-lived.
Insufficient network egress monitoring. QLNX must communicate with command-and-control infrastructure and exfiltrate stolen credentials. Without monitoring outbound connections from developer machines—especially to unexpected domains or IPs—you lose visibility into the exfiltration phase.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 8.3.2 states that passwords and passphrases must meet minimum strength requirements. This principle extends to API tokens and credentials stored in configuration files. Plaintext tokens in dotfiles fail this control entirely.
NIST 800-53 Rev 5 IA-5(1) requires password-based authentication to use cryptographic mechanisms to protect passwords during transmission and storage. Your .npmrc file doesn't meet this standard, nor does .pypirc.
ISO/IEC 27001:2022 Control 8.3 requires that access to information and other associated assets is restricted according to the established access control policy. When any process running as your user can read credential files, access restriction has failed.
NIST Cybersecurity Framework (CSF) v2.0 PR.AC-1 calls for managing identities and credentials for authorized devices and users. This includes protecting credentials from unauthorized disclosure, which plaintext dotfiles cannot guarantee.
Lessons and Action Items for Your Team
Stop Storing Credentials in Dotfiles
Replace plaintext credential files with credential managers or short-lived tokens:
- For npm: Use
npm loginwith 2FA instead of storing tokens in.npmrc. For CI/CD, store tokens in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) and inject them at runtime. - For PyPI: Use API tokens with scoped permissions and store them in your CI/CD secrets, not in
.pypircon developer machines. - For Git: Use SSH keys with passphrases instead of
.git-credentials. Enable commit signing to verify author identity. - For AWS: Use IAM roles for EC2 and ECS instead of long-lived credentials. For developer access, use AWS SSO with temporary credentials that expire after your session.
Deploy Behavioral Endpoint Detection
Signature-based antivirus won't catch QLNX's architecture. You need EDR (Endpoint Detection and Response) that monitors:
- File access patterns: flag processes that read multiple credential files in sequence
- Network behavior: alert on unexpected outbound connections from developer tools
- Process ancestry: detect when a shell spawned by a legitimate IDE starts making credential file reads
Configure your EDR to alert when processes access .npmrc, .pypirc, .git-credentials, .aws/credentials, .docker/config.json, and .kube/config files. Tune alerts based on legitimate workflows—your IDE might need to read .git-credentials, but curl probably shouldn't.
Implement Network Egress Controls
Create allowlists for outbound connections from developer machines:
- Known package registries (npmjs.org, pypi.org, specific internal registries)
- Your Git hosting (github.com, gitlab.com, or your self-hosted instance)
- Cloud provider APIs (*.amazonaws.com, *.azure.com, *.googleapis.com)
Block or alert on everything else. This creates friction when developers need to access new services, but it forces a decision about whether that connection should be allowed.
Segment Developer Networks
Don't place developer workstations on the same network segment as production infrastructure. QLNX's commands include lateral movement capabilities. If an attacker compromises a developer laptop, network segmentation limits their ability to pivot into your production environment.
Audit Existing Credential Exposure
Run this on your developer machines today:
find ~ -name ".npmrc" -o -name ".pypirc" -o -name ".git-credentials" -o -name "credentials"
For each file found, determine:
- Is this credential still valid?
- Where is it used?
- Can we replace it with a credential manager or short-lived token?
Rotate any credentials you find in these files. Assume they're already compromised until you can prove otherwise.
Test Your Detection
Simulate credential exfiltration to verify your controls work. Copy a test .npmrc file to a developer machine and use curl to POST it to a test endpoint. Did your EDR alert? Did your network monitoring catch the outbound connection? If not, you have gaps to close.
The attacker who deployed QLNX is already testing your defenses. Ensure you test them first.
