BLOG

The OpenSourceMalware Show #13

Dependabot cooldowns, Jscrambler and AsynchAPI compromises, new PolinRider research

By cb482791-4ef1-4762-96ad-b0ca4bdd538e ·

The OpenSourceMalware Show #13

The OpenSourceMalware Show is available on YouTube, LinkedIn, and as a podcast.

This week we talked about: 

  • GitHub turns on Dependabot cooldown periods by default — A three day cooldown is now applied automatically to all Dependabot version updates, a shift we've been anticipating in the fight against account takeover malware, though it may leave developers confused about why their upgrades are getting blocked

  • JScrambler compromise — A threat actor gained access to a publishing credential and pushed five malicious versions of the jscrambler package. The malware evolved quickly, with the first three versions containing the trigger in a pre-install script to the last two on-import execution partway through. They also published four versions of related packages that pinned to malicious v8.18.0.

  • AsyncAPI compromised — Attackers exploited a GitHub Actions pull_request_target flaw that sat unresolved for 58 days to steal a privileged token. They published malicious npm packages under the @asyncapi namespace, all with components of the Miasma malware that was open-sourced earlier this year (but no worm).

  • New PolinRider research — Paul's latest hunt found 2,417 newly-compromised repositories, confirming config file injection as the dominant delivery vector alongside a growing fake font technique, still overwhelmingly hitting individual developers rather than organizations

Episode Resources

[00:00:00] Jenn Gile: Hello. Uh, it is Wednesday, July 15th. Paul and I are recording a day early, so hello from the past. Uh, Paul, what you got going on?

[00:00:13] Paul McCarty: I'm in the future right now for you. That's true. So, like, how, where does that put me? I don't know- You are in my

[00:00:16] Jenn Gile: future and everyone else's past ...

[00:00:18] Paul McCarty: I don't know where the timeline is, or I don't know where in the multiverse I sit right now.

[00:00:21] Paul McCarty: But, um- Yeah ... yeah, things are good. It's very windy here. We got a, a week's worth of rain coming at us, but luckily, the Southern Hemisphere headquarters is about to open for, for Open Source Mailware, so I'm very excited about that.

[00:00:35] Jenn Gile: Yeah, that's gonna be great. Um, we have a full list of things- We do ... uh, to talk about today.

[00:00:41] Jenn Gile: Let's do a quick hit. It's at the end of the list, but I'm gonna pop it up to the beginning. BSides Adelaide is coming up. Tell everyone what's going on there

[00:00:51] Paul McCarty: Yeah, so that's not, uh, next week. It's the week after that. So it's Monday and Tuesday. It's w- it's a weird days, but it is what it is. Um, and-

[00:00:58] Jenn Gile: July 27th?

[00:01:01] Paul McCarty: Yes, ma'am. Yeah, it's two days. It's 27th and 28th, but I'm talking, I'm speaking on the 27th. I'll be there both days. I really like this event. I didn't go last year, but I went the year before that. Um, and the cool thing about this Adelaide is that, that this is, this is where a lot of the defense sector in Australia is- Hmm

[00:01:17] Paul McCarty: for whatever reason, for historical reasons. There's, like, this large kinda defense ASD, ASU- Not in Canberra. Oh, I mean, it's absolutely there, but from a private sector perspective, a lot of it is in Adelaide, maybe because it's a port. I don't know. Who knows? I don't know what the history is, but it's there, and so it, it has a very different flair from other BSides.

[00:01:39] Paul McCarty: It's definitely very government. I mean, it's got the community aspect for sure, but it's got a different flair, which is one of the reasons I like it. Varied.

[00:01:46] Jenn Gile: Yeah, that's a reason in general I love the BSides Conference, is you get, like, a flavor of the, the local community. It's different every BSides that you go to.

[00:01:56] Jenn Gile: Okay. So true. Let's hit the news.

GitHub turns on Dependabot cooldown periods by default

[00:01:56] Jenn Gile: So yesterday, I was winding down my day, and I saw GitHub made an announcement about Dependabot. And for anyone who's not familiar with Dependabot, it is GitHub's open source SCA tool. They even actually don't call it an SCA tool, but essentially that's what it is, is it does code scanning, um, for your dependencies that are in GitHub and, um, can do, like, auto-upgrades for you.

