Jenn Gile 0:01

Oh all right. Uh good afternoon from the West Coast. The sun came out. It was foggy the last couple of days, but it's finally warmed up. It is May 7th. We're enjoying a beautiful spring. Uh Paul, you're flopped. You got the other set of seasons. How is it down under?

Paul McCarty 0:19

Yeah, it actually is cold here on the Gold Coast today. So I actually have the heater on, which 99% of the time is AC, but today it's it's in heat mode. And I've got my new office warming up with the uh the space heater in there.

Jenn Gile 0:31

So exciting.

Paul McCarty 0:33

Exciting. I'll send you a picture later.

Jenn Gile 0:34

Can't wait to see it. Uh so welcome everyone. Uh this is our third installment of the open source malware show. We're gonna do some quick hits on the news and then we're gonna jump in uh deep on uh talking about interpreted language malware. So let's hit first on some research, Paul, that you released earlier this week on uh North Korea's Lazarus group, getting creative with their uh kind of like contagious interview task jacker campaign. Um they have shifted from using VS Code files, which I was just doing some writing about earlier today. They're using a task.json file to uh load malware to now it's in git hooks. Uh even worse.

Paul McCarty 1:21

Yeah, well, it's actually both, right? Because it uses its initial loader, is still the VS Code tasks file. They have a cursor version of it too as well, and you know, affects anything that uses VS Code, which is windsurf and cursor. But um, so the initial loader is still in the task.json file, but it it just calls these two concatenated git commands. And um there's two versions of it that I've seen so far in the wild. There's the pre-commit version of it, which we talked about in our um in our blog post. I didn't have as much time to go into the post-checkout commit, but that's really smart because post-checkout is a git hook that most people never call. It basically runs after you check out a new branch or check out, excuse me, check out a branch. So what they do is they um they uh concatenate these two git commands so that the last thing it does is it then checks out a development branch, and then boom, it runs itself. Like it's beautiful. And just to circle back, why they're doing this is because it became really obvious for us and some of our you know, some of the researchers in OSM to find these URL strings um uh in the task file. And so now these are just git commit, sorry, these are just git uh commands, which looks much more normal um until you go and look at what that git hook does. And then it calls the URL or uses a shortener. There's several variations there, but yeah, it's it's smart, and it's funny too because at SecTalks, uh, which is a meetup I run here on the Gold Coast, it's an Australian security meetup. I know I'm running long. Um, somebody asked, Have you ever seen anybody hide stuff in Git hooks? And and I said, Oh, it's been a while, you know. It's honestly been five or six years since I've seen it in a while. But here we go, boom, DPRK is doing it.

Jenn Gile 3:13

Yeah, and you know, uh we saw uh uh borrowing recently of um team PCP borrowing some of Lazarus Group's uh techniques for the mini shy blue campaign. So it's only a matter of time before this technique jumps from these, you know, like developer interview focused attacks to you know an account takeover or something like that.

Paul McCarty 3:39

Yeah, uh DPRK has really doubled down on this like force git commit function, which is great because then they could just keep doing these force commits again and again and again and just changes the payload, right? Well, we saw Glassworm, which is Russian, doing that in late February or early March. So this tradecraft, coupled with the fact that AI is just able to go out there and see these things, then bring it in and then concoct these things. And by the way, the bad guys aren't going, hey Claude, write me up an exploit for Blah. They say, you know, do this, and they describe the functions they want it to do and put a git hook inside of a task.json file bot or whatever. It's just it's really is a it's a it's a perfect storm of those two things coming together.

Jenn Gile 4:19

