OtterCookie npm supply chain attacks expose the limits of package trust

At a glance

What this is: This is Panther’s analysis of an OtterCookie npm malware campaign that used malicious package chaining, credential theft, and SSH persistence to compromise developer environments.

Why it matters: It matters because npm dependency trust can become a direct identity and access risk when stolen secrets, service credentials, and backdoor access are introduced through the software supply chain.

By the numbers:

• 17 minutes.

👉 Read Panther's analysis of the OtterCookie npm supply chain campaign

Context

OtterCookie shows how software supply chain compromise and identity abuse now meet in the same attack path. A malicious npm package can deliver code at install time, harvest secrets from developer systems, and turn those secrets into durable access. In practice, this makes package trust, secret handling, and postinstall execution part of the same governance problem, especially where developers work with cloud credentials and SSH access.

The article’s core point is not simply that malware was present in npm. It is that the package ecosystem still allows a small trust decision during install to become credential theft, persistence, and lateral access. That is why this topic belongs in both supply chain security and NHI governance, because the stolen material is often the identity layer of the build and developer environment.

Key questions

Q: What breaks when npm package installs are allowed to execute code before inspection?

A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.

Q: Why do developer secrets make supply chain incidents much harder to contain?

A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.

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: Who is accountable when stolen secrets are turned into SSH backdoors?

A: Accountability usually spans application security, platform engineering, and identity governance because the compromise crosses code, host, and access layers. If stolen credentials and unauthorized keys are not monitored together, no single team sees the full attack. Policies for secret lifecycle, key management, and incident response must be joined up.

Technical breakdown

How malicious npm wrappers hide payload delivery

The campaign uses a benign wrapper package that imitates a legitimate library and then pulls in a second dependency containing the malicious code. This exploits developer trust in package names and dependency graphs, because the visible package may look harmless while the actual payload sits one layer deeper. The install-time postinstall hook is especially important because it runs automatically during npm install, before most human review happens. That turns dependency resolution into code execution and gives the attacker an early foothold in the developer machine or build environment.

Practical implication: inspect transitive dependencies and block unattended postinstall execution where it is not operationally required.

Why the loader and stealer stages matter

The malware separates execution into a loader and a secondary-stage stealer backdoor. The loader decodes obfuscated JavaScript and hands control to the main payload, which then searches for files, credentials, and environment variables. Splitting logic this way makes static review harder because defenders see only fragments unless they follow the full execution path. The article also notes custom base91-like encoding with different alphabets per function scope, which further reduces the value of simple signature matching and slows triage.

Practical implication: add detonation, deobfuscation, and sandbox analysis for suspicious packages rather than relying on static source inspection alone.

Why secret theft becomes persistence through SSH backdoors

The payload does not stop at exfiltration. After stealing files and credentials, it appends an attacker SSH public key to authorized_keys on Linux systems, creates the directory if needed, and adjusts firewall settings to open port 22. That converts stolen secrets into long-lived access. In identity terms, the attack abuses non-human identity material, especially secrets and SSH trust, and turns a one-time install event into persistent remote access. The governance failure is not just malware execution, but uncontrolled conversion from secret exposure to account-level persistence.

Practical implication: monitor for unauthorized authorized_keys changes and treat secret theft as a persistence event, not only a data-loss event.

Threat narrative

Attacker objective: The attacker wants to steal developer secrets and convert them into durable remote access through an SSH backdoor.

1. Entry occurs when throwaway npm accounts publish a benign wrapper package that pulls in a malicious dependency during npm install.
2. Credential access follows when the payload scans for secrets, environment files, and high-value developer artifacts, then uploads them to attacker-controlled infrastructure.
3. Escalation and persistence occur when the malware writes an SSH public key into authorized_keys and enables remote access on Linux systems.
4. Impact is achieved when stolen credentials and backdoor access let the operator retain control and continue exfiltration from the victim environment.

NHI Mgmt Group analysis

Package trust has become an identity control problem, not just a code review problem. When a malicious npm dependency can execute during install, the boundary between software supply chain risk and credential governance disappears. The practical issue is no longer only whether code is clean, but whether the package ecosystem is allowed to trigger identity-bearing actions before validation. Practitioners should treat dependency installation as a privilege boundary.

