Jenn Gile 0:00

Super excited to be doing this. We've been meaning to do this for a while. So just as a means of a quick intro, my name's Jen. This is Paul. We're the co-founders of Open Source Malware. And we're going to be doing this hopefully on a regular basis, you know, weekly basis, where we spend a few minutes breaking down some recent news in the malicious open source world and then pivoting to talk about something that we've been, you know, observing in the industry, best practices, things like that. So let's start with Bitwarden. Paul, when I got up this morning for context, I'm in uh Pacific time. Paul's in Australia. I saw Paul had been busy overnight, as had other people in the industry. Bitwarden CLI was compromised. Um there was a malicious version published, uh version 2026.4.0, which has already been taken down. So uh if you didn't upgrade, you're fine. Um, but it's always possible that it could have gotten cached. So uh everyone should still know about this that it's happened. Um it was discovered by the JFRUG research team, and the threat actors self-described this as uh Shy Halo, the third coming. And we're gonna circle back to that because we have class. Um so kind of in brief, uh, what does it do? So it includes two files that are gonna steal environment variables variables and credentials. We're seeing a lot of this lately. Um, so kind of five steps to this malware. Number one, um, on npm install, the uh pre-install script is gonna run a bw underscore setup.js file, which silently installs a bun and then executes another JavaScript file. That file is gonna run uh an obfuscator bootstrap, uh reassemble its string table, and then execute its entry point under bun. Exciting so far, right? Um, so the exciting part is it's harvesting credentials um from any uh developer workstation that it's installed on, as well as CI runners. It's validating and escalating across uh several types of environments. So AWS, GCP, Azure, GitHub, and then it's exfiltrating. Um so let's see here. Uh before we talk about what we think about this uh attack, you know, how bad is it, et cetera. Let's take a quick peek at our uh threat feed for it. So, Paul, why don't you talk the folks through what they're looking at? And I'll share this link in the comments so that anybody who wants to take a look at it can. This is ungated. I happen to be logged in with a pro account, so I can see more data than other people.

Paul McCarty 2:55

Yeah, so I mean, like listen, the this happened um last night, so uh it would have been not quite 12 hours ago, roughly speaking. Um and the npm package was up. My math says it was up for about 14 hours. Um, I saw somebody posted a link or our screenshot of the downloads, and it showed only a couple hundred downloads of the CLI. But the reality is this NPM package is actually very popular. Um, and I think it gets 1.3 million downloads per week. I had it installed. You know, I don't have you know auto updates enabled for most npm things, and so I didn't get the bad version of it. But uh a lot of people use this particular CLI because programmatically, if you want to connect a Bitwarden vault to something, you have to use um the uh uh you've got to use this NPM package, right? So it's pretty popular. Um good attack target. Um what we're looking at here, hopefully, is the the OSM open source malware threat report for this particular package. Um Jen's right, it's 2026.4. Um, the version um uh and um if we look at the top of the threat report and the threat description, basically this is a single uh compromised version of an otherwise legitimate package. Um uh, you know, as I said, I I've got it installed um or had installed, um and no longer. Uh but um it was compromised by by we think Team PCP, which kind of vibes. Um, I was just looking before we went live. Doesn't look like Team PCP has taken um official, uh you know, they haven't said that it's them, but it does kind of vibe with where what they do. But basically, um it's a Trojanized uh version of it, drops like Jen said, two files, two new files. So if you diff it against the last version, it's gonna have two different files, and the the package.json will be different because it'll call that that um lifecycle script, um, which it doesn't typically. Um and then those those two scripts as Jen pointed out, kind of bring you onwards to glory. I think, or bad, bad glory.

Jenn Gile 5:01

Glory is a debatable word, but sure.

Paul McCarty 5:03