[00:02:25] Jenn Gile: And that is relevant because the announcement that they made is about cooldown periods, which we've talked about quite a lot, uh, in the last year in the community. And so what GitHub has done with Dependabot is they have flipped the switch so that cooldown periods are automatically on for all packages for, uh, a period of three days.

[00:02:48] Jenn Gile: Now, there's some caveats there. If you have a security upgrade, it'll override that, but, um, they have changed a default. And I think this is an interesting choice on their part, and I'm a little, like, on two sides of the fence about it, and I'll tell you why I'm a little, like, torn, and I wanna hear what you have to say, Paul.

[00:03:11] Jenn Gile: Um, so the good is cooldown periods in general are good. You know, consuming something immediately after it's published dramatically increases your chance of, uh, consuming an account takeover piece of malware. Not that all malware is ATOs, but almost all ATOs are taken down pretty quickly these days. Um, and so a three-day cooldown is certainly going to make a big difference there.

[00:03:38] Jenn Gile: Um, on the con side- The people who will encounter this in production probably won't understand why this has been turned on. And so you're gonna have a lot of developers perhaps wondering why they are being blocked by Dependabot from upgrading to latest. And so I think on the con side, that may push some conversations for security teams or whoever owns Dependabot in a company to kind of explain why this policy has gone into effect.

[00:04:12] Jenn Gile: And, um, I don't know. It, it I think will net be good, but it could create some chaos or strife for people in security, and I never like to see that

[00:04:24] Paul McCarty: Yeah, I'm, I agree. I mean, I think that there's, you know, there's arguments on either side of this whole cool down thing, and we've talked about this before, so I won't belabor that.

[00:04:31] Paul McCarty: But, uh, I think the other thing about Dependabot is that nobody serious uses Dependabot, right? I, um, let me just- You went there ... um,

[00:04:39] Jenn Gile: just- I w- Oh- I wasn't gonna say

[00:04:41] Paul McCarty: it. That's my job here.

[00:04:43] Jenn Gile: I know.

[00:04:44] Paul McCarty: The alt- the alternate name for this podcast is the, the Spicy Sp- Podcast, but um, Spicy Cyber Podcast. Um, I do have that, uh, I do have that URL.

[00:04:52] Paul McCarty: Um- Um ... listen, the, the reality is that, you know, uh, on- the only people that have Dependabot turned on are small teams and, you know, people at the beginning of their journeys, because it's just a noise generator. It creates p- if, you know, a lot of people turn it on to create PRs, and it creates PRs, and then people just, you know, c- cancel them, right?

[00:05:12] Paul McCarty: And d- and then they just have... And so it's just, it's a noise generator. And so I think that the conversation around, the complexity around conversation with cool downs is a more nuanced conversation, and the people that are using Dependabot probably by and large aren't gonna understand the nuance for why there's this balance between, you know, ingesting something as quickly as possible to address vulnerability risk, while trying not to ingest it within the first day to, to keep yourself away from account ta- takeover risk.

[00:05:43] Paul McCarty: So malicious package account takeover risk. Um-

[00:05:47] Jenn Gile: Yeah, that's well put ... but yeah I mean, if you troll the Reddit archives, you're going to see 99% of them are people just absolutely trashing on Dependabot, and sometimes it's for fair reasons. Um, most of the time it's for fair reasons. So yeah, I, I don't know. I know a lot of people use it.

[00:06:06] Jenn Gile: Uh, it's not only small shops. I've talked to lots of people at bigger shops. It's usually about budget because it's free. Um, but you know, there's that old saying- You're not- ... treat it like a puppy.

[00:06:17] Paul McCarty: You're not, you're not, yeah, I mean, you're not really disagreeing. Maybe the small shop thing you're disagreeing, but aside from that, you're not really disagreeing with me, like- No,

[00:06:23] Jenn Gile: I'm not disagreeing with you at all.

[00:06:25] Paul McCarty: Nobody that has maturity in this space uses this as an SCA product, right? It's a, it's a, it's a box ticking thing at best if you're a large organization.

[00:06:33] Jenn Gile: Yeah. It's usually something people choose to rip out when they get more mature, but, uh, a lot of people are using it. So yeah, should be interesting.

JScrambler compromised 

