Jenn Gile 0:00

Okay, hello. It is Thursday, July 23rd. Paul, you're down in Sydney today. How are things in Sydney?

Paul McCarty 0:10

Cold and blustery. But yeah, I think the temperature right now is nine Celsius, I think. I'll tell you here. Uno momento. It is seven. I'm sorry, even colder. Seven. So yeah, I was wearing my yeah, I was wearing my puffer.

Jenn Gile 0:29

Well, up in the Seattle area, we are in like the heat of summer. It's been miserable. Um, but it got cooler today. So hopefully, I don't know. You and I have another week before we head to Las Vegas. And uh pro tip this year, I'm packing a humidifier because it is so dry. And by the end of the week, like I can't wear contacts, I'm dried out. So this year the humidifier is coming.

Paul McCarty 0:53

Let's yeah, going from Seattle to, I mean, like you and I were saying this earlier, Seattle or the Gold Coast, where I am, both very nice and humid. Right. I think the difference is I was saying this earlier is that because I lived in Utah for so long, my body, even though it's been I've been away from there, kind of is used to it.

Jenn Gile 1:08

So I get my lips before.

Paul McCarty 1:10

Yeah, it gets my lips get cracked and all that, but then I get used to it. So yeah, yeah.

Jenn Gile 1:14

All right. We have our listeners are super stoked about this. We've got quite the list of things to talk about today. Um, in no particular order, the first thing on my list is the disclosure from Hugging Face that came through, I don't know, three, four days ago. Uh, they said that uh, and I'll quote here a data set uploaded to its platform abused a security vulnerability to run malicious code on its servers. And uh I took a look at their um disclosure. A lot of other people in the community did. It was a lot of like, we can't really tell what you're saying happened here. Um, a lot of people said it was very obviously written by AI, which I can concur, which I will say is you know not always the greatest thing in your IR reports. But then um what yesterday uh we saw a follow-up. OpenAI came out and claimed that one of its models uh did the exploit, that it broke itself out. And whoops, sorry, we hacked Hugging Face. Um, they said it was an internal cybersecurity test that went awry. Uh, they claimed that it escaped uh isolated testing environment, reached into Hugging Face's system from there. Um we're seeing two reactions to this news. One reaction is uh kind of just the news being uh put out there is true that oh my gosh, this thing happened, open AI did this thing. And then the other side, uh, which is mostly hanging out in the cybersecurity community, cybersecurity community, that's a lot of words, is uh people calling BS on this claim. And there's various reasons for why people are calling BS on the claim, but ultimately it kind of comes down to a lot of the community thinks that's a marketing stunt and that this did not really happen or didn't happen the way that maybe they're saying it did. They're not providing very much information. So, Paul, uh, you've been looking into it. What's your hot take?

Paul McCarty 3:25

Oh man, well, I'm definitely in that other camp, the the skeptical camp. I wouldn't say that I'm like, I don't think, you know, I think it's I think there's some nuance to my position in the sense that all right, so I I would say the first group is the singularity group, right? Like, oh my god, this is this is evidence that AI is AGI and all this other bullpucky. And I think the other group that I fall squarely in is the much more skeptical group. Um so the details are light, which is always concerning, right? And you see this kind of theme coming out of the AI labs where they like to make these big splashy things they call incident response, you know, publications or whatever, but they really are lacking. They weren't written by people that do IR or anything, right? So um, short story long, I just the details are missing. The idea that like a lot of people on the skeptical side think like, oh, how could OpenAI's you know security be so lax, lap sorry, be so poor that that you know it could find this way the whole out from the isolation and in out to the internet, blah blah blah. I don't see that as being that, you know, that's not a deal breaker for me. But what is a deal breaker for me is that they just haven't talked about you know what happened, and so just my immediate flags go up. Um, yeah, I mean that's that's basically it.

Jenn Gile 4:53

Yeah, this is a suspicious by default community. So uh a report with thin information is not necessarily um encouraging, and we've been seeing these um frontier model companies doing things that certainly the pattern is oh my gosh, look how dangerous this thing is. And um, it's it's an interesting marketing strategy. Okay, segue.

Paul McCarty 5:21

