Malicious NuGet packages steal developer credentials, SSH keys, and crypto wallet data

Five malicious NuGet packages have been found targeting .NET developers with an infostealer that can steal browser passwords, cookies, SSH private keys, cryptocurrency wallet data, and local files. Socket researchers said the packages impersonated Chinese .NET UI and enterprise libraries to look useful while hiding malicious behavior.

The packages were published under the NuGet account bmrxntfj and received about 65,000 downloads across all versions. The campaign puts developer workstations and CI/CD build systems at risk because package restores and builds can expose sensitive credentials used in software projects.

The five package names are IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, and IR.OscarUI. Socket said the packages copied or mimicked real-looking library code, which helped them appear normal during quick checks.

Why this NuGet campaign matters

NuGet is a key package manager for .NET development, so a malicious package can reach developers, build servers, and internal software pipelines. That makes this campaign a supply chain risk, not just a single-machine infection.

The attacker did not publish empty or obviously fake libraries. The packages included functional code and used names that could look familiar in Chinese enterprise .NET environments.

This makes the attack harder to spot. Developers may see a package that builds correctly and behaves like a normal dependency, while the hidden payload works in the background.

At a glance

Detail	What was found
Package ecosystem	NuGet
Publisher account	bmrxntfj
Malicious packages	IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, IR.OscarUI
Estimated downloads	About 65,000 across all versions
Main targets	.NET developers, developer workstations, and CI/CD build systems
Data at risk	Browser credentials, session cookies, SSH keys, crypto wallets, Outlook profiles, Steam data, and local files
Known second-stage file	we4ftg.exe

How the malicious packages worked

Socket said the packages used a .NET module initializer, which can run automatically when an assembly loads. This means a developer does not need to manually run a suspicious file for the attack chain to begin.

The payload used .NET Reactor protection and JIT hooking to interfere with the runtime compilation process. After the package loaded, the malicious code could control later method compilation while the visible library code continued to work.

The second-stage infostealer was tracked as we4ftg.exe. Socket said it targeted saved browser passwords, autofill data, payment cards, cookies, crypto wallet extensions, desktop wallet files, SSH keys, Outlook profiles, Steam data, and files from common user folders.

What the malware tried to steal

• Saved passwords from Chromium-based browsers
• Browser cookies and active session tokens
• Autofill data and stored payment cards
• MetaMask, TronLink, Phantom, Trust Wallet, and Coinbase Wallet extension data
• Desktop wallet files from apps such as Exodus, Electrum, Atomic, Guarda, Ledger, and Binance
• SSH private keys, including id_rsa files
• Outlook profiles and Steam session data
• Files from Documents, Desktop, and Downloads

The package rotation made detection harder

The attacker used a version rotation tactic to reduce the value of hash-based detection. Socket found 224 total versions across the five package IDs, with 219 versions hidden from public search through unlisted package versions.

This matters because unlisted NuGet versions can still remain installable when a project references them directly. By rotating visible versions, the attacker could keep changing package files while older versions remained reachable.

Socket said this tactic helped the campaign appear smaller than it was. It also forced defenders to track package names, publisher behavior, and infrastructure instead of relying only on file hashes.

Infrastructure and detection clues

Stolen data was staged under a path designed to look like a Microsoft OneDrive location: C:\ProgramData\Microsoft OneDrive\keys.dat. Socket noted that legitimate OneDrive does not create a keys.dat file there.

The primary command-and-control domain listed by Socket was dns-providersa2[.]com, with endpoints used for beaconing and data upload. The domain name was designed to look ordinary in network logs.

Security teams should also review connections to the reported IP address 62[.]84[.]102[.]85 and search for the malicious package names in project files, package lock files, dependency graphs, build logs, and local NuGet caches.

What developers should do now

• Search all .csproj files, packages.config files, and packages.lock.json files for the five malicious package names.
• Check CI/CD runners and build servers that restored or loaded any of these packages.
• Remove the packages from projects and block them in dependency policies.
• Rotate browser-saved passwords, API keys, cloud tokens, SSH private keys, and database credentials exposed on affected machines.
• Move cryptocurrency funds to new wallets if any wallet seed or private key may have existed on an affected system.
• Check for C:\ProgramData\Microsoft OneDrive\keys.dat on Windows systems.
• Alert on DNS or outbound connections to the reported command-and-control infrastructure.
• Audit recent package restores and builds from September 2025 onward.

Why CI/CD systems need extra attention

Developer laptops are not the only concern. Build systems often store deployment tokens, signing keys, package publishing credentials, SSH keys, and cloud access tokens.

If a malicious dependency runs inside a build environment, it may reach secrets that ordinary users cannot access. This can create a path from one poisoned dependency to broader software supply chain compromise.

Teams should review secrets available to build jobs and reduce what each pipeline can access. Package allowlists, lock files, source mapping, and dependency review should become standard controls for .NET projects.

FAQ