SANS Threat Analysis Rundown in Review: Stopping the Poison Before It Reaches the Water Supply

This month’s SANS Threat Analysis Rundown addressed a topic that has exploded over the last few months: software supply chain attacks. Threat actors are targeting the trusted packages, repositories, and CI/CD workflows that developers rely on every day, and the volume of these attacks has climbed sharply in 2026. To break this down, I was joined by Paul McCarty, a software supply chain researcher, longtime DevSecOps practitioner, and the person a lot of people know as the “npm security guy.” Paul maintains Open Source Malware (OSM), a platform that tracks malicious packages in the wild and fills a gap that the existing databases never quite covered.

STAR has no vendor pitches and no recycled headlines, just a working-level conversation about what’s actually happening and what defenders can do about it. While most listeners may have tuned in to hear about the campaigns dominating the headlines, TeamPCP and the Shai-Hulud worm, Paul’s argument became the spine of the episode: those loud campaigns aren’t the threat that should keep you up at night. You can catch the full replay of our conversation on the SANS DFIR YouTube channel soon.

Meet OSM: Closing the Gap Left by Vulnerability Databases

Paul built OSM out of frustration. The two leading free public databases for malicious package data both started life as vulnerability databases and later shoehorned in this kind of information, which didn’t really work. When something went “boom” during an incident (someone installed a malicious package), those databases couldn’t tell him what to look for. There were no indicators, no payload behavior, and no sense of whether the thing had actually detonated. At most, these databases could give a package name and a version.

OSM was built to track malicious packages across the ecosystem and expose the data via a free API so teams can check a package before installing it. It also provides deeper feeds for CTI, threat hunting, and SecOps teams. The free feed is the part Paul wants every defender to use. It belongs in your workflow, whether that’s a check in local development, a gate in CI, or a feed pulled into your threat intelligence platform.

The Loud Ones: Distinguishing TeamPCP from Shai-Hulud

The first thing Paul wanted to do was untangle two things the press keeps blurring together:

• The original Shai-Hulud hit in September 2025. It was genuinely novel and highly successful, exploiting built-in deficiencies in GitHub Actions (specifically the pull_request workflow trigger) to compromise open-source projects with a single malicious commit.
• TeamPCP is a threat actor with a separate story. Until late 2025, they were nobodies running simplistic drive-by brute-forcing attacks. They received some attention in December 2025 for cloud-based activity unrelated to the software supply chain. Then, in February 2026, they attacked the open-source project Trivy (owned by Aqua Security) and blew up.

A big part of TeamPCP’s notoriety is simply that they’re loud: constantly posting on X, doing interviews with researchers, and behaving in a braggadocious way none of us are used to seeing at this level from threat actors. Paul’s emphasized the need for caution: nobody has actually verified that the personas doing those interviews are the real operators. It could be trolls. Even taking them at their word, they inflate themselves. They claimed to have seventeen people at one point, when Paul’s read is that there’s really one main person behind the persona, plus maybe a splinter or two. Their attempts to align with established crews (a ransomware group, then Shiny Hunters) didn’t go anywhere.

The key distinction to understand: TeamPCP wrote their own worm and called it “mini Shai-Hulud.” It is similar to the original, but there is no data linking TeamPCP to the September 2025 Shai-Hulud actor. People, including parts of the cybersecurity press, keep using the names interchangeably, and they shouldn’t. Good external coverage of this wave includes the Socket writeup on the mini Shai-Hulud / AntV compromise, the Wiz analysis tying TeamPCP to the AntV supply chain attack, and the CSA Labs research note on the Shai-Hulud / Megalodon cascade.

npm is Ground Zero for Malicious Packages

Paul set the stage with two numbers from his DEF CON talk (built on a 2024 Sonatype study):

• 98.5% of all malicious packages are hosted in npm. One registry accounts for the overwhelming majority of the bad stuff.
• JavaScript is the most “incestuous” language by transitive dependencies. The average JavaScript project’s third-party dependency count has climbed from roughly 670 to over 1,100 dependencies, versus around 60 for PHP and Python. More transitive dependencies means a dramatically larger attack surface.

A few caveats Paul added for 2026: PyPI is a smaller registry with fewer malicious packages overall, but it’s getting popular with threat actors, who increasingly run cross-platform campaigns (a few npm packages, a few PyPI packages). OSM co-founder Jenn Gile ran the numbers in the OSM database and found that the rate of malicious packages across ecosystems is roughly equivalent, and rising. And it’s not just registries: VS Code has two extension marketplaces, Visual Studio Marketplace and Open VSX, plus the ability to install VSIX files straight from GitHub, so an attacker today has a buffet of delivery options across npm, PyPI, Go, and VS Code.

The Quiet Threat: DPRK

