Jenn Gile 0:01

Okay. It is Wednesday, June 24th. Paul and I are recording a day early for purely selfish reasons. I have plans to go hiking in the Oregon Cascades with my family. And so yeah, um, life trumps work, but we still have a great show. Um perhaps we'll even be around to chat during it. We'll see if we can make that happen. Um, we have quite the uh roundup of things to talk about before we get into our main topics, but I'll give you the teasers so you know that you have to stick around. Um, first of all, we're gonna be talking about North Korean state uh threat actor trends, so specific to Lazarus Group in software supply chain malware right now. Um we tend to see that they are the innovators in this space. They're continuing to innovate. Um, so we're gonna talk about what we've been seeing. And then we'll get into some general observations we have about what's going on in the supply chain world. But before we get into that, um some, I guess, events, news to share. Uh Paul, why don't you talk about the Sands podcast that you're gonna be on, which by the time this airs, the podcast will have, I believe, already aired, but people can catch it on demand.

Paul McCarty 1:22

Yeah, depending on what time we they might be might even be competing. I don't know.

Jenn Gile 1:26

Oh no, it'll be I think it's an hour earlier.

Paul McCarty 1:29

Yeah, it's 5 45. I'm I'm starting out with 5 45 my time. So that shows you my commitment, y'all, right?

Jenn Gile 1:35

Right and early.

Paul McCarty 1:36

Yeah, no, I had a great conversation with um with Sean O'Connor from Sands. Um, he knows um uh one of my good friends, Thomas Roxia, um, really well, and they've been working together for a while. And um and uh yeah, just uh looking forward to talking at a very like this is great because it's gonna be an hour um and it's gonna be really technical. And we're gonna be talking about I sent you, Jen, the agenda um that we're gonna be talking about. Um so a lot of emphasis. We're gonna talk about unfortunately team PP team PCP in in DPRK, of course. Um, but going into more detail than I often can, which I'm I'm super excited about.

Jenn Gile 2:17

Yeah, so uh for anyone who's gonna be looking it up, we'll have the link in the show notes, but this is the thing, Sans threat rundown analysis. The name of the episode has some lovely alliteration in it. Poisoned packages and stolen secrets. I love it. Uh the rise of supply chain attacks.

Paul McCarty 2:35

Sans post actually didn't include my name and Sean sent an email today saying, yo, what's what's up with Paul's name button not being in that? But anyhow.

Jenn Gile 2:44

That's okay. We'll make sure everyone knows you're there. Uh okay, what else is going on? Um, in the next couple of weeks, uh, we've had interest in bringing our first guest on this podcast slash live stream. Um, we had somebody from OpenVSX reach out. So we're working on the logistics right now. But if you have burning questions about Open VSX specific to malware and supply chain security or just general security about that ecosystem, uh, would love for you to send those to us in advance to help us build kind of our you know run of show, because otherwise it'll just be Paul and I grilling this person. Um, kidding. We're gonna be really nice and we're very excited to have them interested in coming on.

Paul McCarty 3:32

Well, we're gonna ask some probing questions too, as well, right?

Jenn Gile 3:34

Like of course. Yeah, I'm not saying we're gonna throw softballs, but though let's be honest, I don't know if you've been hit with a softball, but those things are hard.

Paul McCarty 3:44

They are hard. Yeah, getting hit by any, yeah, in the face, especially. Um, hey, real quick, I want to make one correction kind of related to the open VSX thing. When we were talking about um Microsoft VS Code Marketplace um a couple of episodes ago, I said something which basically I don't have the quote in front of me, but basically I said something along the lines of Microsoft is pretty proactive about scanning VS Code extensions inside of their marketplace. And I should not have said that because I don't actually know that. I think many of the things that get turned into Microsoft are, you know, this is what kicks things off rather than this proactive scanning that I kind of alluded to that I don't actually have proof of that exists. Um so I want to make that correction. I think it's less Microsoft being proactive and more, you know, people just turning these things in when they find that they're malicious.

Jenn Gile 4:42

