BLOG

The OpenSourceMalware Show #3

git hook persistence, Antrea compromise, Dirty Frag, cPanel exploitation, interpreted language malware

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

The OpenSourceMalware Show #3

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

In this episode we covered:

DPRK Lazarus Group using git hooks: Paul’s latest research shows the Contagious Interview / TaskJacker campaign has evolved. The initial loader is still the VS Code task.json file, but it now calls concatenated Git commands that drop malware via pre-commit and post-checkout git hooks, hiding the payload URL from the place researchers have been looking. Post-checkout is particularly clever: it fires every time a developer checks out a branch, and most people never think to audit it.

Antrea Kubernetes project compromise: The Antrea project, a popular Kubernetes CNI dependency, was compromised but so far no malware has been dropped into it. Paul has been tracking the threat actor and reached out proactively to the maintainers. The source of compromise is contested (we have evidence it was through the March Trivy compromise), but the core takeaway stands: threat actors don’t always act immediately on stolen credentials. Assume credentials are burned and rotate aggressively.

Dirty Frag Linux local privilege escalation: Dirty Frag is a new vulnerability class discovered and reported by Hyunwoo Kim (@v4bel) that chains two page-cache write vulnerabilities (the xfrm-ESP bug and the RxRPC bug) to obtain root privileges on major Linux distributions. It extends the same bug class as Dirty Pipe and Copy Fail. Because it is a deterministic logic bug rather than a race condition, it doesn’t require precise timing, does not panic the kernel on failure, and has a very high success rate. The embargo broke before a patch or CVE existed. It is already public.

cPanel actively exploited at scale: A critical actively exploited vulnerability in cPanel is hitting organizations below the security poverty line hardest. The infosec press has been quiet, but incident responders are getting hammered. Every geolocation, every crew. If you’re doing IR right now, you’re not alone.

Deep dive on interpreted language malware vs. compiled malware: Most malicious open source packages are written in JavaScript or Python, and that is not an accident. Jenn and Paul walk through why: no compilation step means the attack artifact ships with variable names and structural intent intact, post-install scripts enable auto-execution at install time, and sandboxes consistently fail against interpreted language malware for structural reasons. They also cover where static analysis fits in and why purpose-built engines outperform LLM-heavy pipelines for this problem.

Episode Resources

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

[00:00:20] Paul McCarty: 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 in heat mode, and I’ve got my new office warming up with the space heater in there.

[00:00:35] Jenn Gile: Ooh, exciting.

[00:00:37] Paul McCarty: Exciting. I’ll send you a picture later.

[00:00:39] Jenn Gile: Can’t wait to see it. So welcome everyone. This is our third installment of the OpenSourceMalware Show. We’re gonna do some quick hits on the news, and then we’re gonna jump in deep on talking about interpreted language malware. So let’s hit first on some research, Paul, that you released earlier this week on North Korea’s Lazarus Group getting creative with their Contagious Interview TaskJacker campaign.

DPRK Lazarus Group Moves Persistence to Git Hooks

[00:01:15] Jenn Gile: They have shifted from using VS Code files -- using a task.json file to load malware -- to now using git hooks. Even worse.

[00:01:25] Paul McCarty: Yeah. Well, it’s actually both, right? Its initial loader is still the VS Code tasks file. They have a Cursor version of it too, and it affects anything that uses VS Code, which is Windsurf and Cursor. But the initial loader is still in the task.json file -- it just calls these two concatenated Git commands. There are two versions of it that I’ve seen so far in the wild. There’s the pre-commit version, which we talked about in our blog post. I didn’t have as much time to go into the post-checkout version, but that’s really smart because post-checkout is a git hook that most people never call.

[00:02:15] Paul McCarty: It basically runs after you check out a branch. What they do is they concatenate these two Git commands so that the last thing it does is check out a development branch, and then boom, it runs itself. It’s beautiful. And just to circle back -- why they’re doing this is because it became really obvious for us and some of the researchers at OSM to find these URL strings in the task file. And so now these are just Git commands, which looks much more normal, until you go and look at what that git hook does, and then it calls the URL or uses a shortener. But yeah, it’s smart.

[00:02:55] Paul McCarty: And it’s funny too, because at SecTalks -- a meetup I run here on the Gold Coast, an Australian security meetup -- somebody asked, “Have you ever seen anybody hide stuff in git hooks?” And I said, “Oh, it’s been a while.” Honestly, it’s been five or six years since I’ve seen it in the wild. But here we go, DPRK is doing it.

[00:03:15] Jenn Gile: Yeah. And we saw some borrowing recently of TeamPCP borrowing some of Lazarus Group’s techniques for the MiniShyBlue campaign. Tradecraft. So it’s only a matter of time before this technique jumps from developer interview-focused attacks to an account takeover or something like that.