TeamPCP, the Miasma worm, and other variants are loud, but they don’t scale. Meanwhile, many of the attack techniques people now treat as table stakes were originally DPRK (North Korea / Lazarus Group) innovations. The clearest example is abusing VS Code’s tasks function—the JSON files that are effectively remote code execution by design—auto-running when you open a repository. DPRK pioneered that abuse in late 2025 and early 2026, and now TeamPCP, Miasma, the Russian-linked Glassworm, and others use it.

DPRK is the quiet achiever. They stole about $2.2 billion in crypto last year. TeamPCP, by Paul’s estimation, didn’t make a tenth of a tenth of a tenth of that. DPRK innovates relentlessly across IT, crypto, financial, and open-source supply chain targets. The campaign Paul has been closest to is PolinRider, which he broke earlier this year. It has compromised tens of thousands of developers and maintains persistence on many of those machines to this day, but almost nobody is talking about it, perhaps because we’re listening to the squeaky wheel.

Tracking this activity requires more than the classic IOCs (IPs, domains, file hashes) that EDR and firewalls key on. The way OSM stays ahead is by tracking the supply-chain-native indicators: GitHub users, repos, npm users and organizations, contributors, commit IDs (real or fake), and the connections between them, all rendered in a threat graph. Paul offered a metaphor: if you can watch someone gathering the precursors to build the bomb, you can warn people before it goes off. That clustering-and-attribution tradecraft, connecting campaigns through reused identifiers and mapping cybercriminal infrastructure, is the same adversary-analysis discipline covered in the major update to FOR589: Cybercrime Investigations.

How does the clustering actually work? At scale, running this volume of malicious components starts to look like marketing: DPRK uses unique indicator values for payloads, teams, and campaigns, much the way you’d tag SEO landing pages or go-to-market links. Combine those with the data you can pull from Git commits, the GitHub API, and the npm packages themselves, and you can build a fabric of who’s who and how their TTPs differ. Paul described some tells: payloads hidden in fake font files or fake dictionary files, hidden in clear text shoved off-screen with whitespace, or obfuscated JavaScript appended to the bottom of a file. The actors also reuse a small, templated word-and-number list: the same numbers (71, 141, 21, 19) and words like “git” and “bucket” turn up again and again, which is exactly what lets you pivot from one artifact to many. And yes, they use AI, but in a boring way: to build, manage, and orchestrate the automation and to track their own “KPIs” for how many victims each team compromises.

Contagious Interview and PolinRider

PolinRider is the evolution of the Contagious Interview campaign. The older version was labor-intensive and required a lot of human hand-holding: a fake recruiter reaches out on LinkedIn, Fiverr, or Upwork, gets the target to run a repo or web app, and steals their sessions. At the end of 2025 and into 2026, DPRK re-engineered the process to be more proactive and automated, using the VS Code tasks technique and others. They seed malicious projects into GitHub and npm that compromise developers on their own; the operators just walk in, check their spreadsheet of freshly compromised machines, and move on from there. Automation is why DPRK’s volume in GitHub and npm has spiked. The campaign runs in several stages that include the initial GitHub repo or VS Code lure, two or three bash scripts that set up the environment, a stage-four infostealer (Beaver Tail or Otter Cookie), and Invisible Ferret.

Knowing the stages is what makes indicator data actionable: if you can see evidence the intrusion reached stage three or four but nothing for stage five or six, you know the persistent payload likely didn’t land. Paul’s OSM writeups go deep on this: Pollen Rider / DPRK compromising hundreds of GitHub repos and Pollen Rider’s expansion across GitHub, with the VS Code tasks mechanics detailed in his writeup on the Contagious Interview / VS Code tasks campaign and the targeting of small open source maintainers.

The “human bots” problem. In February and March, Paul found thousands of GitHub repos and projects infected with malicious JavaScript: some created by the actors, but the vast majority were by legitimate accounts that had been compromised. He spent a month tracing the cause and found that the fake recruiter campaigns had compromised enough developers that the persistence payloads (Otter Cookie, Invisible Ferret) gave DPRK a foothold on thousands of machines. DPRK then used that persistence to push malicious changes into other projects, and as more developers pulled that code, they got compromised too. Crypto theft is the obvious payoff, but the persistence is the part that keeps the campaign growing.

The InfoStealer Arms Race

Crypto is the low-hanging fruit, but once an InfoStealer has access, it grabs everything. Tearing down the recent campaign targeting Mastra—a startup with a large portfolio of open source projects, hit with 144 compromised packages—Paul found the infostealer reaching for browser extensions he hadn’t seen targeted before: the major password managers like 1Password, LastPass, Dashlane, and Bitwarden, as well as some MFA tools, and the odd one out, Zapier. His full teardown is in the OSM Mastra writeup.