Yeah, so I think we'll learn a bit more about uh how things go on uh behind the curtain, so to speak, in a couple of weeks. So uh keep an eye out for that announcement. And again, uh drop us notes in the comments, DM us on our LinkedIn, let us know what you want to hear about from this person. Um and then what else? Oh, yeah, no big deal. Um, we're gonna be speaking at DEFCOM in the villages. So we have two uh talks accepted. Um, the first is going to be a two-hour workshop with the adversary village. It's titled Hunting GitHub to identify adversary TTPs in the wild. Um, let's pause before we talk about the other one. Paul, this is a topic you're pretty passionate about. It's based on techniques that you have uh used in your own hunts. So talk a little bit about why we're doing this workshop.

Paul McCarty 5:37

Yeah, I mean, really honestly, you know, we thought when we partnered with ABX and the Adversary Village team, um, and we did a version of this at RSA as well, but this one will be updated. Um actually B-sides. We do RSA and B-sides. You're right, yeah. San Francisco, yeah. Um, but yeah, what this is, is this teaches a set of relatively simplistic techniques to look into forward hunt in GitHub, looking for those adversary TTPs that you know when the bomb maker is making the precursors. This is the metaphor I always return to, you know, making the bomb, and you know they have to gather together the precursors to make the bomb. You can identify those ahead of time in GitHub if you know what to look for. And um, so I've been using these in production for years and years and years myself to find this stuff. And now we're gonna be showing other people how to do this. And this is um, I also did an all-day training based on this at Melbourne B-sides in May. Um, so this is a this is a technique and a process that's near and dear to my heart.

Jenn Gile 6:39

Yeah, ABX does a great job with the adversary village. So we're excited to be there. And then I will be on the AppSec Village stage. Um, let me go back to the name of my talk because I forgot what it is. Um, my talk is how malicious AI skills hijack your agents. Um, this is a talk that I developed earlier this year and excited to bring it to DEF CON. It has a lot of the research that we've been doing at open source malware in it. And it kind of explains why skills are such a tasty target for malicious threat actors. Uh, well, I guess all threat actors are malicious, but you know what I mean. And um, what you can do to protect yourself. So if you're going to DEF CON 34, let us know. Again, the schedule is not out yet, uh, but we'll be there. And then maybe uh we're still kind of in the early planning stages. We'd really like to do an open source malware meetup of some kind. So if you're interested in that, um, you know, let us know. Keep following us on LinkedIn. We'll we'll share more details about that later.

Paul McCarty 7:45

I just want to jump in here. I'm going off off script. I I've been wanting to do this thing in my head where we do like a CTF kind of thing inside of OS.

Jenn Gile 7:53

I know, I really want to do it.

Paul McCarty 7:55

Yeah, so I might put something like that together that leads up to the day where we have you know this happy hour or whatever we end up doing during Hacker Summer Camp. But um, we've got some swag as well. So um, we'll do something. I've already started reaching out to some of the homies. Nice.

Jenn Gile 8:11

Okay. Now, time to get into the meet. Um, you've got in our show notes a note about your DEF CON 33 talk. So, why do we start there? What did you talk about at DEF CON last year? Why is it relevant for what we're going to talk about today?

Paul McCarty 8:25

It's super relevant. Um, so basically, the talk I did at DEF CON last year uh as part of the Adversary Village um had it was it was called basically how um threat actors bypass um npm, you know, the security tools that we use to protect ourselves in NPM or the things that are built into NPM. That wasn't the whole title, but anyhow.

Jenn Gile 8:47

That's a terrible title.

Paul McCarty 8:50

I need a workshop that it's already happened, Paul.

Jenn Gile 8:52

Maybe go ask Claude for some help.

Paul McCarty 8:56

