Jenn Gile 0:01

Hello. It is Wednesday, September 9th. Paul and I are live from Strasbourg, France. It's 2.35 in the afternoon for us, but I think our bodies are in vastly different time zones still. But we've been having a great week at the Underground Economy Economy Conference, which Team Cymru puts on. We'll talk about that a little bit more. Paul, why don't we start first with the news? And what I will say is like pleasantly surprised, it's been a quiet couple of weeks in uh malicious open source, right?

Paul McCarty 0:35

Yeah, I mean, I was saying this earlier. Like I think it's quiet, it's relative. It's quiet in the sense there haven't been any big you know attacks, right? Team PCP is um behind bars. But you know, North Korea and everybody else is humming along, and and you know, uh we're averaging just over um it's at least 115 malicious GitHub DPRK related contagious interview uh GitHub repositories a day, over a hundred, um, roughly 115. So the number of malicious things is increasing. So it's hard for me to see.

Jenn Gile 1:14

Yeah, yeah, you're right. Uh quiet is certainly relative. I was looking at the number of total verified threats in our database, and we are getting very close to 200,000, and that has been kind of uh, you know, certainly steadily increasing over the last year, but uh we've seen a big increase in recent weeks. Um it's not on our list, but hey, happy birthday open source malware. Um for people who haven't followed our LinkedIn. Uh we're celebrating our one-year birthday since uh Paul uh got frustrated and DIY. So maybe before we get into the regular uh agenda, how are you feeling after a year of doing this?

Paul McCarty 1:58

Uh you know, it's pretty amazing. Like, you know, you and I at conferences over the last few months, you know, people routinely come up to us and say, you know, they they know us from the podcast here, they they use the platform, but particularly at this conference, a lot of the people we've talked to are pulling our data, um, our free APIs. And that is it just really fills me with a lot of pride. Um that you know the the the pain that I saw, you know, it you know, is shared with other people too as well. And so that makes the data that we provide, you know, valuable to a lot of other people too. So I just it makes me eventually and I know in the Bible pride is one of the seven deadly sins, but screw that noise. I'm I'm very proud of building this thing and how it's taken off. Um so that's pretty cool.

Jenn Gile 2:46

Yeah, I think you should be proud. Um, you and I both love open source. It feels good to do something uh that helps the community, both the open source community and the security community. So yeah, uh as much as I think we don't want to see hundreds of thousands of threats in our database, like that sucks because that means there are threats out there. Also, I've got a bit of pride that we're, you know, a year in and have that much valuable data that is helping the community. So yeah, it feels pretty good.

Paul McCarty 3:17

Yeah, and I want to mention too, as well, we've got over 100,000 IOCs as well as part of the the news stuff. So, you know, um yeah, it's awesome.

Jenn Gile 3:27

Yeah. Okay. So uh the one piece of news that I thought was notable over the last couple of weeks since we recorded the last time, uh over at Aikido, Charlie published a blog about four packages that were um published on September 7th, uh, all within the same hour from the same NPM account. Um, the story here is not, oh no, these are scary, something terrible is happening. The story is actually that they bear the mini Shy Halud uh malware from back in May, uh, the variant that went through ANT V. And um the way that he found them is the hash matched, which, as you and I have talked a lot, you know, often the hashes are not the best way to find things. But in this case, you know, because it stayed static, uh, he found it that way. Now, uh, is this malware dangerous? No, because all the C2 infrastructure is down at this point. Um, but it's pretty interesting to see somebody had this stuff hanging out in their repo, presumably for what is that, May, May, June, July, August, you know, four to five months, and uh it's rearing its ugly head again. Um the comment that he made, which I think is a great point, is this was easy to detect um if pre-publication scanning is happening in NPM, as we've been told it is. This is like the lowest of the low-hanging fruit.

Paul McCarty 5:00

Um let me say this a little bit differently and a little bit spicier. Hey NPM.

Jenn Gile 5:08

I thought I was being pretty spicy.

Paul McCarty 5:10

Well, I mean, for Jen, that was pretty spicy, but for Paul. Um, hey NPM, if you are actually scanning for malware in your registry, please present evidence of said scanning. Because we don't see it.

Jenn Gile 5:26

Yeah, highly doubtful. Um let's see, is there anything else interesting to say on this? Yeah, I mean, essentially what we think, what Charlie thinks happens is this was hanging out in somebody's pipeline. You know, they push some updates. And uh, as we have seen with Pollenwriter and other campaigns, they accidentally pulled the malware along with it. So uh this is not like a new wave of the worm is coming out. That's not what he's saying, that's not what we're saying, uh, but it's more a testament to these things linger.

