They Didn't Hack Axios. They Hacked the Axios Maintainer.

One of the most significant JavaScript supply chain compromises of 2026 started with a Slack invite, not a vulnerability. Here's the full kill chain and what it means for how you prepare your people.

April 6, 2026
Ross Lazerowitz
Ross Lazerowitz
Co-Founder and CEO
They Didn't Hack Axios. They Hacked the Axios Maintainer.

On March 31, 2026, two malicious versions of the axios npm package were published to the npm registry. Within 89 seconds, the first infection landed on a monitored endpoint. Within three hours, at least 135 compromised systems were beaconing to the attacker's command-and-control infrastructure across macOS, Windows, and Linux.

Axios is one of the most depended-upon packages in the JavaScript ecosystem. It's present in roughly 80% of cloud and code environments, downloaded approximately 100 million times per week. It sits inside build pipelines, production applications, and developer tooling across virtually every enterprise that ships software. An estimated 600,000 downloads occurred during the three-hour window the malicious versions were live. If your organization writes JavaScript, axios is almost certainly somewhere in your dependency tree.

But here's the part most coverage is burying: the technical exploit was not the starting point. The root cause was a multi-stage social engineering campaign that ran for two weeks before a single line of malicious code was published.

The attacker didn't find a zero-day. They found a human.

The Kill Chain: Two Weeks of Trust Building

The axios post-mortem, published by lead maintainer Jason Saayman on GitHub, is a step-by-step account of how modern social engineering actually works. Not a phishing email with a misspelled domain and credential harvest landing page. A multi-week, multi-channel operation built on manufactured trust.

Screenshot of the axios post-mortem on GitHub, where maintainer Jason Saayman details the multi-stage social engineering attack used to compromise his account

The attack has been attributed to UNC1069, a financially motivated North Korean threat cluster active since at least 2018. Microsoft tracks the same infrastructure under the name Sapphire Sleet. Multiple researchers have noted operational overlaps between UNC1069 and BlueNoroff, a financially focused cluster associated with North Korea's broader cyber operations, though the exact organizational relationship between these groups remains a subject of ongoing analysis.

Here's how the attack unfolded, stage by stage.

Stage 1: Identity Cloning and Initial Contact

The attacker reached out to Saayman posing as the founder of a legitimate, well-known company. They had cloned the founder's likeness and built a convincing corporate identity around the impersonation. The outreach was personalized and tailored specifically to the maintainer's profile, interests, and open-source work.

This pattern is consistent with what Google's Threat Intelligence Group has documented across other UNC1069 campaigns. In a February 2026 report, Mandiant detailed a similar intrusion where UNC1069 used a compromised Telegram account belonging to a crypto CEO to initiate contact with a target, followed by a fake Zoom meeting and a ClickFix-style infection vector. The group has been observed using AI tools, including Gemini and GPT-4o, to develop tooling, conduct reconnaissance, and modify images to enhance the credibility of their lures.

The point: these are not template-based phishing campaigns. Each operation is individually researched and constructed to match the target's professional context.

Stage 2: Slack Workspace Immersion

After establishing initial contact, the attackers invited Saayman into a real Slack workspace. This workspace was branded with the impersonated company's visual identity, named plausibly, and populated with multiple channels, some of which were sharing LinkedIn posts that linked back to the real company's actual LinkedIn account.

The workspace contained fake profiles not only for the company's supposed team members but also for other open-source maintainers, creating the illusion of a broader professional community. The level of detail was significant: multiple channels, active-looking conversations, cross-referenced social media content, and believable personas across the workspace.

The purpose of this stage was to normalize the environment. Make the target feel like they were participating in a legitimate professional collaboration. Build the kind of ambient trust that makes the next step feel unremarkable.

This is the most operationally expensive part of the attack, and it's also the part that virtually no enterprise security program simulates. Building a fake workspace with branded channels, fake users, real LinkedIn content, and realistic activity patterns requires sustained effort. The fact that a state-sponsored actor invested that effort tells you something about the ROI they expect from it.

Stage 3: The Microsoft Teams Meeting

With trust established through days of Slack interaction, the attackers scheduled a Microsoft Teams meeting. The meeting appeared to include a group of participants who were consistent with the team profiles the target had already seen in Slack.

During or before the meeting, Saayman received a prompt indicating something on his system was out of date. Believing it to be a Teams-related dependency, he installed the update.

