Jenn Gile 0:00

It's Thursday, Thursday, July 30th. Um, and we are back. We've got lots of things on the schedule to talk about. Some of these are follow-ups from things from last week, some are uh pieces of somewhat breaking news. We've got a little maybe industry drama in here and also some new research.

Paul McCarty 0:30

Uh it's always funny. Like when I work right up until the moment that we hit record, um, instead of like spending, you know, the usual hour that I do well when I can researching things, it's always a little bit more YOLO, but that's okay. Um, I'm prepared. Well, I'm I'm YOLO prepared.

Jenn Gile 0:48

As prepared as we can be. Um next week we are in Las Vegas. Um it's surreal, it's only a couple days away. I was getting, you know, some of my pre-packing done earlier this week, but uh I think it's very possible we'll skip next week's recording, but we're getting together with a whole group of security research pals. We're gonna be doing a recording with our friend Mackenzie from over at Aikido. So uh it's it's possible we might not make time to do our normal live stream because it's gonna be chaos, but there will be good stuff out there.

Paul McCarty 1:29

You know, I I know this is off script. I would love for us to do something. Um, don't get me wrong.

Jenn Gile 1:36

I'd like to do it. I'm just realistic that it's gonna be pure chaos.

Paul McCarty 1:40

It's true, it's very true. So we'll see.

Jenn Gile 1:43

Might be a game time decision.

Paul McCarty 1:45

Fair enough. Fair enough.

Jenn Gile 1:49

Start with an update from Hugging Face. Paul, did you get a chance to take a look at the uh after action debrief that they published, I think yesterday?

Paul McCarty 2:00

Only very, very briefly. I glossed over it. Um taking a look at it again here. Um, I did notice that they mentioned that there's a there was a second uh Hugging Face didn't mention this, but OpenAI had mentioned there was a second um uh thing that got popped, company slash project that got that compromised. Uh, I read it was four. Oh, really? That's new to me.

Jenn Gile 2:23

I saw something I'm subscribed to the Axios newsletter, I want to say. Oh and uh I didn't get a chance to digest it all, but I think it's it's more than two. So this model that they were uh training or testing rather um really went off the rails.

Paul McCarty 2:42

Yeah, you know, and to to that point, like if it really is, let's just say four, let's just pick that number. If it really is four companies slash projects that got compromised, um you know, that starts to make this, this starts to tip this, at least for me, back into the you know, probably happened category. Because um until there was until there were additional um companies that had been compromised. Uh, you know, I was pretty skeptical. You know, I think I made that clear last week, and I'm you know, I'm there's still part of me that's very skeptical. But you know, with more evidence comes less skepticism.

Jenn Gile 3:19

I'm gonna drop the link. It was uh strictly VC that I got this from. So let's see here. Here's a Gizmoto article about the open AI part. Uh it was four different uh victims, we'll say. Uh so full disclosure, I haven't had time to read it yet. I did look through the hugging face incident report. I think it's really nicely done. Um, this looks like it was a tremendous amount of work on their part. Um, they said that there were over 17,000 agent attacker actions that they had to analyze. Um, it happened over the course of, let's see here, where's the timeline? Uh five days, I believe. And they caught it part way through.

Paul McCarty 4:05

Um, July, July 9 to July 13.

Jenn Gile 4:08