Paul McCarty 6:01

Well, and source code has this weird way of you know getting itself back into like old source code or or or um isolated or orphaned source code has this weird way of working itself back into main. And I was just thinking a second ago because you and I were like speculating before the the thing, the the podcast, about how it got broke free. And just as we were talking about it, just as we were recording, I thought, you know, I've seen this before with um with DPRK stuff where it'll get stuck in a branch. Basically, what happens is it gets orphaned in a branch, not orphaned, but it gets kind of stuck in amber in a branch. And then what happens is months and months and months later, somebody does a bunch of merging um uh, you know, and and alignment work, and then suddenly something is in main, um, and out it goes.

Jenn Gile 6:49

And that's yeah, I mean these projects look pretty unrelated, like two are clearly related, but the other two seem unrelated. Uh, this reads to me like somebody went in and did some cleanup and uh made a noops.

Paul McCarty 7:05

Didn't even realize what happened. Um I I think it's also evidence of the fact that you know, like this stuff has consequences even after because you said, you know, the C2 infrastructure is down, the domain doesn't even resolve anymore. But um that doesn't mean that you didn't just have malware running your machine, right? Like, yeah, it didn't it can't talk. And I can't remember the order of execution here, but I think this is the XFIL stage. So like, you know, it still ran on your machine, right? Which is not good. Um, it just didn't X fill to TW-Club or whatever the hell it is of the URL. So um I guess the point I'm trying to make is that the malware still ran. Yeah.

Jenn Gile 7:44

Yeah, that's fair. Uh the malware can still run, it's just whether or not the X fill is out there. So I'm sharing uh the blog in case anybody wants to check it out uh over on Aikidos. But yeah, again, this is not like an emergency here, it's just an interesting thing that happened. So flipping over to the conference, um uh been pleasantly surprised uh to meet people who are familiar with the platform, who've seen us uh around the uh interweb universe. So uh Underground Economy is a CTIs that's cyber threat intelligence and threat hunting conference. So these are the more forward-hunting, looking at what's out there. We're meeting a lot of people who are in law enforcement, who work for nation-state certs, um, but also lots of people who are doing incident response, SOC, a huge range of people. Um, it's a fairly small conference, 700 or so people. Um, but we went ahead and uh took down some of the questions, top questions that we've gotten from this group this week, because it kind of gives you a little bit of a like a look into uh the questions that this group has about malicious open source and what we're doing and these threat actors. Um so yeah, that's what we thought would be kind of interesting to share for the rest of the episode. Since, again, fortunately, it's been a quiet news cycle. So, in uh, and I guess I should say we gave a talk yesterday on Paul and Rider. That was our um, you know, privilege to be here for that. So we were educating the community about uh DPRK attacking developers. Uh, this is an area that this community is not as familiar with, so it was a really great opportunity for us. Okay. Um, let's see here. In no particular order, uh, we had somebody ask us if um we're seeing evidence of collaboration between uh North Korean and Russian state threat actors. And I thought that was an interesting question. Um, the way that the person phrased it was, you know, because these are countries that are already collaborating on different levels, you know, are they collaborating in the software supply chain attack space? Um short answer, no, we're not seeing any evidence. Um, Paul, maybe you want to talk a bit more on the long answer of why you think it's probably not happening.

Paul McCarty 10:12

Yeah, I mean, I think I think that there are definitely North Korean, you know, DPRK um hackers in Russia. That's you know pretty clear, and and same thing for China. And then also, too, unfortunately, some of those other countries in Southeastern Asia, Cambodia and Thailand, um, as I understand it. And maybe and probably others, who knows? Um but uh and I heard I think you and I heard recently also some African um countries too as well. But I think aside from the fact that they would be operating from those other jurisdictions, um, I don't think there's any real collaboration because I think we have to understand the intent of what North Korea in particular is doing, which is they're they're keeping the country afloat, right? They are they are generating income revenue by stealing crypto and other stuff. And so it doesn't make a lot of sense for them to be collaborating with Russia, like the state or something, because it's not like an espionage kind of context. It's a we need to make as much money as possible. So why in God's name would we know?

Jenn Gile 11:16

Why would you share that?

Paul McCarty 11:17

