Shai-Hulud’s multi-stage npm malware keeps evolving on GitHub

At a glance

What this is: This is an analysis of the continuing Shai-Hulud npm malware campaign and its unusually complex multi-stage execution and GitHub-based control flow.

Why it matters: It matters because supply chain malware can turn trusted collaboration platforms into command infrastructure, which changes how teams monitor secrets, repositories, and non-human identities across software delivery.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility.

👉 Read OXSecurity's analysis of the ongoing Shai-Hulud npm malware campaign

Context

Shai-Hulud is not just another npm infection chain. The article describes a supply chain campaign that uses obfuscation, encryption, and repeated payload stages to stay active after blocking attempts, which is a reminder that software trust can become an attack surface when repositories, tokens, and build systems are treated as implicitly safe. In identity terms, the real risk is the abuse of non-human identities such as tokens and repository-linked credentials that can be reused, rotated poorly, or inherited across workflows.

The key governance gap is visibility. Security teams often look for a single malicious artifact, but a living campaign can shift markers, reuse trusted platforms, and continue through new accounts or commits. That makes detection, provenance, and secrets hygiene part of the same control problem rather than separate workstreams. For software supply chain teams, this is an operational pattern, not an edge case.

Key questions

Q: What breaks when supply chain malware can use trusted platforms as command channels?

A: Traditional network filtering and signature scanning lose much of their value because the malicious traffic looks like normal developer activity. Teams need lineage-aware detection, repository event monitoring, and identity-based controls around commits, tokens, and package publishing. Without those, the attacker can keep updating payloads inside a trusted environment.

Q: Why do compromised tokens and API keys make npm supply chain attacks harder to contain?

A: Because a leaked token is not just a credential, it is a reusable non-human identity with its own privileges and lifetime. If it remains valid across cloud, GitHub, or CI systems, the attacker can move faster than manual review. Containment depends on rapid revocation, rotation, and scope reduction.

Q: How can security teams tell if a repository is being used for malicious update activity?

A: Look for repeated commit patterns, unexpected payload changes, abnormal account behaviour, and package activity that does not match the team’s normal release process. The strongest signal is when code updates, downloads, and runtime execution line up in a way that serves the attacker’s control loop rather than developer work.

Q: What should teams do after a secret is found in a public package?

A: They should contain the exposure by revoking or rotating the credential, tracing its downstream permissions, and reviewing every related repository, cloud account, and automation path. The correct response is lifecycle action on the identity, not just removal of the file that contained it.

Technical breakdown

How multi-stage npm malware evades simple detection

Multi-stage malware breaks the assumption that one payload equals one compromise. In this campaign, the loader, dropper, and infostealer behaviours are split into chained stages, with later stages reusing different markers and logic paths. That makes hash-based detection, single-string matching, and shallow repository scanning unreliable because the malicious behaviour may not appear until a later execution branch. The important architectural point is that stage separation gives the attacker room to vary code paths while keeping the overall operation intact. Practical implication: detection needs behavioural and lineage-based correlation, not just static indicators.

Practical implication: correlate repository behaviour, package provenance, and runtime execution rather than relying on one signature.

Why GitHub can function as an adaptive command channel

The article describes GitHub being used not only to host stolen data, but to host malicious code and manage live payload updates through commits. That turns a legitimate developer platform into an adaptive control plane that blends into normal traffic and tooling expectations. Because many environments already allow GitHub access, network controls alone rarely distinguish benign package activity from malicious coordination. The deeper issue is trust transference: once the platform is accepted, the attacker can keep changing code while defenders chase individual indicators. Practical implication: monitor repository actions, commit patterns, and outbound data flows together.

Practical implication: treat trusted collaboration platforms as potential control channels and log their use at repository and identity level.

What secrets and compromised NHIs change in a supply chain attack

Supply chain malware becomes more dangerous when it can harvest credentials and reuse them as non-human identities. Tokens, API keys, and developer credentials can extend the attack beyond the initial infected package into GitHub, cloud, and CI/CD systems. That is why NHI governance matters here: a compromised secret is not just leaked data, it is a reusable identity with its own lifecycle and privilege scope. The article also shows why rapid detection matters. Once a token or key is exposed, the attacker can move faster than manual triage. Practical implication: connect secret exposure monitoring to immediate revocation and scoped access review.

Practical implication: link secret detection to immediate revocation, rotation, and repository access review.

Threat narrative

Attacker objective: The attacker aims to maintain persistent supply chain access, steal credentials and secrets, and keep the campaign operating through trusted developer infrastructure.

1. Entry begins when malicious npm packages or repository-linked code is pulled into a trusted software workflow and executed as part of routine development activity.
2. Escalation occurs when the malware uses multi-stage droppers, obfuscation, and GitHub commits to update payloads and preserve operational control after takedowns.
3. Impact comes from secret theft, infostealer behaviour, and continued propagation through trusted developer infrastructure and compromised non-human identities.

NHI Mgmt Group analysis

Multi-stage supply chain malware is now a control-plane problem, not just a malware problem. The article shows how Shai-Hulud uses layered execution to change behaviour without changing intent, which weakens signature-only defence. That pattern is relevant to IAM because the attack depends on stolen non-human identities, not just malicious code. Practitioners should treat package execution lineage, token use, and repository actions as one governance surface.

