Overview
A coordinated malware campaign was uncovered targeting .NET developers through the official NuGet package ecosystem. The attackers published multiple malicious packages that closely imitated legitimate and widely used cryptocurrency and API libraries. These packages were designed to blend into normal development workflows while quietly stealing sensitive information or manipulating crypto transactions.
What makes this campaign especially concerning is that it targets developer environments and build systems, not end users directly. Once a malicious package is pulled into a project, the compromise can spread downstream through CI/CD pipelines and distributed software.
Who is being targeted
The campaign primarily targets:
- .NET developers working with cryptocurrency, blockchain, or financial APIs
- Organizations building crypto-enabled applications, trading tools, wallets, or payment services
- Development teams using NuGet directly from the public repository without strict allowlisting or dependency verification
- CI/CD build servers that restore NuGet dependencies automatically
The attackers appear to focus on developers with direct access to wallets, private keys, or cloud-based advertising and API credentials, where stolen data can be quickly monetized.
What has been compromised
Based on analysis of the malicious packages, the following assets are at risk:
- Cryptocurrency wallet private keys and seed phrases
- Wallet files stored locally on developer machines
- Hardcoded or environment-based API keys
- OAuth credentials, including tokens and client secrets used for services such as advertising platforms
- Crypto transactions, which may be silently redirected to attacker-controlled addresses
In some cases, the malware does not steal credentials outright but instead waits until a transaction meets a value threshold, then alters the destination address while letting the transaction proceed normally. This significantly delays detection.
How the attack works
- Malicious packages are uploaded to NuGet
The attackers publish packages with names that closely resemble popular libraries. Some use subtle spelling changes or look-alike characters, making them easy to confuse with legitimate packages. - Developers install the package
Because the package behaves like the real library and exposes expected methods, it passes basic testing and code review. - Hidden malicious logic executes
Small, carefully hidden functions collect sensitive data (wallets, keys, tokens) or intercept transaction-related calls. - Data is exfiltrated quietly
Stolen information is sent to a remote server using simple HTTP requests. The destination is often obscured in code using basic obfuscation techniques. - Downstream spread becomes possible
If the infected package is part of a shared library or compiled product, the compromise may extend to customers or partner environments.
Known malicious NuGet packages
The campaign includes at least 14 confirmed malicious packages, grouped by function:
Wallet and credential stealers
SolnetPlusNBitcoin[.]UnifiedBitcoinCoreSolanaNetNethereumUnifiedNethereumNetNetherеum[.]All(uses look-alike characters)SolnetUnifiedSolnetAll[.]Net
Transaction hijacking packages
Binance[.]CsharpBybitApi[.]NetCoinbase.Net[.]Api
OAuth and API token stealer
GoogleAds[.]API
Some additional packages were removed before full analysis but share the same publishers and behavior patterns.
Indicators of Compromise (IOCs)
Network indicators
Monitor or block outbound traffic to the following domain:
solananetworkinstance[.]info
Suspicious traffic typically includes:
- HTTP or HTTPS POST requests
- Payloads containing wallet data, private keys, or OAuth parameters
- Requests originating from developer tools, build agents, or .NET processes
File and package indicators
Look for the following within NuGet caches, build directories, or artifact repositories:
- Presence of the package names listed above
- Unexpected versions of crypto or exchange-related libraries
- .NET assemblies containing:
- XOR-decoded strings
- Hardcoded URLs assembled at runtime
- Functions that intercept transaction or address-mapping logic
Behavioral indicators
- Developer machines making outbound connections shortly after building or running crypto-related projects
- Crypto transactions being sent to unfamiliar addresses despite correct code configuration
- OAuth tokens or API keys being abused without corresponding login activity
Sigma rule – Network-based detection
The following Sigma rule is designed to detect suspicious outbound network activity associated with this campaign. It is intentionally written in a general form so it can be adapted to most SIEM platforms.
title: Suspicious Outbound Traffic from Developer Systems to Known NuGet Malware Domain
id: 9f4c2c7e-6e8a-4b3b-9d91-5f6f7a8b2a01
status: experimental
description: >
Detects outbound HTTP or HTTPS connections from developer or build systems
to a domain associated with malicious NuGet packages used to steal
cryptocurrency wallets and OAuth credentials.
author: Internal SOC
date: 2025-01-01
logsource:
category: network_connection
product: any
detection:
selection_domain:
destination_domain|contains:
- "solananetworkinstance.info"
selection_process:
process_name|contains:
- "dotnet"
- "msbuild"
- "nuget"
- "devenv"
condition: selection_domain and selection_process
falsepositives:
- Unknown at this time
level: high
tags:
- attack.supply_chain
- attack.exfiltration
- attack.development
How to use this rule effectively:
- Apply it to logs from developer endpoints, build servers, and CI runners
- Correlate alerts with recent NuGet package restores or builds
- Treat hits as high priority if the system handles crypto keys or API secrets
Recommended response actions
- Immediately remove affected packages from all projects and dependency manifests
- Scan developer endpoints and CI systems for cached copies of the malicious packages
- Rotate all exposed credentials, including:
- Wallet keys
- OAuth tokens
- API secrets
- Review recent crypto transactions for unauthorized destination addresses
- Implement dependency controls, such as:
- Private NuGet mirrors
- Package allowlists
- Mandatory package signing verification
- Increase monitoring on build systems, especially outbound traffic during restore and build phases
Final Takeaway
This campaign reinforces a growing trend: developers and build pipelines are now prime attack targets. By compromising a dependency instead of an endpoint, attackers gain access to sensitive data and can silently influence production systems without triggering traditional security controls.
Treat developer tooling as production infrastructure. What enters the build process can — and often does — reach customers.
