Sapphire Sleet npm Campaign: Microsoft Links Mastra and Axios Attacks to North Korea

A North Korean state actor spent the first half of 2026 systematically targeting JavaScript developers through their package manager. On June 19, Microsoft Threat Intelligence updated its disclosure of the Mastra npm attack and confirmed with high confidence that Sapphire Sleet, also tracked as BlueNoroff, is responsible for both the June 17 Mastra scope takeover and the March 31 Axios compromise. Two supply chain attacks, four months apart, and Microsoft now says they’re the work of the same group. Any team that installed affected packages during either exposure window should be treating those machines as compromised.

Sapphire Sleet is a North Korean state actor operating under the Reconnaissance General Bureau, with documented activity since at least March 2020. Its primary mandate is generating hard currency for the regime through cryptocurrency theft, with a focus on financial services and crypto-adjacent developer infrastructure. The group’s shift toward poisoning widely used npm packages reflects a strategic calculation: a single compromised maintainer account or contributor credential can reach millions of developer environments in hours.

The June Attack: Mastra’s Entire npm Scope

Mastra is a TypeScript framework for building AI agents and applications. The @mastra scope has combined weekly downloads exceeding 1.1 million, with @mastra/core alone pulling roughly 918,000 installs per week. On June 17, 2026, a threat actor used a compromised npm contributor account named “ehindero” to seize the entire scope in an 88-minute automated campaign.

The attack’s preparation started a day earlier. A separate attacker-controlled account published easy-day-js@1.11.21 on June 16, 2026, containing only legitimate dayjs code and no payload. That clean version established credible registry history for the package. At 01:01 UTC on June 17, the attacker published easy-day-js@1.11.22, adding an obfuscated postinstall dropper in setup.cjs. Because the compromised packages pinned the dependency as ^1.11.21, npm’s semver resolver automatically pulled the malicious version on every subsequent install.

Between 01:12 and 02:39 UTC, the ehindero account republished more than 140 packages across the @mastra scope. Each received a single injected line in package.json adding easy-day-js as a production dependency. The Mastra source code itself was untouched in every version. The only change was that single line, and it was enough.

What the Payload Collected

The postinstall hook executed automatically the moment a developer or CI runner ran npm install. The dropper script disabled TLS certificate verification, contacted attacker-controlled C2 infrastructure at 23.254.164.92:8000, downloaded a second-stage payload, launched it as a detached background process, and self-deleted to remove forensic evidence.

The second stage ran a comprehensive credential sweep. Based on analysis from Orca Security and JFrog, the payload targeted:

• Browser data from Chrome, Edge, and Brave
• Credentials from 166 cryptocurrency wallet extensions, including MetaMask, Phantom, Coinbase, and Binance
• API keys for OpenAI, Anthropic, and Google AI services
• AWS, Azure, and GCP credentials
• GitHub tokens and CI secrets
• SSH private keys
• Full host reconnaissance data

On systems where it ran with sufficient permissions, the malware established cross-platform persistence mechanisms designed to survive an npm uninstall. No user interaction beyond running npm install was required. Affected packages were removed and ehindero’s publish access was revoked on the same day.

The March Attack: Axios and the Social Engineering Route

The Axios compromise on March 31 used a different entry point, but it delivered the same class of threat.

Axios is the most widely used HTTP client in the JavaScript ecosystem, with over 100 million weekly downloads. It appears in the dependency trees of thousands of libraries, which means many projects that don’t list Axios directly would still pull a poisoned version transitively on a fresh install.

Roughly two weeks before March 31, Sapphire Sleet launched a targeted social engineering campaign against Jason Saayman, the project’s lead maintainer. The attacker constructed a false identity as the founder of a legitimate company, built a fraudulent Slack workspace with convincing channels and team members, and invited Saayman to a staged Microsoft Teams meeting. During that call, the attacker prompted him to install what appeared to be a system update. The install delivered WAVESHAPER.V2, a cross-platform remote access trojan that gave the attacker control of his machine.

With access to his machine and browser session, the attacker harvested active session cookies, lifting npm credentials without triggering two-factor authentication. The attacker changed the account’s registered email to ifstap@proton.me, then published axios@1.14.1 at 00:21 UTC and axios@0.30.4 roughly 39 minutes later. Both releases injected plain-crypto-js@4.2.1 as a phantom dependency. The malicious versions were live for approximately three hours and fifteen minutes before npm removed them.