Yeah, yeah, exactly. And on the other, on the flip side, um, you know, from a Russian criminal actor perspective, they're in the same kind of boat. Do they do the same thing? No, but you know, they're in the same kind of boat, you know, my precious, precious. They're trying to keep all that that loot to themselves. So I don't see that there's like a and and because we don't see a lot of espionage, um, you know, software supply chain attacks coming out of a DPRK, um, I don't think they're they're driven by that need to collaborate with other state actors. That having been said, I think that there in other ways there is some areas where they are maybe the collaboration is not the right word, but like kind of overlapping in terms of tradecraft and like shared resources and maybe like infrastructure. But other than that, nah.

Jenn Gile 12:03

Yeah. Um, so a related question that I got before the event from a fellow attendee is um, are we seeing malware specifically targeting, and I'll just say country X because I don't think it matters which country. Uh so you know, in general, the question is, you know, are we seeing targeted malware that's going after a specific country or region? And um, what we've historically said and remains true is no, we actually we don't tend to see that pattern um in the way that you might see it with like a phishing campaign or like we see this a lot with like the the ad uh you know, malware ad campaigns and things like that, but those are very regional. Um, with software supply chain security, they tend to target technologies. And it may be that certain technologies are used in certain regions and there could be, you know, connections with that. But for example, what we see a lot of is whatever the latest hot tech is. And when I say latest hot tech, I don't mean like, I don't know, the new iPhone, but um, you know, whatever new uh software uh open source ecosystem people are developing in, um, that tends to be where the threat actors go. And that's for two reasons. One is there's not a lot of history in those ecosystems. So everything looks bad. You know, it's not like a more established ecosystem where you might, I don't mean everything looks bad, but you're not looking for like, oh, this package is five years old or you know, something like that. Like it's just they don't have that, it's all new, so it's a lot easier to fit in. Um, the other reason that they do it is there's a lot of people like going to that ecosystem who may not have the skills necessary to like uh consume open source safely. And so it's just like a really great opportunity for them. So we tend to see a lot of that. Um obviously we see a lot of that specific to crypto and web three because the overlap here is it's usually financial motivation. Uh, we're not seeing a lot of nation-state on nation state attacks necessarily. Um, Paul, you said that there's some examples that you can think of that might like skew a little bit more regionally based on development habits, maybe.

Paul McCarty 14:37

Yeah, for sure. I think it's it's not even development habits so much as like things that are specific to an ecosystem. So, for example, the WhatsApp payment stuff that's huge. And so basically in Southeastern Asia, there's just a ton of emphasis in software supply chain attacks on um uh basically uh overriding or uh uh it's it's complex, but basically what the bad guys are doing in in Southeastern Asia is they're targeting other people in Southeastern Asia to make them send their payments to the wrong WhatsApp address. Um and so they have like the there's all these Bailey's um copycats, um, which is a which is a WhatsApp logging um library. But that's because in that area they use WhatsApp payments a lot, right? And they found this set of hacks and this kind of methodology and this workflow that works there. It doesn't work really well outside of that target area, and then I can think of a bunch of other different examples in different parts of the world too as well. And even back to what you were saying about the marketing stuff, the reason they target, for example, US is because the consumer trend is there, the consumer ability that so basically you're not gonna target a poor country for marketing spend in those areas, instead, you're gonna target you know wealthy countries that are used to buying that way. And so I think it's driven to your point later, I think it's driven by the audience um and the context of that audience that you're trying to target to. Um, and there's a bunch of you know, there's a bunch of kind of regional versions of that all over, much of it having to do with payments. So there you go.

Jenn Gile 16:16

There you go. Yeah. Uh okay. Kind of moving uh laterally a little bit. So we were talking, of course, about DPRK yesterday. Um, had a question after the session. Um well, let me rewind a little bit. I think that there is still, and it's interesting because we're in Europe. Uh, Americans are not in the majority of attendees here at this conference. There's lots of Europeans, there's lots of people from everywhere. And I'm seeing a little bit of the same bias that we see in the United States of like, it's a little hard to believe that North Korea is capable of this. So that's my setup. So the question that I was asked was are they able to do this because of AI? And um I under that's why I say the the setup first, because that question is coming from an assumption that they're not sophisticated, that they're not experienced in this area. And so um I won't say that they're not using AI, but we our opinion, and I want to be clear, it's our opinion, is they don't need it in the way that some of the less mature threat actors absolutely do, you know, like what we saw with Team PCP. We know on one hand, they were being mentored by a more experienced person, but they were also very clearly using some AI with their development. For sure. Um, we see more of a pattern with the North Korean malware of what you would expect from an experienced developer, you know, leveraging AI tools in their development processes. So, yeah, sure, they're using it, but it's not like it's closing an experience gap in the way that it is with other threat actors.