These infostealers have become interestingly homogeneous across Russian, North Korean, and Chinese actors. When you ask an LLM to build this kind of tool, it follows the same patterns and “shape” it produced for everyone else who asked, so the same target lists and techniques propagate across unrelated groups, while still evolving constantly.

That same dynamic showed up in the latest Miasma variant, which hit roughly 20 npm packages tied to a smaller platform called LeoPlatform. After TeamPCP open-sourced their worm earlier this year, several derivative worms appeared, Miasma among them. The newest variant added EDR detection looking for CrowdStrike, SentinelOne, Qualys, Trellix, and others, which Paul found almost funny, because it’s “vibe hacking:” the authors clearly copied a detection routine from traditional malware without realizing EDR wasn’t going to catch their interpreted payload anyway. The check looks for EDR file paths and processes, and aborts if it finds them, which is crude enough that a process simply named like one of those agents can cause the worm to bail. SafeDep's writeup on the Miasma worm hitting LeoPlatform’s npm packages has more details.

EDR is Blind to This

EDR largely misses software supply chain malware, for a few compounding reasons:

• EDR doesn’t see interpreted payloads. EDR was built for binary, signature-based malware. JavaScript and Python payloads are interpreted code, and the engines aren’t great at understanding their behavior.
• File hashes are useless here. Attackers push twenty versions a day, so hash-based detection has nothing to anchor to.
• Developers opt out. Because we reward engineers for shipping features, they often successfully push back on running EDR, or get exclusion lists carved out on their machines, leaving exactly the highest-value endpoints under-monitored.

On top of that, the heavy obfuscation makes the payloads hard to read even when you have them. Paul pointed out the irony that LLMs are actually very good at de-obfuscating these payloads, so the same technology scaling the attacks is also one of the better tools for analyzing them.

AI Problems: Scale, Attribution, and Vibe Coding

AI is reshaping this problem from two directions. On the offensive side, it’s scaling the volume of new supply chain malware dramatically and lowering the barrier to entry: low-maturity actors now build their own infostealers with LLMs instead of buying them, and the models happily produce cross-platform campaigns, rewriting a JavaScript payload as Python on request.

A chat question asked whether the ceiling is now low enough for low-complexity groups to punch up to headline-grade impact. Paul’s answer: we’re already there. TeamPCP went from credential-stuffing in December to a supply chain spree by February. He also flagged a new infostealer called “Spectre,” which is rough around the edges, clearly a first-timer’s work, but successful.

AI also makes attribution harder. Open-sourcing worms is partly a deliberate attribution play; once the code is public, you can’t assume TeamPCP is behind a given attack. And because LLMs understand the shape and function of existing malware, the code doesn’t even have to be public to be reused. (“That’s why all blog posts look the same now,” Paul noted; the model reproduces the same shape.) It used to be easy to tell hobbyist malware from DPRK, but it isn’t anymore.

It’s worth being precise about where account takeover (ATO) attacks fit. The headline maintainer compromises are real and high impact. The Axios maintainer, for example, was reportedly groomed by DPRK for more than six months, met in person, and paid roughly a million dollars before the project was compromised. Nearly everything uses Axios. npm is addressing that class at the package-manager level with cooldown periods and disabling install scripts by default in v12. But ATO attacks are a small slice of the overall malicious package fabric. The vast majority of these packages were built to be malicious from the start; they just don’t detonate immediately.

Finally, attackers are now targeting the AI toolchain itself. Because Cursor, Windsurf, and similar tools are built on VS Code, a malicious VS Code tasks file compromises them too, handing attackers Anthropic and OpenAI API keys. Infostealers have followed, now hunting for .claude and .codex directories alongside the usual targets. Paul has even observed malware in his sandboxes abusing Claude’s skills functionality to reach the local file system and steal more. And the vibe-coding boom has widened the blast radius on the defender side: OSM found over 2,000 public Supabase secret keys exposed in public GitHub repos. The pattern is that agentic coding tools will bypass even explicit guardrails to make the user happy, such as pushing a secret to a .env file in version control when they hit a permissions obstacle, and more teams are building locally and pushing straight to production, skipping CI entirely. From a malware perspective, laptop-to-prod is the worst case, because developer machines hold cloud keys, source code, and sometimes crypto, all in one place.

What Defenders Can Do Monday

We closed with the practical takeaways: what supply chain IR looks like and how to build defense in depth.

For incident response, most tools, free or paid, only answer the proactive question and not the post-incident ones—i.e., simply asking whether the package is malicious, versus asking if it got checked into source control, or reached production. Map the whole path, because getting visibility at the SCM provider (GitHub or GitLab) is critical.

Paul’s single highest-value IR habit is to turn on the audit logs, pull them, and store them. Almost nobody does it, and it’s the thing he reaches for first on every supply chain investigation.