Um uh well, if I could get Claude to do anything security related, uh I would. Um oh yeah, so basically it was just about how how Threat Actors you know bypass security tools to get malware into NPM. Um, and you could also make this argument about because I talk a bit about PyPy too as well. And now, of course, we've ex expanded that to um to talk about the VS Code and marketplace and AI skills and all these other places where we're finding um this stuff. But yeah, there it was pretty technical talk. I had a lot of great people in the audience. I had A Adnan Khan and Ronnie Carta and some of the critical thinking peeps, and it was just a really cool group of people. We all went outside afterwards, outside the room, when the next talk kicked on, and we just had this like 15 or 20 people all sitting around in a circle talking. It was just like magical. I loved it. It was just so much fun. But the reason it's important for um for this conversation we're gonna have here is because a lot of things I talk about in that talk are things that bad guys are now doing, which is not surprising, right? As we create resistance inside of NPM with cool down periods and with you know getting rid of these kind of um dynamic and GitHub, sorry, Git um dependencies inside the package manifests, bad guys are gonna use these other techniques, and that's what we want to talk about today.

Jenn Gile 10:09

Yeah. So uh top of the list we've been teasing at for a couple of weeks now is what's going on with Lazarus Group. Um this is the the Paul show. Why don't you share what you've been seeing?

Paul McCarty 10:23

Yeah, I mean, I'll I'm in the guts of you know, open source malware, software supply chain malware every single day. Like literally every day, I'm in the guts of malware looking at it, you know, deabfuscating it, doing stuff with it. So I get to see these kind of themes up close and personal. I'm at the coal face. Um, God, I shouldn't use it. That's such a dumb term. But anyhow, um the you know, DPRK, North Korea, and I was talking to Thomas yesterday about this at lunch, they just innovate so much, and you don't hear about them because there's the team PCPs and all these other squeaky wheels, right? But the reality is that DPRK stole over two billion dollars last year in crypto, you know, using contagious interview and the processes around contagious interview that have evolved. And so some of those things that we're seeing now are them, you know, finding unique ways to um to hide malware with this increased visibility on especially the npm ecosystem. So the first thing that I want to talk about is something that I talked about in my talk at Defcon last year, which is uh when a bad guy is deploying a new, a net new, this is not an this is not an account uh compromise style takeover. This is a net new, it was this package is published by a bad guy, and it was always intended to do a bad thing, right? What will happen is the first version will not be malicious, the second version might not be malicious, the third version might not be malicious, and at some point they add a malicious payload. But here's the thing then they add another benign version after that. So what's happened is they've sandwiched. It's a sandwich, it's a sandwich, right? It's uh it's a reverse. Oh, I won't say that, but it's a reverse sandwich. I almost did a reverse sandwich where the good the benign versions are you know sandwiching the malicious payload. And you know, bad guys have been doing this for ages, DPR has been doing this for ages, but it's now become like a motion that they're doing almost all the time or or a lot. They're certainly doing it a lot. So here's the thing is that if you scan the latest version of a package and it's benign, you know, and you have and you know something is flagged it as potentially malicious, maybe go back and look at some of those versions in the middle, too, as well. I it happens all the time in our analyses that you know you see the last one is fine.

Jenn Gile 12:40

Yeah, I think maybe it would be helpful for people who are not software developers, or as you like to say, in the software sausage to explain uh what mechanisms is this taking advantage of? Uh, why does this work uh both in terms of tricking, let's say, npm, but also tricking the consumer?

Paul McCarty 13:04

Yeah, that's that's a good observation to talk about. So listen, the you know, npm has its own kind of iterative publishing process. When you do an NPM publish, you know, you publish a new version of it. And you can choose what version number to do, or you can leave that up to npm. But uh what's happening here is that they're the bad guys are using iterative publishing uh versions, right? Like 0.1.0, 0.1.1, you know, whatever they're using. Uh and they only add the malicious payload in the middle. Now, here's the important thing is the last version they've published is the version that you'll grab unless you specifically call the other one. And so they're the bad guys are leveraging this built-in behavior where if you call this package and you don't specify the specific malicious version in the middle, you're gonna get the benign version. You're gonna scan it and say, Oh, that's okay. And I see this this simple trick bypass scanners all the time. You know, a lot of them are getting smarter and they're scanning every single version, right? But um, the reality is that what the bad guys do then is that when they use that as a payload, they call it from another package and they specifically call the malicious version of it, or they do something else that's really unique is they quickly delete the more recent version and the latest tag goes back to the old version and whoop, you know. I it's that last one, that former instance is much more rare, less common than the fact that they just pin to the malicious version. So I and this brings us to another thing, which is not a good one.