[00:03:35] Paul McCarty: Yeah. DPRK has really doubled down on this force git commit function, which is great because then they can just keep doing these force commits again and again and again, and it just changes the payload, right? 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 concoct these things -- and by the way, the bad guys aren’t going, “Hey Claude, write me up an exploit for blah.” They describe the functions they want it to do. It’s a perfect storm of those two things coming together.

Antrea Project Compromise

[00:04:20] Jenn Gile: Yeah. Whole new world. All right, let’s move on to the Antrea Project compromise. So this is a popular Kubernetes dependency. This is a little bit of a good news story. While the project was compromised, there’s no malware in it yet, and so that is the good news. The bad news is, your investigation has traced it back to the Trivy compromise. In all probability they got their stuff exfiltrated because we’ve got some evidence that they were using the poisoned version. And this kinda just goes to show threat actors don’t always act immediately on the credentials that they get. Just because you don’t immediately get popped doesn’t mean it’s not gonna happen. Just assume credentials are compromised if you’re in a compromised situation. So you’ve been keeping an eye on this. You’ve been reaching out to the maintainers. What’s the update?

[00:05:35] Paul McCarty: Yeah, the update is that the lead maintainer reached out to me and said they were not done in Trivy. I think I might politely disagree based on some evidence that I saw that I can’t go into, because it involves a vendor and I haven’t gotten their sign-off. But in addition to that, there are some other discrepancies where the threat actor claims, in a public Git PR comment, to have trashed their EC2 instances. It turns out the maintainer says that’s not the case -- they shut them down themselves. So we’re never gonna get to the bottom of it.

[00:06:20] Paul McCarty: But the reality is that we’ve gotten pretty good now at tracking these threat actors. We like to talk about this like: we wanna see the threat actors before they make the bomb. We wanna 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. That’s one of the things that we do here, and we did it with the Pawn Rider user too as well -- 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. In this case, so far it’s a good outcome.

[00:07:00] Paul McCarty: Also, I do not think this is TeamPCP. Somebody that I trust suggested they think they might be involved in some way with TeamPCP, but want to be on the outside edge. It’s a loose affiliation.

Dirty Frag Linux Local Privilege Escalation

[00:07:30] Jenn Gile: Quick hits. So the next one on the list that you dropped 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 description here is it takes CopyFail and says, “Hold my beer.”

[00:07:47] Paul McCarty: Yeah, so I just got a heads-up on this from Jayden, one of my friends and a longtime listener. I don’t put a lot of time into these things because I don’t red team anymore, and so I don’t build exploits for red team stuff. But this just screams red team exploit. It’s just so sexy. It chains together two Linux vulns -- and here’s the thing, 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 preexisting in all the major distributions.

[00:08:25] Paul McCarty: In this case, the author tied together two vulns in a chain for just a super sexy, short, powerful local privilege escalation bug. And it’s sweet. I was trying to get it running -- it’s really easy to run, I just was trying to spin up a VPS before this, but I didn’t get a chance. They just dropped this, like, two hours ago, and unfortunately the embargo has been broken because a third-party researcher saw the change log or something, and has published. 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 Codex, so here we go.

[00:08:58] Jenn Gile: Buckle up.

cPanel Actively Exploited Vulnerability

[00:09:00] Jenn Gile: Last quick hit. cPanel is having a moment. Not a great moment. There’s some actively exploited bug that’s exposing, according to the internet, millions of websites. This is a little bit outside the malware wheelhouse, but we know that sometimes vulnerabilities lead to malware. So what do you wanna say about cPanel?

[00:09:20] Paul McCarty: Well, cPanel is used by most of the low-end CMS -- WordPress, Magento, Drupal. So there is a relationship between these things. Bad guys have been using vulnerabilities in WordPress for years to upload malware, specifically JavaScript that then runs client-side and does the bad thing -- an overlay or whatever the case may be.

[00:09:50] Paul McCarty: In this case, I think we’re not hearing a lot about it from the infosec press because it’s not really affecting enterprises that much. It is unfortunately affecting some local government that I’m aware of. But the reason is that cPanel is typically used in those lower-end VPS hosting environments, and that means SMB, small shops.

[00:10:10] Jenn Gile: And I was just talking about this with Dwayne this morning on a GitGuardian webinar. The security poverty line concept. These are shops that probably are below the security poverty line -- don’t have the staff to investigate, secure, manage, et cetera. So it’s kinda the worst possible scenario, right?

