Jenn Gile 0:01

Hello, we are live on October 21st. I we're recording at a slightly different time than normal. I happen to be in Europe this week, so uh we're not recording at our normal time because I like sleep. Um, we're gonna be talking today about the OVH CLI compromise, some evolutions that we saw with ghost action this week, and um a new trend that we're picking up in our research. But before we get into that, Paul, what's going on?

Paul McCarty 0:33

Yeah, I mean, I think this is a very different time. It's a different, it's a different day. It's definitely a very different time. It's the middle of the week versus the end of the week for me. So very different. But um, yeah, I mean, this is what happens when you have to align schedules for people that are on almost opposite sides of the planet right now. You're not quite fully opposite from me or me opposite you, but pretty dang close. So it is what it is, right? Um, good to see you.

Jenn Gile 0:57

Yeah, it's it's been interesting uh working this week on a a totally different rhythm. Um, I'm used to being uh, you know, the first thing that I do in the morning, catch up with whatever Paul's been up to, but uh now it's catch up in a different way. But anyway, uh I'm in Barcelona this week uh for work, been really enjoying getting to know the Catalan culture and people. Uh so if you're from Barcelona, hey, great city, beautiful place, went to Montserrat yesterday. Okay, let's get into OVH. So uh what, two days ago, um OVH was hacked via what I would I'm gonna go out on a limb here and say somewhat ancient uh credential compromise from the spring. And when I say ancient, I mean these credentials were stolen seven months ago, uh, which in software supply chain security is a long time. But you and I and some people in the community have been talking about why a threat actor might wait so long before compromising something like OVH. And uh the net of it is if you do these kind of what we would call in the US, there's probably another way to put this, but like a shotgun approach, just you know, fire and see what you hit. You kind of have to go out and then like hunt and see what did you hit. And so the threat actor probably had a lot of data to sift through, uh, you know, probably did some testing to see what's still live. You know, what are what's the possible blast radius if I compromise this thing? Um so the the OVH credentials were stolen. You said about six months ago. Uh, this was one of the things you found while I was sleeping. So tell me what I missed while I was asleep.

Paul McCarty 2:49

Yeah, I mean, I I actually don't know when the credentials were stolen. Um, and it was funny to kind of go backwards. Uh it wasn't you and I, but it was somebody else and I were like just a couple days ago, we were talking about what happened to Glassworm. We haven't heard from them for a while. Glassworm, by the way, for catching everybody up, um, is a Russian um uh threat actor um who in 2025 was doing um some stuff that was kind of similar to Pollen Rider and something.

Jenn Gile 3:18

Anyhow, um well, and there was a big takedown earlier this year of their infrastructure, and so we haven't seen anything really related to glassworm since that major infrastructure takedown, maybe back in like uh May or June or so.

Paul McCarty 3:34

Yeah, so basically I woke up and timing was just really, really good for me. Like I saw it happen in almost real time, and so I jumped on it and nobody else was working it. And um, you know, I mean OVH, uh, just some background. So OVH is uh is a uh French-based VPS virtual private server company, they've been around around forever and a day. Jen and I were just talking about this. There's two big ones in Europe that I can think of. One is OVH and the other one's Heinziger. Um but um basically what happened is they have a CLI that allows customers to interact with assets and resources in the OVH cloud. Um, and same thing like a DigitalOcean's got and Vultures got and AWS has got and everything else, right? Um and the the CLI tool for OVH was compromised, four four versions of it were compromised. Um and the uh original push, force push for the compromise developer, um Hassan BF was back. And I like I said at the top of this, uh, we don't know when his creds were stolen, but when Glassworm pushed the initial payloads into those four GitHub repos that I mentioned in the blog post, that happened March 5th, which is like seven seven months ago. So, old mate Hassan, you might want to look at your repos a little bit more closely, but I mean, for whatever reason, uh you know, they had dwell time that long. Um and you know, you said it, like their glassworms infrastructure got taken down. So I I I guess they just it took them a while to take a look and see what was still live, like you said, and they found that this guy's creds were still live. Um, and uh yeah, the rest, as they say, is history. This did not happen in GitHub Actions. These were built. Um, if I'm I'm I'm I hope I'm not mistaking the two, but if I remember correctly, um these were built off, yeah, they were these were built on um Hassan's laptop, so they weren't built in in the CI.