Paul McCarty 17:59

Yeah, it's all true. I think that that observation of that question uh, you know, really kind of accentuates the ignorance of the the person asking that. And that sounds harsh, but my point is that them not understanding that North Korea is the heaviest hitter in the software supply chain space by by a couple of miles, right? Like this is and so and they just don't know that, right? Like the the reality is that a lot of people we talked to didn't realize that North Korea is paying for its ballistic missile program and it's other and its military buildup, it's not just the missile program, it's military buildup with money they've stolen from Contagious Interview, more than two billion dollars last year. They just people didn't know that. And I think that when they do know that, that suddenly it kind of like they're they go out of one dimension into a parallel dimension where now that they know that they realize, oh shoot, I almost messed up. Um Oceanikes, um uh you know, they're actually a heavy hitter, they're they're a mature um uh you know player in that space, North Korea is, you know. Um so yeah, I mean, I guess that's all to say that you know it's just I guess we know it and that person just didn't know it, but now they do.

Jenn Gile 19:15

Yeah. Well, uh, I think um, let's see here. I'm looking through my notes of some of the interesting things that we discussed with people over the last couple of days. Um one of the topics we discussed in our session, and actually was discussed in one that we watched previously on IT workers, um, was the ability to manipulate uh GitHub's data, your Git data, around um when commits were pushed, who pushed them, what was pushed, all that kind of thing. Um it was relevant in the IT worker one for kind of separate reasons from the reason it's relevant for Pollenwriter in that um the threat actor malware is able to um infect your GitHub and force push these commits that have no uh, I was gonna say paper trail, uh bit trail, whatever it is, when you look in the GitHub website, like if you're in the web UI, you're not gonna see any evidence. And you know, the question came up, um, and this is kind of like a twofold question like why does GitHub allow you to do this? Why can you completely uh fabricate your Git history? Because you know, you can use these techniques to make your GitHub account look older than it is, you can use it to make it look more active than it is, you can use it to hide commits, you can use it to make it look like commits happened that didn't. So, like let's talk about why we think GitHub made this choice, however many years ago that they made it, because they didn't make this choice thinking, oh, let's make it super easy for people to commit fraud. They had a legitimate reason and whether we think this choice should still be something that's possible right now.

Paul McCarty 21:14

Well, I mean, I think that if we continue to use Git, and I feel like the whole world is kind of landed on Git, we're kind of stuck. So the problem is git. The problem, well, that's not true. The problem is git, and then the fact that all right, so let me take a step back and I'll say the things that I said yesterday in other places, which is that commit history happens on the local workstation. So as you're changing code and you get uh and you get commit and you store those commits up, and at some point then you then push to uh remote, right? And the that when it's remote and it's GitHub, or by the way, GitLab and everybody else does the same thing, they just accept the history that that is sent with that git push. And So if there's 20 or 30 or 200 commits that are all kind of rolled up in that one push, you know, they just trust that. And I think the problem is that when people go to GitHub and they look in GitHub at a particular set of files in a repo and they see those timestamps, they think those things are being you know originated or the origin of them is from GitHub and it's not, it's from Git itself. And Git was designed in a time, a long time ago, before you know authentication for for you know this kind of stuff was built into it. So Git itself doesn't have any authentication whatsoever. You set up when you config it up, it asks you what's your email, what's your username, and that's it. And so when you push to Git GitHub using GitHub credentials, it still takes that username from that commit and adds it. So even though it's my credential, it looks like it's Linus Torvald's in in GitHub. So um and now GitHub has made a few things like now about well, not really. I was about to say they did some things about being able to see those big personas, but they haven't. And this is the reason that signed commits are.

Jenn Gile 23:09

Well, they've talked about I was literally just gonna say that signing your commits is it's it's more like we can't change this behavior, but if we start to opt into some things like signing commits, at least it becomes easier for you to be like, oh, well, that commit's not signed, so it must not be legitimate. So it's a little like it's kind of tough because it means you're looking for the absence of something to indicate that it's bad instead of the existence of something. Um but yeah, I think this does come back a bit to understanding how code is written, that it's written locally on the developer machine, then it's pushed to the cloud via GitHub, you know, GitHub being the cloud. And then from there it's pushed out to, you know, whatever distribution channels, NPM, et cetera. And so understanding that there's this multi-stage process of things linked together, and it's not all one program, it's not all one, you know, you're not just like logged into, you don't have to be connected to the internet to write code, I guess is the the net of this, right?