GitHub-as-C2 creates a trust inversion that many security programmes still do not model. When a trusted collaboration platform becomes the update mechanism for malicious payloads, allowlisting the platform does not equal trust in the content. This is where NIST CSF detection and response controls intersect with NHI governance, because the identity of the account performing the commit matters as much as the file being fetched. Teams should classify repository actions as security events, not just developer activity.

Secret exposure windows are the real attacker advantage in this campaign. Once an API key or token is harvested, the practical question is not whether it was leaked but how long it remains usable across GitHub, cloud, and CI systems. That is a classic non-human identity lifecycle failure: standing privilege, weak revocation discipline, and incomplete lineage tracking. The governance conclusion is simple. If a secret can outlive the workflow that issued it, the attacker controls the clock.

Shai-Hulud shows why software supply chain resilience must include identity hygiene. Package security, code review, and malware scanning are necessary but insufficient if secrets remain embedded in repositories or build contexts. The campaign only becomes durable when non-human identities are reusable across multiple systems and when defenders cannot see which account, token, or commit actually drove execution. Practitioners should align software supply chain controls with NHI lifecycle controls, or they will keep chasing symptoms.

Named concept: trusted-platform persistence. The campaign demonstrates how attackers can retain operational continuity by using a platform that defenders already trust for collaboration and delivery. That persistence model matters because it reduces the value of one-off takedowns and increases the importance of identity-bound monitoring, lineage analysis, and rapid secret revocation. Security teams should build for platform abuse, not only payload detection.

What this signals

Shai-Hulud reinforces a broader programme signal for security leaders: trusted developer infrastructure now needs identity-aware monitoring, not just malware inspection. The practical shift is toward correlating repository actions, package execution, and secret use as one control domain, with rapid revocation tied to exposure events. For identity teams, the lesson is that a build credential with standing access behaves like any other reusable NHI, so lifecycle discipline matters. If you need a framework for aligning those controls, the NIST Cybersecurity Framework 2.0 is the right lens for governance, detect, and respond integration.

Trusted-platform persistence: when a collaboration platform becomes the delivery and update channel for malware, defenders must monitor behaviour inside the trusted platform rather than rely on perimeter blocking. That means repository events, commit provenance, and token lifecycle become operational signals. For teams responsible for software supply chain resilience, this is the point where CIS Controls v8 and identity governance overlap in practice: asset inventory, account management, and audit logging all need to extend to non-human identities.

The next step for mature programmes is to stop treating secret sprawl as an individual mistake and start treating it as a systemic control failure. Publicly exposed credentials create an attacker time advantage measured in minutes, not days, which makes detective-only approaches too slow. Identity, cloud, and DevSecOps teams should align on a single response path that includes discovery, revocation, and offboarding of affected non-human identities before the attacker can chain access across environments.

For practitioners

• Hunt for stage-specific indicators in build and repo telemetry Search for multi-stage dropper markers, unusual commit strings, and repeated payload-loading patterns across package and repository logs. Focus on execution lineage, not only file hashes, because later stages may use different strings and logic paths. Cross-check GitHub activity with CI/CD execution records.
• Treat exposed secrets as active non-human identities When an API key, token, or cloud credential is found in public code or logs, revoke it immediately and inspect where that identity was used. Build the response around blast radius, not ticket closure, because exposed secrets can be consumed in minutes.
• Monitor trusted developer platforms as security channels Log repository commits, account changes, and outbound fetches from GitHub and similar services, then correlate those events with package installs and runtime behaviour. The goal is to distinguish normal developer use from attacker-controlled update activity.
• Shorten the usable life of build and publishing credentials Replace long-lived secrets in pipelines with tightly scoped credentials, enforce rotation after repository exposure, and remove standing access where possible. If a token can survive multiple releases, it can also survive a compromise.
• Tie repository hygiene to identity governance Review who can commit, publish, or update package dependencies, and verify that offboarding removes those paths completely. The practical control is not just code review, but ensuring that repository permissions and non-human identity ownership are current.

Key takeaways

• Shai-Hulud shows that supply chain malware can behave like a living control plane, not a single malicious package.
• Exposed secrets and reusable non-human identities create attacker windows that can collapse in minutes, which makes slow governance controls ineffective.
• Practitioners need repository telemetry, secret revocation, and NHI lifecycle control to reduce blast radius in software delivery pipelines.

Key terms

• Multi-stage dropper: A multi-stage dropper is malware that delivers its payload in several chained steps rather than one obvious action. Each stage can decode, download, or activate the next, which makes static detection harder because the malicious intent may not appear until later execution paths are reached.
• Adaptive command channel: An adaptive command channel is an attacker-controlled mechanism that can change payloads or instructions while remaining inside a trusted service. In this article, GitHub is used that way, which means defenders must watch identity, commit behaviour, and content changes rather than only blocking traffic.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.

What's in the full article

OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• Stage-by-stage breakdown of the six-layer dropper logic and how each branch behaves in execution.
• Indicator lists for the Miasma and firedalazer markers used to track variant activity across GitHub.
• Repository-level behavioural clues that distinguish the 3rd stage and 6th stage payload paths.
• Malware artefacts and string patterns that can be fed into your detection and hunting workflows.

👉 OXSecurity's full post covers the multi-stage dropper logic, GitHub control behaviour, and IoCs.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It is built for practitioners who need to align identity controls with real operational risk.