Jenn Gile 5:38

Yeah, it was outside of the regular pipeline, which I think is probably why it got taken down so quickly, is they as we've seen with other compromises, account takeover style compromises this year, when the threat actor publishes through a method that's not the typical avenue, you know, if you have some kind of alert structure set up, it's pretty obvious when there's a problem.

Paul McCarty 6:02

Yeah, and um, you know, we have we have a community member to thank for finding it. Um, I I can't remember the the user's name off the top of my head, but basically somebody was using the CLI and saw there was a new version of it and and realized really quickly that it was doing something weird. And um, you know, a bunch of people took over um from that point. I saw the CEO while I was working, I saw the CEO post saying, Hey, we've done incident response. So I wrote back, hey mate, you might want to look at your incident response because this guy um who has a longstanding kind of you know contributor relationship with with the OVH CLI, which is open source, obviously, um, is still compromised. Um and I checked earlier today, and the pre-installs were still there earlier today. I haven't checked since then, but so yeah, fun times.

Jenn Gile 6:48

Yeah, you know, it uh it sparks some thoughts for me about open source business models, as you know, and some people know about me. I used to work for Nginx, another uh widely used piece of open source that nobody knows the company owns. So, you know, there's kind of this interesting relationship when there's a company behind an open source project that is also accepting external contributions to said project. Uh, I hope OVH doesn't over-correct in their incident response and their, you know, security next steps and decide to no longer accept external contributions. For example, that could really change the way that that project and that community works. Uh, you know, coming again from Nginx, uh, we didn't accept a lot of external contributions, and that had more to do with the complexity of the tool and the need for stability. But there was always that like tension with the community wanting to be able to contribute more to the project. So I'll be interested to follow what OVH decides to do with regard to external contributors who may not be um at the same, like have the same security standards as the company contributors themselves.

Paul McCarty 8:07

One of the things that I saw that I was really disappointed with um is that I'm just verifying right now the um oh maybe it wasn't OVH. It's not OVH. A lot of the a lot of the open source projects I've been looking at lately that have that have had compromised assets, and there's been a bunch over the last two or three weeks. There it seems like a lot of their commits are unsigned. And I'm thinking now I get that using agents complicates this. And so you'll often will see, like if you're looking at the commit history, you'll see like verified when they do an actual push as a human, right? And then those you'll see you know an unverified, unverified as their agent pushes for them. But um, you know, I think that I've said it here before, like signing your commits is like one of the most powerful uh things you can do to prove and attest that you you know or your account, you know, push that thing. Now it doesn't mean that everything else that you know but that precludes a lot of malicious behavior right there. And I just really wish people I've been harping out about this for like I swear to god, 10 years or more, but like sign your commits if you're building in public and public sign your freaking commits. It's not that hard and it it provides so much value and require that you need it. Now, here's the problem, Jen. As we were talking about last week, a lot of the things that the GitHub has put in lately, you know, push protections and whatnot, you know, those don't work for these public uh repositories, and so you can't enforce certain things. I think you can enforce I if I'm not mistaken, I think you can enforce it. I think you can enforce signed permits. Yeah. Um it'd be silly if you couldn't, right?

Jenn Gile 9:48

Well, lots of silly things. Lots of sillier things have happened. Okay, not on the agenda, but I think it's worth like maybe 30 seconds to a minute because you and I were talking about it earlier. It's open source deno was acquired by Cloudflare. Um so kind of an interesting, you know, another open source project uh is going to be changing in a major way. For people who don't know Deno is ostensibly a way to do JavaScript without having to bring in all the packages. It kind of like lets you call out at runtime to different things. Um, the concept is that it makes it lighter weight, uh, you know, less work, those kind of things, you know, better performance. But the flip side that we've seen is that's also a great way to um be sneaky about where you hide your malware because if you're calling runtime dependencies, I mean if you're calling runtime dependencies, those can swap out. You know, you you evaluate the package, but you don't evaluate, or even if you do evaluate the runtime dependencies. Anyway, long story short, I don't think we know a whole lot about the acquisition of Deno, but certainly the community that uses Deno is very concerned about it. And as I've seen lots of acquisitions over the years, big company acquires an open source project, things will change. Like that's inevitable. Um whether that means people move away from Deno, who knows?