I just want I want to say one more, I just sorry, I want to say one more thing that I forgot to say in my first little blurb. I it's unfortunate because you're right. I think a lot of people are listening to open AI here and thinking, oh, this is just you trying to you know drum up something after the whole mythos create, you know, this whole cultural shifting thing about mythos, right? You have people that have no idea asking me, what do you think about mythos? Is it you know, but um, but here's the thing is open AI's latest models are actually very capable and relatively inexpensive and crushing it. And so it's unfortunate that if this really is some sort of marketing ploy, and it feels like at some level, some N percentage of this is really just you know marketing fluff around something that might or might not have happened. But you know, it's unfortunate that they're they're doing that instead of just like letting their models speak for themselves because I and a lot of other people, because of the anthropic shisel show, have moved over to open AI and other models, and they're very capable. So maybe try to win on the merits of your models rather than making up this contrived mission impossible bullpucky scenario.

Jenn Gile 6:22

All right, sorry, I know we'll have to keep our eye on it. Okay, all right. We added, I just did the mental math, almost or maybe over 10,000 new threat reports in the last few days outside of our normal uh ingestion pipelines. And those two uh that that huge boom in new records came from two places specifically. And so the first one is in GitHub, and the second one is in RubyGems, and they're two very different scenarios, totally unrelated, but both uniquely interesting to talk about. So the first one, the GitHub one, uh, more than 7,000 malicious repositories, GitHub repositories, were um disclosed by a company called Island in a campaign they're calling agent reading, where they said uh at least 800, maybe more of those repositories are posing as AI skills or MCP servers. And this is a wave that peaked back in April. Um so we have, of course, added those repositories to uh our threat database. You can pull them, you can see them today. I think they're under the agent baiting hashtag. However, um, I think what's interesting here is less about oh, these repos are scary, you know, block them, and more the trend that we're seeing and that worries us and should worry the industry about where malware is heading and how threat actors are going to be able to take advantage of natural language.

Paul McCarty 8:02

Yeah, um great segue. I mean, the the concern here basically the the intent here, and it's just a there's a lot of repositories in this campaign, right? And so the idea here was those those repositories were created by bad guys, threat actors, non at non-attributed bad guys, to basically then be pulled in as dependencies or um subject matter uh publications, you know. So basically, when the the AI was looking for, you know, hey, what's the strongest, you know, uh AI model for dental hygiene or I don't know, whatever, you know, like it goes out and finds these things, um uh, which is a very, very, I mean, it's a common thing we're seeing. Like, so the across the board in NPM and in VS Code and all these ecosystems, we're seeing bad guys really kind of focusing on AI, MCP and AI aligned kind of um you know, malicious stuff. Um, and there's like a I'm saying stuff because there's just so much of it across the board, but they're targeting um those areas because what they want to do is they want to get to that natural language, sorry, that natural language boundary where you know you can get it into um an agent and have it do the bad thing. So for for the vast majority of these things, they pretend to be um uh a subject matter expert publication about a thing that get pulled in and they've got instructions, natural language instructions inside of them that does the bad thing, pulls payloads and goes from there.

Jenn Gile 9:35

Um yeah, yeah, and the point here is that's harder behavior to detect because many of the tools that are out there are designed around detecting the code that does the bad thing, not the natural language instructions to do a bad thing.

Paul McCarty 9:54

Yeah, and I'm also um concerned, like first, I'm concerned on two fronts. First, because this is just a whole new thing, and it's just we've never seen anything like it, and there's not really a lot of ways to protect ourselves from this. And it's it's concerning for me both personally and and as well as you know, kind of professionally. So that's one thing. But the other thing is that I think what'll happen now is that the whole industry, you know how the cyber industry is very, you know, thematic, will be like, oh, we need to address this, and we'll just all the effort and budget dollars will all go towards that, which I'm not you know, I'm I'm expecting it, but I'm also worried that then we're gonna like just drop the ball because historically this has often happened. We dropped the ball in those other areas that have been successful for us, right? Those places where we still need to do the thing is like make sure the bad malicious packages aren't being um ingested into your npm, your JavaScript, or your Python application.

Jenn Gile 10:44