unknown 24:13

Right.

Paul McCarty 24:13

Yeah, and GitHub wasn't GitHub wasn't designed with any of that authentication stuff in in it. So it's you know, we've added this later. Anyhow, go ahead.

Jenn Gile 24:21

Well, since we're picking on GitHub, uh the next question that I got, uh this very nice gentleman from Italy came up and you know, lovely presentation, super interesting, but like couldn't GitHub just stop this? Uh meaning, couldn't GitHub stop the spread of Pollenwriter uh in GitHub repositories? And this is this is a tough one because I think our opinion, Paul, is yeah, they could. Um, you know, we're looking for signals. Um, you know, we literally just concluded another hunt. I was looking at the data. We have over 9,000 confirmed compromised repositories in our database that were compromised by Pollenwriter. And, you know, you did this as well as we've gotten some contributions. You know, all you got to do is look and you find thousands of them. And so, yeah, I mean, could GitHub be doing what we're doing and either proactively, you know, prevent certain signatures, like if they see a certain signature, say, whoa, whoa, whoa, you gotta stop. Um, or could they be uh retroactively, you know, scanning for these and do something? Yeah, there's no reason they couldn't do it. Um, but it's kind of not their business model, and that's the reality. It's not their business model, and it's not how their security team is staffed and empowered to uh respond. I don't know. Do you have a spicier take than I do?

Paul McCarty 25:58

Well, I don't know, maybe, maybe this time no, but um, I mean, I guess they make such a big deal of some of these things they do, right? And it's like it's kind of it kind of seems like, you know, I don't know, a used car salesman that says, you know, oh, you know, we've put tires on the car, and but then you know, it's like falling. I don't know, it's not a very good metaphor. I didn't really think it through it.

Jenn Gile 26:23

Maybe it's more like uh we put some ground effects and gold rims on, but like you need a new new set of the rubber is like worn down on your tires.

Paul McCarty 26:31

It's still a 91 accord. Yeah, it's still a 91 accord, right?

Jenn Gile 26:35

Yeah.

Paul McCarty 26:36

I I uh all right, so getting back to the question, the heart of it. Listen, I mean, the scale of one a project I did years ago, I don't know if I've ever even shared this with you, Jen, is that I sat there and just watched the API event API for like months to identify how many um GitHub users are created per minute and how many um repos are pushed per minute. And the answer is you know, it's in the hundreds and thousands relatively. Um so just there's a lot of volume, is what I'm saying. But they haven't been said, going back to what Charlie said about you know the NPM and the Shy Halud, mini Chai Halud stuff, that it's a known hash, everybody and their brothers got their hash. In the same way, the way that I'm finding GitHub. Here we go. Let me get let's get intimate here. Hey, GitHub. The way I'm finding these North Korean malicious packages is I use uh a known detection string, which we and everybody else and their brother is you know has put out there, which is the RMCE and you know, one that Jen and I have seen eight bazillion times. There's a bunch of us, but yeah. I just search in your platform, GitHub, and I find malicious stuff. And I suspect you could be doing the same thing. So maybe that's something you could do sooner rather than the later. Um, I I just I'm I'm at the point now where I'm just so frustrated. They make a big deal about these things that they should have done 10 years ago, right? And they are so behind the times. Man, I feel like I just want to unload. I like maybe I'll save this up for next week and I'll just like here's why GitHub sucks. But I mean, I love GitHub. I'm I'm logged into GitHub 8,000 times right now. I'm wearing a GitHub shirt and hat today, but like at the same time, I think the coffee's kicking it in. Yeah, at the same time, I think at the same time, GitHub is so poorly covering and managing its security that it's really now gotten to the point where I mean it's almost criminal. I mean, I want to say it's criminal, but it's almost criminal, it's that bad. So, like maybe just look for the same signatures I'm I have a GitHub repo, a public GitHub repo repo GitHub that you can use to find this in your own platform. All right, end of rant.

Jenn Gile 28:52