Paul McCarty 11:18

Well, I think they're gonna have to. Like, I mean, it sounds like the the I mean for it sounds like they're making major changes to it. Yeah, I mean, this ecosystem's imploding. And I mean, uh there's no other way for me to really think about it. Like by this time next year, it's effective it's not gonna be working, right? Between updates and the Deno land stuff being taken offline.

Jenn Gile 11:38

It's you know, it's well in reality, someone's gonna fork it and a fork, you know, this will be open tofu or uh, you know, the open the terraform, open tofu, open terraform uh whole thing that happened, I don't know, three to five years ago. Time's funny.

Paul McCarty 11:54

Well, I mean, there's I don't know that much about I know more about Bun than I do about Deno, but like there, I mean there are some actual infrastructure assets there too as well, like you know, Denneland and you know, where you pull that that that CDN that they use, you know, not you so you'd have to fork it and replace that or take over that. I think it's interesting too. Like, I mean, like, so Deno was a project started by um Ryan Dahl that wrote Node to kind of um I in this is my words, not Ryan's, and so I don't want to I don't want to um offend him, but I think in you know, I think he said it kind of in his own way before, but it was his way of kind of writing wrong the wrongs that he did with Node. And and when he wrote Node, you know, we never knew what was gonna happen to Node in NPM and become this huge, you know, the largest software registry on the face of the planet and the holder of all things malicious between GitHub and NPM. I that's like 99% of the malicious stuff out there. Almost said a bad word. Um, anyhow, so Ryan, you know, like he built this thing, and it and lately in the last six months, Bon has just kicked its booty, like it's just you know, Bon has become much more popular with malicious actors too, as well. I remind everybody the mini shy hulud.

Jenn Gile 13:05

Well, and let's not forget Bun was also acquired. So interesting things happening at the runtime JavaScript D alternative universe.

Paul McCarty 13:15

It's really hard to make money in that space because people don't want to pay for it. They just think you can do it for you know, like interpreters, like commercializing open source is really hard.

Jenn Gile 13:23

And when you look at companies that have tried to build a commercial product on top of their own very popular open source project, Nginx included, um, it's a very small percentage of people who need the commercial version and or are willing to pay for a commercial version. And I think what a lot of companies and salespeople lose sight of is that the expectations of the core open source project um change over time and evolve over time. And the people who are using that core open source project continue to expect that that project improves over time. And what I tend to see when open source gets commercialized is there's this desire to kind of leave the open source project as the not great alternative. You need like a a reason to upgrade to the commercial one. And often, I'm going somewhere with this rant. Uh, often one of the things that gets added in the commercial version is something related to security.

Paul McCarty 14:29

Yeah, which sucks.

Jenn Gile 14:32

Yeah. Anyway, um, I want to take things slightly out of order because we went down this rabbit hole on open source and we're talking about um different ways to sneak malware in. You know, we talked about runtime. Uh, we've been seeing a trend, which I don't know that we've talked about on the show yet, of what we would call compound payloads. And so there's like different ways that threat actors are evolving right now to make the malware more difficult to find in malicious open source because they've realized if you put it right in the project, anyone with you know a decent agent or uh a tool like ours or a scanner is probably going to find it. It's getting, you know, you look for these little tip mops. Does it have a pre-install script? Does it have a post-install script? Is it calling bun? Is it telling you to install truffle hog? Oh gosh, this might not be good. And so they're finding ways to uh hide where the payload is. And one of them that we were just talking about was hiding it in a runtime dependency. But this other way, this compound payload is exactly what it sounds like. It's like a transformer or uh what did we say last week? Um, Power Rangers or something. Like they all come, what's the evil version?

Paul McCarty 15:52

Vol Voltron. Voltron. Yeah. Voltron, yeah.

Jenn Gile 15:55

Sorry, I can only think of the good ones. You know, the the separate pieces come together to form the malware.

Paul McCarty 16:01

And Voltron wasn't bad. Voltron was, they were good. They were good. Yeah, yeah, sorry. They're good. Just to be clear. Yeah, as a Voltron as a Voltron fan from the from the 80s.