[00:10:30] Paul McCarty: It is. And from an incident response perspective, we might not be hearing about it in the infosec press, but every incident responder I know, especially those that deal with the smaller end of town, 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. The Southeastern Asian crews, the Russians. Everybody is using this because it’s just so easy and so popular. I mostly wanted to put this on the run sheet today just to give a shout-out to those -- you might not be hearing about this that much, but I understand it’s a big deal. Our hearts go out to you if you’re doing incident response right now.

[00:11:15] Jenn Gile: Yeah. Rough time.

Where in the World: Upcoming Events

[00:11:25] Jenn Gile: Okay, let’s do a quick “Where in the World Will Paul and Jenn Be?” because you and I possibly overcommitted ourselves slightly in the month of May.

[00:11:40] Jenn Gile: So I’ll start. Next week I’ll be in the Bay Area. I’m gonna head down for a cool event called the San Francisco Secure Software and AppSec Summit. That’ll be over in Palo Alto on the 14th. I’m gonna be on a panel with some very recognizable names talking about how AppSec should actually run. Lots of audience opinions. At the end of the day I’m just gonna say it really depends on your organization -- there’s probably a lot of things we can tell you not to do. And then toward the end of the month, Zenity is doing their second AI Agent Security Summit. I’m excited to have been invited to speak, and I’m gonna be talking about malicious AI skills.

[00:13:00] Paul McCarty: I wanna circle back to your first one there. That’s the Clutch event, right? My friend Cole Cornford and Ben Gittins will both be there. CK Tricky, Ken Johnson will be there. It looks like a really good one.

[00:13:15] Paul McCarty: For me, I well and truly overcommitted. I’m going to Melbourne next week for Melbourne BSides, which is probably my favorite BSides in the world. Thursday night I’m speaking at the AppSec meetup in Melbourne -- the last time I was there, I think there were about 100 people. Then Friday I’m giving an all-day training at Melbourne BSides on some of my traditional CTI stuff. Then I’m keynoting on Saturday, and on a panel with Ricky Burke on Sunday. Then I come back to the Gold Coast and I’m speaking at AusCERT -- one of our oldest, longest infosec conferences in Australia, and it happens to be on the Gold Coast. And then Saturday is Gold Coast BSides. And that’s when I have my heart attack.

[00:15:10] Jenn Gile: Right on. Okay.

Deep Dive: Interpreted Language Malware vs. Compiled Language Malware

[00:15:20] Jenn Gile: I teased it last week. We have time for it this week because thank goodness nothing blew up. I wanna talk about interpreted language malware versus compiled language malware. You and I have kind of been fiddling around with a white paper on this for a little while. We haven’t gotten it over the line because…

[00:15:38] Paul McCarty: It’s giant.

[00:15:40] Jenn Gile: Yeah, I might have written too much.

[00:15:44] Paul McCarty: This is War and Peace right here.

[00:15:50] Jenn Gile: But it’s legit. It really is. Let’s just talk about why we’re focused on interpreted language malware. 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 phishing attacks and things like that.

[00:16:20] Jenn Gile: There are several reasons that interpreted languages are chosen -- they have specific properties that make detection harder. One is that there’s no compilation step. The source code is shipping as the attack artifact, so it’s not gonna be discarding variable names, comments, structural intent, that kinda thing. This is at the semantic level. Import time and dependency context execution is a real bypass. Why don’t you talk a bit about that, Paul? We’ve been discussing the role of post and pre-install scripts, which can get discovered by a sandbox. But what we know about a lot of the open source malware we’re seeing is that a lot of them have pre-install and post-install scripts. What are they doing differently in interpreted language that lets those scripts sneak through in a sandbox?

[00:18:00] Paul McCarty: Yeah. It really boils down to one simple thing -- the install scripts allow it to auto-execute. 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 when it downloads, it automatically also runs. Those scripts are there for a reason. JavaScript in particular makes heavy use of these things, and having these lifecycle scripts in a CLI is really helpful because it does the thing to make the CLI be able to work. But the post-install scripts make it really easy for bad guys to run their payloads. The Axios compromise -- it had a post-install script, and bada boom, bada bing, it was running on lots and lots of pieces.

[00:19:10] Paul McCarty: But I want to say, not all JavaScript malware uses these lifecycle scripts. Many of the effective ones work on import. And it’s not just JavaScript -- I saw Socket find six or seven NuGet packages that were doing what they said on the tin -- people would install them, see they were working, use them. And if you can actually do the good thing, then people won’t vet it well enough to see if it’s doing a bad thing as well. Bad guys are taking those patterns from JavaScript and moving out to different languages.