Jenn Gile 14:40

Well, and we saw something a little bit along this lines uh one or two weeks ago with the attack on Mastra or Maestra, where they published that easy day.js dependency. The first version was clean, the second version was malicious, and what they did is they pinned it to the first version with a little carrot, which meant you would always pull the latest. Now uh it just so happens that package is still live on npm right now, which that's a whole other thing. But anyway, I digress.

Paul McCarty 15:11

So but not anyone is live, yeah.

Jenn Gile 15:14

Yeah. Um, so you know, they're taking advantage of the various automations that are available both through npm and just how pulling dependency versions work in order to get you to pull a poisoned version without realizing.

Paul McCarty 15:31

Yep. And so this brings us to the next um part of this, which is that bad guys will then use that that you know, that pack that first package, they'll call that package as a dependency from another package, right? And they'll specifically pin that malicious version in that package. Um, so the in this technique where you're calling, we're now um, you know, when people deploy these clusters, which we'll talk about in a second, the the cluster usually only well, um let me jump ahead to the cluster in conversation because it'll just make itself self-obvious. Um when bad guys are publishing now, they typically will publish in a cluster. And a cluster is anywhere from two to maybe 10 packages, and they they typically will publish these clusters close together in time. So if you look at the publishing date, it's you know relatively close together. And typically what happens is not all those payload, all those uh packages have malicious payloads in them. Four or six of them will call one or two of them that actually have the payload, right? Um, and what's great about that is let's just say at some point in the future a researcher like myself or somebody at Socket or Akito or wherever else you know gets the malicious payload taken down off of MPM, what they'll do is they'll just convert one of the benign version versions that used to call that, and it will uh it'll now take over as the master payload or whatever, right? And these clusters, this is becoming you know, the the standard operating the SOP for for bad guys.

Jenn Gile 17:08

Yeah. All right. So your second thing in this list is about reusing pollen writer, aptos, and BSC keys. And before you get into it, um, I just want to share a little story. As you know, I've been working on some uh onboarding workflows for open source malware to just make it easier for people to like get started really fast. And um, I have a list of the things we track and crypto keys or crypto wallets are in that list. And I put it into Claude and I was kind of having it help me with some of the logic. And it said, Oh, well, you know, crypto wallets don't belong in this list because that's really, you know, just for Bitcoin transactions, that's not malicious. And I was like, oh no, you're wrong, Claude.

Paul McCarty 17:54

Well, and it gets really murky, right? Because neither you or I are crypto people, right? And so I'm the first to admit this, right? So, like when Tron and Aptos came along, like those are chains, and you know, they have the the reason that DPRK and other bad guys like those particular chains, there's three chains that that the bad guys really like Aptos, Tron, and the Binance BSC one, and I don't really understand much about that one at all. I don't really want to, but anyhow. Um the reason they like those changes is because while the thing that is stored in the chain is immutable, which is the power of the blockchain, uh both of those have these kind of memo components which allow which are uh which are mutable, um, which you can change. And so what happens is when you make a transaction to um the Aptos or Tron uh chains, you know, the original thing that you stored there doesn't change, which is usually just a benign thing, right? It's just blah. It's the this the little memo that they're using. So because of this, like this like blockchain addresses and wallets, you know, it's all kind of like is fuzzy and stuff. But the reality is that to your point, bad guys are absolutely using this stuff as infra. And this gets us to the next point, which is for whatever reason, DPRK is reusing these specific uh block addresses, blockchain chain addresses, uh and using continue to reuse these memos, maybe because they've just used them in so many places, but they're out there, and if you know how to call what's in the memo, you can call it and you can see what they've updated the most recent payload to, right? So that's great. It's just as a really like DPRK is really good at just burning down and rebuilding, and they use AI and automation to do this constantly. You know, me and all the other researchers just see this constant flood of DPRK stuff. But the fact that they're reusing these particular chains from February of 2026 is really interesting because it allows you to tie together you know disparate activities under the same threat actor. Um, and that's absolutely why those chain addresses and those wallets and you know those things are in OSM.