Yeah. Uh so this is again really nice debrief um or I guess analysis. They've got this really neat little um timeline thing at the top of the blog that you can play with that shows you uh everything that happened along the five-day um attack timeline. And then they've gone in and kind of talked about the changes that they made. Uh, no surprise the model was able to take care, uh take advantage of security vulnerabilities in their configurations that were not novel things. You know, they had uh something that was over permissioned, they had credentials where they shouldn't have been. Um, you know, they acknowledge in the report like, look, this, these were basically this happened because of security hygiene issues. We fixed them. Um, and I think I'd give them a lot of credit for making that comment. Um what they said is that, and I think this is from OpenAI as well, that this model that broke in, the reason that it decided to head on over to Hugging Face is it was testing this benchmark and it went to go try to steal the answer key from Hugging Face. And there's a couple of questions with that that I think are interesting questions to discuss. So, one, um, why did it go seek out the answer key instead of just trying to solve the challenges that were put in front of it? And there's a couple of hypotheses that are out there that I think are believable. Um, one is that some of those challenges in fact are not solvable. And the model in some way may have known this and said, well, I'm just gonna go circumvent because I'm trying to get the highest score here. Um, some of the other hypotheses are around, you know, rather than attempting to, you know, do the challenges that it wanted to get the best score that it could. And so instead of perhaps trying, trying and failing, it just wanted to go get the answers. It's all kind of coming back around to the task that was put to the model was test this benchmark, get the best score you can. It heard the get the best score you can and said, Oh, well, the best score will be on the answer key. So if I go steal the answer key, I can get the best score. And I think this ties back to something you and I have talked about, Paul, which is a challenge with really all models, is they're designed to do what the user asked for. And often that um core, like do what the user asked for, gets it away from what the user actually wanted it to do. In this case, OpenAI surely didn't need the answers stolen. It probably could have, we may have even had access to those somewhere else. You know, it wanted to actually test the model. Um, but the other being it broke numerous security policies in order to do it, you know, managing to jailbreak itself out of the sandbox, getting into hugging face, doing things that I don't know that anyone's used the word illegal, but you know, certainly unethical illegal behavior.

Paul McCarty 7:49

Oh, I I have. I've definitely heard multiple people on Twitter and LinkedIn, you know, basically ask, like if a human did. In fact, I commented on one of them.

Jenn Gile 7:57

Um, yeah, if a human did this, what would happen?

Paul McCarty 8:00

You would and that's what that's what the person posited, right? And so my response was uh what if I just tell the agent what to do and then I walk away. I'm good, right?

Jenn Gile 8:11

Yeah, uh so um feeling very much like I'm living in a late 90s, early 2000s apocalyptic AI movie right now, right?

Paul McCarty 8:24

Yeah, like we know we know how this ends, Jen. We've all read the books. We've all literally we've seen the movie, we've seen the freaking movies, like we know how this ends. Why are we just foolishly, as a culture, just running towards our inevitable end?

Jenn Gile 8:40

Like, you know, the the I will say, you know, I live in a community that's not a strong tech community. I had lunch with a couple of friends last week. One is a hairdresser, the other uh is an accountant, neither are what you would call AI experts. And they both vocalized, hey, we're trusting this less and less, we're seeing the edges, we're understanding where it works and where it doesn't. And that conversation in itself honestly makes me feel better about where we're going. Of I don't think people are quite as blinded by the technology as they may have been one, two, six months ago.

Paul McCarty 9:22