[00:20:05] Jenn Gile: Yeah. We’ve talked about sandbox evasion quite a bit. In addition to firing on install or on import, they can call out to the OS APIs to detect if they’re in a sandbox environment. You’ve documented some BeaverTail variants that are pretty sophisticated with their concealment and environment gating checks.

[00:20:35] Paul McCarty: Yeah, by traditional malware also does that, but I think the difference is that you have to set up an interpretive environment in the sandbox. And if it’s on import, you have to call it in the right way. You have to ask it in the right way to do the bad thing. That happens when you import it and it goes to do the thing -- but that doesn’t happen in the sandbox. The sandbox doesn’t have any context around how you actually get this on-import thing to go boom.

[00:21:10] Paul McCarty: And there’s all kinds of other things like that. Setting up the environment is such a pain in the ass, which is the reason the bad guys get saddled with this too. Before DPRK drops BeaverTail or OtterCookie, there typically are at least two batch scripts just to set up the interpreted environment. Just getting that set up correctly and having it run is painful. And that’s something else that the sandboxes often miss.

[00:21:45] Jenn Gile: And I think it’s worth taking each requirement for a sandbox to be effective and talking about it, because we do get asked on a fairly regular basis, “Oh, you’re sandboxing, you’re doing dynamic analysis, you’re detonating.” We do believe that those techniques have a place, but with interpreted language malware, by and large, they’re not as effective. In terms of the requirements -- the artifact’s gotta be able to execute. The sandbox has to be able to run the file type. NPM or PyPI requiring a full Node.js or Python runtime setup -- there’s gonna be some issues there. It’s gotta fire during the window that it’s in the sandbox. Those default durations could be a minute up to 300 seconds, and often because things are time-gated or environment-gated, it just won’t fire.

[00:23:05] Paul McCarty: Yeah. Most of the JavaScript and Python we see has a delay now. They specifically delay it because most sandboxes -- if you use Anyrun or Triage or any of those -- 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. I have these technical conversations with friends who really like to sandbox, and that’s cool, but there’s always a trade-off there -- time, compute. Now, when it makes sense to perhaps sandbox is when you have a very, very heavily obfuscated file. A lot of DPRK and other stuff in JavaScript and Python is using PyArmor. PyArmor, you need to fix your shit.

[00:24:10] Paul McCarty: So if you’ve got a heavily obfuscated file, the time it takes might be as long as what it takes to actually sandbox it and get good data out of it. But setting up and instrumenting that sandbox is so much more complicated than having a good static analysis tool. And that’s why I’ve really focused on static analysis for these things.

Static Analysis and AI’s Role in Detection

[00:24:30] Jenn Gile: Oh, you read my mind. I wanted to wrap up with us talking a little bit about static analysis and where AI fits in. Again, I was on a webinar this morning where we were talking about where AI could hurt, where AI could help. Certainly, as we’ve talked about several times, the threat actors are using AI to their benefit to be able to move faster. Without spilling the trade secrets, what’s your philosophy here? Because obviously you don’t believe you can just set AI loose 100% and it’ll detect malware. There’s a balance there.

[00:25:10] Paul McCarty: Yeah, there are people that are using LLMs heavily in their malware analysis pipelines and creating a lot of false positives. You can quantify that. There is this expectation you can just run an LLM and it figures it out. But the reality is -- I just had a sandbox blow up last week because of a heavily looping obfuscation. It just used up the memory and OOM’d my sandbox.

[00:25:55] Paul McCarty: When to use AI -- AI is really important to have inside of your pipeline, but we found that custom purpose-built static analysis is the best, fastest way to do this. And that doesn’t mean these other things don’t have a component. I think when you’re doing your static analysis, it’s important to come at this from a really thoughtful perspective about how things go boom.

[00:26:20] Paul McCarty: Me and a good friend had lunch a couple weeks ago and we were talking about -- when you’re doing pen testing and bug bounty, you have sinks and sources. I’ve taken a concept of that 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. I’ve built the static analysis myself, I’ve built some fuzzer functionality around that. Custom purpose-built, focused, subject matter expertise inside of the static analysis engine is probably the best way to go.

[00:27:10] Jenn Gile: All right. I think that leaves us at time. As always, reach out if there’s something you wanna hear about. Join us next week to hear the news. And I don’t know -- what are we gonna talk about next week? We haven’t decided what our deep dive is gonna be yet. Do you have some ideas, Paul?

[00:27:28] Paul McCarty: I’ve got some ideas. We might have to talk about kill chain. We’ll definitely come up with something. That’ll be before my training, so I’ll have to be Johnny on the spot. I’ll keep my answers even more terse.

[00:27:45] Jenn Gile: Thank you. See ya.

[00:27:47] Paul McCarty: See ya, Jenn. See ya, everybody.