[00:06:41] Jenn Gile: Okay. Let's talk about two compromises that happened in the last four days or so. They're totally unrelated. Uh, the shape of them is totally unrelated, so we're gonna talk about them separately. The first of those compromises is JScrambler. Uh, it came through on July 11th, and, uh, this came through in kind of like- Three steps.

[00:07:05] Jenn Gile: Uh, they published a whole bunch of malicious versions of the main JScrambler project. We don't quite know how the threat actor got access. Um, it was made possible through an NPM publishing credential, but we don't know if that was a stolen credential. We don't know if it came through, uh, a GitHub actions exploit.

[00:07:26] Jenn Gile: We just know the threat actors had access to a cred. Um, they started off by publishing three malicious versions that shipped a pre-install hook, so kinda that classic NPM life cycle script auto-install your malware feature. And then they published two additional versions where they moved the trigger, so, um, versions 8.18.0 and 8.20.0.

[00:07:53] Jenn Gile: And then they published four related JScrambler packages that pinned to that 8.18.0 version. So some very, like, interesting series of things that the threat actors did here. Uh, Paul, you did a deep dive on the malware because, um, I was looking at our threat reports and I said, "Hey, it looks like, uh, 8.18 is malicious."

[00:08:20] Jenn Gile: It had been reported by another, uh, researcher, and it hasn't been taken down. Let's double check, you know, is this a false positive on their part or did JScrambler miss something? So Paul, you dove in. What did you find?

[00:08:33] Paul McCarty: Yeah, I mean, I think the, when you pinged me about that, I was going systematically through each version and verifying, you know, which versions had it and which versions didn't.

[00:08:43] Paul McCarty: And I really quickly saw the 8.18 and 8.20 still had the payload but didn't have the, um, pre-install and the setup.js files that the earlier versions of it were using to trigger it on install, right? Um, so yeah, I mean, the, the, the, um, you know, I looked at so many different malware strains since then, it all kinda blends together.

[00:09:06] Paul McCarty: The details have muddied. But it is, it's in the blog, it's in the blog posts. Um, it's in the blog post. Uh, but I think the thing that's really interesting about this one is that, uh, you know- The original post from, um, a researcher, and I don't actually know this researcher that well, but specifically called out 8.18.

[00:09:28] Paul McCarty: And I think what happened is I think somebody at the JScrambler team, you know, grepped for the existence of the pre-install stuff, didn't see it, and then just skipped 8.18 and 8.20, and then went back and got 8.20 out. Anyhow, three and a half, three and a half days later, I ping him on G- on a GitHub issue.

[00:09:46] Paul McCarty: I'm like, "Hey, 8.18 is still in NPM. What's going on here?" And we got a really terse, classically Euro response back to us saying, um, basically, it's been deprecated. Didn't say, "Oh, you know, thank you, you know, I've now deprecated it because of what you said." You know, it was just like... So, and also too, reading, I'm looking at the, the incident res- the incident response blog post that they posted, which they did a really good job of from a timestamp and a kind of incident response perspective.

[00:10:13] Paul McCarty: This is a really good, and I wish I saw more of this. And because they have a background in, in code integrity, I think that's where this is coming from. But what I don't see is I don't see ownership and e-explanation of how this got into the JScrambler, um, organization. Um, and that's concerning for somebody that, you know, is, is building a code integrity platform, a paid commercial code integrity platform.

[00:10:39] Jenn Gile: Yeah. And, uh, something that was observed by one of the researchers in the GitHub issue was, uh JScrambler had initially s- started deprecating before the threat actor was done publishing all the versions. And, uh, you know, the hypothesis here is JScrambler didn't rotate credentials well enough, missed something in this series because they came out and they published, uh, what they said was a safe version that was lower than what the final safe version was.

[00:11:15] Jenn Gile: I think it was, like, 8.15 or something was a safe version. It was,

[00:11:18] Paul McCarty: yeah.

[00:11:19] Jenn Gile: And, um, yeah, the other researcher came back and said, "Hey, you, you did not rotate this correctly. They're still publishing." And so there's clearly some things-

[00:11:29] Paul McCarty: Right ...

[00:11:30] Jenn Gile: missed there. Um, again, I know, uh, we don't love seeing these ever, um, but the IR part is only part of it.

[00:11:40] Jenn Gile: Understanding kind of the post-incident, how did this happen, is important to the community. Would've been great to see that.

