North Korea Mastra NPM Supply Chain Attack: How It Works

You installed a dependency before lunch. Tests passed, app booted, nothing looked wrong. By dinner, your machine had quietly run someone else's code.

This episode covers the Mastra npm supply chain compromise Microsoft attributed to North Korea linked threat actors. We break down how postinstall scripts became the attack vector, why an 88 minute exposure window still matters, and what remote access trojans do on developer endpoints. You will learn how AI framework supply chains expand your attack surface, the difference between package takedown and forensic cleanup, and why lockfiles are history snapshots not security verdicts. We walk through the controls that protect teams most: deterministic builds with pinned versions and provenance attestations for verified package origins. The episode includes timeline thinking for exposure windows, hunting for execution artifacts beyond package names, and the specific steps for rotating secrets and rebuilding compromised environments.

This is for developers, security teams, and engineering leaders managing open source dependencies in fast moving stacks.

One Topic, Ten minutes, No panic.

YouTube more your speed? → https://links.sith2.com/YouTube  
Apple Podcasts your usual stop? → https://links.sith2.com/Apple  
Neither of those? Spotify’s over here → https://links.sith2.com/Spotify  
Prefer reading quietly at your own pace? → https://links.sith2.com/Blog  
Join us in The Cyber Sanctuary (no robes required) → https://links.sith2.com/Discord  
Follow the human behind the microphone → https://links.sith2.com/linkedin  
Need another way to reach me? That’s here → https://linktr.ee/rich.greene

Transcript

Copy

A Normal Install Turns Dark

SPEAKER_00 0:00

You pull in a new open source building block before lunch, just a small library, the kind you grab a dozen times a week. You glance at the name, looks right, looks familiar, so you install it. Your tests pass, the app starts up, nothing looks wrong. But by dinner, your computer has quietly reached out to a stranger server, handed over your secrets, and run code you never wrote and never okayed.

What Mastra Attack Means

SPEAKER_00 0:26

Welcome to Plain Text with Rich. Today we're talking about the Mastra attack, a break-in where the malware didn't sneak past the front door, it rode into the delivery you were expecting. Two quick definitions for us. A software supply chain attack is when someone poisons code you trust before it ever reaches you. You don't download the attacker, your tools do it for you automatically because you told them to trust that source. And npm. NPM is the delivery service most JavaScript teams use to pull in free open source code. Millions of developers, billions of downloads. When it works, it's magic. When it's poisoned, it's a super highway. In this case, attackers slipped bad code into a popular set of packages called Mastra, a toolkit developers use to build AI apps. Anyone who installed during a very short window that night could have run the attacker's payload without a clue. And again, a quick callback: if you want the ground up version of supply chain attacks, go back to episode 12. For the last big case study on this, episode 29, today is about what changed because here's what's new. This wasn't a board kid or a smash and grab crew. Microsoft tied this to a North Korean state group they call Sapphire Sleet, a government team, and they moved fast enough that normal human review never got a chance to catch it. We're talking a window you'd measure in mere minutes and not days. So how does a national government end up inside your laptop through a coding library? We're gonna start with the way in.

The Dormant Account Entry Point

SPEAKER_00 2:08

It wasn't some genius hack, it was an old, forgotten account. How many times have we talked about, you know, those old accounts that just get forgotten, old contractors, you know, it's huge, right? One of the maintainers, someone who'd had the keys to publish updates for these packages, had a login that had been sitting dormant for over a year. Nobody shut it off. The attackers got a hold of it, and just like that, they could push out updates that everything or that every trusting machine would accept. That's again the first everyday lesson. The weigh-in wasn't clever, it was neglected. All my students at TakeSec301 will hear me labor about that concept. Now, here's why one poison account spreads so far. Trust in open source is a chain and it's mostly invisible. You trust package A. Package A quietly trusts package B. Package B runs a little setup script the moment it's installed. Your machine runs that script because that's the whole point of automation. You never see B, you never choose B, but B runs on your computer anyway. The attackers used exactly this concept. They took a normal master package and wired it in a brand new dependency, and they gave that dependency a sneaky name, almost identical to a real wildly popular library that developers pull in tens of millions of times a week. One glance, and it looks completely legitimate. Think of ordering a replacement lock for your front door. The box shows up from a store you've used for years. Inside is the right lock, it fits, it works, you install it. What you can't see is the tiny extra piece inside that also opens it for someone else. From the outside, you just got your delivery.

Post Install Scripts As A Trap

SPEAKER_00 3:59