Yeah, that's a great point. I mean, we see that uh on repeat in the tech industry, whether it's cybersecurity or not. You know, we you and I both lived through the on-prem to cloud, on-prem is dead in a uh, you know, phase. Um there have certainly been other phases like that where it's, you know, oh, agents are here and no one's ever gonna write code again. The truth is always somewhere in the middle. Uh, there will continue to be your standard malicious packages that will continue to get harder to detect um through the means that we've been talking about on the show. Uh, whether that be, you know, clustering or hiding things in dependencies, but they will continue to be code. And then there will be a set that will be this novel approach of hijacking an agent through um natural language. So yeah, the truth is somewhere in the middle. We're gonna need both. Uh, beware the hype because it's coming.

Paul McCarty 11:41

And beware the hype.

Jenn Gile 11:44

Okay. Second verse to the things to say, but about yeah. Moving on. Uh you added 2,539 new RubyGems threat reports to the database this week. And when you messaged me, I was like, are you sure, Ruby? Really? What's going on over there? Um, and again, this is another like something unique is happening. Um, these packages have indicators that suggest that they're similar to the Gem Stuffer campaign that was um talked about, let's see here, back in May or so. I think maybe Socket found the Gem Stuffer campaign. And uh not a guarantee that it's the same threat actor or the same campaign, but similar vibe. Um, and these packages are not necessarily malicious, but what they're being used for is a means of hiding exfiltration in gems. And we've seen threat actors use other technologies in similar ways um to evade detection. So let's rewind. We had um uh uh crypto wallets became big, you know, in the last year of DPRK hiding payloads in crypto wallets because they um look like regular traffic. Presumably, what's happening here is these are commits that contain data, right? That the the way that these are getting exfiltrated is through these commits to projects. What are you seeing with it?

Paul McCarty 13:26

Yeah, what they are is they're actually net new uh packages, they're net new RubyGems packages. So basically, um this campaign that Socket found several months ago, the the Gem Stuffer campaign, was really um similar to Shy Halude and Team PCP, where what what for Shy Halude and Team PCP, what they would do is they would they would steal all your credentials, they would compress it, and then they would create a net new repository with a name, and that just allowed the threat actors themselves to go and search GitHub, find those those X-filled payloads and pull them and then you know use those credentials. This is similar to that, as I understand it, in the sense that this was targeting the UK government, um, and it was X-filling the contents of those compromised systems as RubyGems packages, which is like seems like there could more efficient ways to X-fill data, but you know, hey, you know, innovations always interesting, I suppose. Um, this latest wave, again, it's not for sure because the payloads just aren't there like they were in the first one. Like I went and inspected some of the payloads from the first wave of gem stuffer, and sure enough, it looks like X-filled data, right? There's some other stuff in there too as well, but and and it's kind of it's different from from package to package, but there was obviously in many of those packages from the first wave X-filled data in them, which you know leans towards this theory that this was exfiltration from the targets. In these new packages, I could find any X-filled data, but they're still there, they're creating them. And the name the naming construct is is very similar or the same. And so the the expectation. So I reached out to the RubyGems team and trying to get some clarity and and around that. Um uh so maybe more to come on that in the future, but I don't think it's a it's a big high impact thing, it's just like a lot of packages when we don't really know why, and that's always a concern, right? When you're using when you're seeing somebody use automation like that, like just because the first shot misses doesn't mean that the second shot isn't gonna hit. So we wanna, you know, we want to try to understand so we understand if there's something we need to protect against um going forward. Is that a good segue to our other Ruby shot?

Jenn Gile 15:38

That's a good segue to our other one. I feel like this is like the wacky news, like, truth is stranger than fiction. Um what you shared with me as we were getting ready to record is um RubyGems has been leaking user API keys for years. And this was an unintentional uh flaw that they corrected and they're notifying people about. But uh, I think like the TLDR is if you use RubyGems and you've got API keys in there and you haven't gotten a notification, maybe better safe than sorry, you know, go ahead and rotate. But uh Paul, you know this through some uh networks of yours, and it's you know to some extent public knowledge. So um yeah, share what's going on there.

Paul McCarty 16:24