Yeah, yeah. Glory for uh for a threat actor, douchebags that they may be. Um so listen, hey, the what they do, what what the the payload does is that actually, and this is where it starts to vibe with team PCP, is it's actually a cloud native um uh info stealer. So the first thing it does, which is really unique, is it downloads and installs four SDKs, the AWS, the Azure, the GCP, and the GitHub SDKs. So it can then talk to those platforms programmatically um uh via the payload. And it basically goes and does what you think it does for a cloud native um uh infostealer across all four of those environments, and it sucks up a bunch of stuff. It also, by the way, Jen, um sucks up Claude. Um we're seeing this now more and more where info stealers, including DPRK, uh Invisible Farah, I think the latest version of Invisible. I could be wrong in this. I think the latest version of Invisible Farah also hoovers up Claude and other AI config files. Um but yeah, it's just it's just a kind of cloud native uh info stealer. Um it's meant to be run in either a CI environment or on a workstation laptop, and we'll just suck up all those credentials and things. Uh, if it runs in a CI environment, if it runs in a EC2 instance, it does check metadata to see if it can grab um data out of metadata, which is kind of classic AWS and um and cloud tradecraft. And yeah, um it's fun little payload.

Jenn Gile 6:38

Fun, fun. Let's take a look at the um threat graph that we have put together here. So we have warden. We have this uh domain audit.checkmarks.cx, and then we have uh two c2 servers. Maybe talk through what these you know relative chips mean.

Paul McCarty 7:02

Yeah, so basically in the in the if you uh deobffuscate this all the way down, um turtles slash deobfuscation all the way down, um basically this X fills out to um a lookalike checkmarks domain, checkmarks.cx. And we saw something similar to this when team PCP. And the other reason that people are attributing this to team PCP is that they did take credit for the checkmarks kicks um uh attack, um, and they used similar tradecraft there, same thing here, so look-alike domain, um uh X fills, uh that all that hoovered up cloud stuff to an endpoint in checkmarks.cx um and an endpoint called telemetry, which you see this quite common. Um bad guys will use kind of telemetry endpoints or you know fake ones because it looks legit, right?

Jenn Gile 7:57

Yeah, for sure.

Paul McCarty 8:00

And and I don't know if the I I actually haven't looked at this part of the the payload enough. Um, but I think that the secondary I'm I'm gonna guess the secondary X fill point is the IP address, but that might just be what checkbox.cx resolves to. So I haven't verified that.

Jenn Gile 8:16

You know what? Uh we walked through all of that and I just realized I never added it to the stage. So just in brief, this is what we've been talking about.

Paul McCarty 8:25

I was wondering because I didn't see it. I know, user errors, right?

Jenn Gile 8:29

Uh no, definitely it's me. Um, so kind of clicking back over here. Uh what you can do if you come to this page is you can get the uh threat description that Paul was discussing, all of these payload details. Um, I see since I looked at it this morning, the IOCs have been updated, which is super helpful if you did ingest this. Um, can help you kind of take a poke around. We have evidence linked, and then um this would be the threat graph showing the relationship between Bitwarden CLI package, that uh sneaky domain and the um C2 servers. So I think what would be interesting.

Paul McCarty 9:12

Oh, do you wanna I I was just gonna say I'm I'm literally updating that exact report right now because Tom Abai has done a great, I think that's how you say it. Tom, if I said your last name wrong, I really apologize. But Tom is somebody I've been following for a while, great researcher. He's done up an amazing uh uh analysis of the payload from beginning to end. Well, the whole thing, the whole kill chain from beginning to end. Um, and so I just put that into um the uh uh external evidence and references section inside the threat report. Sorry, Jen.

Jenn Gile 9:44

No, no apologies required. That's uh it's always great to get the fresh stuff. So um let's talk about why or why you don't think that this is the third Chai Halud wave, the third coming of Chi Halud, as the threat actors have claimed.

Paul McCarty 10:05