Jenn Gile 20:06

You know, this these are if you were like, let's let's take a step away from pivoting and research and talk about using it for alerting. You know, you and I've talked a lot about the incident response related use cases. Um I don't know if people are thinking about alerting based on a crypto transaction in their seam or whatever.

Paul McCarty 20:31

Right.

Jenn Gile 20:33

Yeah, well, new things to think about.

Paul McCarty 20:35

Yeah, and at the very least, these are things that you know, if you are, you know, a threat hunter, you know, uh look into you know, you know, kind of expanding out to look at these things. OSM's got a bunch of them, got a couple hundred of these things in them, and we're adding some, you know, almost every day. So um good thing to pivot on.

Jenn Gile 20:53

Yeah. All right. Third in your list is uh new campaign names. Uh talk us through. Why is this interesting?

Paul McCarty 21:02

Oh listen, DPRK and all the all the you know big threat actors use campaign names. And just to kind of like talk about these, there's the campaign names and in um basically these are unique identifiers that DPRK will use. So a really good example of this is when you find um a payload in GitHub, typically in a VS Code tasks.json file or wherever it is, but there'll be there'll be three lines, whether it's obfuscated or not, there'll be three lines where it's calling a Windows payload, a Linux payload, and a Mac payload. And each one of those has a little different designation, right? Whether that's going through a shortener, it's going directly to Vercel or wherever it's going or an IP address, they're differentiating that because there's different payloads. That's one thing. What they do is they add another thing, which is a campaign name so they can track it.

Jenn Gile 21:53

And it's it's kind of like anybody that's uh what do they call it? You know, like the marketing thing.

Paul McCarty 21:59

Yeah, look. Literally where I was going, like SEO GTM tags and stuff like that. Yeah, yeah. Yeah. URL tags. Yeah, yeah. Um, and who knows? You know, we'll never probably really know how these things map to individuals, but you know, some people I've talked to say, oh yeah, we think it's individuals inside of you know these groups, right, that are tracking for KPIs or whatever, right? Like campaign 39186, you know, is gotta check the performance. Yeah, right. You got you got you're handing out bonuses at the end of the year, whether it's in Pyong Pang or or you know, wherever in Russia somewhere, you you know, you gotta know who to to give your bonuses to, you know, your your shining star or your gold coin, your child challenge coin, whatever, whatever, whatever the incentives. So what I started seeing um last month is these kind of sexy um campaign names, and I just included two here. Um and I included it with the um with the packages that I found them in, but one of them was uh ace a6-shadow dash 15. And we found that one in the tailwind uh dash color dash shades npm package. Um a6 shadow 15. Now we found another one contemporary um in this in the secure dash box npm package, which was a6-Orion-271. Now the funny thing is that you'll see when DPRK spins up new endpoints, whether that's in first sell or wherever it is, they will often use those same numbers in the endpoint. So what you can do is you can begin to tie like a package to an endpoint to a campaign name, and you can kind of and it's not, you know, it's amorphous and it's mostly just their automation. Sometimes it works and sometimes it doesn't, but it allows you to kind of tie together these things in this loose, you know, relatively loose abstraction, which is really cool.

Jenn Gile 23:48

If you say this is more of a research tactic, uh rather than if you're actively, I don't know, uh doing some kind of IR in your your organization. When would you do this?

Paul McCarty 24:01

