Malicious NuGet packages turn routine restores into credential theft

At a glance

What this is: Five malicious NuGet packages impersonated real .NET libraries and used assembly-load behavior to trigger credential theft during routine restores.

Why it matters: This matters because build systems, developer endpoints, and internal mirrors can inherit compromise from trusted package workflows unless teams govern package identity, cache hygiene, and build-scoped credentials.

By the numbers:

• The campaign reportedly published 224 total versions across the five package IDs.

Context

NuGet supply chain abuse turns package restore into an execution path, not just a download step. When a package carries functional code that runs on load, the trust boundary shifts from the repository name to the assembly lifecycle, and that creates a direct governance problem for .NET build pipelines and developer endpoints.

This case matters to IAM and NHI practitioners because build credentials, package-registry tokens, SSH keys, and other secrets often live on the same hosts that perform restores. Once a malicious package runs in the build context, it can reach into the non-human identity estate through scoped tokens, cached credentials, and mirrored packages.

Key questions

Q: What breaks when a NuGet package can execute code during assembly load?

A: The assumption that restore is a passive supply-chain step breaks. If an assembly can run module initializers or hidden loader logic when it is loaded, then dependency import becomes an execution boundary. That means scanning hashes alone is insufficient. Teams need package-identity controls, runtime inspection, and build environments that treat loaded dependencies as executable software.

Q: Why do build and developer hosts make supply-chain credential theft worse?

A: They often hold the broadest mix of secrets in one place, including cloud tokens, registry credentials, SSH keys, browser passwords, and signing material. A malicious package that runs on load can reach both human and non-human credentials from the same host. The risk is amplified when restore systems and secret-bearing workflows share the same machine.

Q: What are the signs that a NuGet package impersonation campaign is active?

A: Watch for unfamiliar package IDs that resemble internal libraries, exact-version installs of unlisted packages, suspicious outbound traffic from build jobs, and unexpected files created in locations that mimic legitimate vendor activity. In this campaign, package ID consistency mattered more than visible search listings, so detection should correlate manifests, caches, and network telemetry.

Q: How should teams respond when a build host restored a malicious package?

A: Treat the host as compromised, remove the package from every trusted cache and mirror, and rotate any secrets that were reachable from that machine. Then review restore logs and outbound network telemetry for evidence of package-triggered execution. The goal is containment before the stolen credentials can be reused elsewhere in the environment.

Technical breakdown

Why module initializers turn restore into execution

A module initializer is .NET code that runs before normal application code when the CLR loads an assembly. That matters because a package does not need an obvious exported API call to start its payload. In this campaign, the malicious path could activate as soon as a test, build, or application process loaded the DLL, which makes a routine restore or dependency resolution step enough to cross into execution. The technical risk is not just the package content but the loader behaviour attached to it.

Practical implication: Treat loaded packages as executable content and review where restore-time assembly loading can occur in CI and developer tooling.

How anti-tamper loaders hide second-stage payloads

The reported loader verifies a .NET Reactor anti-tamper signature, allocates executable memory, decrypts a second-stage payload, and hooks JIT compilation so the code can run while the library continues to behave normally. That combination defeats simple static inspection because the package appears functional until runtime conditions expose the hidden path. Cross-platform code paths also broaden impact, because Linux and macOS builders can be exposed when restore workflows are shared across environments.

Practical implication: Inspect packages for runtime loading patterns, not just hashes, signatures, or platform labels.

Why package identity is now part of credential governance

Package name abuse becomes identity abuse when build systems trust a dependency namespace that looks internal or familiar. The article shows that unlisted versions can remain installable by exact version, so package-ID governance matters even when public search hides the most suspicious releases. That creates a governance gap between dependency approval and the actual credential-bearing hosts that restore those dependencies.

Practical implication: Control package admission by identity, not only by version, and scope build credentials so restore hosts expose minimal reusable secrets.

Threat narrative

Attacker objective: Steal developer and build-host credentials and high-value local data that can be reused for broader infrastructure access and downstream compromise.