Yeah, and I'm hearing kind of anecdotally the same kind of thing, both in my own network, you know, of humans and you know, online in the places where I'd I'd like to hang out. I, you know, getting back to the hugging face thing in particular, you got a couple questions that I need to research where this um where they say the third party launch pad was I I don't know if they it doesn't look like they're specifying what I don't think they named it, no. Interesting. So yeah, stage one from open AI evaluation sandbox to a rooted launch pad. They talk about the first couple parts of those. Um, and then yeah, the the part that's in orange, the rooted uh code of ail sandbox, um, they don't describe that. And and we have heard that um uh JFrog's Artifactory was involved. Um, in fact, I think that Artifactory now is one of those four companies that was um if I get this wrong, if I get this wrong, then next week I will I will me a cope on this. But my my understanding based on some um signal conversations I'm having is that Artifactory is one of the companies that was popped. Um, but also that perhaps Artifactory itself was part of the escape. So if that's what they're referring to right there in that orange box, I don't know, who knows? Um, but that aside, getting back to your point about you know the LLMs making you happy, they are forgive the Philip K. Dick um reference here, but you know, they are LLMs and our agents are the pleasure bots of 2026. It is their job to make us happy, right? And yeah, at the same time, there's this weird thing where once they get themselves going down a rabbit hole and they've kind of built up momentum, they just go off the rails. And so you have this weird quantum thing where they're trying to make you happy and give you what you want as quickly as possible, but they also have pivoted down a rabbit hole they didn't need to, and now they're just it's like um what's that called when you you spend the time in it, so you're you're you're committed and you just oh it's the the sunk cost fallacy, I believe. Yes, yes, correct. Very good. That's exactly what I was thinking of, and that's what happens. I literally had this happen yesterday, where I had Claude, very specific set of skills, some modulated determinism, which is where I have like an LLM will interact with a stateful typed, you know, library and very narrowly focused, and then pop back out to an LLM stage and so on and so forth, hence the modulation. And then I just went off the rails. And I was like, I did not I stopped it, control seed. I said, I didn't tell you to do this. Why'd you do this? And it's like, oh, you're right. I was, you know, I was trying to do this, but then I got too worked up in trying to figure this out. I'm like, I yeah, I gave you explicit instructions, and you just kind of you know pivoted. And um, so I think both things can be true. Sorry, that was a bit of a rant there, but um, you know, they are pattern matchers and they are you know trying to figure out what we want next. And so sometimes they just don't get it right.

SPEAKER_00 12:27

Yeah, they get a little too excited. Okay, Paul, do you want to talk about GitHub? Yeah, do you want to talk about GitHub now?

Paul McCarty 12:34

Oh, oh man, I do. Which one? Do you want to talk about the the malware scanning thing?

Jenn Gile 12:39

Yeah, let me let me summarize because two announcements came out. Uh I saw them yesterday, but I think they actually came out on the 28th, um, July 28th, right pretty much at the same time. Uh, so in no particular order. The first announcement is that um they've made a change with GitHub Actions so that it will now uh hold potentially malicious workflows for approval. And then the other announcement, kind of two sides of the same coin, is NPM is implementing publish time malware scanning. And these are both um very obviously meant to address um malware in the ecosystem. The GitHub Actions change is meant to prevent account takeovers uh in these circumstances. And I know you're gonna have a lot to say about this, where we've seen a GitHub action exploited in order to uh push malware into a pipeline instead of having to steal a credential. And then on the other side, we have been crying for months, perhaps years. Um, please, npm, please take some responsibility and proactively scan packages. So I will say, uh, first of all, the intent here is good. Happy to see these issues being addressed. Um, as a follow-on, the information in their announcements is very thin. Um, the GitHub Actions workflow announcement is one, two, three, four paragraphs, but two of those paragraphs are like one line each. So very, very light on the the information. Um where do you want to start, Paul?

Paul McCarty 14:32

Well, let's start with the the one that I have less immediate anchor about or or you know passion about. Um, and by the way, did I just sorry, uh orchestration or sorry, administration stuff. Did I send you that blog post for the my response to the the GitHub actually?

Jenn Gile 14:49

I feel like you were talking about it, but I don't remember seeing it. I looked for it while I was um sorry, it got missing. So there will be a blog post from us analyzing this, much like what you did on npm version 12. But yeah, why don't you yeah, go ahead.

Paul McCarty 15:06