Jenn Gile 16:12

There's always a bad version. This is the bad version. So we've got a package that you were looking at earlier this week. Uh now I lost it.

Paul McCarty 16:22

Yeah, WebRunk.

Jenn Gile 16:23

Webrunk. Yeah. I I look at this package and I think we brunch and it makes me hungry. Um, WebRunk. And I don't think this is like a there's not like, you know, danger flags. This is more of a scientific, this is an interesting thing. So it's a PyPi package that we found with our sort of forward hunting um automation. It doesn't pull a secondary payload or include an X-Fill destination. So there's no malicious component in the package itself. However, what you were seeing is that it appears to have been intended to run in conjunction with other packages that complete a malicious payload. And so it's got a fetch and execute pattern in it, which is retrieving some uh remote content. You know, it's uh as you said in the the write-up on it, it's got a bit of a dropper loader attacker module uh model. So um, what's what's interesting about this? Um, what do you want people to understand about this kind of new new way?

Paul McCarty 17:27

What why are bad guys doing this? You you kind of alluded to this uh you know a minute ago. Bad guys are doing this because you know, people you know the companies like OSM and Socket and Akito and everybody else are getting better at finding the bad stuff, right? And so when you when you build a detection engine, I don't want to go into too much detail because I don't want to spill the tea for the bad guys, but the the reality is that talking about it at a high level, when you're building a detection engine, you can't just accept what like a lot of um oh my gosh, this this is a great segue into something else I came up with today, Jen. Uh, this is totally YOLO. I came up with an acronym acronym today, PEST, potentially exploitable security tool. And here's here, like I'm I'm gonna I'm seeing it. I I'm seeing a ton of these right now. So basically, in the age of vibe coding, some person that doesn't have a background in building security tools or encoding uses a vi uh an agent and builds you know a security scanner, right? And there's just a plethora of these, they're just popping up everywhere. And a bunch of them are actually malicious too, they're hiding malicious stuff, but most of them are not. Um where was I going with this? The um uh when they're building these uh potentially exploitable security tools, they will often use Yara the first time around because that's what the agent will say. Well, you use Yara, and so you know in Yara, you know, you'll have I don't know, maybe 20 or 30 rules that you can find, you know, out in the in GitHub world, and you use those and you'll detect stuff, right? And you'll detect these like kind of one-off behaviors or signals. Really quickly, though, you'll figure out, oh, Schneikes, there's just a ton of false positives. I'm spending all my time triaging all these. And so as your maturity in, you know, as working with your scanner grows, you'll start to realize I can't just take one signal, I have to take multiple signals, right? And I have to combine those together until they hit some sort of you know trigger value, and then I'm gonna say, all right, this is potentially malicious. I need to pop this over to an AI judge or whatever the case may be. Why I'm saying all this is that bad guys know that. And so what they're doing is they're they're kind of chunking, right, or sharding their I love using sharding. Um, they're sharding their um their payloads up into three or four pieces, sometimes more, um, so that it doesn't it doesn't ever hit that kind of that trigger value. Right.

Jenn Gile 19:49

Each individual thing is like maybe a little sketchy, but not sketchy enough to hit the the bar for this is malware.

Paul McCarty 19:57

Here's a great example. Going back to our CLI, right? The OVH CLI and all that. Every CLI that has to do stuff, the first thing it does is it imports dot env and so it can so it can access environment variables, right? That's that's what CLI tools all do, right? And if you just use these YAR rules, it'll be like, oh my god, it's loaded dot env, it's malicious. And really quickly you realize, oh my gosh, 99.9% of the time it's just a CLI doing what a CLI is supposed to do. So what they'll do is they'll build one package that just does that part, and then it'll call in a sneaky way a dependency that does the other. Now, typically, what you want to do is you want to have one umbrella package that calls out to these separate things, and we're seeing DPRK doing this right now, actually.

Jenn Gile 20:39

Because what you don't want to do is think about this, I feel like a couple of months ago, of you know, the the pros and cons of this approach, right? Uh, you have to have that umbrella package, you have to have the sub-packages. And if one component gets killed, then you gotta update the rest or find an alternate way to get your payload to work.

Paul McCarty 21:01