Whole new world. All right, let's move on to the Antria project compromise. Are you gonna sing? Uh yes, I am the uh Antria project compromise. So this is a popular Kubernetes dependency. Um, this is a little bit of a good news story. Um, and the good news story being uh while the project was compromised, uh there's no mallearning yet. And so that is the good news. Good news, bad news. The bad news side is um, you know, your investigation has traced it back to the trivi compromise. Um you know, they in all probability, uh, you know, got their stuff exfiltrated during the time because we've got some evidence that they were uh using the poisoned version. And this kind of just goes to show threat actors don't always act immediately on the credentials that they get. Um, just because you don't immediately get pop doesn't mean it's not gonna happen. And uh just assume credentials are you know compromised if if you're in a compromise situation. Um so you've been keeping an eye on this, you've been reaching out to the maintainers. What's the update?

Paul McCarty 5:36

Yeah, the update is that the lead maintainer reached out to me and said they were not done in Trivi. I don't I'm I think I might politely disagree based on some evidence that I saw that I can't go into, but um, because it involves a vendor and I haven't gotten them checked off and blah blah blah. But um uh in addition to that, there are some other kind of discrepancies where um you know the the threat actor claims, claims in a public get commit comment, uh PR comment, claims to have trashed their their um EC2 instances. Um it turns out that um uh the the maintainer says that's not the case, they shut them down themselves. So listen, we're never gonna get the it's a he says, she said kind of thing. We're never gonna get to the the he said, he said, he said kind of thing. We're never gonna get to the bottom of it. But the reality is that we've gotten pretty good now at tracking these um threat actors. Um we like to talk about this, like you know, we want to see the threat actors before they make the bomb, we want to see them making the precursors to the bomb. And there's a bunch of different ways we do that at OSM and how I've been doing it as an independent researcher. But basically, that's one of the things that we do here, and we did it with the Pond Rider user too as well. Um, watching the different projects that they're interacting with, and that gives us a heads up. We can then reach out to those projects, which I've been doing and and going from there. And in this case, so far, it's a good also, too. I do not think this is a team PCP. There uh I think it might be somebody on the periphery, um, somebody that I trust um suggested that they think they might be involved in some way with team PCP, but want to be on kind of the the outside edge.

Jenn Gile 7:13

Because it oh, and it's a bit of a loose, you know, a setup affiliation. So yeah, okay. Let's move on to yeah, cool.

Paul McCarty 7:19

All right, keeping me the time. Good job.

Jenn Gile 7:21

Quick hits, quick hits. Uh so uh the next one on the list that you dropped uh right before we started. So I haven't researched this at all. You're gonna have to teach me here is something called dirty frag. And your your description here is uh uh takes copy fail and says hold my beer.

Paul McCarty 7:39

Yeah, so I just got I got a heads up from this from from Jaden, one of my friends in um and uh a long time listener. Um uh I know I don't put a lot of time into these things because I don't build I don't red team anymore, and so I don't build you know exploits anymore for for red team stuff, but this just screams out you know, red team exploit, like it's just so sexy. It chains together two Linux. And here's the thing is this is a universal Linux bug. In other words, it runs on most or all distributions because what it relies on are libraries and functions that are pre-existing in all the major distributions, and so in this case, um, the author um tied together two um volumes in a chain um for just a super sexy, short, powerful local privilege escalation um uh bug. And and it's it's sweet. Like I was just in the process, I was trying to get it running right. It's really easy to run. So I just was trying to spin up a VPS and blah blah blah before this, but I didn't get a chance to do that. But I saw some some video. They just dropped this like two hours ago, and unfortunately, the embargo has been broken because like a third-party researcher saw like the change log or something. I haven't I haven't gotten all these details because it's like only two two hours old, but saw that and has published. And so now, unfortunately, the embargo has been broken. So this is out there in the wild. Bad guys are gonna start taking the C code and working with it using our friends Claude and Codec. So here we go.

Jenn Gile 9:02

Buckle up. Okay, last quick hit. Uh so uh cPanel is having a moment, uh, not a great moment. So there's um some uh actively exploited bug that's exposing uh, according to the internet, millions of websites. Uh, you know, this is a little bit outside the malware wheelhouse, but what we do know uh is sometimes vulnerabilities lead to malware. So what do you want to say about cPanel?