And by the way, that blog post is one of the best things I've written. I really am pretty happy, pretty happy with it. Not to sound that sounds terrible, but too important. Okay, I'm very happy with it, and I'm looking forward to it, and I'll get that to you right away. But um, yeah, okay. So, first let's start with the the actions thing. I I think there's like there is no details in this. Like this thing, like you said, I mean, this thing is tiny. This, you know. Um uh when quote when a workflow run is identified as potentially malicious and held, the workflow won't execute until repository collaborator with right access reviews and approves it. So that's gonna just first and foremost, that's just gonna break a crap ton of GitHub actions. And maybe it should. I'm not arguing that's necessarily a bad thing. I would suspect, because there's no details here. There's like I this is it's crazy how GitHub's you know, PR is getting worse and worse and worse. I makes sense though, because they keep losing people. So um, anyhow, uh, I would suspect that what they're gonna be looking for is they're looking for specifically those like high-risk triggers that we all kind of know, like the the pwn request triggers, right? And this is like this is like Francois and Ronnie and all those guys, this is their special adnon and all those guys, that's their specialty. But you know, things like the pull request target trigger and workflow run, these are all things that run in the context of the originating um repository, and that's where the problems come up. So I'm gonna guess that if the execution engine sees some of those triggers in the workflow file, then it might just hold them. Um or you know, might look for, you know, might parse it for to see what's happening there or what's being passed to it or something like that. But it might just be something as simple as like, you know, we're just gonna we're gonna block on these triggers. Who knows? There's no detail, so I'm just speculating.

Jenn Gile 17:04

Yeah, I mean, as we're speculating, what would make sense would be to block some of these things that have been exploits in the last what, six, eight months. We've seen GitHub actions abused several times. It's often, like you said, these pawn request scenarios. So stands to reason that would be on the list of things to block.

Paul McCarty 17:28

I I mean, I I I still wonder, and I wonder this with lots of things with GitHub and NPM, but I still wonder why things like you know, those um, you know, those triggers still exist full stop. Like, why does why does pull request target still exist? And the only reason why, let's just be very explicit, is because lots and lots of people still have it. I know because you can just go and search GitHub and look for them. Lots and lots of people are still using it because they're too stupid and too slow to change it, to update it, right? And so, because of that, GitHub doesn't want to create this massive breaking change, but they might actually be creating a breaking change here, maybe not quite as massive, in the form of these, you know, these stops, so these block actions, but we'll see. And here's the other thing, and this is gonna blend into this next one I'm gonna talk about. The reason that GitHub and NPM have not wanted to wade into this space is because they don't want liability. What they don't want is they don't want to not block a GitHub action workflow and then have it be malicious, and then the customer say, I thought you were blocking these, and GitHub would be like, Well, we are, but it didn't look like it was malicious. And then the customer is like, Well, that's because your your detection is bad, or you know, whatever. Like, this is the presumed back and forth. You know, and there's unfortunately, there's you know, legally, there's like um that that is important, you know, crossing that breaking that plank is important. So, all right, now let's talk about the scanning malicious packages in April, uh, April 1st, April Fool's Day. I sh you not, that was really hard. I shizzle you not that April Fool's Day, GitHub came out with an announcement saying, hey, we are now scanning all npm packages. Zach came out with it, it was legit. It was not an April Fool's joke, it was legit. Um, why they decided to do that in April Fool's, who knows? But um, you know, like I said about GitHub PR right now. So they have been scanning packages since at least April. And the reality is they've been doing it before that. So they, you know, the inside baseball is that Microsoft built some scanning technology and they've been using that for months and months and months, actually over a year, I think. Um, but then Zach mentioned that you know, in April that they're doing it now on all packages. Now, the difference, the difference between what happened on April Fool's Day and two days ago is that the difference is now they're moving the scanning to before something is published, and this is a big deal. Um, the the reality is that if they can stop these packages from ever entering the the ecosystem, then it's just less opportunity for these things to get pulled into artifactories and you know the nexuses of the world and the Rdachios of the world and all those other places where we store packages. Um that having been said, it is so poorly described and so lacking in technical details that it's like it's stunning in its lack of details.

Jenn Gile 20:28

I just I just no, that's the best way to put it. I read it and it's got more detail than the GitHub Actions one, but that's a low bar.

Paul McCarty 20:39

Right. Um, what we do know I killed less people than last time.

Jenn Gile 20:43