End of rant. Okay, I am gonna rant a little bit, and then we actually do have a question over on our LinkedIn that I'm gonna pop up. Uh so the end of rant is we were talking maybe two weeks ago about a developer who has been uh compromised and recompromised um over the last six months. And we've been trying to get a hold of him. Uh I opened up our you know shared mailbox this morning and saw the bounced back email. So I mean, it's it's the community is trying to do the right thing by opening issues, by trying to connect with these people on LinkedIn, by trying to email them, you know, contact them through whatever means possible. But as third parties, it's really hard for us. You know, if if their email is no good, if they're not paying attention to their issues, you know, we can't, it's really hard for us to do anything about it. Uh GitHub has these people's contact information, could get a hold of them and could say, Hey, you're you're pwned.

unknown 29:50

Okay.

Paul McCarty 29:50

Well, and they could they could take the repo down too as well. They could just take it down.

Jenn Gile 29:53

There's a lot of things they could do. Yeah.

Paul McCarty 29:55

Yeah, 100%.

Jenn Gile 29:56

I don't know that I advocate for taking it down because you could break a lot of stuff, but yeah, we could argue that like okay. So it does have malware in it. Uh so we have some comments over in the um LinkedIn event. So Mark has joined us. He's left a couple uh comments. Hey, Mark, happy, happy to have our audience here. So um back on the the comment that we made a little bit ago, he says, Why do you think people still believe that North Korea is not a competent state actor? The supply chack chain attack used by them surprised me after my return to hunting them. Uh I'm gonna say that here, you're gonna get my spicy side. I think there's this this is xenophobia and uh bias at play. You know, we've been making fun of North Korea as a planet for a while. And um, you know, there's just a lot of like cultural narrative that they're incompetent, that they're run by a despot who doesn't know what he's doing. Like I honestly, I just think that it's groupthink um that has allowed them to be so successful. I think their success is in large part because people don't take them seriously. If they were China or Russia or Iran, there would be task force pointed at it. Um, but you know, you have uh stunts by people like Dennis Rodman going there. You know, you have our president um talking about, you know, thinking that they're great, like it no one takes them seriously uh for other things. So why would you take them seriously for cybercrime? That's my my thought of why it's just so hard for people to believe that they're as sophisticated as they are.

Paul McCarty 31:45

I I think there's a couple other things too that are important. I I agree with everything you just said, like genuinely. I'm not like I totally agree with that. I think it's definitely um group think, but here's here's some other kind of contributing factor. And Mark, that's a really good question. Um, and I wish it wasn't like this. But the other thing is that North Korea does not do ransomware, and the whole enterprise, I'm I get every time I go to one of these conferences.

Jenn Gile 32:06

That's fair, yeah.

Paul McCarty 32:07

Um every time I go to one of these conferences, and I've been going to these conferences for a long time. Every time I go to one of these conferences, I'm reminded that the enterprise security architect only cares about ransomware. They don't even really care about info stealers. It's bizarre, like they are singularly. That's why they think that EDR fixes everything, right? Because EDR has an answer for uh ransomware because you know EDR can see that a number of files are being encrypted and they go, oh look, that's bad. Let me stop it after 10 or 15 or whatever. But like part of it is that they don't do ransomware. There's a couple other things, too, as well. Uh the first of which is that the the types of attacks that we are concerned with at open source malware, software supply chain attacks, don't really get a lot of visibility for the enterprise security architect type person, like sec ops person, right? And this is you know driven home again every time we go to one of these conferences. So I think between those things, there's just not a lot of visibility and understanding of it. And here's the thing, too, is that North Korea now has somewhere between 60 and 100 nuclear missiles. Like that's roughly the equivalent of uh Israel. And so they are a nuclear power, um, you know, and this has happened on our watch. Um, and they've done it with money that they stole. So um the, you know, it if you're not taking them serious, then that's kind of on you for you know not looking around, right? It's like if I'm only looking in the ground, I miss the fact there's a pterodactyl about to pick me up and eat me.

Jenn Gile 33:40

Well, I would say I agree with you on the comment about the type of attack certainly is not what um people are more likely to be paying attention to. Um okay, another comment from Mark. Um curious uh liability and provide privacy business, fear by GitHub. Uh he says he's just playing devil's advocate. He's aligned to your viewpoint. Um yeah, I mean, if GitHub said that they were gonna take responsibility for preventing malware and then they didn't, yeah, there could be some liability there that they're concerned about. You and I have talked about this before, Paul, that if you uh don't make a claim that your platform is secure, then it's a lot harder to sue you if your platform's not secure or if bad things happen to you in that space. So yeah, I I think it's a nuanced problem. And there are probably, in addition to like staffing reasons, there's probably a lot of reasons that Microsoft has made the decision not to um be more restrictive on GitHub. I don't personally know a lot about GitLab, but I know they have a very different business model. Um, you know, it's not this massive number of free accounts. And so you might like look at what do other SCMs do that's different. And, you know, because they've chosen to be more enterprise, perhaps they have different policies as a result. You know, when you have mostly a large free user base, it's different. Paul, of course, you're more familiar familiar with GitLab than I am.