Here's my crazy metaphor, here's a Paul metaphor, a classic Paul metaphor. It's like you've got the octopus and the eight arms, and basically what happens is if me or somebody else identifies the umbrella, right? You you chop the head off the the umbrella, the octopus arms. You just got a bunch of flailing arms. Yeah, you got all the alarms, you can just come along and put another head on it, and the arms just go, you know, Voltron. There we go. Octopus, Voltron. Um I'm getting kooky here because it's late. Um, but that's the reason they do that to make it portable. And that's a really the modularity and the portability of this. So if that umbrella one that kind of combines these things, now what I have also seen is I've seen like two packages doing the umbrella work and they'll call out. Um, but you typically are not gonna see um the one doing the you know, there's like a there's gonna be an X fill, there's gonna be the credential grabbing, and there's gonna be the X fill at the beginning and the end, right? This is the sync on the source. Um, and then there's gonna be some other stuff in between if there's persistence or whatever. Um, and all those different kinds of things have to be kind of Grouped together under the umbrella package or the thing that calls it. DPRK just a couple weeks ago started doing something new, which I I this was not in the thing, but I'm gonna say it. It's actually it's another kind of evolution of compound packages, which is for contagious interview, like like old school contagious interview, which by the way, I know Pollenwright is very successful. DPRK is still actively doing proper old school contagious interview, i.e. hitting you up on LinkedIn. Hey, I've got this great job in crypto or whatever. Are you interested? And what they're doing, Jen, is they're sending you a um an invite to a private repo, right? Um, and you uh you join that private repo, and then part of it is to download an NPM package. And basically in the private repo, there's an NPM RC that points at a different um npm registry. So when you install the npm package in the package.json, there's a file getting there's a package getting called out that's not in the public registry. Like, what is this, right? And it just bypasses it because it can't install it. But if you have the if you have got the repo already installed that's got the npm rc, and then you run the npm install in that directory structure has access to that, then you get the malicious payloads. Very smart. Wow. But yeah, but that's a bunch of things. There's a bunch of things that can go wrong, right? Like that they have to and it requires it's contagious interviews. So there's like you know, somebody in in Pyongyp or somewhere else has to be like managing all this and getting you to and do the invite. There's a lot of like fiddly stuff, and that's why they they are mostly moving to automation like Pollenwriter. But this git repo beforehand, that's that's like the jab that kind of gets you going. And then the the the left hook is the npm package that then um calls out to this thing that doesn't get resolved otherwise. It's really smart.

Jenn Gile 23:50

It is smart. Um well, you know, the thing that comes to mind here is they've introduced dependencies to their process, and like we see with any developer, you make a change to a dependency that introduces unexpected behavior and you have breaking changes. So uh I wish them nothing but breaking changes.

Paul McCarty 24:12

I have something I like you and I will talk afterwards because I got some tea about uh, but I don't want to say it here.

Jenn Gile 24:19

Okay. Well, why don't we move on to our last topic? Uh late last week, it would have been Friday, no, Thursday last week. Uh we got hit up on our um internal community by one of our community members, Tys from JAMF, who is just like a fantastic member of our community. He's always doing hunts.

Paul McCarty 24:41

He might be awake right now, too, as well. Oh, you're right.

Jenn Gile 24:43

He probably is awake. I'm in his uh time to reach out to him.

Paul McCarty 24:47

I meant to reach out. If you're if you're listening, mate, I meant to reach out to him, but because that whole login thing that happened before this gen, I didn't get a chance to reach out to him. Sorry, sorry, inter I interrupted, interrupted.

Jenn Gile 24:56