Yeah, I mean the the GHSA is out, the GitHub Security Advisory is out. Um I don't know if there's it sounds like there might not be a CVE, but um, yeah, so basically my mate Luke, um down, he's actually near where I am right now, but um uh you know he works for Truffle and Truffle identified that um it looked like there was um some caching of API credentials um in the Ruby gems. Um only uh you can only find it was certain older clients were were doing this because you had to ask for the right you had to ask it for the right way. So you had to um you know not everybody was getting it, um but uh the point is that under the right conditions, unfortunately, the the CDN was caching those API credentials, um, so that you know exposing those and people were getting somebody else's API. Um so imagine trying to push packages to RubyGems, and you're like, hey, how come I can't push this package, right? And then you go and do like a RubyGems list, and you're like, wait, that's not the name of my packages. This is somebody, and then you go and look at them, and you're like, hey, that's that's gem's package. Why am I seeing Gems package? Um, that's the kind of thing that could could happen out of this. But anyhow, RubyGems um handled it, they jumped on it really, really quickly. Um, just big shout out to them. Um, super impressed with having dealt with NBM and other ecosystems for years, where it's not as responsive. I and I said this to the RubyGems team. I was like, you guys crushed it. Like, this is the best response I've seen from a from a registry ecosystem um team, volunteer or otherwise, um, ever. So big shout out to them. They fixed it, um, and they're letting customers know right now, and they you know they're disclosing it. It's already public now. So um big shout out to Luke. Um, I don't know if he's listening today, but um, you know, that was entirely on him. Um, so good on him.

Jenn Gile 18:15

Yeah, uh, always good to hear about good incident response responses from uh the open source ecosystem. Okay, last topic.

Paul McCarty 18:25

I actually want to say I want to say one more thing. I think it's important because like when this kind of thing happens, we have this network, right? And you reach out to your network and you figure out the right people to tell, and that just kind of came together really, really well here, right? That I know some of the people on the RubyGems team, and you know, so this is the kind of thing I really would like to put back out there. If you're doing disclosure on either side of that, try to find those people that can bring the conversation together as quickly as possible and as powerfully as possible, right? If you're just sending something to an email and it and you're not hearing back much, well, maybe that's because you haven't gone and done what you need to do, which is you know, reach out to people inside your network if you can put that together.

Jenn Gile 19:04

So that's yeah, it's a great example of like the real value of a network beyond career progression. Okay, for real for real, crash stealer. Um, we teased last week that we would be talking about macOS malware, which is not something we really bring up a whole lot. And in part, that's because um we don't see a lot of malware that targets specific ecosystems. A lot of times it's more agnostic. But our friend and uh top contributor to open source malware threat intel reports ties from JAMF published a really great report recently on this campaign. He's called Crash Stealer. What it is, is it's a novel uh malware info stealer. It's a C C and it impersonates Apple's crash reporting framework to harvest stuff. So it's harvesting credentials, keychain data, you know, the usual stuff, and then it's exfiltrating it. Um, Paul, you took a look at this after um Tai's published his blog. And um, you know, it's always interesting to see the way that these things build. So you did some building on the work that he did. And uh to kind of summarize uh sort of three discoveries that you made. Um basically you discovered that there's uh a second and a third track to this, that it is not just crash stealer, but that this threat actor uh has other, what's the right way to say, pans in the fire, pokers in the fire? I don't know. Something's something's on fire.

Paul McCarty 20:40

What other weapons in their quiver.

Jenn Gile 20:42

Yeah, something else is going on. Um so one of these other ones is a rat, a remote access Trojan. Um, after Ty's published his article, um, the threat actor did uh clean up some of the crash dealer stuff, some but not all. Um, and very, very quickly spun up um a new track. So we've kind of been holding off publishing. Um we want to make sure that we uh can support the research on this without you know burning the infrastructure and having them go underground again.

Paul McCarty 21:20

I think this is just a really unique story. And the reason that we've kind of held off on publishing is that I think that the story that I want to tell is about in this new world that we live in with AI and access to you know weapons, cyber weapons, software supply chain in this case. You know, what used to be true isn't really true as much anymore. So what we're what we're seeing right now is we're seeing a single threat actor, which uh which is obviously not a single human being, right? But we're seeing a single threat actor in a campaign actually using many different, totally unrelated malware strains in their in their and it's just I've never seen this before. One goes away and another new one goes. Comes in, and you're like, what just happened? Did I just go out of one dimension where that was true and now into another where this other one? Um, and so I think that's the thing that really kind of sticks with me is that you know, whether this threat actor is buying these things from somebody else and just buying many multiples of them, right? Or if they're creating them themselves or they're taking old code and making it new again, a la team PCP and my esma and stuff, who knows? But I've never seen one threat actor group you know run through so many massive, big, totally independent, you know, weapons of mass destruction as these guys are. So I think that's the thing that stands out for me, Jen.

