Malicious NuGet packages turn routine restores into credential theft

At a glance

What this is: Corgea reports a NuGet supply-chain campaign in which five packages impersonated legitimate .NET libraries while carrying an infostealer that executed when loaded.

Why it matters: This matters because routine restores on developer machines and CI/CD builders can become credential-theft events, and those hosts often hold secrets that extend far beyond the build system.

By the numbers:

• The campaign reportedly published 224 total versions across five package IDs, with most older versions unlisted but still installable by exact version.

👉 Read Corgea's analysis of malicious NuGet packages targeting .NET developers

Context

Software supply chain attacks increasingly use trusted package ecosystems rather than obvious malware delivery. In this case, the risk is not simply a bad dependency name or a compromised hash, but a package that looks legitimate enough to be restored into normal .NET workflows and then executes when the assembly is loaded.

That pattern matters for identity and access governance because build hosts, developer workstations, package caches, and internal registries frequently carry cloud tokens, SSH keys, browser credentials, and registry secrets. When those environments are treated as low-risk utility systems, attackers inherit a broad credential estate with very little friction.

Key questions

Q: What breaks when a malicious package executes at module load time?

A: Install-time scanning can miss the abuse because the payload does not need a lifecycle hook. If the package is loaded through require() in a build, test, or runtime path, secret theft can occur after approval and before many organisations realise the dependency was active at all.

Q: Why do developer build hosts increase the impact of package supply-chain attacks?

A: They often hold the exact assets attackers want: SSH keys, cloud tokens, signing material, registry credentials, and cached service secrets. A malicious package can harvest those non-human identities from the build context and then expand into connected systems. That makes endpoint hygiene and identity hygiene the same problem during a supply-chain incident.

Q: What do security teams get wrong about package hash blocking?

A: Hash blocking is useful, but it does not solve package identity risk when the same malicious package name is republished in multiple versions or hidden through unlisting. Teams that only block known hashes will miss version rotation and internal mirror exposure, so package ID approval and lifecycle review must come first.

Q: How should security teams respond when a build may have run malicious dependency code?

A: Treat it as a potential credential incident, not just a software issue. Revoke exposed tokens, rotate any secrets available to the build host, inspect package provenance, and review source control and registry activity for follow-on abuse. Build compromise often becomes identity compromise very quickly.

Technical breakdown

How malicious NuGet assemblies execute before application code

The core technique is loader abuse inside the .NET runtime. The package includes functional code and uses a module initializer, which CLR invokes before normal application logic starts. That means the malicious path can execute without a developer ever calling a suspicious API. Public analysis describes a protected loader that verifies a Reactor anti-tamper marker, allocates executable memory, decrypts a second stage, and hooks JIT compilation so the payload can run while the library still behaves plausibly. This makes static inspection and simple restore-time checks less effective than runtime-aware controls.

Practical implication: Treat assembly load events as a security boundary and inspect restored packages on systems that compile or test code.

Why package identity and version control matter more than hash-only blocking

The campaign used legitimate-looking metadata and many published versions, with older ones often unlisted but still installable by exact version. That creates a persistence problem for defenders because package-ID trust can survive even when visible search results change. In practice, the attacker can rotate payload hashes while preserving a name that is already pinned in lockfiles, mirrors, or dependency graphs. Hash-based detections still help, but they are reactive if the package identity itself is not governed.

Practical implication: Control package ID approval, not just artifact hashes, and review unlisted versions in internal mirrors and lockfiles.

How exposed developer and CI credentials turn package execution into identity compromise

Once the malicious payload runs, the objective is credential collection rather than simple disruption. The sampled payload targets browser passwords, cookies, wallet extensions, SSH private keys, Outlook profiles, cloud tokens, and files from common user directories. That is an identity problem as much as a malware problem because the infected host becomes a shortcut to service accounts, registries, and cloud access. If build credentials are over-scoped or reused across jobs, a single malicious restore can expose multiple downstream systems.

Practical implication: Reduce the credential blast radius on developer and CI hosts and rotate secrets immediately after any package exposure.

Threat narrative

Attacker objective: The attacker aims to harvest reusable credentials and session material from software build and developer environments so they can pivot into cloud, code, and financial assets.

1. Entry occurs through a trusted NuGet dependency that impersonates a legitimate .NET library and is restored into developer or CI/CD environments.
2. Credential access begins when the assembly loads and the module initializer triggers the protected infostealer without requiring an explicit API call.
3. Impact follows when the payload collects browser, SSH, cloud, and wallet credentials from systems that already hold privileged development access.

