npm package campaign uses fake Web3 security brands to steal secrets

At a glance

What this is: This is an analysis of a 22-package npm campaign that used fake Web3 security branding, MCP tool hooks, and postinstall payloads to steal credentials or deliver binaries.

Why it matters: It matters because software supply-chain abuse now intersects with secrets management, AI-agent tool execution, and runtime identity exposure, all of which affect how IAM, PAM, and NHI controls are enforced.

👉 Read Xygeni's analysis of the 22-package npm campaign targeting Web3 secrets

Context

The primary problem here is not just malicious npm publishing. It is the collapse of trust between package metadata, build-time execution, and agent-driven tool use, which allows a seemingly legitimate helper to become a secret-harvesting or binary-dropping mechanism. In practice, that means appsec teams have to look beyond install-time scans and treat package provenance, runtime behaviour, and secret exposure as one control surface.

The identity angle is genuine because the campaign targets credentials, API tokens, wallet material, and MCP tool invocation paths that an AI agent can trigger during normal work. That places it squarely at the intersection of software supply chain security and NHI governance, especially where service accounts, tokens, and developer secrets are reachable from build or agent contexts.

Key questions

Q: How should security teams handle packages that resolve control endpoints at runtime?

A: Treat them as higher risk than ordinary dependencies, because mutable endpoints allow the operator to change exfiltration targets without changing the package hash. Require provenance checks, network controls, and explicit approval for any package that fetches executable content or configuration from externally editable sources. If a package needs that pattern, it should be isolated from production build paths.

Q: Why do AI agent tool calls increase supply-chain risk for secrets exposure?

A: Because the tool invocation can be the trigger that activates hidden logic after installation, at the exact moment the agent is interacting with a trusted workflow. That means the package can sit dormant until it sees the conditions it was designed for. Teams should treat agent tool permissions as part of privileged access management, not as ordinary utility usage.

Q: What do security teams get wrong about malicious npm packages?

A: Teams often focus on whether the source package looks legitimate and miss the transitive dependency that actually runs the payload. They also underestimate postinstall hooks, which can execute automatically and bypass human review. The right focus is the full dependency graph and the privileges available at install time.

Q: What should teams do immediately if a malicious dependency may have accessed local secrets?

A: Assume any readable secret is compromised, rotate credentials that were present in dotfiles or environment variables, revoke tokens with broad scope, and isolate the affected workstation or build runner. Then review downstream systems for signs of token use, because the main risk is not just theft but follow-on access using still-valid identity material.

Technical breakdown

How malicious npm packages hide two payload layers

The campaign uses postinstall hooks to execute immediately after installation, but the packages are not relying on that alone. Variant A adds an MCP-time trigger, where the malicious logic activates when an AI agent calls an advertised tool. That separation matters because the package can appear mostly benign during static review while reserving the real abuse path for runtime interaction. A separate variant uses a simple download-and-execute flow, showing that attackers mix sophistication with low-friction delivery when it reduces detection.

Practical implication: inspect postinstall scripts, runtime tool entry points, and any package that executes beyond installation, not just the manifest.

Why secret-harvesting logic focuses on developer and agent environments

The secret scanner is built to scrape the places where developers and operators routinely leave high-value material. It reads dotfiles, shell history, git credentials, environment variables, and common wallet or mnemonic paths, then applies regex-based detection for keys, tokens, and seed phrases. That design is effective because the attacker does not need perfect exfiltration. Small fragments can reveal account type, token format, or enough structure to accelerate follow-on attacks. In NHI terms, this is credential discovery and credential abuse chained together.

Practical implication: treat developer workstations and agent runtime contexts as credential-rich systems and restrict local secret exposure accordingly.

How dynamic C2 indirection reduces package-level visibility

The campaign avoids hardcoding all infrastructure into the npm artifact. One path resolves the collector endpoint at runtime from a GitHub Pages JSON file, while another uses a Pinggy tunnel to fetch executable content on demand. That indirection makes signature matching harder because the package does not need to ship the final endpoint in a stable form. It also lets the operator rotate destinations without republishing the package, which weakens registry-based detection and makes provenance checks more important than simple hash checks.

Practical implication: flag packages that resolve outbound destinations at runtime and block toolchains that depend on externally mutable control endpoints.

Threat narrative

Attacker objective: The attacker aims to capture developer and wallet credentials from trusted build or AI-agent workflows and then use that access for downstream compromise or persistence.

1. Entry occurs when developers install a package that presents itself as a Web3 security or deployment helper, reducing suspicion during normal dependency intake.
2. Credential access follows as postinstall or MCP-triggered logic scans dotfiles, environment variables, histories, and wallet paths for secrets, keys, and mnemonic material.
3. Impact occurs when harvested material is exfiltrated or a remote binary is executed, creating a pathway to account compromise, wallet theft, or broader supply-chain abuse.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Brand prefabrication is now a trust attack, not just a packaging trick. The campaign did not merely use a plausible package name. It manufactured fake organisations, matching GitHub shells, and security-flavoured vocabulary to create social proof around malicious code. That matters because reviewers, developers, and AI agents often infer legitimacy from packaging signals before they inspect behaviour. Practitioners should assume that branding can be weaponised as part of the supply-chain attack surface.