It's okay. Anyway, so Ty's reached out. Uh he was doing a regular hunt for compromised repositories, looking for pollen writer indicators. Uh, he found a group of them. And normally he would just report those and move on. But uh he looked at the payloads in them to, you know, make sure they weren't false positives, and he saw something weird. Um, normally what you see in these, uh what he had flagged was something like 94 compromised repositories, which had a VS Code uh tasks file, which auto-ran a fake font, you know, 400.wath, whatever file. Uh sounds familiar, right? And so he thought, bam, that's Pollenwriter. But then when he looked at the fake font file, instead of seeing the classic obfuscated JavaScript that we've come to expect with these files, he just saw plain old JavaScript plopped in there, no white space, no attempt to hide it. And it didn't look anything like what he knows our Pollenwriter stuff looks like. But what he did see was the IP address that uh Ghost Action has been using. And so if you're not up to speed, Ghost Action is a campaign that weren't threat actor or both that's been around for about a year and had a resurgence in the last month. We reported on it in last week's show. Um they had started pushing malicious uh GitHub Actions workflows, they had started um phishing open source maintainers. Well, Tai's pushed this over and he said, hey, it's weird. You guys should take a look at it. And so I took a look at it, and indeed it is weird. Um, it is definitely ghost action. I went and did some Git forensics on the compromised repositories and found the sequence of events was essentially they got compromised first by the ghost action malicious workflow. And then uh the threat actor used that to push this pollen writer style malware into their repository so that they could maintain persistence as well as infect others, because that's what this particular vector does, even if the malicious workflows um were removed. And coincidentally, the first repository that I investigated, um, the maintainer actually had gone in and removed the malicious workflows, but didn't realize that the new malware was there. So I did um submit an issue. I should follow up and see if they saw it and removed the malware. But essentially what we're seeing is a copycat, and it's pretty clearly not uh DPRK because gosh, I don't have a nicer way to put this, but it wasn't especially sophisticated. Um, so the initial tasks file, you know, runs this fake font file. It has an info stealer that's looking for something like seven different things. Uh, what do we have here? AWS creds, PyPy, npm, git credentials, um, claude login, Gemini login, some uh Kubernetes stuff. So it's looking for that sort of thing, uh, reads those files, uh, reads SSH private keys, and then it's um grepping across the home directory for everything, you know, keeping the matches. Um and then the second thing it does is it installs a cron job where it phones home every, I think it's five minutes to see you know what's what's on the server. What else can we do? Um, but the issue is the um the info stealer kind of doesn't work.

Paul McCarty 28:50

Which is pretty crap.

Jenn Gile 28:52

Yeah, it's it's it's not great. Um that's it partially works.

Paul McCarty 28:57

It partially works.

Jenn Gile 28:58

Yeah, it has a lot of issues, which I've outlined in the blog that I shared in the comments. So if you're curious about that, but what this reads like to me, and I think you and I even talked about something similar recently. Certainly I've been talking about it as I've been doing talks uh out in the community about Pollenwriter, is there's just tons of malware out on GitHub right now. And if you're a threat actor and if you're not very experienced and you want to quickly iterate over a weekend, which is definitely what we saw happening in the ghost action campaign a week ago, is you know, they started with the workflow and then they started the typosquatted domain with the phishing. And then I, you know, pieced together the timeline. They were setting up this pollen writer component of the attack right around that same cluster and pushing it out like the day after they did the phishing. So this is all happening very closely. All they would have had to do is point an agent at one of thousands of repos infected with pollen writer and said, Hey, you know, make something that's kind of like this, but does you know these five things? And I think that's what they did here.

Paul McCarty 30:05

And it it used literally the exact path and name of the first thing.

Jenn Gile 30:11

It installs that awesome files uh though it's uh awesome font, sorry. It actually changed it a little bit in ways that are weird. Yeah. Uh instead of all of WAF2 files, they're all TIFS except for the payload, which is like maybe you want to change that one also because it would make it harder to find.

Paul McCarty 30:30

There's at least three different like kind of iterations of that. Yeah, right. The one that I saw most was actually just one WAF2, which is the the Yes, I saw that as well. WAF.

Jenn Gile 30:42

It didn't install the full suite.

Paul McCarty 30:44

Yeah, so it didn't install all the other fake um uh font files, it just had that one, and it was exactly the the original Pollen Rider WAF2 path, you know, regular 400 WAF2. So um G'day, Cody.

Jenn Gile 31:00

This is really coincidental. We've got somebody on LinkedIn asking, are people getting more aware of attack patterns and following suit? Try to capitalize on known successes. That's exactly what we're talking about right now. Um, you know, people are aware of what is happening uh with these fake font files. And this is a great example of, hey, this thing works. People don't look for this, you know, attack vector. You know, they already maybe use VS Code, so they don't notice that the VS Code folder in their repo all of a sudden has an extra file in it. Um, you know, maybe they should notice that a public fonts folder is suddenly appearing as well. Um most I would say most uh repositories that I've seen, and Paul tell me if you've seen something different that have the public fonts folder, they're not already using that in the repo. It's a a net new addition to the repo.