[00:11:48] Paul McCarty: Yeah. And just, you know, like, it's just, take, take a little bit more responsibility for it, right? Like, the... And listen, having been in this situation, I just wanna double click on something you said there.

[00:11:58] Paul McCarty: Having been in this situation bef- where you have a credential- Mm-hmm ... has been stolen and you're trying to do incident response at the same time, it's very common for this kind of, these things to overlap, where you're getting rid of stuff and they're pushing new stuff. So that's not surprising.

[00:12:12] Jenn Gile: Yeah.

[00:12:12] Paul McCarty: Um, and the fact that they didn't rotate creds correctly right away, 'cause they did have a very, very- quick response to this to, to their credit.

[00:12:22] Paul McCarty: Well,

[00:12:22] Jenn Gile: I think from reading between the lines of their incident response, I think they actually had detected it before the community reported it. There was something- Yeah ... that was anomalous behavior that they were able to identify, so they were on it very quickly.

[00:12:36] Paul McCarty: Somebody saw a notification. I can't remember if it was in a Slack channel or if it was an email, but somebody saw a Slack notification.

[00:12:40] Paul McCarty: They're like, "Oh, that doesn't look right." And so they, they saw it almost immediately via that. Which is one of the reasons that you wanna have those, you know, those notifications, those async notifications turned on, and a lot of people don't because they think that, you know, whatever ASPM tool they've got inside the CI is enough.

[00:12:56] Paul McCarty: No. Turn those notifications on, have them sent to... 'Cause at the very least, when you're doing instant response, you can go back and you can look at the timestamp for each one of those things. That's important.

[00:13:05] Jenn Gile: Yeah. Well, that's the same situation that happened with Nx a couple months ago. That's how they figured out that a threat actor had gotten access, is those notifications.

[00:13:14] Jenn Gile: So- Correct ... uh, embrace a little bit of noise. Okay. Let's talk about Async- Let's talk about the other one.

AsyncAPI compromised

[00:13:14] Jenn Gile: Yeah. AsyncAPI. Um, again, not related. Woo. Uh, what we do know about this one is attackers gained access through a disclosed GitHub actions vulnerability. Uh, not only was this a known vulnerability, but AsyncAPI was aware of this vulnerability.

[00:13:39] Jenn Gile: It was... You know, there was a PR open for something like 58 days to resolve it. Oops. Um, so a threat actor came in and was able to take advantage of that vulnerability to gain access. Uh, again, this is not a situation of a stolen, uh, credential. They were able to gain access through a vulnerability. So, you know- Yeah

[00:14:02] Jenn Gile: we've talked a lot about tokens, uh, expiring and email and things like that. None of that would've helped in this situation because of the existence of this vuln. So they pushed some malware that, um, has some markers from Miasma, and we'll talk a little bit about how it is and is not the same as the other Miasma that's been out there.

[00:14:25] Jenn Gile: And, um, something that's, I think, worth noting, because people are always curious about who's behind these, we have a potential indicator, and that is that it monitors for Russian language, and if it finds it, it exits. As we know, that's not a guarantee that it's- Right ... you know, therefore a Russian actor. It could just be somebody vibe coded something and that got pulled over.

[00:14:48] Jenn Gile: Um, but yeah, Paul, um, you've taken a look at the payload. You know, it's not a worm, but it is- Nope ... Miasma. So let's talk maybe a bit about how we've seen Miasma evolving since it was released, what, in late May, I think is when that, uh- At Worm got open sourced, or maybe it was June. Oh, yeah. But yeah, not that long.

[00:15:16] Paul McCarty: No, it hasn't been, it hasn't been that long. Yeah, I mean, this is a classic pull request. Um, it uses, you know, pull request, um, target, pull_target. I'm sorry, pull_request_target. You and I both know somebody that's been behind the scenes sending out disclosures to people, and might or might not have sent one to this team team.

[00:15:39] Paul McCarty: I- it's just, you know, and, uh... And, and by the way, something you, you forgot to men- or didn't... Sorry, you didn't forget. But they got done, the same team got done in Shai Hulud 2.0-

[00:15:49] Jenn Gile: Yes ...

[00:15:50] Paul McCarty: in 2025. And

[00:15:51] Jenn Gile: indicators is that it's not a related attack

[00:15:56] Paul McCarty: Correct

[00:15:57] Jenn Gile: You never know for sure. Yeah. But yeah, they could have just been incredibly unlucky this year.