Jenn Gile 22:40

Yeah, and I think, like you said for the beginning, this kind of um pivoting, you know, ability to be this diverse, you know, it's what like the malware industry's e-got award or something like that. You know, they're they're they're winning multiple categories here, um is potentially being traced back to the way that LLMs are making this easier to develop quickly.

Paul McCarty 23:10

And and we're seeing this echoed across, you know, as I talked about something totally different earlier at the same time. We're seeing the same thing here, which is like everywhere we're just seeing the number of net new, novel new info stealers, which all you, if you look hard enough at them, they all have the same kind of core, right? They all are born from the same Adam and Eve or the same Eve, right? But people are just iterating on these so quickly and so fast, and so many different new um info stealers out there in particular. Um, they're just uh it's like triples, they're just um bam! I just dropped a Star Trek pretty good.

Jenn Gile 23:47

I I saw a reference to Gremlins the other day, and uh same same vibe, don't get them wet, um, or don't give them water or something. I don't remember.

Paul McCarty 23:56

Don't let them replicate, whichever don't let them replicate. Uh yeah, it's crazy.

Jenn Gile 24:03

Um, so why don't we we've got a little bit of time and um we did have a request from the community to kind of go a little one-on-one on some things. So maybe this is a good opportunity for us to talk about about info steelers because not all Mauer is info stealers. So, like, what are some of the characteristics that you look for in an info stealer? Um, how do they get assembled? Um, yeah, what what do you feel like is kind of a good base level of knowledge for people to have about these?

Paul McCarty 24:35

Okay, we talk about info stealers like they're like a class of thing, and they they are, but they're not. Um so, like the what I'm seeing is I'm seeing ultra simplistic, totally in the clear, you know, 50-line code info stealers. And then I'm over here, I'm seeing DPRK, massively obfuscated, six-stage complex things, also, you know, using info steelers. So the it's a it's a vast kind of ecosystem, but I think that first group where people can basically just go to an LLM and say, hey, create this thing really quickly and to drop it in. This is where I'm seeing the most expansion, right? And so what you're looking for in an infostealer is like, what is it targeting? Is it specific to you know, is it is it focusing on just crypto? Is it focusing just on Solana? Um, is it focusing on uh some of them really, really focus on AWS? Or Azure stealing those creds, and you can tell then that the intent for the author was you know that's what they want. Um, so you're looking for what it's stealing, and then you're looking for what does it do with it? How does it exfil? And that you always have that X fill component because that what does a bad guy? Bad guy creates, you know, steals something, and they gotta have take their loot and they gotta do something with it.

Jenn Gile 25:52

Gotta put it somewhere, gotta put it somewhere.

Paul McCarty 25:54

And so, you know, we built a whole system at OSM um using our kill chain technology that basically takes that X-fill uh point and kind of works backwards towards the entry point and figures it out. It's similar to reachability for um vulnerability analysis, like identifying reachability. The idea behind reachability is that figures out if the vulnerability in a piece of code and you know at the functional level or wherever is actually exploitable, right? Can you actually get to that vulnerability if you call it the right way? In a similar way, kill chain says, you know, what's the it's really what the what the attack path that's really the it's the execution order ultimately of the malware. So you can just ignore the other files that are there, and you know, a lot of these threat actors are just throwing hundreds or thousands of files to hide their shiz. But if you know how to just follow the the the execution order, it's relatively easy. And so if you find the exfil point and work back from that, um it's been very successful.

Jenn Gile 26:55

Uh okay, surprise topic. Uh, it's been such like I feel like it's been a really long week. I forgot that I published some research on Friday about Pollenwriter. And so why don't we wrap up on the Pollenwriter stuff? Uh, and I think this is uh a complicated but not complicated situation. So I read uh some research last week that was published by the team over at Checkmarks where they published a breakdown about a supply chain campaign that they called uh chain veil, and then a follow-up to that that was vibe venom. And honestly, the vibe part is what caught my mind because I was like, a lot of people use vibe. I should see what's going on over in Vipe. And I read through it and something really stuck out for me in the IOCs that they listed. Uh, they specifically listed Tron, Aptos, and Binance uh blockchain addresses. And I thought, oh, that particular combination, you know, the three of them together, that's very familiar. We've been tracking that since the beginning of the year with Pollenwriter.