Paul McCarty 9:34

Well, I mean, cPanel is used by most of the the the low-end um, you know, CMS WordPress and you know, Magento and and what have you, Drupal. Um so one, there is a there is a relationship between these things. So, for example, you know, bad guys have been using vulnerabilities in WordPress for years to upload malware, you know, specifically JavaScript, that then runs client-side and does the bad thing, right? An overlay or whatever the case may be. But um in this case, um, I think we're not hearing a lot about it from the InfoSec Press because it's not really affecting enterprises that much. I have it is unfortunately in some local government that I'm aware of. Um, but the reason why is let's be clear, is because cPanel is typically used in those kind of lower end VPS hosting environments, and that means SMB, small shops, right?

Jenn Gile 10:21

So yeah, and I mean I was just talking about this with Dwayne this morning on a Git Guardian webinar. Uh you know, the security poverty line concept. These are shops that probably are below the security poverty line, don't have the staff to uh you know investigate, secure, manage, et cetera. So it's kind of the worst uh possible scenario, right?

Paul McCarty 10:46

It is. And uh from an incident response perspective, we might not be hearing about it in InfoSec Press, but every incident responder I know, especially that deals with the smaller end of town, um, is reaching out to me saying they are hammered right now. This is a huge issue, super easy to exploit. Bad guys are all over it, and we've got bad guys in all kinds of different geolocations using this, right? You got south the Southeastern Asian crews, you know, the Russians, like everybody is using this because it's just so easy and it's just so popular. Um, so I just want I mostly wanted to put this on the run sheet today, just to give a shout out to those, you know, you might not be hearing about this that much, but I I understand it's a big deal. We understand it's a big deal, and our hearts go out to you if you're doing incident response right now.

Jenn Gile 11:31

Yeah, rough, rough time. Um, okay, let's do a quick uh where in the world will Paul and Jen be? Uh, because you and I possibly overcommitted ourselves slightly in the month of May. Um, it's gonna be awesome. So um I'll start next week. Um, I'll be in the Bay Area twice this month. Um, I'm gonna head down next week for a cool um event um called the San Francisco Secure Software and AppSec Summit. And uh that'll be over in Palo Alto. I think it's on the 14th. Yeah, that's next week. What am I gonna be talking about? Um I'm gonna be talking about this is like gonna be 100% full of hot takes. Uh, how should AppSec actually run? Um, I'll be on a panel with uh some very recognizable names and uh lots of audience like opinions here. So I'm looking forward to hearing what people think. Uh at the end of the day, I'm just gonna say uh it really depends on your organization. Like, I don't think anybody can tell you how AppSec should run, but there's probably a lot of things that we can tell you not to do. Um, and then the other event that I'm gonna be doing in May will be toward the end of the month. Uh, Zenity is doing their second AI agent security summit. I didn't make it last year, I heard it was super cool. Uh, so I'm excited to have been invited to speak at this year's event, and I'm gonna be talking about uh malicious AI skills. So, yeah, if you're coming to either of those, come say hi. Paul, you've got like four things.

Paul McCarty 13:09

Oh, yeah. Well, first, I want to circle back to your first one there. That's the clutch event, the first one, right?

Jenn Gile 13:14

Yes, yeah.

Paul McCarty 13:15

So my friend Cole Cornford and Ben Gittens will both be there. Uh CK Tricky, Ken Johnson will be there. I know, all our buddies are gonna be there.

Jenn Gile 13:22

It's too bad you're coming.

Paul McCarty 13:23