Yeah, I mean, I think you know, hyperbole is you know, we we live in a culture. I mean, team PCP is like spending a lot of time. Well, they were, they're spending less time on Twitter than they were before. But, you know, I said to him publicly, you know, I mean, not that I'm rooting for the bad guy or anything, but like you guys are out there talking a lot. That's just that's not good, right? Like you're just drawing attention to yourselves, you drop an opsect, you know, like maybe don't do that. So this is definitely not shy hulute. I think all the researchers that have looked at this that I trust, um uh, you know, don't think this is the original threat actor. Um, and um, you know, one reason for that is the kind of so basically if you go and look at the actual commits that the threat actor made um in the um Bitwarden um CLI uh CI config and GitHub, uh, you know, it's kind of like they tried multiple times in public commits to try to get the thing to fire off, right? Which means that they weren't staging this. You means that they were doing this in in more or less real time, which is fair enough. But if you do something in real time, if you're experimenting in real time, you know, you drop hints, like you, you know, you expose your thinking, you expose your flaws, you expose your tradecraft. And that's why you know the the APT nation state threat actors never you know almost never do that. Um, so I would say that's part of the reason I don't I don't think it's shy halud second coming. The third is that the worm was yeah, not very wormy. No, not very wormy. Uh when I checked last time I checked, three people had been worm. Now that is three people, just to be clear, I'm not that's three people, and I went and looked and they got pwned properly, right? Like their you know, GitHub credentials and a bunch of other stuff was X filled publicly, and and that's part is similar, Jen, to Chi Halud. So basically, what happens is not only are these these X-fill sources, and by the way, I haven't had a chance to kind of really drill into what's getting specifically X-filled there and what isn't, but what I know based on what I saw last night before I went to bed is that this is following the kind of Chi Halud style, where when they X-fill stuff, they drop it into public GitHub repos. And so what it looked like to me is that they were a la shy halud, they were creating net new repos in the compromised users that had common strings, so the team piece or team piece beer, whoever it is, could go and like find those easily using the API, the GitHub API, the GitHub search, which you could. Um, and um uh so that's that's very similar.

Jenn Gile 12:46

Um yeah, you know, there's a difference between inspiration and uh the real thing, right?

Paul McCarty 12:53

Right, 100%.

Jenn Gile 12:56

All right, let's put a bow on that. Uh, I don't think it's like the most fascinating sample for good reasons, you know. This is hopefully not a wide impact, but I want to talk about a trend that you and I have been observing for a while. Uh I talked about it a bunch last week when I was in Phoenix for VolmCon and in Denver for Snowfrock, and that is uh NPM lifecycle scripts. And so I want to talk a bit about what they are and uh what you might want to be thoughtful about um because they do open you up to the probability that if an account uh that you trust, a maintainer you trust, has been compromised, that if you're using these lifecycle scripts, you're a little more likely to install something you weren't expecting. I mean, certainly it can come about in you know bad from the core types of malware as well. So um here's how I describe these scripts, and you you tell me if you like this definition or not. Uh you know, when you're a vendor, you want to make using your thing as easy as possible, right? Uh the easier you make it, the less friction there is, the more likely people are to use it. And so what uh these lifecycle scripts do is mean that when you do NPM install, you don't have to go through and like approve each little thing to get installed. And um, so it can include like a pre-install, a post-install. And uh what we're seeing is this little convenience factor. Um threat actors take advantage of it. You know, they took advantage of it with this Bitwarden thing, they took advantage of it with Axios. I mean, we see it in almost every ATO and certainly lots of non-ATO situations where they say uh we're gonna hide this, you know, uh benign looking file in the package and it's just gonna get auto insold. And that's why we say um it's a different you don't need an attack path with malware. Uh these lifecycle scripts essentially create that attack path from inside the colors in the house. Um so, Paul, what would you say about these scripts?

Paul McCarty 15:30