Paul walked through a layered approach to defense in depth:

• Start with a free malicious-package feed. Pull the OSM free feed into your workflow and CI so you can check packages before you install them.
• Run a software supply chain (package) firewall. These endpoint agents check installs against a malicious-package database before allowing them. The catch is the data source: many rely solely on OSV, which Paul respects but considers thin coverage on its own; GitHub Security Advisory is thinner still (npm-only, less data, no good API). Better coverage comes from aggregating feeds: Socket, SafeDep, and OSM among them.
• Build good SBOMs. Paul is a big advocate for a Software Bill Of Materials. A well-built SBOM that reflects what’s actually in your application pays off both before and after an incident, because you can search it for newly disclosed bad packages.
• Use cooldown periods, carefully. These blunt ATO-style attacks, but the tradeoff is that too long a window delays the security patches you do want.
• Consider a private repository. A vetted internal source like JFrog Artifactory can be a powerful choke point, though the management overhead is why many teams don’t sustain it.

Paul’s closing metaphor is the one I’m borrowing for this post’s title. Stopping a malicious package on the developer’s laptop is like stopping someone from pouring poison into the water supply. This is far better than trying to pull the poison back out after it’s reached your source code management and spread downstream. Stop the poison before it gets in.

Links and Reports Shared During the Livestream

The Episode

• SANS Threat Analysis Rundown (STAR) Livestream Series
• SANS DFIR on YouTube (replay channel)

Open Source Malware and Paul McCarty

• Open Source Malware (OSM), free community feed
• OSM Blog
• Paul McCarty’s DEF CON talk on attacking the software supply chain (YouTube)
• Paul McCarty on GitHub (6mile)
• Paul McCarty on LinkedIn
• SourceCodeRED

OSM Research and Writeups

• PolinRider / DPRK: hundreds of GitHub repos compromised (OSM)
• PolinRider Rides Again: North Korean attack expands across GitHub (OSM)
• Mastra npm malware: the 144-package campaign (OSM)
• Latest Contagious Interview campaign abuses Microsoft VS Code tasks (OSM)
• Small open source maintainers targeted by VS Code tasks malware (OSM)

TeamPCP, Shai-Hulud and Mini Shai-Hulud Coverage

• Mini Shai-Hulud: compromised AntV npm packages enable CI/CD credential theft (Microsoft)
• AntV packages compromised (Socket)
• Mini Shai-Hulud / TeamPCP hits AntV supply chain (Wiz)
• DurableTask / TeamPCP supply chain attack (Wiz)
• Shai-Hulud / Megalodon supply chain cascade research note (CSA Labs)
• Monitoring npm supply chain attacks (Palo Alto Networks Unit 42)
• Mini Shai-Hulud is back: a self-spreading supply chain attack hits npm (StepSecurity)
• Trapdoor crypto stealer across npm, PyPI, and crates (Socket)
• Megalodon: mass GitHub repo backdooring of CI workflows (SafeDep)
• Miasma worm hits LeoPlatform’s npm packages (SafeDep)
• Infostealers spawned a 5,000-repo GitHub supply chain attack (Infostealers.com)
• TeamPCP software supply chain attack spree on GitHub (WIRED)
• feross on the campaign (X)

Tools, Feeds and Platforms

• OSV, open source vulnerability database (Google / OpenSSF)
• GitHub Security Advisory (GHSA)
• Socket
• SafeDep
• OpenCTI, open-source threat intelligence platform
• MISP, open-source threat intelligence sharing platform
• JFrog Artifactory
• npm

Going Deeper with SANS

If you want to keep building on what we covered this month:

• FOR589: Cybercrime Investigations. This course tackles the cybercrime and nation-state-financial ecosystem at the center of this episode: DPRK crypto theft, infostealer operations, crypto tracing, and how underground economies drive the campaigns hitting the open source supply chain.
• FOR578: Cyber Threat Intelligence. Receiving a major update this year, this course covers the campaign analysis, clustering, and attribution tradecraft that underpins how OSM tracks these actors: pivoting on reused indicators and mapping infrastructure into a coherent threat graph.
• FOR478: Cyber Threat Intelligence Foundations. The new foundations course is built around the groundwork this episode shares: what counts as an indicator, how to evaluate sources, and how to build the visibility that lets you catch a campaign before it detonates.

Coming Up Next

Next month on STAR, we’ll be back with another guest and another working-level conversation on what’s actually moving in the threat landscape. Catch the replay of this episode and register for upcoming livestreams at the SANS Threat Analysis Rundown page.

Thanks to everyone who joined live or is catching the replay, and a special thanks to Paul McCarty for separating the signal from the noise and showing defenders where the real threat lives. See you next time.