Yeah, I really wouldn't use these as detection strings so much. I mean, they because they're just so granular, there's just so many of them, right? But absolutely in your research, you know, if you if you're collecting these things like I am, you know, you can begin to tie them together, you know, inside the your graph fabric, whatever you're using, right? To to to understand what these kind of loose, and then you can you can gain insights by like, okay, this is three npm packages and then a PiPi package or whatever the case may be. You know, you can begin to gain some insights about what's going on behind the scenes. So and plus it just sounds cool. A6 Shadow 15. Why they both say A6? Is that the same team? Is that the team name? And then the next one is their their call sign. I'm just I'm making all this up, right? The first one is team name A6, the second one is their individual call sign. I'm Shadow, I'm Orion. I want to be Mr. Pink, I want to be Mr. Brown. Um uh Shadow and Orion. And then the last one, maybe that's the sub-campaign name or like the individual payload, right? Which is something that you see a lot. They'll tag the specific payload with a number or a unique identifier.

Jenn Gile 25:07

Or they've got a random generator running.

Paul McCarty 25:11

Could be that.

Jenn Gile 25:11

That's not as fun.

Paul McCarty 25:13

Oh, they're definitely randomly generating some of these things, like the numbers I think they're picking. Because you see the same numbers 112 and 71 and 141, and you see the same numbers kind of coming up again, and they just randomly kind of associate them with other words. But in this case, I think it actually might mean something. Interesting.

Jenn Gile 25:31

Uh, so is that all you've got on North Korea? You want to move on to general stuff?

Paul McCarty 25:36

Yeah, that's it for DPRK. Let's move on to general.

Jenn Gile 25:39

All right. So this is kind of like zooming out some of this ties into what we just talked about with DPRK. Some of it is a little bit more unique. You've mentioned uh back at the top of the episode about uh cross-ecosystem malicious packages. This is definitely a trend we have really started to see heavily this year. And some of the research that I did earlier uh looking at the velocity of uh new NPM packages versus new PiPi packages, malware in each, seeing those move at the same track. A lot of that uh velocity matching is because the threat actors are you know making it a little more ecosystem agnostic. They'll get you regardless of where you are.

Paul McCarty 26:29

Yeah, it's in four. It makes sense, right? Spread the love. Um so, or I guess the opposite of what's whatever it is. Yeah, so I think the reason that Jen and I wanted to kind of separate these into two categories is because um, you know, the the greater threat actor, you know, threat actors are learning from whoever's you know innovating the most. And so we saw this very we've seen this a number of times with Team PCP, Glassworm, and others you know, using kind of things that DPRK Lazarus Group has been using. Really good example is the VS Code tasks.json file that is now being used. That's ubiquitous, like everybody's using it, and they're pack they're piling on, they're using you know the tasks.json VS Code to also compromise um cursor and windsurf and other applications that are built on top of VS Code. So it makes sense. But the same thing with you know the the canisters and a number of the other things that DPRK first innovated, we now see that being used in a broader context by more threat actors. And so some of those other things that we've seen is that just the fact that everybody is now building a more than one ecosystem, or almost everybody is building in one ecosystem, used to just be the glassworms and DPRK, and now it's not the case. This week I've been looking at a number of clusters from Chinese threat actors, Indonesian threat actors, and Russian threat actors. All three of these are low-end, low technical. These are not APTs, these are anti-APT groups that are using vibe coding to quickly build payloads in multiple languages that they can then apply to different package ecosystems, right? So you're seeing, and if you you know, if you burn down to the actual payloads, they're typically either the same or very, very similar. Um, and they might use you know different um, you know, PyPy will will they'll detonate in a different way there than they will in other places. But this is something we're now gonna see because of vibe coding, vibe hacking, we'll see this across all stratuses of threat actors, the low, crappy, you know, crappy ones all the way up to the nation states.

Jenn Gile 28:34

So I think it bears explicitly stating um what this is telling us, and you know, I think most people understand this is don't just look at npm. Um, I think we've been a little bit conditioned to see NPM as the sole problem or the sole source. And that has been somewhat true just based on sheer numbers, right? There's hundreds of thousands of malicious package threat reports just in npm. But uh, if, for example, you're only tracking malicious npm packages, even though you're using other languages, then you're leaving yourself open. And if you're really focused on just the security improvements that are happening in the npm ecosystem, like understand that those are not automatically the same in other ecosystems. So, for example, if you're already using open source malware to find out the new npm packages that we've added every day, you know, maybe add PyPy, maybe maybe add VS Code. Think about uh broadening your uh data that you're pulling in.