Oh man, we could spend an hour talking about just these scripts. So listen, npm gets a lot of shit for still having lifecycle scripts, post and pre-install script. There's also something called an install script too as well. But um so they get a lot of heat for it. Um, but just to be clear, all of the package managers have had historically something similar and still do. Here's the thing. So, you know, PyPy famously, you know, started um they they you know, they basically the the underscore underscore init files, you know, they did some stuff so that those weren't auto-running. But the reality is you can still create those weird PhD files or whatever they are. There's there's other ways to auto-start. Oops, hitting my mic. I'm getting so excited. And there's other ways to auto-start in Python too as well. And the same thing happens across the board. And the reason why is let's just be clear packages are not libraries all the time, right? In other words, they're not meant to be imports. Sometimes they are, right? But a lot of times, especially with npm, you're building CLI tools, and these are you know, these are tools that you're gonna like piping stuff in and out of, you're gonna be using them. And so you need that, it it just runs in a different way. So, what we're doing is we're expecting uh we're expecting you know two totally different use cases to like kind of follow the same, you know, instantiation uh mechanics, and we just can't do that. So as much as well, a couple other things, as much as I would love to see the pre- and post-install scripts go away, I like them being there because A, it's easy for me to detect, and everybody else is scanning, the first thing we look for is post and pre-install stack scripts, and right and all the low-end thread actors and even some of the high-end threat actors still use them, and so that makes it relatively easy for us to find them. A B the reality is that having written a lot of you know JavaScript CLI tools, you know, the post and pre-install scripts come in handy, but then there's also other things you can do. Like there's, for example, npm supports this this bin uh component, which you use for for CLI tools, which basically basically creates you know a simlink in your in your uh uh and sources the path the right way. So it takes a JavaScript.js file and makes it look like it's a binary and runs, you know, in your path is the its path for its local instantiation is is exported to your path variable, and so you can use it. Those are really, really different use cases, and we have to understand that's why these things still exist. Do they cause us pain? Yes. Are they easy to detect? Also, yes. So it's a it's a more complex, and it's just like everything else, it's like we were talking about earlier in you know in our chat. This, you know, pin versus um you know, yeah, like pin versus pinning cooldown periods.

Jenn Gile 18:25

There's a myriad of things that you can do to like add some friction for the threat actors. Some of those things are easier than others. Um, so like you look at PNPM, you look at Bun, you look at other ecosystems where these lifecycle scripts are off by default and you have to opt into them. You know, what's different about npm is it's on by default. And people are using these without realizing what the risk is. And that's where we have some opportunity for change, right?

Paul McCarty 18:59

Yeah, for sure. I mean, I think that the reason they're on by default is because of that earlier use case that I was talking about, right? Like I get why it's still there and why it's still enabled by default, you know. I mean, you can make the same argument about VS Code and tax file, why it was, you know, why in why it's still so easy to to enable those things. But you're right. I would also say, just to double down on this, that you know, if you're a developer and you're developing like a true library, you know, Pnpm makes some sense, right? But if you want to build a CLI tool in JavaScript, you're gonna go to npm, and that's just the difference between the use cases.

Jenn Gile 19:39

So I uh dug up a resource this morning. Let me find the right tab. Um OWASP, which uh I know you and I are very familiar with them, but not everybody watching might be. OWASP, I always forget what it stands for. Um, is essentially uh the organization for application security. And I'm gonna leave it at that because what it stands for is less important than what it is and does. So OWASP has published this, uh, they're calling it a cheat sheet of NPM security best practices.

Paul McCarty 20:17

Oh boy.

Jenn Gile 20:18

Oh boy. Um I haven't yeah, I hadn't either. Um I haven't even looked to see like when it was published, but maybe we can there's probably 10. I had to hazard a guess. Oh no, there's 11. Look at that. 12. Okay, they wrote their normal top 10 list. I love it. Um, I think there's some very obvious stuff in here about you know, avoid publishing secrets to the NPM repository. Uh enough said about that. Enforcing lock files. Uh, right here is where they kind of talk a bit about uh minimizing the attack surface by ignoring run scripts. And uh they talk about using a loud list for lifecycle scripts. So I'm not gonna make you like have a hot take on this uh document because I've just seen it for the first time. That's unfair. But I will go ahead and share the link in the comments so that anybody who wants to take a look at it and see you know what value there might be can do that.

Paul McCarty 21:24

I mean, there's there's good stuff here, Jen. I'm only I'm only five in of the 11. So there's there's good stuff here, but I mean none of it is groundbreaking.

Jenn Gile 21:35

But you know, here's the deal like it's not groundbreaking, but you and I go to a lot of conferences and talk to a lot of people, and a lot of these things aren't happening.

Paul McCarty 21:48

Yeah, 104. I mean the whole thing, like you know, number six or whatever, the artifact one, artifact governance and supply chain protection. So they're basically saying that you know, use some sort. Of proxy. Either it's something that you build yourself or you use a local NPM proxy, or you use something like Artifactory or some other kind of place to store your packages. The reason that breaks down in a lot of organizations, just to be clear, is because you implement this and then developers start complaining and saying, hey, listen, I need this new library, this new version, and you know it's not in Artifactory or whatever. And then some team that doesn't really understand how a software sausage is made takes two weeks or three weeks or six weeks to okay it and then finally gets added. And that just breaks, you know, you know, the the ability to build and write applications quickly.

