Skip to main content
Lazarus Group Brandjacks npm PackagesIncident
4 min readFor Security Engineers

Lazarus Group Brandjacks npm Packages

What Happened

Between late 2024 and early 2025, the Lazarus Group deployed malicious packages on npm that mimicked legitimate ecosystem tools without relying on typosquatting. Sonatype's research team identified packages like buffer-utilities that embedded Base64-encoded URLs pointing to payloads hosted on jsonkeeper.com. Some of these packages accumulated up to 500 weekly downloads before detection. Unlike traditional typosquatting campaigns that rely on developers mistyping package names, this operation used naming conventions that appeared legitimate to developers in specific technical domains.

Timeline

Late 2024: Initial package uploads begin, targeting developers through familiar naming patterns.

Early 2025: Sonatype detection systems flag suspicious behavior patterns in packages with legitimate-sounding names.

Analysis period: Research confirms only 9% of identified brandjacking packages relied on misspellings, marking a tactical shift from previous campaigns.

Current status: Packages removed from npm registry; investigation ongoing into download telemetry and potential compromise scope.

Which Controls Failed or Were Missing

Package vetting at ingestion: npm's automated scanning failed to detect malicious intent in packages that didn't match known typosquatting signatures. The buffer-utilities package passed initial screening despite containing encoded payload delivery mechanisms.

Developer verification workflows: Teams lacked processes to validate package authenticity beyond name recognition. No secondary verification occurred before adding dependencies to production codebases.

Runtime behavior monitoring: Systems didn't flag packages making external network calls to third-party hosting services during installation or execution. The Base64-encoded URLs to jsonkeeper.com executed without triggering alerts.

Dependency review gates: Pull request workflows approved new dependencies without human review of package metadata, maintainer history, or behavioral characteristics.

Supply chain inventory: Organizations couldn't quickly identify which systems had pulled these packages because they lacked complete software bill of materials (SBOM) tracking.

What the Relevant Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed in accordance with secure coding practices, including validation of all inputs. For dependency management, this extends to validating the authenticity and integrity of third-party code before integration. Your procurement process must verify that packages come from trusted sources and haven't been tampered with.

NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires organizations to employ anti-counterfeit measures and protect against supply chain threats throughout the system development lifecycle. This means establishing verification procedures for software components, including open source packages, before they enter your build pipeline.

ISO/IEC 27001:2022 Annex A.8.30 (Outsourced Development) addresses security requirements for development involving external parties. While npm packages aren't traditional outsourcing, the control's intent applies: you must verify the security posture of external code before granting it access to your systems.

OWASP ASVS v4.0.3 Section 14.2 (Dependency) specifies that applications must use a software bill of materials to track components and their versions. Your tooling should maintain current inventories and alert on known vulnerabilities or suspicious packages.

Lessons and Action Items for Your Team

Implement multi-signal package verification. Don't rely on name familiarity alone. Before approving any new dependency:

  • Check package age and publication history (new packages from new maintainers warrant extra scrutiny).
  • Review maintainer profiles for established contribution patterns.
  • Examine the package's GitHub repository for actual development activity, not just mirrored code.
  • Verify the package download count against ecosystem norms for its category.

Deploy runtime behavior analysis. Install tooling that monitors package behavior during installation and execution:

  • Flag any package making unexpected network calls, especially to non-CDN domains.
  • Alert on packages that decode or execute Base64-encoded content.
  • Block packages attempting to write to sensitive filesystem locations during npm install.

Require human review for dependency changes. Your CI/CD pipeline should pause when developers add new packages:

  • Generate automated reports showing package metadata, maintainer history, and behavioral flags.
  • Require approval from someone other than the PR author.
  • Document the business justification for each new dependency.

Build comprehensive SBOMs. Use tools like Syft or CycloneDX to generate machine-readable inventories:

  • Integrate SBOM generation into your build process.
  • Store SBOMs in a queryable database.
  • Create alerts that cross-reference your inventory against threat intelligence feeds.

Establish package allowlisting for critical systems. For applications processing payment data or handling sensitive customer information:

  • Maintain an approved package registry.
  • Require security review before adding packages to the allowlist.
  • Block installation of non-approved packages in production builds.

Monitor for ecosystem-adjacent naming patterns. The 9% typosquatting statistic from Sonatype's research means 91% of brandjacking attempts use other tactics. Watch for:

  • Packages with names that sound like they belong to your tech stack but aren't official components.
  • Generic utility names that could plausibly exist but lack established ecosystem presence.
  • Packages claiming to provide common functionality already available in standard libraries.

Create incident response procedures for compromised dependencies. Document your process for:

  • Identifying which systems pulled a specific package version.
  • Rolling back to safe dependency versions.
  • Assessing whether malicious code executed in your environment.
  • Notifying affected customers if data exposure occurred.

The Lazarus Group's shift away from simple typosquatting means your defenses must evolve beyond spell-checking. Brandjacking exploits contextual trust—packages that seem like they should exist in your stack. Your verification workflows need to catch malicious intent hiding behind legitimate-sounding names because the next 500 downloads might include yours.

jsonkeeper.com

Topics:Incident

You Might Also Like