I know. I don't know if it's worth a trip over from I'm doing a lot of trips this year, so I'm glad to keep up. But um, I that one sounds like a great one. I I've done a number of the clutch events here in Australia. They do a bunch of them here, and I'm actually doing one in Sydney with them. I'll be on a panel in June um with Cole and the team. But um, yeah, so for me, I I like well and truly overcommitted. Um, so I'm going to Melbourne next week for Melbourne B-sides, which is, you know, I know I run the Gold Coast B-sides, and you know, like that's my local, but Melbourne B-sides, frankly, is probably my favorite B-sides in the world, just because so many of my friends there. I spent a lot of time between 2018 and 2022 going to Melbourne almost every week, and just have a lot of friends there. I have a lot of connections to the InfoSec community and AppSec. There's a really strong kind of AppSec scene there too, as well. But um, all right, so Thursday night I'm speaking at the uh B Sorry, sorry, the AppSec meetup, which is really well attended in Melbourne. Like last time I went there, I spoke there. There was like a hundred people, it's like huge thing. And um, anyhow, it's dope. That's Thursday night. Then Friday, I'm giving an all-day training at Melbourne B sides. Um, the conference starts on Saturday, but they do the day before training. So I'm gonna be doing some of my CI C DIDA CTI stuff, anyhow. Um, and then I'm keynoting on Saturday. Um, and then I'm on a panel with Ricky Burke uh on Sunday, and then I come back to the Gold Coast, and then I forget is it Wednesday or Thursday? But Wednesday or Thursday, I'm speaking at Oz Cert, which is like one of our oldest, longest InfoSec um conferences here in Australia. Happens to be on the Gold Coast, it's in my local hometown locale. Um, and then and then Saturday is Gold Coast.

Jenn Gile 15:13

Oh wait, there's more.

Paul McCarty 15:14

But wait till yeah, so and that's when I have my heart attack. Um so I I will be looking forward to uh uh after the from the 24th going forward when I have a lot less to worry about and be anxious about.

Jenn Gile 15:27

Right on. Okay. Uh I teased it last week. We have time for it this week because thank goodness nothing blew up. Um, I want to talk about interpreted language malware versus compiled language malware. Um, you and I have kind of been fiddling around with a white paper on this for a little while. We haven't gotten it uh over the line because I'm giant. Yeah, I I might have written too much.

Paul McCarty 15:54

This is a fucking world warm piece right up here. Um but it's legit.

Jenn Gile 15:57

It really is. It's it's uh if I were uh going after like a doctorate or something, yeah, maybe this might be some sense.

Paul McCarty 16:05

Um it's pretty technical. Like, so um, it's and that's why I think it's taken us.

Jenn Gile 16:10

It needs to be right, but like let's just talk about uh why we're focused on interpreted language malware, and that's because in malicious open source, most of the time malware is written in JavaScript and Python. And that differs from the malware that you more traditionally see through you know phishing attacks and things like that. Um, and there's several reasons that interpreted languages are chosen. They have specific properties that make it harder to detect. So, you know, we talked about all kinds of other things earlier that um make the malware hard to detect, and that's all sort of outside of you know the interpreted language nature itself. And so uh one is that there's no compilation step. Uh the source code is shipping as the attack artifact. So it's not gonna be discarding variable names, comments, structural intent, that kind of thing. Um, this is at the semantic level. Um import time and dependency context execution is you know a real bypass. Um why don't you talk a bit about that, Paul? We've been kind of discussing the role of post and pre-install skips uh uh scripts, excuse me, which can get you know discovered by a soundbox, but uh what we know about you know a lot of the open source malware that we're seeing is a lot of them have pre-install and post-install scripts. You know, we talked about it last week on the show. Um what are they doing differently in interpreted language that lets, you know, lets those scripts sneak through in a sandbox?

Paul McCarty 18:02