Jenn Gile 22:35

And so one of two things happen in that circumstance. Number one, it slows down, or number two, uh, they find a way around it, whether an approved way around it or an unapproved way around it. And the outcome is the same, you make your security processes too hard to use or not well aligned with software development, and they're in the way. Now, what I'll say is uh it's been interesting. I'm hearing more and more people talking about doing private registries and wanting to see private registries. So yeah, uh it will be interesting over the next year to like see how many people are increasing that adoption.

Paul McCarty 23:21

Yeah, I agreed. Um, continuing to look at this list, number seven, responsibly disclose security vulnerabilities. Now, I haven't read the blurbs underneath it. I don't know if they're aiming this at people outside of the maintainer group or if they're talking about the maintainer group. But the problem I run in, just to be very explicit, is that when I find a vulnerability or I find a malicious package, reaching out to the maintainers often is very difficult. And if especially if it's a vulnerability, you know, often you're gonna get a lot of you know pushback.

Jenn Gile 23:53

So, like, I mean, a lot of these yeah, they're talking here specifically about security researchers following responsible disclosure. And I would apply exactly what I said about the last thing to this of if you make it too hard to responsibly disclose, then the benefit goes away, right? Uh yeah.

Paul McCarty 24:14

And even when you do have a good pipeline, sorry I interrupted you there. My apologies. Even when you have a good pipeline, like for example, you look at the um uh you look at the curl team, Daniel, famously, you know, what like the most the most visible, uh transparent, you know, open source project that accepts and has been doing this for a long time, accepts both bug bounty, you know, uh submissions and and disclosures, they're getting slammed by so much AI shit. Well, and now it's even worse. Now it's changed. Daniel says he doesn't really know how it's changed, but now it's not slop, it's mostly not slop anymore. It's good, but the problem is is just the volume of it. Um, you know, the models, the uh Opus and you know, 4, 6, and 4.7 had a lot to do with that too as well. But so I mean, I guess you know, like I said earlier, these are all things that are enable 2FA, you know, NPM now um is tackling that and and you know, Python.

Jenn Gile 25:10

I see tokens in here, which honestly, uh this may be a little dated. We'll have to dig into the dates, but right um PSA out there, uh leaked tokens is a leading cause of breaches these days. So if you have an option that's not uh just a token, you know, go get yourself a hardware key.

Paul McCarty 25:39

Well, and like the the problem with RC tokens in particular, right, which is I I think what they're talking about here. Let's see, npm token create um uh well okay, so the the problem with like uh 2FA is great and we all should use it where we can, but the problem is when you're deploying you know the same npm package uh you know maybe like three or four times a day, that 2FA push, you know, becomes an obstacle, right? And so we have to create automation and sure people should be using things like you know trusted publishing and you know between you know GitHub and NPM. But as we saw with today's attack, you know, trusted publishing was enabled, and still the bad guys were able to pone uh you know the the Bitwarden CLI. Um so I mean I'll again with a lot of these things, man, it's it's easy to say them, but it's really fucking hard to do them. Um and and that's always been the problem, you know, like why aren't people scanning, you know, with pre-commit git hooks? That technology's been around for 25 or 30 years, but nobody does it because you know nobody does it.

Jenn Gile 26:48

Yeah, yeah. I think um, you know, the other top question I definitely get is like, why do people not do these things? And like you said, it's certainly because it's hard is sometimes the reason. And also I think there's a lot of um, you know, human psychology behind it. We have biases of like, well, nothing bad has happened, so nothing bad is going to happen kind of things. But we even see with organizations, people who have been popped, that even after that, they don't necessarily enable the things that would prevent it from happening again, or at least decrease the probability. And I mean, yeah, I don't have a great explanation for why that is, other than it's hard. It's hard to do this when it's not your full-time job and you know you don't have the the resources to dedicate to it.

Paul McCarty 27:42

Uh there's actually 12 things on this list, Jen. The last one I know.