Paul McCarty 35:25

Yeah, I would say, listen, I, you know, I have my, you know, I'm not certainly I'm gonna skip that part. Um GitLab has basically they've got they they have um hired and built out a better security apparatus and they take it more seriously. That's what it comes down to. They take security more seriously and they build it in. They're much more responsive. Are they perfect? No, of course not. But um, you know, they had a significant SecOp and Red Team and just had built for a small much smaller company, they had built out a security apparatus and and showed the world, at least to the way I see it, showed the world that hey, we take this seriously. GitHub doesn't do that seriously. Like there's like you know, most of the people, security people that are there that well were there are gone. Um, they've outsourced, you know, I know we've said this before, but they've outsourced sourced a lot of the things. I currently have in multiple, multiple tickets for things that are malicious, and it's taking ever longer to get those things taken off of either npm or github. So you know, maybe this is just another opportunity for me to kick GitHub, but I mean they're just that you know, oh, oh, and what I was gonna say to Mark's question, liability. I think that um here's the thing is that that plank has already been broken, right? That that horse is already bulked. So they they they've already said they're scanning for malware, they've already done a number of other things, it's just not effective, right? And so I don't think they can make the argument anymore that oh you hands-off approach, so we're not liable for it. No, they know they're liable for it, and yet I see more like malware and stealers hosted on GitHub now than I've ever seen before, all right. So, you know, whatever they're doing is not working, so yeah.

Jenn Gile 37:12

Okay, two more questions, and then uh we're going longer than we thought we would. So uh good job, us, I guess. Um so I uh also had uh someone who was like genuinely like, what can we do about this problem? What can we do about developers um consuming you know poisoned GitHub, you know, forks, uh poisoned NPM packages? What can we do to help them? And um their suggestion is can't we just give them Yara detection rules that would look for the same things that we're threat hunting for? And um I say that with a smile because it's it's so well-intentioned. Um but uh unrealistic in terms of how developers work. And so, Paul, again, you have more experience with YAR rules than I do. So, like in a balanced way, how would you explain why like much in you know some of the other ideas that can come out of the SecOps side that just won't work for the the engineering side, why would you say YARA rules for developers is not the solution?

Paul McCarty 38:25

I mean, there's a whole bunch of reasons. Like, and are are YAR rules you know uh effective to some degree for software supply chain uh malware? Yeah, for sure. Like a bunch of our competitors you know use them, and that's how they and and when you read their you know the descriptions of not our competitors, but people that are you know finding malicious packages, and you when you read their descriptions, clearly it come from a yar rule. But I mean first using YAR rules kind of skips the fact, kind of uh blight blaze the the point that they don't understand how the bad thing gets to you. So like it's it's a dependency named in a package manifest. And so for your YAR rule to work, you'd have to have something that's kind of the equivalent of software composition analysis that pulls each one of those things, runs a yar rule against it, pulls all their dependencies, runs a yar rule again, pulls all their dependencies, and so on and so forth. And right, and it's just so you know, effectively it's you know from that perspective, that's not the right tool for the right job. And then that's the important thing to know about Yara. YAR is great and you know, and I'm glad if you're using it. But then the other thing is that YAR only works if there are signatures and rejects that you can look for. And the reality is that like DPRK is a great example of this. You know, these campaign markers that they use are ever changing because they're creating new special snowflakes, but each one of their things is a special kind of unique way of building it. And it's different from the last one. So, you know, being able to find those things that you can, you know, the YAR rules will actually be able to find and parse out just don't exist. Um and they're getting better, their obfuscation is getting a lot better. Um, so you know, being able to pull anything discernible out of it is hard. So Yara is not the right tool for this. Um certainly getting it.

Jenn Gile 40:22