The key phrase here for us is post-install script. All right. In plain text, a post-install script is code that runs automatically the second a package finishes installing. Totally normal thing. Honest packages use it to finish setting themselves up. But it's the perfect hiding spot because it runs right away, whether or not you ever actually use that particular package in your app. And that's the scary part. You didn't have to run the program, you didn't have to import anything, you just installed it, and the trap sprang. So in this case, what did the trap do? Well, it dropped what's called a remote access trojan, or what you may hear or see a rat for short. In plain text, that's malware that hands an outsider ongoing control of your machine, like they're sitting at your keyboard from the other side of the world. Then it went shopping. It reached into browsers for, say, passwords, it hunted for crypto wallets, it phoned home to the attackers and waited for orders. And that tells you what this crew is really after: money. This is a group that steals cryptocurrency to fund a regime. But here's why a developer's laptop is a jackpot. That one machine often holds the keys to the cloud, the keys to the source code, and the keys to the money, all in one place. You compromise one engineer and you get everything they can touch. Now, the question everyone asks: the bad packages got pulled, so we're fine now, right? Eh, not automatically. Taking down the packages protects the next person who tries

Why Cleanup Is Not Enough

SPEAKER_00 5:31

to install them. It does nothing for a machine that already ran the code. If that setup script fired on your laptop, that laptop is a crime scene until you prove otherwise. This is where smaller teams lose time. They check their project's version list, don't see the bad name, and they take a sigh of relief. But that list is a snapshot of right now. It's not a report of what happened that night. All right, and again, for plain text, that version file, the lock file, just records the exact versions your project is using today. It doesn't tell you what ran on which machine during the attack. What you actually need is a timeline thinking. Who installed something during the danger window, on which machines, with what level of access, and what did that machine reach out to right afterward? A little mind shift here, of course, or a mindset shift, I should say. Stop treating installing a package like signing for a delivery. Treat it like running a stranger's program, because that is exactly what it is. AI tools, especially, they move fast and they pull in a lot. One thing you install can drag in dozens or hundreds of others behind it, each with its own scripts and its own updates. More convenience for sure, right? Bigger surface though, more places for something to hide. The answer is not never use open source. That's not real life, right? And open source runs the world.

A Practical Containment Checklist

SPEAKER_00 6:54

The answer is to install with your eyes open. Two moves I think will help the most, right? First, build from an exact reviewed list every time in a clean environment. No surprises, no latest version, whatever that is today. You pin down precisely what goes in, right? You're not eliminating risk. You're you're really trying to stamp in or tie down, you know, surprise. Second, ask for a receipt. There's a growing push to demand proof of where a package came from and who actually built it. If a piece of code can't show that receipt, it doesn't belong anywhere near your important systems. Now, I always have to add these, especially when we start talking about actual attacks that are going on, right? Because this stuff moves week to week and it moves fast. The exact head count of poison packages, the precise timeline, even pieces of the attribution can shift as more evidence comes in, right? But the playbook itself doesn't change. Contain fast, figure out exactly what got hit, rebuild from something you know was clean. And like I always like to do, I'm gonna give you a starter kit. Move number one, figure out who installed what during the danger window, right? Pull the logs from your build system and your machines and find every device that touched these packages that night. Move number two, hunt for what actually ran, not just for the bad name. Look for strange programs kicking right off after install, new things set to launch on startup, connections out to servers that you don't recognize. Move number three, rotate your secrets. Any machine that might have been hit, change the passwords and keys, your source code access, your cloud keys, your publishing tokens, your save browser logins. If that script ran, assume it grabbed them. Move number four, rebuild the machines you're not sure about. For anything that might be compromised, wipe it and start clean. Then reinstall from that pinned reviewed list. Don't try to pick the malware out. Just start fresh. If you think it might have been compromised, it's compromised. Fifth, put up guardrails for next time. Pin your versions, turn off automatic install scripts where you can. I know it's not always possible. Require two-factor login on any account that can publish packages and set an alarm for when a package you trust suddenly spits out a pile of updates all at once. That's kind of sometimes a tell. And hey, if five feels like a lot and you're a team of one, just do two of those tonight. Rotate your high value keys and turn on two-factor on your publishing account. Those two alone should shrink the damage pretty fast. If we bring it home, the Mature Attack turned a trusty delivery pipe into a delivery method. A short window, again, doesn't mean small damage because the trap springs on install and it can dig in and outlast the cleanup. For AI tools and everything else, installing a dependency is running someone else's code. So treat it like that exactly.

Guardrails And Listener Challenge

SPEAKER_00 9:43

Now I want yours. Send me your weirdest discrepancy surprise, right? The package you trusted a little too hard, the most tangled mess of a project you've ever inherited. Email, DMs, comments, or just send me a screenshot of a dependency tree that looks like spaghetti. Every message gets read, every message gets answered. If you're enjoying this, go hit subscribe or follow or whatever the button says on your particular viewing or well, not viewing, listening platform now. It's the best way to make sure that you always get the next one. And I always ask if this helped you and you think it'll help somebody else, please share it with them. This has been plain text with rich. One topic, 10 minutes, no panic.