Jenn Gile 27:45

I love that it's an OWASP page that's not a top 10. So I will say a couple of these things are like you should know this thing exists rather than yeah, a genuine thing you can do. Because they are talking about typos squatting and slop squatting, slop squatting, slop squatting, dependency confusion attacks. Um, yeah, worth digging into more. Uh looks like a reasonably good resource. Yeah.

Paul McCarty 28:12

Yeah, and and just because I have some observations about the obviousness of some of these things doesn't mean I think this is a bad document. I'm glad they had it. I wish I had known about it before today, but um, I just want to double-click on prevent dependency confusion attacks. Dependency confusion attacks be happen because people create internal private packages, right? Which they should be doing, right? Which is a good thing. And because of the way the package managers are built, that if you if you come up with a public version of something and you know somebody hasn't you know taken the the steps to the kind of protect themselves from that, they will get the public version of that. And we've known about dependency confusion for years, even before Old Mate Um, okay, what was his name? Um him and the guy from Critical Thinking. Anyhow, before they they made it famous in 2020 or 2021, you know, people have been doing dependency confusion for years, and the package managers haven't really done anything about it because that's just the way it works. So a lot of this is just kind of the built-in um, you know what's the word I'm I'm tired, so I'm not thinking the word. Lethargy. That's funny because I'm lethargy.

Jenn Gile 29:22

Yeah, that's what popped out.

Paul McCarty 29:24

The lethargy inside of the package ecosystems, um, you know, to to do real fundamental changes around things that actually affect developers' use of their tools. Um, but you know that's what it comes down to. Dependency confusion exists exists in NPM because you can make private packages either inside of NPM or other places. And, you know, if you call them, if you call that name of that thing and there's a public version of it, you're probably going to get the public version of it before the private version. And that's something that we need to address at some point.

Jenn Gile 29:59

Yeah, something that I think you're calling out without saying it, and sorry if I'm putting words in your mouth here, is I think there's a uh misconception that dependency confusion typosquatting is like obvious, and you're a dum-dum if you consume it. Am I picking up on what you're laying down?

Paul McCarty 30:23

Oh my god, I've said the same thing from stage a couple of times, like 100%, especially with typosquatting. You're you're right.

Jenn Gile 30:28

People apply, think about like, oh, you didn't see that was a zero instead of an O. And it's like, well, you know, you have to understand, first of all, we can all get pwned by social engineering. I mean, the stuff that people are doing these days is gross and sophisticated. And anyone can click something in an email, but that's not what we're actually talking about here. So, with like typosquatting dependency confusion, this is more relying on like machine automation in some cases. Like, you may not be explicitly reading through this and picking it.

Paul McCarty 31:07

100%. The you know, oh my god, that could say so much about this. Typos squatting in particular, people look down at it like, oh, you're such a dummy, you know. Who who would be the idiot that would, you know, put a zero instead of a O, or you know, would use an I instead of a Y, or whatever the case may be. Well, who what idiot does that? But this is typos squatting is so much more effective. And by the way, you know, everybody talks about these big high impact things like Bitwarden and you know, chalk and debug and you know, all the singularity stuff and the shy lude stuff. But the reality is that every day, if you look at the volume of malicious packages that are hitting NPM and PyPy in particular, the vast majority of them are typosquatting and dependency confusion attacks, and they're effective for a number of reasons. And for people to like look down on organizations that get pwned via these is really kind of frustrating because they don't understand how the software sausage is made. The most famous example that I use is that, and you and I have talked about this before, that Web3 parser. Um uh so there's a famous NPM package that and it's only a few years old, or at the time that it was poned, it was only a few years old. So it was new. Um, you know, it wasn't hadn't been around for years, like chalk and debug and lodash and all these other things. But um, it was new and it was named Web3. But what it did is it parsed Web3 events and then sent them wherever you wanted those things to go, right? So the bad guys just created a package called Web3 uh parser dash parser, and then they artificially inflated the download stats, which by the way you can still do. Thanks, MPM. Um uh and you know, a bunch of other things. They actually made that package look very you know legitimate, right? Yeah, it's one of the one of the best things.

Jenn Gile 32:52