[00:16:03] Paul McCarty: Yeah, but I mean, the, there's a thread, Pwn requests, you know, there's a thread of Pwn requests through all of these, right? And so if you get done in 2025 via GitHub actions, um, you know, you would think that you would replace these or, or refactor all these GitHub, these workflows. But, you know, obviously that's not, you know, the case.

[00:16:24] Paul McCarty: Uh, but getting to your other observation about is this miasma or not, I think this is mostly like a, um, like it's a, it's a moot point. It's like w- you know, because the, as you and I were talking before we started rolling- Yeah ... the miasma now, that word has evolved because as soon as they open sourced it, it changed it from being like, what is the TTP specific to the first miasma attack, which was a worm, to now they've open sourced it and it's become this other thing, right?

[00:16:49] Paul McCarty: And that's not, that's not me making some decision. That's just culture and language and the free form nature of it. So I saw somebody being persnickety about this isn't a var- this isn't a variant or whatever, and I l- like, there's... I, I just don't think that's an argument worth having, right? Is this derived from the miasma open source code?

[00:17:11] Paul McCarty: Yes, absolutely. I don't think anybody disagrees with that. Do they make significant changes to it? Yes, I'm happy to talk about those.

[00:17:18] Jenn Gile: I'm curious, and I know this is not a definitive thing you would know, but why do you think they might have decided to remove the worm component? Because, you know, in the malware game, the more people you can hit, the more stuff you can potentially get.

[00:17:33] Jenn Gile: Now, certainly as I'm asking you this question, I'm gonna partially answer it, and then I wanna hear your thought. But, uh, you know, it being worm-like certainly will make more people find it, potentially, and so you might get caught sooner. But what do you think? Why do you think they removed the worm?

[00:17:51] Paul McCarty: You know, obviously I don't have any specific thinking.

[00:17:54] Paul McCarty: Um, uh, but you know, and just in general, I think that we, we, I think we attribute way too much brilliance to these authors and these threat actors, and I think they just took something that was open sourced and they modified it and got it working. And maybe they ripped out the NPM, the worm stuff because that just complicated it.

[00:18:13] Paul McCarty: Who knows, right? And the CIS stuff might have been added by Claude because it's done in the past. TeamPCP added, you know, a CIS check to theirs, and then somebody asked them, you know, "Do you have anybody in, in the CIS?" And they made up some bull pucky answer about, you see I didn't cuss there, bull pucky answer about, um, of, "Oh, well, you know, we have team members all over the world."

[00:18:33] Paul McCarty: Not true. Um, uh, you know. So anyhow, the CIS part could just be there because, you know, the agent suggested 'cause hey- Yeah ... oh, hey, you're writing-

[00:18:42] Jenn Gile: From somewhere else. All malware looks for CIS countries,

[00:18:44] Paul McCarty: so Yeah.

[00:18:45] Jenn Gile: You're

[00:18:45] Paul McCarty: writing malware? Here, let me help you. Here's the section w- does the CIS check.

[00:18:49] Jenn Gile: Yeah.

[00:18:51] Paul McCarty: It also confuses people too, 'cause then you start looking at, you know, Russian or Russian-aligned actors.

[00:18:56] Paul McCarty: Um, so you know- Yeah ... there's a million, not, maybe not a million, there's a lot of reasons that th- this could be like this. Um, uh, so yeah.

[00:19:04] Jenn Gile: Who knows? Okay, speaking of state-sponsored- That's Peter down there ... let's talk about something that we do know who's behind it, and we do know it's state-sponsored, is, uh, we just released earlier today, and I'll share the link in the show notes, some new PolinRider research.

New PolinRider research

[00:19:19] Jenn Gile: Uh, for anyone who has, uh, not been following that research or, um, you know, you kinda get lost in the campaign names, just in brief, PolinRider is a North Korean sta- state-sponsored campaign that we found earlier this year. Um, it originally was weaponizing credentials stolen through a different campaign that Paul, you, uh, named TasksJacker, which I enjoy.

[00:19:48] Jenn Gile: Um, and we think- Thank you ... it's probably, uh, we would consider it like a parallel or sub-campaign to Contagious Interview, which has been running for several years. And we're seeing a lot of activity in PolinRider over the last, let's see here, March is when you discovered it, so what is that? Four months.