Paul McCarty 32:01

Yeah, 10-4. Yeah, it's not totally net new. Um you know, I think it's not surprising that the um that the shape. So basically, like LLMs are really great at like, you know, hey, I want to build this thing. So it goes and grabs the exact path of like the Pollen Rider WAF T thing, like literally the exact same path. But then the content, as you mentioned, is totally different, right? It's not it's not similar to to what is in the Pollen Rider one at all. Because here's where the LLMs, they're like, oh, I don't want to help you do this kind of stuff, right? So you have to chunk it down in individual things, like you know, have having done a lot of red teaming myself. The you know, when you're building these things with LLMs, you have to like you know chunk it down to like do a function that does this. Because if you tell it what you want to do, it ain't gonna do it, right? So you gotta chunk it.

Jenn Gile 32:51

Oh, good grief. Half the time I can't get it to read a blog about malware. Like yeah, Jim does it. The controls are pretty aggressive.

Paul McCarty 33:00

Jim was on Twitter yesterday, last couple days, saying that you know, if you're having problems with blockages and refusals, it's because you've done something wrong, effectively. That's what he said. Uh-oh. And I was like, I think we froze.

Jenn Gile 33:11

I don't know if I froze or Paul froze.

Paul McCarty 33:14

Uh I was talking the whole time, obviously. So you froze for me, but okay.

Jenn Gile 33:19

I'm back. Okay. Sorry, I missed that. You can continue on.

Paul McCarty 33:23

Yeah, anyhow, Jim, Jim Manico was talking about um, you know, like if you have problems with refusals or blocks, it's probably on you. And he basically said it's because you haven't signed up for stuff or whether you're using the wrong model. I'm like, mate, everybody I know that's a researcher is having this problem. Everybody's having this problem, right? So, anyhow, that aside, getting back to the point about Cody's question, like the the the shape of these things, the LLMs are real. They'll they'll suggest, hey, why don't you do this, right? But then when you get in the guts of it, actually doing the info stealing and doing the the crypto stuff, that the ether hiding, that's where it starts. It'll be like, oh, I don't want to do that, right? And so that's why, for example, this payload in the WAF 2, only about 60% of it worked, you know, like um it didn't.

Jenn Gile 34:07

Yeah, I'm gonna say I'm not gonna say why, but looking at the tasks file, it was simplified in a way that made it less effective. So who knows if that was the LLM being clever, if that was the threat actor not understanding what that code did. Um, regardless, all of this together combined implies to me that this is an opportunistic person who is able to reach further because of LLMs rather than an experienced threat actor inspired by uh a fellow threat actor. That's that's how this reads to me.

Paul McCarty 34:50

Yeah, well, it's confusing. Like I've said this uh you know publicly several times. Ghost actions confuses me and intrigues me because in some ways it reminds me a lot of team PCP. You had these people that were like very low technical capability, but in some ways punching way above their weight, right? And the same and ghost actions like has actually pulled off, like I mean, they they they hauled in a bunch of credentials from the first couple of iterations, you know, campaigns. Um, so you know, and they're using those now, obviously. We've seen that, right? Um, but one threat actor has done you know GitHub actions-based, um, you know, kind of mini shy halud style attack, you know, worm stuff inside of the the CI has also done look like domain fishing, totally different. Like, I'm gonna go as far away from CI based attacks as possible and go over here to fishing land, right? Um and they've come back and they're they're you know mirroring detailing devs. Yeah, like it's all over the shop, and it's just this is the world we live in. I am seeing so much malware. I was talking to one of my friends, you know, uh a couple days ago. Bad guys are because they're all vibe coding, they're using C2 infrastructure like MySQL and Superbase and Postgres for their for their C2, but then they have to include their username and password. They don't realize anybody else can use those username and password to see what you've hauled in, right? Like it just and they just don't know because they just don't understand, right? So, but that doesn't mean that that hand grenade doesn't explode and cause the company real damage, even though the person writing it is a Muppet, right? And doesn't understand what they're building, doesn't mean those things can't have damage. So um, you know, I have to be careful about my flippancy, or is that what I'm trying to say?