Yeah, I mean, it really boils down to one simple thing, right? Which is that the install scripts allow it to auto-execute. That's what it comes down to. It auto-executes. So just the process of you downloading it and installing it runs the payload. It's like if you were to download the latest malicious binary, and then when it downloads, it automatically also runs. You know, I mean, it's it's effectively the equivalent of that. Um and I think as you point out in the white paper and some of the other stuff we've written about it, is that you know, those scripts are there for a reason. Um, you know, JavaScript in particular, which makes heavy use of these things, um, is used in all kinds of different ways. It's used to do, I build a bunch of my CLI tools in it, and having these install scripts, these lifecycle script scripts in a CLI is really helpful because it does the thing to make the CLI be able to work. You know, JavaScript package.json also has the ability to create a bin, but and which creates a link and an alias. But um I think that the the post-install scripts are there for a reason. It makes it really easy for bad guys to to run their payloads. The Axios um, you know, uh compromise was when it called the plain crypto plane.js file, I had a you know, a post-install script and bada boom, bada bing, you know, it was running um ground on lots and lots of pieces. So there's that, and and then uh but the problem is that we talk a lot about post and pre-install scripts, and those are a huge part of the JavaScript kind of ecosystem. We have similar things in in Python too, as well, with the init and and the way setup runs and a bunch of other things, but it's particularly an issue in JavaScript. But I want to say, like, not all malware, JavaScript malware uses these lifecycle scripts, right? Many of the good things, many of the when I say good, I mean the effective bad ones, right?

Jenn Gile 19:56

Smart ones, yeah.

Paul McCarty 19:58

Yeah, work on import. And you and I have talked a lot about this, right? Um, and it's not just JavaScript. I saw Socket did a found six or seven um NuGet packages that all um were doing what they said on the tin. We're we're doing so people would download, they would install them, and they would run. Well, first they would look at them, they would see, oh yeah, you know, look it's doing what it says it's supposed to. So then they they use them and away they go. Now that's in a different ecosystem, but the point remains that if you can actually do the good thing, then people will won't look, well, you know, won't vet it well enough to see if it's doing a bad thing as well. So the combination of those two things just makes JavaScript particularly painful, but it's it's moving out, bad guys are taking those patterns from JavaScript and moving out to different languages.

Jenn Gile 20:43

So yeah, you know, we've talked about um sandbox evasion quite a bit, you and I. Um, you know, in addition to you know it firing on install uh or on import, you know, they can call out to the OS APIs to detect if they're in a sandbox environment. You've documented some beaver tail variants that are pretty um sophisticated with their concealment, um you know, environmental gating checks, things like that.

Paul McCarty 21:16

Yeah, I mean, by like traditional malware also does that. But I think the difference is the difference is that you know, we have the fact you have to set up an interpretive environment in the sandbox, and then if it's on import, you know, you have to call it in the right way, you have to ask it in the right way to do the bad thing, right? And that happens when you import it into like if it's a a crypto library, when you import it and it goes to do the thing, it you know, it knows how to hand the parameters over to it. But that doesn't happen in the sandbox, the sandbox doesn't have any context around you know how you actually get this on import thing to blow up, to to go boom. And there's all kinds of there's all kinds of other things like that. It's just the fact that like setting up the environment is such a pain in the ass, right? Which is the reason the bad guys. Get saddled with this too as well. But even now, before they before the bad guys run, before DPRK drops Beaver Tail or Auto Cookie, there typically is at least two bash scripts just to set up the environment, the interpreted environment, right? So just to get that set up correctly and have it run is painful. Um, and so you know that that's something else that the sandboxes often miss.

Jenn Gile 22:21

Yeah, and you know, uh, I think it's worth like taking each requirement for a sandbox to be effective in talking about that, because we do get asked on a fairly regular basis, oh, you're you're sandboxing, you're doing dynamic analysis, you're detonating. Uh, we do believe that those techniques have a place, but with interpreted language malware, by and large, they're not as effective. And so, like in terms of the requirements, you know, the artifact's got to be able to execute. You know, the sandbox has to be able to run the file type. Well, you know, in PMR PyPy, requiring a full Node.js or Python runtime setup, you know, that's there's gonna be some issues there. Uh, it's gotta fire during the window that it's in the sandbox. Um, you know, those default durations can be, you know, a minute up to you know, 300 seconds. And often because things are time gated or environment gated or whatever, like it just won't fire, right?