Paul McCarty 29:41

Right. Um, yeah, 100%. I don't have anything to add. Exactly. No notes.

Jenn Gile 29:48

All right. Uh you talked a little bit about clusters already in the context of DPRK. Do you have more to say on that?

Paul McCarty 29:57

No, just again, this is something the reason it's in this category is because just everybody's doing it now, right? It used to be that these the DPRK would, you know, publish these kind of clusters together, and they'd have those campaign names, and you you know, you could tell kind of roughly what the abstraction is. Now everybody's doing it, they're all coming in these clusters, and it makes sense. And they're also modifying not each one of the things, you know, the way that the benign package will call the malicious package, you know, changes, right? And we're seeing a lot more. This isn't on the list, but we're seeing a lot more dynamic imports inside of the code rather than in the package manifest because the npm package manager and the upgrades to the security around npm package manager itself don't help there at all. So we're seeing more of the Yeah, why don't we pause on that?

Jenn Gile 30:43

Because I'm not sure I've been hearing a lot of people talking about it, and I'm not sure everyone understands. Again, if they're not involved in software development, uh, how dynamic imports work. So let's let's go a little deeper on that.

Paul McCarty 30:56

Yeah. Uh so I like this. Um so what God, what was it? Today is Thursday here. So it would have been Monday or Tuesday my time here. Um, I jumped in to to look at a uh a user source code. And the first two lines I noticed in that in this particular package repository, were lines one and two were importing from URLs in the JavaScript additional JavaScript, right? And this is totally legitimate, happens all the time, these dynamic imports. When you basically, when when uh a JavaScript file runs in your browser or in whatever v8 engine you're using, it can call additional uh dependencies in the code from URLs. And guess what? Your package manager can't find that, your package firewall can't find that, your proxy can't fire that. Artifactory can't deal with that. Basically, none of the security tools that you're using can help you with that. Like it there are things in the source.

Jenn Gile 31:59

It mirrors a lot of what we saw with malicious AI skills earlier in the year, where the skill itself is benign, but it's saying, hey, you need to go over to this outside thing to download the CLI or whatever. Um, are you seeing this predominantly in JavaScript because of JavaScript's tendency to bring all its friends?

Paul McCarty 32:23

Yeah, I mean, I'm mostly seeing it, and I'm I'm seeing it a lot in vibe-coded apps. Um, and that's because being written quickly, they're not having a lot of oversight. Um, I'm seeing it a lot in you know, lambdas and other kind of um, you know, transient compute kind of uh code snippets. So these are things to look for. Uh, you know, I'm actually looking at you know, building something to try to identify these things, um, but just to say this very explicitly as the NPM ecosystem adds protections around the package manager, right? And we're all making a big deal about you know, npm version 12 coming with these things, and all those things are good. Again, these are all great things. Bad guys are going to find a way, and one of those ways is is to drop or to leverage uh dynamic dependencies you've already got, um, or find some way to add some um, you know, another way, or here's the other thing is a lot of these dynamic dependencies get pulled from CDNs that you've never heard of. Little known fact, there's like 150 JavaScript CDNs just in China. These are all just you know managing the Chinese developer market, and they're all kinds of crazy. And how would you know one URL is malicious versus you know, like you just have no idea? And so you've got a piece of you've got you know uh some code of yours that is calling a dynamic dependency from something that that is a CDN or ostensibly a CDN. You have no idea. So now you gotta go and research that thing. What is this, right? esm.sh. What uh what the hell is that? That's oh, it turns out that's legit. What about this next one? js-deliver dot com. Jsdeliver.com is legit, but js dash deliver is that oh shoot, that looks like that might be malicious, right? I have a question.

Jenn Gile 34:14