Oh goodness. Um, so they said that it's typically gonna take around five minutes for a scan. Uh at peak times, or if the package is big or complicated, they say it can take 15 minutes or more. Um, they're not saying a lot about what kind of behavior they're going to be looking for, which is a similar comment that you made about GitHub actions. Um, I think it's it's always a challenge to you know be blunt. How much do you share publicly so that threat actors um don't understand what you're looking for versus so that your users realize what the the security policies are. Um it's probably, in their opinion, safer to be vague about it. And then if you're an enterprise customer, you can probably get more information about how this is going to work. But they're saying that if a package is blocked, the publisher may receive a notification with the option to appeal. I think the choice of the word may is uh it's a choice. So uh I interpret that to mean you might also not. Receive a notification. Um, one would think that that would happen in cases where they think the publisher themselves is malicious and then they don't tell them and they probably just kill the account. Um, but yeah, not a whole lot of detail, and then they link to the acceptable use policies.

Paul McCarty 22:19

Oh, I want to make a correction. I'm pretty sure GitHub came out with that statement about scanning all packages April 1 of 2025. I will verify. I was looking for in the background right now. But if that's the case, their scanning has been in place before Shy Balude and Axios and Chalk and Debug and all of this shizzle show that we've been dealing with in the last year, even if it is April of this year, there's still been a bunch of high profile software supply chain attacks involving NPM packages that have happened. And I'm pretty sure it's last year.

Jenn Gile 22:55

So yeah, I mean, regardless of when it was implemented, um, as you and I were talking about earlier today, there is a lot of malware in NPM right now that people know is there that has public reports on it. Um, we're gonna talk about one of those actually next.

Paul McCarty 23:14

Uh, I'm sure you have more to say about the malware scanning, but I do what we'll do is we'll we'll we'll punt that until next time, whether that's next week or the week after that, when after my blog post comes out, because then I can reference specific things. I don't want to hit every bullet point from the blog post now. So, yeah, let's talk about this. I love this.

Jenn Gile 23:33

Okay. Uh, next on the list is a blog that came out from Amazon today, yesterday. What's the date on this? Yesterday. Uh, the title of the blog is Amazon Identifies North Korean Hacker Group Behind Open Source Supply Chain Attacks. I promised a little um drama here. I think Paul, I'll let you take the lead.

Paul McCarty 24:00

Oh, I want to choose my words very, very carefully here because um okay.

Jenn Gile 24:05

So basically, it's all over, and we're not here to throw rocks.

Paul McCarty 24:08

I'm just gonna say, Yeah, I've got friends in all these companies, and um I want to navigate this in a way that's respectful to their work and at the same time is honest about some of the failings and publications research, whatever. So I think the first thing is that Amazon's main point in the the recent um uh article, yeah. Uh article, thank you, geez. Um uh, you know, that came out yesterday is that they have tied the chalk and the debug uh packages, uh account takeover attacks from last year to DPRK, and they make it sound like they're the first ones to do this. And the reality is that Charlie at Akido has been saying this publicly for a while. We've been all saying this. I think I've said it several times, you know, in talks and whatnot. Um, it certainly was a known thing, it wasn't like we're hiding. We didn't have specific attribution, but the reality is that like when you're in the guts of DPRK malware as much as I do, like you know, like it just looked and smelled like you know, a lot of the other stuff. I mean, it was unique, and not saying that it was exactly the same, but you know, it definitely looked and felt like DPRK, and you know, sure enough, the closer you got to, the more it looked that way as well. So, um, so I guess the first thing is like you know, Amazon taking credit for saying that this is DPRK and being the first ones to say it, which is what they explicitly say in the report. It was a bit of a stretch. So then Hacker News, Shaq the Hacker News comes out with a uh uh blog post yesterday on Hacker News or earlier today, actually, basically just like questioning much of the Amazon everything in the blog, yeah.

Jenn Gile 25:55

It's uh it's got an interesting tone to it.

Paul McCarty 25:58