Why Two-Factor Authentication Did Not Help Here

Saayman confirmed that 2FA was enabled on all of his accounts, including GitHub and npm. In his post-mortem, he noted the attacker had access sufficient to hijack active sessions directly from his browser, lifting credentials and session cookies without any authentication prompt. From npm’s perspective, every publish looked like it came from the legitimate maintainer using his own valid access.

Trusted Publisher mechanisms and OIDC-based publishing controls would not have blocked this either. Those controls apply to the publishing workflow. They don’t protect against a maintainer’s machine being fully compromised before a publish request is sent. When an attacker controls the machine, they control the session, and the authentication layer has nothing left to enforce.

CISA issued an advisory on the Axios compromise on April 20, 2026.

What Connects These Two Attacks

Microsoft’s June 19 attribution rests on infrastructure and post-compromise tradecraft. Systems that communicated with the Mastra campaign’s C2 servers showed follow-on activity consistent with previously documented Sapphire Sleet operations, including a PowerShell backdoor the group has used in prior campaigns, additional persistence mechanisms, Microsoft Defender exclusions, and a malicious Windows service granting SYSTEM privileges.

The tactical overlap between the two attacks is also structural. The clean-bait-then-weaponize staging pattern used in the Mastra attack, publishing an inert version of the dependency first and then a malicious one, mirrors the Axios attack’s preparation timeline for plain-crypto-js. Snyk confirmed this structural overlap independently in its own analysis of the Mastra incident.

Target selection fits Sapphire Sleet’s known objectives. Where Mastra goes, LLM API keys follow. Developers building AI agents routinely store OpenAI, Anthropic, and Google credentials in environment variables, making the @mastra ecosystem a high-value target for a group whose primary mandate is cryptocurrency and hard-currency theft.

What to Do Now

Check for Mastra exposure. In every project that includes @mastra packages, run:

npm ls easy-day-js

If the command returns output, that environment installed the malicious dependency during the exposure window.

Check for Axios exposure. Search your lockfiles for axios@1.14.1 or axios@0.30.4:

grep -r "axios" package-lock.json | grep "1.14.1\|0.30.4"

Rotate every credential in range. Any credential accessible from an affected machine should be treated as exposed: LLM API keys, cloud provider credentials, npm tokens, GitHub secrets, SSH keys, and CI secrets. Rotate each one before you assess whether unauthorized access occurred. Assume it did until you can confirm otherwise.

Check for persistence artifacts. Removing the compromised package does not remove a persistence mechanism that’s already been installed. On macOS, audit ~/Library/LaunchAgents/ for unexpected launch agent entries. On Linux, check ~/.config/systemd/user/ and ~/.config/NodePackages/ for unexpected services and files. On Windows, inspect C:\ProgramData\NodePackages\ and the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key.

Treat affected machines as compromised. Frankly, an npm uninstall is not remediation. If either set of versions ran in your environment, the appropriate response is a full credential rotation and either a complete machine audit or a rebuild.

Why Point-in-Time Scanning Isn’t Enough

Socket flagged plain-crypto-js@4.2.1 within six minutes of its publication on March 30, before the Axios packages were even live. Socket and StepSecurity published analysis of the easy-day-js payload on June 17, the same day the Mastra scope was poisoned. In both cases, behavioral detection was fast. However, detection speed only matters if it’s upstream of your install.

Point-in-time SCA scanning checks what’s already in your lockfile. It doesn’t watch for a dependency published minutes ago whose postinstall hook executes before any static analysis has run. Real-time behavioral scanning is what caught both of these attacks early, and it’s the essential control for closing the window between publication and block.

Moreover, lockfile pinning and disabled install scripts are the two hardening steps that work alongside detection. Pinning limits your exposure window by preventing semver resolution from pulling a new version automatically. Disabling install scripts removes the postinstall hook vector entirely. Combined with real-time scanning, those controls would have substantially reduced the blast radius of both campaigns.

For a practical guide to Socket’s approach to supply chain defense, see our Socket review. For a comparison of real-time scanning against Dependabot’s point-in-time model, see Dependabot vs Socket.