Um and I'm just thinking about logistics here of, you know, okay, once once you know what's bad, um, what do you start labeling as malicious at that point? What do you start tracking? Do you track the package that contains the dynamic dependency, which may or may not be intentionally sharing something malicious? Because as we know, there's lots of stuff out there that wears, I don't know, friendly hat, but has something else underneath. Do you track it as malicious URLs? How do you what do you what's your thought? Like, how do you think you track this kind of stuff? How do you look for it?

Paul McCarty 34:54

Audience at home, this is not a setup. Like, this is Jen actually asking a question that we've never talked about before. Yeah, I don't know. I don't know. Jen, in OSM, we actually do both. We track the end of it. That's a great question. I've had to deal with this myself because do I track the CDN? Yes, absolutely I do. So, for example, if I find that there's a malicious CDN or something that has been consistently delivering um, you know, malicious packages, I will add it. I or somebody else will add it to OSM as a top-level domain, right? First.

Jenn Gile 35:26

Malicious domain category.

Paul McCarty 35:28

Okay. Yes, ma'am. Second, when I found a specific payload, and I did this several times yesterday, of malicious uh payloads, I will add the full URL into OSM. Um, because a lot of times that's actually not a malicious CDN, it's just a malicious payload being called from a CDN, right? And it's where it's getting that, it's getting that from GitHub somewhere, and who knows where it's getting from, like Code Burger, who knows, right? But the point is that it's serving it up to you, and some of these things are already pre-built as ESM modules, and some of them are, you know, there's all kinds of different ways to do this. So you have to cover off both. And I ask you, audience, what security tool are you using right now that does both of those things, right? Protects you both from these domains that you've never heard about, these weird CDN or fake CDN militia CDNs and the payloads themselves. That is a bad mofo.

Jenn Gile 36:20

That's no fun. Okay, last item on here, which I don't think we've hit yet, uh, but this falls into the category of um threat actors getting creative to evade detection. And this is the idea of splitting the payload into multiple pieces. Um, and you've got an example here where uh you're seeing it split into four pieces. The URL is in one JavaScript file, a protocol is in another JavaScript file, the path is in yet another, and the post is in yet another. Um what are some examples like that you can share where you've seen this, you know, in reality? This is not a hypothetical researcher. Well, they could do this kind of a thing.

Paul McCarty 37:06

No, I've seen this multiple times this week. Um, no, it happens quite frequently, um, and it's gonna happen more and more um because there's so many people that are analyzing, you know, packages as soon as they're getting deployed. It makes sense for the bad guys to chunk up their payloads into separate pieces and then publish them and then either call the things, you know, uh via dependencies or find other ways to implement.

Jenn Gile 37:30

Are they like different functions in the same package or are they uh like transitive dependencies? How are they good question making the lines connect? Both, okay.

Paul McCarty 37:43

Both, yeah. It's it's obviously easier when the pack when the files are individual JavaScript files or TypeScript files inside of a package, right? They can just call each other from the code and and bundle together the payload and and away you go. But I am also seeing at the same time multiple packages. Say you if we take one of our clusters, you know, let's just say four packages, right? They'll kind of chunk up the payload across those four packages and they will then bring them together via dependent. Now that's a much trickier thing. It's much, you know, um, if one of those packages gets burned, gets sorry, removed, deleted, yoinked, thank you, gets yoinked, suddenly your payload no longer works, right? So it's a trickier, um, uh riskier thing for the bad guys to do. Very, very common for people to do this in individual um uh JavaScript files and stuff within a single yeah, yeah. Very, very common to do that. Less common to do the other.

Jenn Gile 38:37

Makes sense. Very good question. Yeah, I didn't know. It's worth asking. Okay, that's the end of our list of things. We've made it a little over our normal recording time, so I think this is probably a good place to stop. Uh, but yeah, this has been super interesting. Thanks for answering my questions, Paul.

Paul McCarty 38:54

You know worries. Great questions, Jen.

Jenn Gile 38:57

Happy to do it. All right, take care, everyone.

Paul McCarty 38:59

Nice. Thanks for listening. Appreciate it. Bye bye.