It was a remote access trojan.

As Saayman described in his post-mortem: "I installed the missing item as I presumed it was something to do with Teams, and this was the RAT."

The pretext worked because it was contextually plausible. Software update prompts during video calls are common enough that most users wouldn't think twice. The entire social engineering chain, from the initial outreach to the Slack immersion to the meeting setup, existed to make this single moment of trust feel natural.

Stage 4: Full Access and Supply Chain Compromise

With the RAT on Saayman's machine, the attackers had complete access to his environment, enough to hijack browser sessions and lift cookies. As Saayman later explained, the attacker had "enough access to hijack from my browser… lifting sessions or cookies." This gave them control of both his npm and GitHub accounts, bypassing 2FA entirely. They didn't need his credentials. They had his machine.

From there, they published axios@1.14.1 and axios@0.30.4 with an injected dependency, plain-crypto-js@4.2.1, that deployed a cross-platform RAT through a postinstall hook. The malware self-deleted after execution, replacing its package.json with a clean version to evade forensic detection.

The RAT itself was purpose-built. Elastic Security Labs' analysis revealed three parallel implementations (PowerShell for Windows, compiled C++ for macOS, Python for Linux) all sharing an identical C2 protocol, command set, and message format. The RAT maintained a 60-second beacon loop, capable of executing arbitrary commands, in-memory binary injection, directory browsing, and process enumeration. On Windows, it established persistence that would survive reboots.

One curious design choice: all three variants used a hardcoded IE8/Windows XP user-agent string for C2 communication. Trivially detectable on any modern network, and an immediate anomaly on macOS and Linux. But it provided a consistent protocol fingerprint for server-side routing.

The attacker had also pre-staged the malicious dependency 18 hours before detonation. A clean version of plain-crypto-js@4.2.0 was published by an attacker-controlled account to establish publishing history on npm and reduce the likelihood of automated scanners flagging the subsequent malicious version on account novelty alone.

The Attribution: North Korea's Expanding Target List

The axios compromise sits inside a well-documented pattern of North Korean operations. Google's GTIG attributed the attack to UNC1069. Microsoft attributed it to Sapphire Sleet. Multiple security vendors, including CrowdStrike and Sophos, have corroborated the attribution based on shared infrastructure, forensic metadata, and C2 patterns.

UNC1069 has historically targeted cryptocurrency companies, DeFi platforms, venture capital firms, and software developers at financial institutions. Their playbook is social engineering-first: build a relationship, establish trust, then deploy malware through a contextually plausible pretext.

What makes the axios attack significant is the target class. As security researcher Taylor Monahan noted: "Historically, these specific guys have gone after crypto founders, VCs, public people. They social engineer them and take over their accounts and target the next round of people. This evolution to targeting [OSS maintainers] is a bit concerning."

The shift in target class matters. Crypto founders control wallets. OSS maintainers control packages that run on millions of machines. The blast radius is different by orders of magnitude.

And this is not the first time. In September 2025, the popular npm packages Chalk and Debug were compromised through a similar maintainer account phishing attack. GTIG analyst Taylor Long told The Hacker News that "several DPRK threat actors have a history of conducting supply chain compromises and leveraging malicious npm packages for cryptocurrency theft, while also continuing to rely on social engineering techniques."

The tooling is also evolving. Mandiant's February 2026 investigation of an UNC1069 intrusion documented seven unique malware families deployed on a single host, alongside AI-generated deepfake video of known cryptocurrency CEOs used during fake Zoom calls to create social proof. The group has been observed using GPT-4o to modify images and enhance lure credibility.

This is where social engineering is headed: AI-assisted, multi-channel, individually tailored, and patient.

The Simulation Gap

Most organizations measure their social engineering resilience by sending phishing emails and tracking click rates.

