Supply Chain Alert: Malicious 'StripeApi.Net' Typosquatting on NuGet
Just caught the report regarding a new malicious package, StripeApi.Net, hitting the NuGet Gallery. It’s a textbook typosquatting attack aimed squarely at the financial sector, impersonating the legitimate Stripe.net library (which has over 75M downloads).
The malicious package attempts to exfiltrate API tokens upon initialization. If you are in a .NET environment handling payments, you need to audit your dependencies immediately. The attackers are relying on the simple mistake of missing a dot or trusting the namespace blindly.
Immediate Detection Steps: I recommend running a quick scan across your repos to ensure no one accidentally installed this. You can use PowerShell to scan your project directories for references:
Get-ChildItem -Path C:\Projects -Recurse -Filter "*.csproj" |
Select-String -Pattern "StripeApi.Net" | Select-Object Path, LineNumber, Line
**Detection Logic:**
From a SOC perspective, watch for suspicious outbound connections from build agents or dev workstations shortly after package installation. The exfiltration usually happens in the class constructor.
Has anyone implemented strict allow-listing for NuGet feeds in their org, or are we still seeing wild-west package management in most places?
We moved to strictly using Azure Artifacts feeds with upstream sources disabled last year after the System.Net.Http fiasco. It's a bit more overhead to onboard new libs, but it completely blocks these types of typosquatting attacks if the malicious package isn't in the public upstream you've approved. If you aren't proxying your internal feed, you're flying blind.
Good catch on the PowerShell snippet. For those using GitHub Advanced Security, you can add this custom pattern to your secret scanning to catch the token exfiltration if the attacker uses a known header format:
- pattern: 'Bearer\s+sk_live_[a-zA-Z0-9]{24,}'
Although preventing the install is better than detecting the leak, this acts as a safety net.
It’s insane that NuGet still allows package names that are just one character off or simply append '.Net' to existing popular libraries without some verification flag. We rely on dotnet list package --vulnerable in our CI/CD pipelines, but for typosquatting, manual code review during PRs is still the only 100% reliable defense I've found.
Beyond auditing dependencies, verify if the exfiltration already occurred by checking network telemetry. You'll likely see an outbound connection to a C2 domain. If you use Sentinel or Defender, run a quick KQL hunt for anomalies:
kusto DeviceNetworkEvents
| where InitiatingProcessFileName has "dotnet"
| where RemoteUrl contains "stripe" and isnotempty(UrlQueryString)
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessCommandLine
This helps confirm if credentials were actually transmitted before you remediated the malicious package.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access