It has now what is interesting is that there are a couple of Amazon does have some good detail in in the um uh the report, and I noticed some chatter from the SEAL team uh people um uh you know talking about it as well. And there was you know the I so basically in the report was an IP address and a in a domain name, AWS something store or something like that. No, no, it's sorry, mpmjs.store um and an IP address. Now those IP add the IP address in that domain were already out there, known. The SEAL team pointed that out. You know, we had some of that data inside of of OSM as well. Um, but it is you know, it's good and to tie it to that.

SPEAKER_00 26:46

And they also talk about this package typo what is it, typo core typo dash crypto.

Paul McCarty 26:53

Yeah. Now here's the thing, people, and Amazon does refer to this like it's a compromised package, it's not, it's it's net malicious by dprk. Yeah, it's a typo squad, it's a typo squad, right? Just it's just uh it's like one of the hundreds that DPRK publishes every day, right? Like it's it's not unusual. Here's the thing, though, is it's still on NPM after over a year. Um, so if you want to do some research, you want to grab a payload, and it's still unfortunately. I just tested right before I literally right before this, I was testing it. It's still live. Now, here's the thing is that because they pull, because they've been using the the um the ether hiding technique for months now, um, the payload that you get today is not the payload you would have gotten, you know, in the middle of 2025. So let's just be very clear like the the IOCs that we've extracted today are not necessarily the IOCs that we have, but you know, I can't go backwards in time and and figure that out. So that's you know, that is what that is. But um, yeah, it's just all really interesting, just watching it with the popcorn. Um, and I think it's you know, it's a bigger example of what's happening right now in the security ecosystem, which is that everybody wants to say say how much they're doing. Everybody is announcing that they've discovered the same thing all at the same time, right? And it's kind of frustrating, especially for those of us that have been here for a while when nobody else was here doing this, um, to hear everybody saying talking about how awesome they are and how they're discovering things that you've already discovered and had inside your platform for months. But anyhow.

Jenn Gile 28:23

Well, uh kind of taking it back to the announcement itself, um, where I think there's some value here is there's been a lot of public attention on Team PCP, uh, and they have been, you know, synonymous with account takeovers. Um DPRK intentionally is not trying to catch as much attention with these attacks. Um, I'm gonna share a link to a podcast that um was referred to me. It just came out recently. The latest to catch a thief is on North Korea. It's quite good. I was listening to the first episode last night. Um, but their you know MO is to make money and to fund their uh economy and their weapons development. And if you think about motivators, um, that's not what Team PCP is doing. They don't have a country to run, they don't have missiles to develop, and uh being loud and splashy and bragging aligns with whatever it is their goals are. Um, whereas with North Korea's goals are much more uh economic. And, you know, to some extent, I'm sure they would like to get some intelligence um, you know, in the US economy. And so if that's your goal, then you don't want to be as obvious. You don't want to be as easy to link. And I think the reason nobody has been loudly talking, you know, claiming linking chalk and debug to DPRK is to your point, it smells like it, it looks like it. Can we prove it? Probably not, but do we have a really high certainty? Yes. The same thing with Axios, right?

Paul McCarty 30:12

Yeah, I and I mean, I think there were, you know, I I think there were some pretty hard signals. Like I think that there was shared C2 infrastructure, and I think there were there was evidence. It's not like this was just complete conjecture. So um uh, you know, I I no, I wasn't suggesting it's conjecture at all.

Jenn Gile 30:32

It's it's strong, yeah.

Paul McCarty 30:34

Yeah, sorry, I wasn't suggesting that you were suggesting. Um I I think that the as a really good example of what you're talking there, Jen, about is I went to I've gone to two events in the last week and a half, and at both of those events, I because I have these really interactive talks, I like asking the the audience questions, and I asked the audience, who's heard of Contagious Interview? And in the first audience, I don't know, maybe eight to ten hands went up. And then I asked, who's heard of team PCP? And about three times as many hands went up, right? And I did the same thing at B-Sides Adelaide the other day. Contagious Interview got maybe five or six hands, team PCP got like 30 hands. So the reality is, to your point, we've been focusing on this squeaky wheel that really hasn't been, you know, causing the damage that DPRK has, while we've been completely ignoring the professionals that have been over there making over $2 billion last year. And I think you and I both want us to kind of reset, you know, the talking points here. Let's focus on who's really, you know, especially now that Team PCP is on the run. DPRK is not on the run, right? They're pretty safe. So um, yeah, sorry. Talking points reset.