MCP tool surfaces create a new secret-exfiltration boundary for NHI governance. The dangerous step is not only installation but the moment an AI agent invokes a tool that claims to search for credentials or validate deployment safety. That means NHI governance now extends into package-level tool permissions, not just secret storage and token rotation. The practical conclusion is that agent tool approval needs the same scrutiny as any other privileged integration path.

Dynamic control-plane indirection is a governance gap, not a clever C2 detail. When a package resolves its endpoint from mutable external content, the operator has lost deterministic control over where code sends data or what executable it fetches. That undermines both inventory-based security and auditability. Appsec and identity teams should treat mutable outbound resolution as a control failure because it breaks traceability across the software and identity lifecycle.

Credential exposure windows are too wide for install-time-only defenses. The campaign shows that install-time sandboxing can miss the real abuse path if the package waits for later tool invocation or pulls a second stage from an external service. In identity terms, the exposure window includes the developer workstation, the agent runtime, and the downstream account material the package can see. The correct response is to govern the full lifecycle of secrets, not just their storage location.

Secrets management and NHI lifecycle controls need to be joined to software supply-chain policy. A package that can read dotfiles, histories, and environment variables is effectively operating as an identity-adjacent collector. That means access review, rotation, offboarding, and runtime restriction must be enforced for the secrets that build tools and agents can touch. The field should stop treating software distribution risk and identity governance as separate problems.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For lifecycle context, see NHI Lifecycle Management Guide and Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

This campaign is a reminder that software supply-chain controls now have to account for identity material, not just code integrity. When packages can read local secrets, agent tools, and environment variables, the practical boundary becomes the NHI lifecycle itself, especially where tokens and service credentials sit inside developer workflows. Teams that still separate appsec from IAM will miss the pathway by which legitimate tooling becomes an identity collector.

Credential provenance gap: the failure is not only that a secret exists, but that its exposure path is invisible at the moment the package or agent consumes it. That is why governance needs to move upstream into package intake, build isolation, and access scoping, with complementary guidance from the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Block mutable runtime endpoints in package workflows Prevent build and agent workflows from resolving executable content or collector targets from GitHub Pages, Gist, paste sites, or similar mutable sources unless explicitly approved and logged.
• Review MCP tool permissions as privileged access Require explicit approval before an AI agent can invoke package tools that scan repositories, secrets, or deployment contexts, especially when the tool name implies auditing or validation.
• Sweep developer environments for exposed credentials Check ~/.ssh, ~/.env, ~/.git-credentials, shell history, wallet files, and process environments for exposed material, then rotate any secret that could have been read by a malicious package.
• Quarantine packages with fabricated social proof Treat empty supporting organisations, inconsistent branding, and security-themed package names as a triage trigger, then verify publisher history, two-factor status, and SCM linkage before allowing use.

Key takeaways

• This campaign shows how fake branding, MCP tool hooks, and runtime fetches can turn ordinary package intake into a secrets-exfiltration path.
• The main exposure is not theoretical: 14 packages remained live while the campaign was already partially detected, which shows how uneven registry visibility still is.
• The effective control is lifecycle-wide governance of secrets and package behaviour, not just install-time malware scanning.

Key terms

• MCP-time activation: A payload pattern where malicious behaviour does not run at install time but when an AI agent invokes a tool exposed by the package. This matters because the trigger aligns with ordinary agent usage, which can make abuse look like legitimate execution rather than malware activation.
• Brand prefabrication: The deliberate creation of fake organisations, README identities, and supporting accounts to make a malicious package appear socially validated. In supply-chain attacks, branding becomes a trust signal that can mislead developers and agentic systems before behaviour is inspected.
• Dynamic configuration indirection: A technique where a package resolves its collector, command, or executable target from an external mutable source at runtime rather than embedding it directly. This reduces static detection value and lets an operator change behaviour without republishing the package.
• Credential provenance gap: The disconnect between where a secret is stored and the organisation's ability to prove who or what can read it at runtime. When build tools or AI agents can access local credentials, provenance becomes a governance problem, not just a storage problem.

What's in the full report

Xygeni's full article covers the operational detail this post intentionally leaves for the source:

• The full package catalogue with version-by-version grouping across all 22 malicious entries.
• Indicators of compromise, including the dynamic webhook resolver, the Pinggy tunnel, and the dropped binary path.
• The exact MCP tool names and scanner logic used in Variant A, including the file and regex targets.
• The publisher fingerprinting evidence, including the account pattern and brand-front structure.

👉 Xygeni's full post covers the package catalogue, payload variants, and indicators of compromise in detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners connect identity policy to the build, runtime, and offboarding decisions that shape real-world exposure.