[00:20:07] Jenn Gile: Um, but what they basically do is they th- uh, fork popular open source projects, submit malicious pull requests. They inject payloads into JavaScript config files and, um, they're very good at putting those payloads in files that people just don't look at in code review. Um, the f- the font files was one of the locations.

[00:20:32] Jenn Gile: Um, but the, you know, bringing us back to present tense, present time, uh, you've been working on detections and Found another more than 2,400 poisoned repos that you can attribute to this campaign.

[00:20:53] Paul McCarty: Yeah. So that brings it over, like, 4,400, I think, um, in total. Something like that, yeah. Something like that, yeah.

[00:21:00] Paul McCarty: I think the thing that's really unique about PolinRider, and the reason it's kind of a separate, we talk about it as a separate campaign or a separate thing, is that every single one of these poison packages is sitting on top of existing, you know, compromise. So basically, the only reason that DPRK can do this is typically because they have compromised a developer's laptop, either through a contagious interview, interview process where they, you know, the, the victim downloaded something, or a malicious NPM or PyPI package or what have you.

[00:21:32] Paul McCarty: Um, or there's, you know, a couple other ways that this happens, too, as well. Or, or just- Right ... the spread of it naturally inside of the open source ecosystem, which is, which is I think what we're seeing now. We're seeing, like, a lot of people just getting pwned that way. But anyhow, it's, it's really unique because it does require existing compromise, not of GitHub, but on the developer's laptop, and this is where you and I are gonna be coming out with some more stuff about the human bot net, the, and, and, you know, what DPRK is able to do with this.

[00:21:56] Paul McCarty: But that's a very concerning thing. If they've got persistence and they can do PolinRider, they can do other stuff, too, as well. So, um, it's not cool, uh, at all.

[00:22:05] Jenn Gile: Yeah. What I think people may be familiar with with contagious interview is kind of the playbook previously was reach out to a software developer, you know, tell them that you wanna interview them, have them do a take-home, that's where the poisoning happens, uh, and then use that access to steal their crypto.

[00:22:24] Jenn Gile: That was kind of the playbook with contagious interview. Yeah. Um, what PolinRider is doing is it's continuing that, uh, exploitation of the developer who got popped, again, one of several ways. Uh, once you've taken their crypto and you've gotten into their repos- You know, what we've seen is this is predominantly individuals.

[00:22:50] Jenn Gile: Uh, you know, they haven't had, whether not targeting or just not successful, they haven't exploited as many organizational repos. It's predominantly individual repos. That doesn't mean that organizations are not getting compromised by this. It just means that it's not the repo that's been compromised.

[00:23:12] Paul McCarty: 100%.

[00:23:12] Paul McCarty: And you can see that in our data set. So if you go to github.com/opensourcemalware/polinrider, you'll see our data set there, and you can just look right in the, the CSV files, and you can see we've labeled organizations which are, you know, typically companies or, or, you know, some abstraction other than a human, single human being.

[00:23:32] Paul McCarty: Um, you know, there's a fair few of those in there, and this is something that DPRK kind of cottoned onto, and I think we're still playing catch-up inside of the enterprise. Well, not just the enterprise. Which is you target the individual to steal their crypto. You also target the developer to get access to what they have access to.

[00:23:51] Paul McCarty: And if they're a freelancer, that's even better, right? If they're just some guy working for themselves in Armenia, right? And they work with 10 different companies, some of them might be crypto and some of them might not, then that- Yeah ... one person has access to the source code, the core intellectual property of all 10 of those clients, and they can then push those payloads into them once they compromise that one developer on their, their machine.

[00:24:13] Paul McCarty: So it's just a very, um... And you know, like, in the whole contagious interview, LinkedIn recruiting, it's still going on, but now they're using, they're using the same payloads, the same PolinRider payloads now. So I saw one yesterday on Twitter, I interacted with it. Mm-hmm. So if you follow me on Twitter, you'll see me interacting with this person.

[00:24:32] Paul McCarty: But they got done just two days ago, stole all the crypto. The victim said, "I don't know how many wallets they drained." And I'm thinking to myself, "How many freaking wallets do you have, yo, if you don't, if you don't know how many wallets got drained?" You don't know how

[00:24:43] Jenn Gile: much money you lost.

[00:24:45] Paul McCarty: But here's the thing is I went and looked, that GitHub repo was already in open source malware.