So let's talk about what is the right tool and then wrap up from there. Um so as you and I have talked about for the last few months, this campaign in particular targets individual developers. And in general, you know, when somebody's consuming a compromised asset, it's an individual making that choice. It's not a company has made the choice. Um, and so I think like let's set aside things like package firewalls and uh registries, because that's just not realistic for a lot of people. Um, the first thing that I would do if I were taking a look at a repo fork or a package to download is I would look for the presence of a VS Code folder in uh in the GitHub. And I would look for a task JSON file. That's the first thing I would do. Um, because you know, there's a lot of a lot of indicators you could be searching for, but you can like low-hanging fruit, it takes me two seconds of looking to see, oh, there's a task.json file that's saying I'm gonna auto-run. Oh, it's gonna auto-run, you know, this file right here. Like that's a concern. Um so you know, what we've talked about is the reason VS Code is such a nice attack vector, uh, or rather auto-install your malware uh feature for threat actors is because developers don't look at the task.json file. And so I would say, look at that file, see what it does. Um there's lots of other things you can and probably should be doing, but that's that's what I would say.

Paul McCarty 41:59

Yeah, also look for the the VA400 solid.waf2 file.

Jenn Gile 42:05

Look for fonts. And I'm gonna say like fonts that are not fonts. Um we're seeing uh two types of uh delivery mechanisms. One is this fake font thing that started at the end of 2025, and the other is um poisoned config files. Uh the fake font one candidly is pretty easy spot. The poison config files are harder because it's not just one or two files that they're going after. It's like anything that's a config.js or TS or .mjs. Like it's such a huge breadth of config files. So like scanning those config files for obfuscated JavaScript would be the other top tip.

Paul McCarty 42:50

Yeah, well, 100%. Um and and they're now going after not just the config files. Now they're dropping on app.js and database.js and all kinds of other stuff. So they I mean, really now you're they're making it real hard. Yeah, they're making it hard. So basically any dots, dot js, dot wof2, and dot cjs, dot mjs, um, and there's actually several more too as well. Yeah, even they're even dropping it on on um certain other um like YAML files and stuff like that, that if they have a command string. But the point is that you know it's hard to find this stuff, um, and it's ever changing. Um, and that's just not the kind of thing that a YARA rule is built to look for. So YARA's part of the solution for sure. Um but also understanding what the thing does. And and Yara doesn't help you, for example, if you're pulling a dynamic dependency, right? And this is something that as people move away from as bad guys move away from lifestyle, lifecycle scripts, pre- and post-install scripts, they're gonna start focusing on how to bring something into the to the package dynamically. Um, and and that's you know, YARD is gonna have a really hard time touching that.

Jenn Gile 43:59

So yeah. Uh let's see. Is there anything else we need to cover? There's so much. Oh, you know what? The whole reason that um the question about AI came up was because in many cases it helps threat actors uh translate their malware for other ecosystems. The super interesting thing to understand about Pollenwriter is it's all JavaScript. They'll put it anywhere. And um, you know, I was looking at uh a developer's repositories two days ago as we were preparing for this talk. We had somebody reported a Go package or a Go module that had been uh compromised. So I went upstream and I was like, oh, interesting. Almost all of this guy's stuff is C sharp. I wonder like if he's still gonna be compromised. And sure enough, it was in his C sharp repos. It was in uh, he had some other languages that were not, you know, JavaScript TypeScript, et cetera. So I guess the thing to understand is you're not safe just because you're not a JavaScript shop. Uh it is it's a it's great. It's great if that's your your MO.

Paul McCarty 45:09

That's a great point. And I just want to really quickly drill in a little bit more just so people that are listening understand what's happening. So your language the repo can be any language you want. And what they're doing is they're dropping in a VS Code task file, which is gonna auto-run on folder open and do all that stuff. And then they're dropping in a malicious JavaScript payload that gets run by the task file. So it doesn't matter whether the rest of it's PHP or C sharp or whatever the hell it is. As soon as you open that up in VS Code, it's gonna run that task file, it's gonna run the malicious payload, which is a JavaScript, and you're done. Um, so yeah, it's it's a good point to bring up.

Jenn Gile 45:45

Uh and I want to end on just one thing uh in the comments here. I like to treat dev's security uh offset consultants development pipelines as an enterprise threat, not as a traditional enterprise security problem. Uh I don't I actually don't completely disagree uh because Holland Writer basically does turn your developer into an insider threat. They have no idea.

Paul McCarty 46:11

All right, here we go. You ready for this? Instead of zero trust, zero dev trust. Oh, we're gonna break some parts here.

Jenn Gile 46:19

Okay, why don't we wrap it up? We've gone way over our normal time. I think we're gonna do that. I'm a dev, I'm a dev, by the way. We're extra caffeinated today. Um, and so let's end on that. Um, we'll be back at uh regular bat time jet bat channel next week. Uh and yeah, it's been fun.

Paul McCarty 46:37

Say love.