1. Entry occurs when a developer workstation, build host, or mirror restores one of the impersonating NuGet packages by exact version or cached reference.
2. Credential access begins when the assembly loads and the protected loader decrypts and runs the second-stage infostealer.
3. Impact follows as browser passwords, SSH keys, wallet data, Outlook profiles, and cloud or registry tokens are staged for exfiltration.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package identity has become a security control, not just a supply-chain label. This campaign worked because the malicious packages looked like real .NET libraries and could still be installed by exact version even when unlisted from search. Dependency review that stops at reputation or hash comparison misses the governance problem: restore systems trust the package namespace before any code is executed. Practitioners should treat package admission as part of access governance, especially where build systems hold reusable credentials.

Restore-time execution is the real control boundary. The critical failure is assuming that dependency import is a passive event. In practice, module initializers, cross-platform loaders, and runtime decryption let an attacker move from package retrieval to code execution before normal application logic starts. That means the security question is not whether the package is signed or functional, but whether the build and test environment permits unreviewed code to run during loading.

Secret sprawl on developer and CI hosts creates the blast radius. The article’s theft targets include browser credentials, SSH keys, cloud tokens, and registry secrets, which are often co-located on the very hosts that restore dependencies. This is a classic NHI governance overlap: human and non-human credentials share the same operational surface, so one compromised build workstation can expose both. The practical implication is to separate restore trust from credential privilege wherever possible.

Restore governance needs a named control concept: package-identity trust gap. This is the failure mode where teams validate package provenance too late and then allow runtime loading to decide security outcome. The gap sits between dependency approval and executable behaviour, which means conventional allowlists are incomplete if they do not account for loaded assembly actions. Practitioners should shift review to package identity, restore policy, and build-scoped secret containment as a single control problem.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Package-identity trust gap: restore workflows need to distinguish between a package that is reachable and a package that is actually trusted. When exact-version installs and unlisted releases can still execute on load, the control point has to move from search visibility to admission policy and runtime containment.

Developer and CI hosts are a particularly dangerous convergence point because they combine dependency retrieval with credential-bearing workflows. If those systems can access registries, source control, cloud accounts, and browser-stored secrets, a single malicious package can turn a supply-chain event into an identity event.

The broader lesson is that NHI governance now includes the build plane, not just production workloads. Credential scoping, cache hygiene, and package approval are becoming the same control family when the restore process itself can execute attacker code.

For practitioners

• Audit NuGet package IDs and versions Search manifests, lockfiles, package caches, mirrors, and build logs for IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, and IR.OscarUI, then remove any matching artifact from trusted paths.
• Block unlisted package installs by default Require explicit approval for unlisted external packages and unfamiliar package IDs that mimic internal libraries, especially where exact-version installs can bypass search visibility.
• Purge affected restore environments Clear local and shared NuGet caches on developer machines and CI hosts that restored the malicious packages, then reimage or rebaseline hosts that loaded the assemblies.
• Rotate secrets exposed on build hosts Rotate cloud keys, registry tokens, GitHub tokens, SSH keys, browser-saved credentials, and wallet material that may have been reachable from affected restore jobs.
• Constrain build-scoped credentials Use least-privilege credentials for each job so a compromised restore host cannot reuse broad package-registry or source-control access beyond the build task.

Key takeaways

• Malicious NuGet packages can turn ordinary restore activity into code execution when assemblies load, which makes package identity part of the attack surface.
• Developer workstations, build agents, and mirrors are high-value targets because they often hold both human and non-human credentials in the same operational footprint.
• The most effective containment is to govern package admission, purge affected caches, and rotate every secret that a compromised restore host could reach.

Key terms

• NuGet supply-chain attack: A NuGet supply-chain attack uses a package repository to deliver malicious code through dependencies that developers already trust. The attacker relies on normal restore and build behaviour, which makes the compromise blend into routine software delivery unless package identity and runtime execution are both governed.
• Module initializer: A module initializer is .NET code that runs automatically when an assembly loads, before application logic starts. Security teams care about it because malicious code can trigger without an explicit function call, turning a seemingly benign package restore into an execution event.
• Build-Scoped Credentials: Build-scoped credentials are tokens, keys, or accounts that are intended to exist only for the duration and purpose of a build or restore job. When they are long-lived or broadly permissioned, a compromised pipeline can reuse them outside the narrow task they were meant to support.
• Package Identity Trust Gap: The package identity trust gap is the space between approving a dependency by name or hash and controlling what that dependency can do at runtime. It appears when teams assume restore is passive, even though loading the package can execute attacker-controlled code.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the operational context security teams face every day. It helps practitioners connect identity controls to the broader build, runtime, and access workflows that shape real-world risk.