Those programs test one vector (email), one pretext (credential harvest or malicious link), and one moment of decision (click or don't click). The result is a metric that tells security leadership how many employees clicked a fake email, and very little about how the organization would hold up against a campaign like this one.

The axios attack involved four distinct vectors: email or messaging for initial contact, Slack for trust-building, Teams for meeting pretext, and a software update prompt for payload delivery. Each stage had its own pretext. Each stage built on the credibility established by the one before it. The final action, installing an "update," only made sense because the target had been operating inside what appeared to be a legitimate professional context for weeks.

No single-email simulation captures any of this.

The gap between what enterprises test and what adversaries actually do has become a vulnerability in itself. Security teams report on phishing click rates and call it a social engineering program. Meanwhile, state-sponsored actors are building fake companies, populating Slack workspaces with AI-generated personas, and running multi-week trust-building campaigns before they ever deliver a payload.

The disconnect is not subtle and the adversaries know it.

What a Realistic Response Looks Like

Consider what the maintainer was dealing with. This wasn't a suspicious email from an unknown sender. It was a weeks-long relationship with a credible-looking professional community. The Slack workspace had channels. It had LinkedIn content. It had other people in it. The Teams meeting had participants. The "update" prompt appeared in the context of a legitimate software tool during what felt like a normal professional interaction.

Saayman had MFA enabled on everything. As he wrote: "I have 2FA/MFA on practically everything." It didn't matter. The attack bypassed technical controls by targeting the layer those controls were designed to protect: human judgment.

Socket's analysis put it directly: "This attack did not exploit a flaw in Axios itself. It exploited the ecosystem's trust, the maintainer's access, and the human layer of the software supply chain."

The technical response to this incident has been well-documented by StepSecurity, Snyk, Socket, and others. Pin your dependencies. Audit your lockfiles. Rotate credentials. Block the C2 domain. Those are table stakes. None of them would have prevented this attack. MFA didn't prevent it. The attack bypassed all of it by compromising the human first and inheriting their authenticated access.

That's the gap. Here's how to close it:

Simulate multi-vector campaigns, not single-email tests. If your social engineering program only covers email, you're measuring resilience against a vector that state actors treat as an initial touchpoint, not a standalone attack. Vishing, smishing, Slack-based pretexts, and meeting-based delivery should all be in scope. The key is that each stage builds on the credibility established by the one before it. A standalone phishing email tests one decision. A multi-stage campaign tests whether an employee recognizes when trust is being manufactured around them.

Measure reporting behavior, not just failure rates. The most valuable metric is time-to-report. In the axios attack, community members flagged suspicious activity on GitHub almost immediately. An employee who reports a suspicious Slack invite at stage one has broken the kill chain three steps before payload delivery. That's the outcome security teams should be optimizing for, and it's the metric simulations should be scored against.

Score every stage of the chain. Traditional phishing simulations produce a single binary metric: clicked or didn't click. A more useful approach measures behavior at every stage. Did the employee engage with the outreach without verifying the sender? Did they join an external workspace without reporting it? Did they install software based on a prompt from an unverified source? The defensive value of early reporting is exponentially higher than the defensive value of not clicking a link, because by the time you're evaluating a link, the adversary has already built a context designed to make you click it.

Train for trust escalation, not just link recognition. The axios attack didn't rely on a suspicious link. It relied on two weeks of ambient trust-building that made the final action feel normal. Your training should teach employees to recognize when trust is being constructed for them, and to verify through independent channels before acting on it.

Include your engineers and maintainers. Traditional security awareness programs often focus on non-technical employees. The axios attack targeted a senior developer. The DPRK IT worker campaigns we've written about previously target hiring teams and engineering managers. Anyone with access to critical infrastructure is a target.

The Bigger Picture: Where AI Social Engineering Is Headed

This incident is not an anomaly. It's the operational direction of social engineering by state-sponsored actors.

The tradecraft documented here (impersonation, workspace fabrication, meeting pretexts, fake software updates) has been tracked across UNC1069 and BlueNoroff campaigns for years. Google documented a nearly identical attack chain in their February 2026 UNC1069 report, targeting crypto firms with compromised Telegram accounts, fake Zoom meetings, and ClickFix infection vectors. The axios compromise represents the extension of those techniques to open-source maintainers, a target class with outsized access and limited institutional security support.

The pattern is clear: compromise a trusted human, use their access to poison trusted infrastructure, and let the ecosystem distribute the payload for you.

Every link in that chain is a trust decision. And right now, most enterprises aren't testing any of them.

Organizations that treat phishing simulations as a complete measure of social engineering resilience are testing for one move in a game that's three moves long. The adversaries have adapted. The question is whether your training has.


Mirage Security builds AI-powered social engineering simulations across vishing, smishing, spear phishing, deepfake video, and multi-vector attack chains. If you want to test your organization against the same techniques used in the axios compromise, talk to us.