Paul McCarty 23:21

Um yeah, and most of those open source, you know, the JavaScript and Python that we see, you mentioned this earlier, but you know, has a delay now. Like they they specifically delay it because most of the sandbox, like if you use any run or triage or any of those, you know, you typically run those sandboxes for a minute to five minutes max, and then they just wait longer than that, and it never goes boom. Um, I think like for everybody that we we get into these, I have these kind of technical conversations with our friends, right? And won't say any names here, who who really like to sandbox, and that's cool, but there's always a trade-off there, right? There's time, there's compute. Now, when it makes sense to perhaps sandbox is when you have a very, very heavily obfuscated file, which we're seeing a lot, you know, with DPRK and other stuff in JavaScript and in Python. A lot of people are using PyArmor and Python. PyArmor, you need to fix your shit. Anyhow, um the the so you know if you've got a heavily obfuscated file, like the the time that it takes might take as long as what it takes to actually sandbox it and get good data out of it, right? But setting up and instrumenting that sandbox is so much more complicated than if you have a good static analysis tool. And that's why I've you know really focused on static analysis for these things.

Jenn Gile 24:32

Well, you read my mind. I wanted to wrap up with us talking a little bit about static analysis and um where AI fits in. Uh again, I was on a webinar this morning where we were talking a bit about you know where AI can hurt, where AI can help. Certainly, as we've talked about several times, the threat actors are using AI to their benefit to be able to move faster. So um, you know, without spilling the trade secrets, uh, you know, what's your what's your philosophy here? Because obviously I know you don't believe you can just set AI loose 100% and you know it'll detect malware. There's there's a balance there.

Paul McCarty 25:16

Yeah, I mean, there's people that are using heavily using LLMs in their malware analysis pipelines and creating a lot of false positives, right? We see that, and you know, you can you can quantify that. I think that um uh and there is this expectation you can just run an LLM and it figures it out, right? But the reality is that you know, like I just had a sandbox blow up last week because you know it was the this heavily kind of looping uh obfuscation, it just you know used up the memory and oh I am my my sandbox. Um uh where was I going with that? Uh the rabbit hole that when do you use AI? Thank you. When do you use A? Listen, AI is really important to have inside of your pipeline, but we really um you know we we found that custom purpose-built static analysis is the best, fastest way to do this. Um, and that doesn't mean these other things don't have a component. I think is it is important too when you're doing your static analysis to be coming at this from a really thoughtful perspective about how things go boom. And me and a good friend had lunch you know a couple weeks ago, and we were talking about, you know, when you're doing pen testing and bug bounty, you have like the sinks and sources. I've taken a concept of that and and moved with it and built some libraries and some functionality around that to understand specifically how the malicious execution order happens inside of these things, and that's because I built the static analysis myself. I built, you know, like oh man, we can get into the fuzzer, but um, we'll we'll leave that for another time. Anyhow, that's that's my take. I I you know, custom, purpose-built, focus subject matter expertise inside of the static analysis engine is probably the best way to go.

Jenn Gile 27:00

All right, I think that leaves us at time. Um as always, you know, reach out if there's something you want to hear about, but otherwise uh join us next week to hear the news. And I don't know. I don't know what are we gonna talk about next week. Uh we haven't decided what our deep dive is gonna be yet. Do you have some ideas, Paul?

Paul McCarty 27:18

Uh I've got some ideas. We might have to talk about kill chain. Um, but um we'll yeah, we'll we'll uh we'll we'll definitely come up with something sexy. That'll be before my training, so we'll I'll have to be uh Johnny on the spot. I'll keep my answers a little more tersive.

Jenn Gile 27:36

Thank you, and I'll see ya.

Paul McCarty 27:38

See everybody