The recent Axios npm supply chain attack, attributed to UNC1069 (suspected North Korean actors), was not a technical exploit. It was a meticulously crafted social engineering campaign. From a cloned CEO identity to a fake Slack workspace and a fake Microsoft Teams error, the attackers manipulated a single maintainer into handing over access to one of the most downloaded JavaScript packages on earth.
Key Takeaways
- The human layer is the target. UNC1069 didn't break through code, they broke through trust. The entire attack chain relied on impersonation, rapport-building, and a single believable fake error message.
- The attack was hyper-personalized. The threat actors cloned the founder's identity, set up a fully branded Slack workspace with realistic channels, and tailored every step specifically to the maintainer they were targeting.
- Open-source maintainers are the new high-value targets. With nearly 100 million weekly downloads, Axios was a force-multiplier target. Compromising one maintainer unlocked a blast radius spanning millions of downstream applications and CI/CD pipelines.
- This wasn't a one-off. Socket later confirmed that maintainers of Lodash, Fastify, dotenv, mocha, and Node.js core itself were targeted in the same coordinated campaign, most of them narrowly avoiding compromise.
The software supply chain has become one of the most consequential attack surfaces in modern cybersecurity, and the recent compromise of the Axios npm package makes that painfully clear.
Axios is the most widely used JavaScript library for HTTP requests, with over 100 million weekly downloads. The attackers didn't target a vulnerability in its code. They targeted the person responsible for maintaining it.
The campaign was carried out by UNC1069, a financially motivated, North Korea-nexus threat group active since at least 2018, and formally attributed by Google's Threat Intelligence Group (GTIG) and Mandiant. Their method wasn't a zero-day exploit or a sophisticated malware dropper, at least not at first. It was a fake Slack workspace, a cloned CEO, and a fake Teams error message. That's all it took.
The Social Engineering Chain: Step by Step
What makes the Axios attack so instructive and alarming is the level of operational detail that went into the social engineering. Maintainer Jason Saayman published a post-mortem on GitHub describing exactly how it unfolded. The Hacker News covered the full account here.
Here is the attack chain, reconstructed:
1. Initial Contact: CEO Impersonation via Slack
- The attackers approached Saayman posing as the founder of a legitimate, well-known company.
- They had cloned the founder's identity: name, photo, professional profile, with enough fidelity to appear convincing at first glance.
- He was invited into what appeared to be the company's real Slack workspace.
- The workspace was branded to the company's CI and named in a plausible manner.
- It included active channels sharing LinkedIn posts, news, and professional content — all designed to build ambient legitimacy over time.
- Saayman later described it as: "extremely well coordinated, looked legit, and was done in a professional manner."
2. Trust Building: The Warm-Up Phase
- Rather than immediately pushing a payload, the attackers invested time in building rapport.
- The workspace felt lived-in and credible, not rushed or obviously fake.
- This phase mirrors what researchers at Huntress and Kaspersky had previously documented in UNC1069 campaigns targeting cryptocurrency founders, a playbook the group has now clearly extended to open-source maintainers.
3. The Escalation: A Fake Microsoft Teams Meeting
- After establishing trust on Slack, the attackers scheduled a Microsoft Teams call with Saayman.
- Upon joining, he was presented with a fake error message stating that "something on his system was out of date."
- The error prompt was a [ClickFix-style lure](https://arsen.co/en/blog/clickfix-attacks-targeting-microsoft-cloudflare-and-crypto): a technically plausible message instructing the user to install an update or fix to resolve an audio/video issue.
4. The Payload: Remote Access Trojan Installed
- Saayman followed the prompted "fix."
- This action triggered the deployment of a Remote Access Trojan (RAT) on his machine.
- With the RAT installed, the attackers gained persistent, covert access to his environment, including:
- npm credentials (the keys needed to publish packages)
- Browser session tokens
- Stored secrets and API keys
5. The Consequence: Two Trojanized Axios Versions Published
- Using the stolen npm account credentials, UNC1069 published two malicious versions of Axios:
axios@1.14.1axios@0.30.4
- Both contained an obfuscated dropper that silently installed the WAVESHAPER.V2 backdoor, a cross-platform RAT supporting Windows, macOS, and Linux, as documented by GTIG and Mandiant.
- The malicious code executed automatically through the package's
postinstallhook, meaning any developer or CI/CD pipeline that rannpm installpulled in the backdoor without any manual interaction.
A Coordinated Campaign, Not a Single Hit
The Axios compromise was not an isolated incident. It was one confirmed success in a broader, coordinated targeting campaign against high-impact open-source maintainers.
After the story broke, Socket published a follow-up analysis revealing that several other maintainers had come forward to report nearly identical approaches:
- Jordan Harband, a maintainer of ECMAScript polyfills and shims
- John-David Dalton, a creator of Lodash
- Matteo Collina, a lead maintainer of Fastify, Pino, and Undici (first contacted via Slack)
- Scott Motte, a creator of dotenv
- Pelle Wessman, a maintainer of mocha and type-fest (lured via a fake podcast recording invitation, then prompted to run a
curlcommand in Terminal when he refused the fake app install; attackers deleted all messages and went silent after he refused) - Jean Burellier, a Node.js core collaborator, initially contacted via LinkedIn by someone posing as a representative of a company named "Openfort"
In every case, the pattern was the same: build rapport, schedule a video call, present a fake error, prompt a fix. As Socket CEO Feross Aboukhadijeh put it:
That fix is a RAT. Once it's on your machine, they have your .npmrc tokens, browser sessions, AWS creds, and Keychain. 2FA doesn't matter. OIDC publishing doesn't matter. Game over.
Why This Attack Is So Hard to Stop
Unlike traditional phishing, which relies on a malicious link or email attachment, this attack chain weaponized professional trust and human helpfulness:
- The victim wasn't tricked into clicking a suspicious file, they were guided through what appeared to be a normal technical troubleshooting step.
- The social engineering unfolded across multiple platforms (LinkedIn or Slack for initial contact, Teams or Streamyard for the payload delivery), making it harder to detect any single red flag.
- The fake workspaces and identities were operationally convincing, not quick phishing kits, but carefully constructed environments.
- Once the RAT was installed, 2FA on the npm account didn't matter: the attackers already had live session tokens.
Security researcher Taylor Monahan summed up the broader trend:
Historically, these specific guys have gone after crypto founders, VCs, public people. This evolution to targeting OSS maintainers is a bit concerning.
Prevention: What Maintainers and Organizations Can Do
Supply chain attacks like this one are hard to prevent with technical controls alone, because the entry point isn't a software vulnerability, it's a person. That said, a combination of behavioral awareness and structural safeguards can significantly reduce the risk. Jason Saayman himself outlined several remediation steps taken after the incident: resetting all devices and credentials, setting up immutable releases, adopting OIDC-based publishing flows, and updating GitHub Actions to follow current security best practices.
In summary
UNC1069 is a financially motivated threat group with ties to North Korea, active since at least 2018. They have previously targeted cryptocurrency firms, venture capital investors, and AI companies, as documented by Google and Mandiant. The Axios attack represents a notable escalation: shifting from targeting financial sector individuals to targeting the open-source maintainers of critical software infrastructure.
Multi-factor authentication protects the login process — but once a RAT is installed on a machine, the attacker doesn't need to log in. They already have live session tokens, browser cookies, and stored credentials. This is why endpoint security and avoiding RAT installation in the first place is the real defense, not just account-level MFA.
Standard phishing typically delivers a malicious link or attachment in a single interaction. The UNC1069 campaign involved weeks of trust-building, across multiple professional platforms, with convincingly branded fake workspaces and identities. The "payload delivery" was disguised as a routine technical fix during a scheduled video call — a level of operational sophistication that most employees and maintainers are not trained to recognize.
If you or your CI/CD pipeline ran
axios@1.14.1oraxios@0.30.4, treat the affected environment as fully compromised. Isolate the host, rotate all credentials and secrets that were present on the machine, audit your dependency lockfiles forplain-crypto-js, and block traffic tosfrclak[.]comand IP142.11.206.73. Full remediation guidance is available in Mandiant's original advisory.
How to protect against such social engineering tactics?
How do you detect an impersonation attempt before it succeeds?
The UNC1069 playbook (cloned founder identity, branded Slack workspace, plausible meeting invitation) is specifically designed to survive casual scrutiny. A few signals tend to cut through the surface credibility.
- Check whether the outreach arrived via a channel you didn't initiate and couldn't verify out-of-band: a Slack invite from a workspace you have no existing relationship with is not the same as an email from a known contact.
- Look at the pace and structure of the interaction: legitimate business relationships rarely accelerate from cold introduction to scheduled video call within days, with an urgent "fix" required on the call itself.
- Verify the identity through a completely separate channel: find the real company's contact details independently and confirm the person exists and reached out. As we explain in our analysis of social engineering tactics, organisations should establish explicit verification rules for any request arriving from an unusual or external route, especially when it involves access, credentials, or software installation; not just for financial transactions.
How do you recognise a multi-step social engineering attack while it is unfolding?
Multi-step campaigns are deliberately structured to make each individual action seem reasonable in isolation. No single moment feels like "the attack." This is precisely what makes them harder to catch than a one-shot phishing email.
The clearest warning pattern is a sequence that follows this arc:
unsolicited contact → rapport-building period → escalation to a higher-stakes interaction (a call, a meeting, a demo) → a technical prompt that requires you to install, run, or approve something.
Our coverage of ClickFix and multi-platform campaigns highlights that attackers frequently chain platforms deliberately (LinkedIn for credibility, Slack for ongoing presence, Teams or Zoom for payload delivery) because each handoff feels like a natural professional progression. ==The practical counter-measure is to treat the full sequence as the unit of analysis, not each step independently:== ask yourself not just "does this request make sense?" but "does this entire interaction, from first contact to this moment, follow a pattern I would expect from a legitimate relationship?" If a technical ask “install this, run this, fix this” arrives at the end of a relationship that appeared from nowhere, that sequence itself is the red flag, regardless of how plausible the final step appears.