Secret exposure in developer workflows creates a standing access window that attackers can automate against. The campaign shows how quickly stolen secrets can be converted into access and persistence. That makes secret handling a NHI governance issue because API keys, SSH keys, and environment credentials function as identities, not just configuration values. Dynamic install-time compromise: the control gap where package execution, secret access, and persistence happen before human review can intervene. Teams need to close that window with stronger pipeline controls.

Obfuscation now serves operational delay, not just concealment. Custom encoding, split payloads, and wrapper packages increase the time defenders need to reconstruct intent. That matters because response quality falls when analysts must manually reconstruct behaviour from multiple dependency layers. The lesson for security programmes is to align detection engineering, package policy, and secret monitoring around the same threat path.

SSH backdoor installation shows why exfiltration and persistence should be investigated together. A stolen secret is often only the first step toward a longer compromise. Once attackers can add keys, open ports, and preserve access across sessions, identity recovery becomes part of incident response. Practitioners should update playbooks to treat key installation as a compromise indicator, not an isolated host event.

What this signals

Dynamic package compromise is now a secrets governance problem. Development teams should assume that any install path capable of reaching local credentials can be converted into a theft path. That means secret storage, dependency policy, and build isolation need to be assessed together, not as separate controls. For identity programmes, this is another example of why secrets are operational identities and not just configuration artefacts.

Attack patterns like this also strengthen the case for tighter lifecycle controls on SSH keys and API tokens. If a package install can pivot from code execution to authorized_keys modification, then incident response has to include identity recovery, not just malware cleanup. Read more in the Ultimate Guide to NHIs and map it back to your pipeline controls.

Package-chain abuse turns detection into a timing problem. Once secrets are stolen, the window to respond is measured in minutes, not hours, so telemetry from package managers, endpoint sensors, and identity platforms must converge quickly. Security teams should look for a correlation between suspicious dependency installs, new outbound C2 traffic, and changes to key material in the same session.

For practitioners

• Block uncontrolled install-time execution Restrict or review postinstall hooks in npm workflows, especially for packages that are not explicitly trusted or pinned. Where possible, run installs in isolated build environments so package code cannot touch developer secrets or SSH material.
• Separate developer secrets from package installation contexts Keep cloud credentials, SSH keys, and environment files out of workspaces where dependency installation occurs. Use scoped credentials, ephemeral environments, and secret injection only at the point of need.
• Detect unauthorized SSH key persistence Alert on unexpected changes to ~/.ssh/authorized_keys, new firewall rules for port 22, and abnormal ownership changes under user home directories. Those signals indicate the malware has moved from theft to persistence.
• Inspect transitive dependencies for wrapper-and-payload patterns Review packages that mirror legitimate libraries but add extra dependencies with unrelated naming patterns. Pay special attention to dependency chains that introduce obfuscated JavaScript or dynamic download behaviour.

Key takeaways

• OtterCookie shows how npm dependency trust can become a credential theft and persistence path in one install chain.
• The campaign’s use of obfuscation, wrapper packages, and SSH key injection highlights a control gap that spans code review, secrets handling, and host hardening.
• Security teams should treat package installation as a privileged event and monitor secret exposure and key persistence as linked indicators.

Key terms

• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Wrapper Package: A wrapper package is a benign-looking package that imitates a legitimate dependency and then includes additional transitive dependencies. Attackers use it to hide malicious code one layer deeper in the graph, making source review and name-based trust far less reliable.
• Authorized Keys Persistence: Authorized keys persistence occurs when an attacker adds their SSH public key to a user or service account’s authorized_keys file. It creates durable remote access that survives password changes and many secret rotations unless the key material is explicitly removed.
• Secrets Governance: Secrets governance is the discipline of controlling where credentials are stored, who can use them, how long they remain valid, and how they are removed. It links discovery, rotation, offboarding, and auditability so that a secret does not outlive the legitimate need for access.

What's in the full article

Panther's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step decoding of the custom base91-like obfuscation used in the loader and payload stages.
• The exact package names, dependency chain patterns, and infrastructure overlaps that support attribution.
• YARA rule examples for the loader and stealer components, useful for detection engineering.
• Infrastructure indicators and C2 endpoint details for hunting across endpoint and network telemetry.

👉 Panther's full post covers the package chain, obfuscation method, and persistence logic in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle control. It helps practitioners connect identity risk to the broader security programme that depends on it.