Jenn Gile 31:43

Yeah, I think that's a useful framing. Um many people in the community discount or um perhaps, and I shouldn't say the security research community, because much of that community is well aware of what DPRK has been doing, but the tech community doesn't necessarily associate North Korea with sophisticated cybercrime, and that's a mistake. Um, and so as we're talking uh for the rest of this episode, the last topic that I have is some research I published today on DPRK activity. So a little backstory here. I was reading uh a blog from Socket earlier this week about the compromise of two packages in um an ecosystem called Joy Fill, which is kind of like a PDF generator. And that's nothing new. You know, we see little compromises like this all the time. But what was new is this is a legitimate package. This is not uh, you know, like that typo crypto package. This is not a typo squat. And Socket found uh pollen writer signatures. And so while DPRK does do account takeovers, what we have not seen is account takeovers where uh the pollen writer infrastructure was involved. And so I went really deep, maybe too deep. I am still in it, um, looking at uh a more of a bigger cohort of packages that we found that kind of have a similar shape. And so I looked at uh two packages that um JFrog found a month or two ago from a small developer, and then uh a collection of 16 Go modules. So these are all, you know, these three groups are all from different maintainers. None of them are very big, all of them had pollen writer signals. Uh, went ahead and confirmed, yes, indeed, they are all pollen writer related. Um, but the reason that these are account takeovers is different than what we're used to. So if we start with like a definition of what's an account takeover, what we typically think about is there's a legitimate maintainer who is explicitly targeted by a threat actor because they have access to a project or projects that are high value. So Axios, great example. Chalk debug, great example. These are maintainers that have just an enormous blast radius if you can get into their infrastructure. So they find a way to compromise uh the maintainer in a way that lets them publish a malicious version, and that's the you know, genesis of a typical account takeover. That is not what happened with these 20 packages that I investigated. These are ones where the compromise is uh, you might say that it's somewhat upstream from those packages. These maintainers at some point consumed the Pollenwriter set of malware. And Pollenwriter tends to target individual developers, which is a pattern I saw in these 20 packages with a couple exceptions. They're like single maintainer type situations, not affiliated with a company. And their MO is to get in quietly. Usually the malware fires on a VS Code task JSON, which is exactly what happened in these cases. And then uh it looks for credentials and then it continues kind of doing its thing with those credentials. But those maintainers are not necessarily targeted. Now they may come in through the contagious interview campaign, in which case they were targeted by somebody, but not for like a big account takeover. They were targeted to get persistence on their machines. And these account takeovers are evidence of the automation that's possible with this pollen writer malware. And that's like ATO through automation. These are almost uh, oops, we didn't really mean to do that, but cool. We're glad we managed to, you know, pop your project. Like they did mean to do it, but it wasn't the targeted ATO strategy that we tend to see.

unknown 36:14

Correct.

Jenn Gile 36:15

I'll pause there.

Paul McCarty 36:17

Yeah, no, I mean it's it's all it's all great research. Um, I think that that we generated a lot of data, um, and you know, sifting through that data has been a challenge. So good work there, Jen. Um I think the the the way that Pawn Rider is working, like you know, I said this at at least one of these conferences I was at last week. Contagious interview, the kind of classic LinkedIn recruiter style. You know, I I found one this week just on Twitter randomly on and posted about that. But that takes a lot of energy, right? You have to have a human in Pyong Peng or somewhere else that's managing the stuff, creating this stuff, then interacting with humans. You know, I'm sure they're using some automation along the way, but the reality is that you have to have humans, you know, DPRK operatives manage a social media or uh a social uh oh my gosh, works social engineering scam.