[00:24:52] Paul McCarty: It was already... It was a compromised, it was somebody else that had already been compromised via PolinRider. PolinRider then used it on a net new person via, you know, classic contagious interview fake recruiter. This is just like the levels of inception here, Jenna, is just crazy, off the charts crazy.

[00:25:09] Paul McCarty: Yes.

[00:25:10] Jenn Gile: I wanna pull out some stats from the research that we published today. Um, as I was kind of going through it and preparing it to publish, these are still kind of in my head. So the first stat, uh, in case you sort of missed it, listener, in the numbers is we have seen basically a six and a half time increase in confirmed poisoned repositories since we pulled the numbers, the repos in April.

[00:25:38] Jenn Gile: So that's pretty substantial. Um, the second thing that is A clear trend here is how they are, uh, smuggling the malware in, and there's two ways, but there's a very clear, uh, leaning toward one way. And so in 94% of the cases, Paul, you found that they were through a config file injection and just, uh, you know, 5% or so was through one of these, uh, font files.

[00:26:14] Jenn Gile: And then there's, like, a very small percentage where both were, um, present. So- Talk to me, talk to the listeners about why these config file injections or the fake font vector might be a smart place to hide your malware.

[00:26:33] Paul McCarty: Yeah, great question. Don't

[00:26:34] Jenn Gile: give anyone advice here.

[00:26:37] Paul McCarty: Um, yeah. Well, that's... I was just thinking while you were talking, I was just thinking about something else I wanna talk about.

[00:26:41] Paul McCarty: I was like, "Oh, actually, I don't wanna talk about that 'cause I don't wanna give anything away." Okay. But, um, you know, sometimes describing the problem in too much detail, you know, lets the threat actor know how you're- Yeah ... finding it, and I don't wanna do that. But, um, yeah. So listen, a lot of the, um... So basically, the whole PolinRider payloads kind of fall into two categories.

[00:27:03] Paul McCarty: One is that they're appending malicious JavaScript to an existing... Or, or actually it's not always existing. If it exists, they just append it to it. Otherwise, if it doesn't exist, they just create a file. It's just hilarious. They create a file, and then append their payload to the... You know, 'cause they got this o- they got this orchestration clearly in Pyongyang or wherever they are, and it's working, and they don't wanna change it, right?

[00:27:24] Paul McCarty: They're iterating on all the other places, but they're not changing that. So there's that way, and so basically then what happens is you have to run the app to, to, to get the nasty thing, to have it run on your machine and get compromised that way. Now, the other way, and they are really doubling down on this, is VS Code.

[00:27:40] Paul McCarty: And I know I'm the guy that's out here bitching about VS Code, but the reality is that... Listen, don't take my word for it. Go and look, right? Either look in open source malware or go hunt yourself. DPRK uses VS Code because it is very, very successful. It's successful if you're using VS Code, it's successful if you're using any of the, the IDEs or, or AI agents that sit on top of it.

[00:28:02] Paul McCarty: But basically what's happened now is the, the... They'll use VS Code to automatically instanti- to run, to execute the payloads, and they use several different versions. Like Jen said, they use fake font files, which are really not font files. It's just JavaScript, and they append a font TLD, you know, name suffix to it.

[00:28:20] Paul McCarty: But, um, uh, or they just run it just as a command inside of, of task.json. Or in a small ca- number of cases, they use a fake dictionary file, which is basically the same thing as the font file. It's just like, it's not a dictionary, it's just, you know, basically JavaScript with a dictionary.dict, um, appended to it.

[00:28:40] Paul McCarty: Um, but what we're seeing increasingly now, and this is something that we need to flesh out more in our data too as well, is that DPRK is shipping these with at least two of these triggers in every single repo. So they're gonna have a task.json trigger, so that if you open up in, in, in VS Code, it automatically...

[00:28:59] Paul McCarty: Or Cursor, it's gonna automatically run, or Windsurf is auto- automatically gonna run. But also, if you just spin it up, you're also gonna get comp- compromised via the, um, you know, the Vite config files or the, the, um, the other, um, uh, JavaScript files that they've, they're appending to It's really smart.

[00:29:17] Paul McCarty: Multiple, multiple triggers per repo means that they increase their chances of, of that trigger happening, one of those triggers