Well, and they made it do what it said that it did, and that's the most like I think a lot of people don't understand. A lot of these packages actually do what they say they're gonna do.

Paul McCarty 33:03

And they don't use post or pre-install, they don't use lifecycle scripts, right? So, like web3 parser is a great example of that. It actually parsed web3 events, and if you know, if the if nothing else, you know, you're using it, you install it and you import it and you start using it as part of your application, and it's doing what you think it is. So there's nothing there to make you think that it's doing something bad. In the meantime, it's silently you know, x filling all your web 3 events to the bad guy as well. But like they took advantage of the fact that the name of the GitHub repo was Web3 parser, and the name of the package was Web3, and somewhere else they called it web three.parser.

Jenn Gile 33:39

So they basically there was within the taking advantage of the original package not having the best naming, and then they picked a better name. Uh before we wrap up, I want to have us talk briefly about a couple packages that you came across what two days ago that we saw were targeting a specific company because I think it uh helps tell a story of what we're talking about. We're not gonna name the company, they're aware of talked with them. Um they know what happened, but like yeah, talk about what you found.

Paul McCarty 34:15

Yeah, I didn't know that Jen was gonna bring this up, but I'm really glad you did because this is super timely. The uh bad guys this week targeted a particular company, an individual single company inside of an ecosystem. And we'll leave both of those kind of up, you know, up to or we won't talk about it. But like the the reality is the attacks were successful or not weren't successful, but could have been successful because they actually used multiple ecosystems. So they built packages, malicious packages in multiple ecosystems targeting the same users in the same company, right? And that's just to be clear, they were not targeting the company, they were targeting people that were going to use this technology, blah blah. So um the and and we didn't used to see this. We the only time we would ever see multiple packages in different ecosystems is very it was rare, and it would only be like you know, glassworm and a couple of the other really big, well-done um APT style threats. Well, now with agents and with generative AI and these really, really smart models, it's really easy for you. So the one thing, so just to be clear, what Claude won't you do is it won't it won't let you say, hey Claude, write me up a new info stealer in JavaScript, right? But let's say you get your hands on one and you modify it yourself, and you know you work with Claude to like find at the function level, you know, make it be successful. Once it's doing its thing in say JavaScript, you can then say, Okay, now Claude, rewrite this in you know, Python or rewrite this in Go, right? Whatever, and it will, it'll do that. So um uh in and the gutter reels are getting better now. So you know they're they're starting to see when there's there's uh um you know movies.

Jenn Gile 35:58

Someone's writing nasty code or asking for nasty code, yeah.

Paul McCarty 36:01

But you're not asking explicitly write a payload, instead, you're saying, hey, can you just take this thing that works right now and put it in this other language? And it will happily do that. And the power of that is just so and the immediacy of it makes this um so anyhow, cut to the chase. I think we're gonna see a lot more of this happening. All of those packages were deployed within an eight-hour time span across the different ecosystems, right? So they had it all queued up. Now the payloads in this case were in clear text and they weren't super sexy, yada, yada, yada. But you know, as soon as you know people, bad guys start perfecting this, you know, they'll start obfuscating and hiding it better, and this will be a very successful thing. So um, I'm glad you called it out.

Jenn Gile 36:42

Yeah. All right, I'm gonna share uh one comment that we got. We have someone on LinkedIn, uh, they're gonna steal your software sausage. That's fine so long as uh we get the residuals, right? Is that the way that we say that? Yeah, yeah.

Paul McCarty 36:56

10%, mate. 10%.

Jenn Gile 36:58

10%.

Paul McCarty 36:58

I've been I've been saying that for years. They the infosec doesn't know how the software sausage is made. So I'm glad that somebody likes it. Yeah.

Jenn Gile 37:06

All right. Um, I hope people enjoy this. Um, leave some comments about what you like about it, what you want to see us talk about. This is probably about the length and format that we'll stick with. Again, we're gonna try to do this about once a week, uh, travel schedules allowing. So yeah, Paul, it's been good.

Paul McCarty 37:24

I'll try to be more uh energetic in in uh more sleep next time.

Jenn Gile 37:29

All right.

Paul McCarty 37:31

Ciao.

Jenn Gile 37:36

Okay.