Paul McCarty 28:02

And before.

Jenn Gile 28:04

Yeah, even before.

Paul McCarty 28:06

Yeah.

Jenn Gile 28:06

Um, and it's, you know, maybe we can talk a little bit again for uh people who aren't familiar with blockchain uh multiplexing. You know, when I tell people crypto wallets can be involved in uh malware, they think of it more like, oh, the crypto wallets are being stolen, but in fact, they're being used as a way to hide traffic uh and data being ex-filled, you know, again, like the gems, like um other things. They they're using that as a part of their uh C2 infrastructure because it looks like legitimate traffic. And this is what makes it so hard for things like EDR to catch them. Um anyway, long story short, I looked at the IOCs for this Vite Venom chain mail um set of something like 13 packages that were published um between like July, June, July timeframe. And wouldn't you know it, uh they had five shared IOCs with uh your pollen writer research, Paul. So um some keys, some wallets, an aptos address. Um they were byte for byte identical. There's uh kind of no doubt here. This is not uh somebody else got a hold of this infrastructure and is running a totally unrelated campaign. This is Lazarus Group um executing their Pollenwriter work. And, you know, we were just talking last week about Pollenwriter and the huge number of new compromised repositories that you discovered. And we talked about how those repositories end up getting discovered. Poisoned. Sorry, brain. I haven't had my second coffee today. Uh, we talked about they um one of the ways they compromise developer repositories is if that developer consumed something malicious in the past. And so I would hypothesize that these um typosquats that check marks discovered are part of that campaign to get people to consume poison packages to then do whatever it is that they've got planned with their whole pollen writer orchestration stuff.

Paul McCarty 30:15

Yeah, I mean, so I think the the first thing is that Pollenwriter is, you know, we talk about Pollenwriter like it's a campaign, um, and it is, but it's also an evolution of a set of North Korean threat actor kind of you know TTPs. So, for example, in 2025, you know, we saw the advent of ether hiding, um, which is basically using specific blockchains like Aptos and Tron, which the the the chain, you know, blockchain is immutable. When you put something there, the whole point of it is that you know that that you can't change that, right? But those Tron and Aptos and this BSC um uh Binance thing have these little kind of memo things that you can change, and those things are mutable. So when you make a transaction, you can basically buy, excuse me, buy your ability to make a change, and that's where DPRK is hiding their payloads because otherwise, they when the first version of Ether hiding, they weren't doing that, and then you know they put their payload there and everybody can see it, and then it couldn't change, and then you went like kind of you know it puts it, it's too public. So then they figured out a little memo thing. So we have to make a distinction between ether hiding and this this a TTP versus Pollen Rider, which is really this human botnet that you and I are talking about, where TPRK has persistence on thousands or tens of thousands of developers' machines based on either you know fake recruiters or or just because as this has grown, a lot of people have been compromised now just when they pull open source. I've we've we've been disclosing this to open source projects and they've been removing these things and whatnot. But so a lot of people are getting compromised in a lot of different ways. But the point is that Pollenwriter is really this like movement, this campaign where it's like has access to all these developers and it's using it to do more bad stuff. That's Pollenwriter in another one.

Jenn Gile 32:07

Helpful. Okay, we're at a little over half an hour. We hit a lot of topics today. Look at that. Uh yeah, busy day. Uh so we'll go ahead and wrap up here. Um, if you're gonna be in Adelaide next week for Besides Adelaide, hit up Paul and another plug if you're gonna be at Hacker Summer Camp. Let us know. Uh, we'll be there all week. We've got now three talks during DEF CON. Uh Paul, you've added a panel in the Cloud Village on uh MCP servers, I think. Melicious MCP servers. So yeah, that should be interesting.

Paul McCarty 32:40

Yay.

Jenn Gile 32:41

Yay. All right, have a good week, everyone. Good weekend.

Paul McCarty 32:44

Thanks for listening, people. Appreciate it. Cheers.