NHI Mgmt Group analysis

Package identity, not just package content, is now a governance control. This campaign works because the attacker preserved a believable library identity while changing the payload beneath it. That undermines dependency trust models that rely on name familiarity or simple signature checks. For .NET teams, package approval must become a lifecycle control that covers new IDs, unlisted versions, and mirror hygiene, not only vulnerability scanning.

This is a classic credential blast-radius problem disguised as supply-chain malware. The malicious code targets browser sessions, SSH keys, cloud tokens, and wallet material because the build and developer estate is often over-trusted. That means the real failure is not merely code execution, but the assumption that non-production hosts hold low-value identities. The right control lens is privilege minimisation across the build chain, aligned to OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Secret theft in software delivery is increasingly an identity incident, not a pure malware incident. Once a package can execute at load time, the line between software integrity and identity compromise disappears. That is why build platforms, package registries, and developer endpoints need joint governance across IAM, PAM, and software supply chain controls. Teams that separate these domains will keep missing the path from dependency restore to downstream account takeover.

Unlisted package rotation creates a hidden persistence channel for supply-chain actors. The operator can keep the package name stable while cycling visible versions and keeping older versions installable by exact reference. That is a naming and lifecycle problem, not just a detection problem. Practitioners should treat dependency lifecycle review as part of secure software procurement and offboarding.

Secret sprawl in developer tooling is the named failure mode this campaign exploits. The attacker does not need a novel exploit when one compromised workstation can expose browser data, registry tokens, SSH keys, and cloud credentials in a single sweep. That failure mode is exactly what the NHI governance lens is designed to surface. The practitioner takeaway is to map every developer and CI identity to the secrets it can reach and the systems those secrets can unlock.

What this signals

Secret sprawl in build and developer tooling is becoming a repeatable compromise path. Teams should expect attackers to continue targeting package ecosystems because those ecosystems sit close to source code, signing keys, and operational secrets. The most useful near-term signal is not only whether a package is malicious, but whether a developer or CI identity can reach secrets that are valuable outside the build process.

The practical shift is toward lifecycle governance for package trust and identity reachability. That includes tighter approval for new package IDs, stronger internal mirror controls, and faster secret rotation when a restore event is suspicious. For identity teams, the lesson is simple: the software supply chain now behaves like an NHI estate, and it must be governed accordingly.

For practitioners

• Hunt for the affected package IDs across the full software estate Search dependency manifests, lockfiles, package caches, internal registries, and build logs for IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, and IR.OscarUI, then treat any host that restored or loaded them as compromised.
• Purge and re-seed package caches after exposure Remove local and shared NuGet caches that contain the package, then rebuild from a verified upstream or internally signed source so old binaries cannot be reintroduced through cached artifacts.
• Rotate every secret reachable from affected developer and CI hosts Reset cloud keys, package registry tokens, GitHub tokens, SSH keys, browser-saved credentials, and wallet material that may have been accessible from the infected environment, and assume session theft even if no exfiltration alert fired.
• Block unlisted external packages unless explicitly approved Require manual review for new package IDs that resemble internal libraries, and deny restore paths that depend on unlisted versions unless the package has been validated in a controlled mirror.

Key takeaways

• Malicious NuGet packages can turn ordinary dependency restores into credential theft events before application code even runs.
• The scale problem is not only the malware payload, but the number of package versions and trusted developer hosts it can reach.
• Package-ID governance, cache hygiene, and immediate secret rotation are the controls most likely to limit impact in this campaign pattern.

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.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
• Unlisted package persistence: Unlisted package persistence is the ability of a malicious package to remain installable by exact version even after it is hidden from public search. That behaviour matters because defenders who rely on visible package listings may miss active exposure in lockfiles, mirrors, and caches.

What's in the full analysis

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

• Exact package IDs, publisher patterns, and versioning behaviour that help defenders build detection logic
• Indicators of compromise including host paths, domains, and network endpoints observed in the campaign
• Remediation workflow details for removing packages, purging caches, and resetting credentials at scale
• Cross-platform loader behaviour on Windows, Linux, and macOS builders that affects CI triage

👉 Corgea's full post covers the package indicators, loader behaviour, and remediation steps in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle control. It gives security practitioners a practical way to connect identity governance to the systems and secrets that software delivery depends on.