[00:29:24] Jenn Gile: Yeah, and I don't think we've talked about this out loud, but one of the advantages of hiding your malware in VS Code files is they don't get the same scrutiny as dependencies.

[00:29:38] Paul McCarty: Correct.

[00:29:39] Jenn Gile: And I think- Yeah ... in some ways that's changing. Um, you know, I'm talking to more and more people who understand the risk there, but it's somewhat complicated from a management perspective to control what people are consuming. And again, these are individuals who are being hit by, uh, this campaign, and so the probability that these are getting scanned by any kind of an enterprise tool is, like, zero.

[00:30:10] Jenn Gile: They're, you know, left to just look at the, the thing that they're pulling in and say, "Oh, that looks okay." And then they miss, uh, the malware hidden deeply in these, these sneaky little places.

[00:30:23] Paul McCarty: Yeah. Uh, something else they're using a lot right now is Git. So they're using Git branches, so they use a, a, a Git web hook...

[00:30:32] Paul McCarty: Sorry, Git hook. Excuse me. Um,

[00:30:34] Jenn Gile: hook- These are your poisoned, poison Git hooks.

[00:30:37] Paul McCarty: Yeah, yeah. They use the post checkout, which is a very... No- hardly anybody uses it, but basically then what happens is inside the task.json, they just run, uh, a Git command that changes the branch. And as soon as they do that, that triggers it as well.

[00:30:50] Paul McCarty: So, and they're using other kind of crafty ways. They're using pre-commit hooks too as well. Um, so just this... And you'll sometimes will see those in addition to some of those other triggers too as well. So we are not, to your point, we are not prepared for this. The existing security tools that you're using probably are not able to catch this stuff.

[00:31:07] Paul McCarty: And even if you go and m- m- yourself manually, like, change VS Code to not run some of these things, these payloads will drop a settings.json file over the top of it, which overwrites your settings. So then they can basically get rid of some of the hardening that you've already done to VS Code. I mean, it's- It's just well, you have to give them credit, man.

[00:31:27] Paul McCarty: Yeah. It's well done, and it's super effective. Um, as I said yesterday, I'm, you know, continuing to see people on LinkedIn and, and Twitter getting popped. It's super effective.

[00:31:39] Jenn Gile: So to kind of wrap this up in terms of advice, uh, if, you know, listeners out there, if you're running take-home coding tests, if you're installing any unfamiliar front-end templates, if you're cloning project starters from strangers, uh, treat, you know, treat all of that as untrusted, especially the config and the font files.

[00:32:00] Jenn Gile: Make sure you check those. And then, um, if unfortunately you did consume something dangerous, we do have a detection script that can help you, um, identify that. It's in the blog that we'll share the link of. I think maybe it's also in that repo that you referenced, Paul. Is that right?

[00:32:19] Paul McCarty: Yeah, and in that original blog post, the original PolinRider b- blog post, at the bottom of it I also tell people how to harden VS Code.

[00:32:27] Paul McCarty: So I'm sorry, I don't have that link in front of me right this second, but, um, we'll try to append that to the, to the podcast.

[00:32:33] Jenn Gile: Yeah, I can pop that in there. Um, unlike with NPM lifecycle scripts where you really do have a legitimate reason to have them turned on, um, there are some things that you can disable in VS Code that everybody will be happier.

[00:32:47] Jenn Gile: Well, not North Korea, but everyone else.

[00:32:51] Paul McCarty: Unfortunately, a bunch of extensions that people run, which are also... We didn't even talk about that. That's the other way the DPRK is getting people. But a lot of extensions unfortunately require those tasks, that JSON to do stuff for the extensions. Yeah. So it's kind of similar to the, you know, like, the fact that ESLint requires a, a post-install script to do stuff to set it up.

[00:33:10] Paul McCarty: So it's unfortunate. We, you know, we require a lot of these automated script things.

[00:33:16] Jenn Gile: Yep. Okay. We are at time. Sure. Uh, I think we're at a good place to stop. I'm gonna tease a little bit, next week we're planning on talking about some macOS malware. Ooh. Uh, our friends over at Jamf published some really cool stuff, and we found some other cool stuff, so more, uh, on that next week.

[00:33:36] Paul McCarty: Yeah, I'm stoked. Take care, everybody. Thanks for listening. Appreciate it. All

[00:33:38] Jenn Gile: right. Bye.