Jenn Gile 37:11

You need humans to social engineer.

Paul McCarty 37:13

Yeah, it's important. And what Pollenwriter does is that basically just gets rid of that need for humans to be managing it and orchestrating it instead, just creates automation. And you have to watching some of these payloads pop in a sandbox where like within like less than a second, it's already you know dropping payloads into GitHub actions and stuff like that. It's pretty phenomenal. Um, you know, you gotta you gotta give them credit. Um, and so I think people that don't the InfoSec that doesn't really have visibility, and one of the reasons I like going and doing these kind of you know, InfoSec heavy, you know, like financial services stuff and whatnot, is because InfoSec there hasn't really been um you know kind of exposed to software supply chain attacks and don't realize that in a lot of cases North Korea they they are creating more of this than everybody else combined. I don't know if that's actually true statistically, but it certainly feels like that, right? So I believe it. I yeah, I mean, I think it's true. I wouldn't have said it if I didn't think it was true. I just don't have the data right now to back it up. Um, I'll work on that for next episode.

Jenn Gile 38:18

Yeah, I mean, I guess the net here is we are going to see more. This is the continuation of a pattern where DPRK started by compromising GitHub repositories. Paul, your research that we published a week or two ago shows thousands and thousands of compromised, mostly individual developer repositories. That's kind of stage one. Stage two is it the malware leaks into whatever those people own. And you and I debated like, do we do we go as far to call this a worm? It's not really a worm, but it's got some real worm-like behavior. Like, as I say in the blog, when is an ATO not an ATO? When is a worm not a worm? It's a little bit of that with this um this behavior. And you know, as I was falling down the rabbit hole and you know, prepping for our show today, I found yet another, a PHP package that um is part of this, we'll call it leaking of the malware out of Git repositories into packages, or as you called it, you know, jumping the fence. We're gonna see more of these compromised packages that come through this way. And, you know, they're not um typically high download packages. They tend to be pretty niche because it's individual developers getting popped. However, it's not gonna stay that way. We're gonna see someone somewhere bigger get hit with this.

Paul McCarty 39:52

Well, and we have seen Pollenwriter over the last six months. We have seen it penetrate into very, very large ecosystems. Um, so in particular, um, the the developer, the single developer that manages Neo Vim got compromised. Um, and so and it found it, Pollenwriter found itself into a VS Code extension. So um, you're right, we're gonna see this. But I think the important thing is here is it doesn't have to that for this to be successful. Pollenwriter does not have to get into OpenSearch or Light LLM. It doesn't have to do that, it just has to get into all the little packages that all these developers, and they've there's tens of thousands of people now that that have this, right? So it doesn't have to be in these big ones. In fact, if it gets in the big ones, that's when they're we get a lot of visibility and people will start taking account. If it stays in these little tiny ones, you know, in these medium, you know, a hundred stars or whatever, then you know nobody's really talking about it. And meanwhile, it's doing what it's supposed to be doing, which is self-replicating, which is the whole that's the the the first worm, yeah. Yeah, the firm wet worm Turing test. Are you are you a worm or not? Is that are do you self-replicate, right? And the reality is that this is absolutely self-replicating. So you and I don't want to use the word tur worm because we just don't want to get in this flame war with with everybody else about it. But um, the reality is, you know, like you said, it what it's a worm, we're just not calling it a worm.

SPEAKER_00 41:12

Yeah.

Jenn Gile 41:13

Well, it's interesting stuff. Uh, I was at an event last night where I got to talk about it. I'm looking forward to talking about it next week in DEF CON. We're gonna be talking about how to threat hunt in GitHub. We've got all kinds of stuff going. I think this is a good place to wrap it up.

Paul McCarty 41:29

I agree. Thanks everybody for listening. We really appreciate it.

Jenn Gile 41:32

Have a great week. Uh we may or may not be here next week, but we will be in Vegas for sure. Come say hi. All right, take care.