Jenn Gile 36:42

My no, I think that's right. You know, uh, just because they're immature doesn't mean they're not dangerous and not to be taken seriously, and you shouldn't um be concerned about what's happening. So let me ask you, Paul. What would you tell people? Because we haven't really talked a lot about GitHub action workflows. What would you tell people in terms of like a preventative or protective action? This is not like the situation where you turn on commit signing and you're fine, right?

Paul McCarty 37:13

Yeah, I mean, so GitHub has done a lot to um you know to uplift the security of the CI and of GitHub Actions in particular. But people are still using old motions, and and that's the problem, is like you know, like pwn requests, right? Like people are using those old uh versions of the actions um uh because they've been using them for years and years and years, right? And that they don't realize that that makes them you know susceptible and vulnerable to to pwn requests in the same way, you know, people have been you know using the same uh repository, sorry, same CI actions for years that have the GitHub pat right there in you know in the in the GitHub action because they they don't know anybody, that's just been working for years. And so GitHub is scared to go and break this stuff um and because they don't want to break people's CI. But they're starting to do some of that, and I think that we're we're slowly making progress. But I think something that you have to realize when you are building you know continuous integration in GitHub or GitLab or anywhere else is that you're just calling a bunch of you know Docker containers that you don't have control of over, and then exposing your source code and a bunch of credentials to those. So you know how many people are actually looking at all those different things they're calling in those different action stages, right? Um most people are not. So I think the first thing is like become aware of what's happening inside of your continuous integration, whether it's GitHub Actions or anything else. That's the first thing you need to do. It's just like understand what's happening there, right? If you copy and paste something three years ago, you probably should come back and revisit it and understand what it's doing. Um, because then that'll help you understand what do I need to make some changes here? Because there's a whole bunch of things that you need to do, you might need to do depending on you know what's happening inside your particular CI.

Jenn Gile 39:10

Yeah, that's great advice. I mean, you know, it's one thing if you're an individual developer running CI, but if you're in a company and you have someone, you know, if this is not your thing, uh your platform engineering team is probably if you have one, might be involved. Your security architects, you know, there's probably some people who own parts of this to start to get together and just do an audit, see how it works, um, see what needs to be renovated.

Paul McCarty 39:37

100%. And the cool thing is now LLMs are really good at helping you understand. Hey, take a look at my workflow files and tell me, you know, can can I uplift them?

Jenn Gile 39:49

Cool. Well, on that note, uh I think it's probably time to wrap up. Say goodnight to Australia, good day, good morning to uh Europe. And we've got one more wacky week of this because I'll be at Lascon in Austin, Texas next week. And then I get to be home for a while. Um, but we're kind of working out uh our recording schedule around LasCon, but that shouldn't be an issue. I'm really looking forward to that conference. I've said it on the show before. I enjoy it. It's just like a fun time with the community. Every time I go, I meet people that like it turns out I'll see them 10 other places throughout the year after that. But like for whatever reason, I meet them at LasCon.

Paul McCarty 40:31

It has the highest, I think you and I have said this before to each other. It has the highest density of high-quality app sec people of any conference I've ever been to. Like, and then this crappy, you know, strip mall location.

Jenn Gile 40:44

Oh, the the location cracks me up. Um I'll say my one spicy thing on the way out. I think Lascon is what AppSec Global uh in the US should be. So I'm not going to AppSec Global this year. Uh I'm gonna stick with LasCon.

Paul McCarty 41:03

Yeah, right on. Well, I I have some FOMO. I really like LasCon a lot. I'm not wearing my shirt this week, but I was last week. Um, I do want to, I I know we're signing off here, but one thing uh GitHub has released for a general preview their package firewall. And oh my gosh, I've had so much fun today messing with that and not doing what I should have been doing, but that's okay.

Jenn Gile 41:27

I can't wait to hear all about it. Have a great weekend.

Paul McCarty 41:30

You're gonna, Jen. You're gonna. Um I'm stoked.

Jenn Gile 41:35

All right, signing off.

Paul McCarty 41:37

All right, thanks, guys, appreciate you listening. Bye bye.