Where the Wild Things are - Kadi McKean and Frithjof Hoffmann

My name's Katie Mckean. I'm an open source community manager at ReversingLabs. What does that mean? It means I interact with the open source community and I work with uh threat researchers and a lot of the open source maintainers in PyPI, uh Java, NPM, you name it. I pretty much talk to them all. So, I have a lot of horror stories that I know and love. Um and this is my colleague. >> Fridtjof Hoffmann. I'm in pre-sales. I talk a lot about people all over Europe about office supply chain and malware analytics and threat hunting. And a little bit of a condensed of that we would like to share with you today. >> Yeah, so buckle up. We've got 25

minutes. We're going to throw in a demo here just to show you guys some cool stuff. Um but before I get into what were the meat and potatoes of today, I'd like to poll the room just to get a temperature check of who we have in here. So, if you are a developer, please raise your hand. >> A few. >> Okay. This is a good mix. What about a security professional? Yeah. Well, that's an obvious one. What about Here's the bonus Jonas. Um threat researcher? Okay. Wow. Okay, I'm I'm actually excited. We don't get that answer too often. So, cool. This is going to be fun. Um so, what are we in for today? This is

what is on the track for what we are doing. Um typically what we see when we are looking at different things in software supply chain security, we see one. Um there's two approaches, right? There's really that hardcore malware threat hunting approach. And then those are the folks who really just want to scan their software to make sure it's like secure, right? There there's kind of two different approaches to this. Um so, we're going to go through that. We're going to go through where things are in the wild in regards to open source, where we're finding it. We're also going to cover what's in your legacy stack. So, uh Mythos has kind of talked about that recently. So, might as

well chat through some of it. Um and then some practical defenses and key takeaways. So, um I think it's always good to just set the table, right? Of understanding where we're coming from on this. And here's the thing. Open source ecosystem, we all rely on, we love it. And the packages you install without thinking twice, like let's be honest, how many of us have just hit like, I don't know, pip install, npm install, and then like >> [snorts] >> fingers crossed, right? Yeah, you don't want to openly admit it, but like we've all been there, right? And this is actually where we're seeing a lot of uh these types of attacks come in through, right? And it's coming in not just

through the packages you love, it's also coming in through dev tooling, um and a few other ways. So, it really cuts across your entire software supply chain from packages you download, tooling, warehouses, CI/CD, and we'll get into that. So, couple of quick numbers I want to run through. Um 73%. So, that's the increase in malicious open source packages we found this year. This isn't like, "Hey, this is a CVE." Right? Like, that's table stakes, people. If you're not scanning for CVEs, you you might be in for a rude awakening today. But, malicious packages, we're talking about malware. So, we're talking about an increase in malware in open source. Um and that's just 2025. So, that's like

90% of those, just so we're all aware, come from the npm community. And that's because that community is extremely large. I'm not knocking the npm community, but they also have some security controls that just weren't that great, right? Um So, and that community actually saw the amount of uh malicious packages double in 2025. So, that 10,819, that is just coming from the npm community alone last year. Um so, how many of you are using npm? Yeah. Okay. So, I just want to that number sink in cuz it's for me I found it a little bit jarring. >> Um and most people it's in your build pipeline right? >> Uh 400,000 that's also the raw number of

secrets exposed in a single shy hulud attack. So, guy downstairs um is actually handing out if you do well in the capture the flag the malware for it that you can actually like look into. So, highly recommend checking it out. Um but 400,000 is the amount of secrets that was stolen um and this is infecting 30,000 GitHub repos. And it was publicly um exposed because it was a mechanism through dependabot, right? So, that's going upstream and it's automatically infecting other things. So, just a few things to think about as as we kind of go through this. Um where have we seen different attacks in the wild, right? I think these are some four really good

use cases actually where they kind of exhibit the different types of attacks we're seeing. So, one, you know, the xc utils, who's heard of this? No? Anyone? >> [clears throat] >> Okay. Okay. Oh, good. We got one. Perfect. Thank you. So, this is 2024, but this is social engineering. We had someone who, you know, openly admitted in the open source community like, "Hey, I'm having mental health problems. Um do we have any folks that want to kind of take over maintaining? Like this is actually like a pretty good project. Billions of people download it, right? Or millions." One guy made a couple of good commits uh and then was like, "Hey, I'm going to start going ham with putting malicious

software in there." So, then he exposed it and went rampant through that community that people were downloading that package. Um PyPI malware surge. So, PyPI in the past year has actually put in some really good two-factor authentication controls to double lower this number. So, their number actually is significantly lower this past year than uh NPM. But we did see that in 2023, which then implemented those 2024 um security controls. Quix, anybody hear of this one? If you are we had some NPM people in here, but does anybody know of the Quix fishing campaign from last year, last summer? Yeah, you're you're raising your hand. You're like, "Yeah, that was a gnarly one." So, this was one, too, where they got in

through the maintainer account. So, this isn't someone who's just putting in a good commit, who's part of the project. It's, "Hey, I got pawned through a fishing campaign." Two-factor authentication. Um and this is where we were seeing, you know, this guy maintains what really well-known packages, and five in the top 10 uh NPM packages, popular ones, were infected. So, this is just going to show that attackers are going after the most popular packages. Why? It has the biggest blast radius and the most chance for it to be successful. So, go big or go home is that mentality there. Um but, what's really cool here is the NPM community actually reacted in a healthy way. And they say that because when

something happened and it started to look off, the NPM community actually like rallied around uh this maintainer and were like, "This doesn't look right. Like, something's going on here." So, open-source community actually responded pretty well to it, even though the impact was a little gnarly for a little bit. Um but, people were responding in a healthy way to be like, "This doesn't look right. How can we help?" Which is really the the open-source spirit. The last one I want to just briefly go over, and the last uh speaker actually brought this up. I forget that it's like DPRK, something North Korea. Okay. Um this is one that most recently happened in April, and I don't know if anybody

heard of Grafalgo uh or the fake recruiter campaign. So, how many times have you had to do like a coding test when when you're talking with a recruiter? Like, probably everybody in this room, I'm guessing, unless you're running your own company right? What's crazy here is the fake recruiter scam is they were actually being like, "Hey, download this dependency." And that's where the the malware came in. What is crazy about this, though, is once it was recognized, the company that was recruiting these folks actually went dormant for like 4 months. Why? They came back and I kid you not, they had a new company name and they actually registered like an LLC in the state of

Florida. So, they were literally working just as hard to make this legit as we try as hard to keep these folks out. So, just goes to show you the level of commitment that folks are taking in in investing really in these types of attacks and seeing what they can get from you, whether that's secrets, credentials, whatever. Um and for me, I just find that disturbing. Like, you're going to go create a fake company to make it look real. That's That's like next level. >> [snorts] >> Um so, for each of I think this is probably a good point where I talk pass it to you and be like, "Well, what can we do about this?" Like, Katie, stop

terrifying people. >> Yeah, yeah. So, as as Katie mentioned in the beginning, we see two types of people dealing with software supply chain things. One is malware and threat hunting. And this is where kind of sort of YARA hunting is coming in, right? You you kind of sort of write your YARA rule. You kind of sort of find to to catch things. And here just a few examples, right? You kind of sort of combine different thing into one YARA rule to kind of sort of strip it down. So, these are techniques that are widely used and time-consuming. So, if you are just a software developer, that might be not in your wheelhouse. So, we kind of sort of will

look into both buckets. So, this is just a highlight saying of three things that we might think you want to have in such a YARA rule. I just put in like the whole YARA rule like in a text channel and you see it has different sections and we want all of them to kind of sort of grab like what kind of secrets can we store what kind of post behavior does it thing have what kind of install base and um the next thing that you would like to do is if you having a YARA rule you would like to retro hunt right you would like to find out is it a good rule so you

will kind of sort of posted to a repository that might give you some answers. So here's a YARA rule in that tool I have it running for a while and it actually caught 210 malicious pieces. Um and give me different kind of things like most matched format and all of that. And so here's like one example of how that then would look like um what kind of software is it and just for you as a bottom you say this is like my YARA rule kind of sort of hit and I can do now in this platform if I'm a threat hunter everything I want to do. So here's a problem. If you are working in software supply

chain security this looks like a Russian submarine. Right? So that's kind of sort of wow I just want to use that extension I just want to know what's kind of sort of in that is it good to use is it safe for for my environment and and that's why I put the same binary I have in here in a piece of software that's just focusing on software supply chain security so it's here. >> [snorts] >> Um instead of me doing that YARA rule development that took like two weeks and testing it and all of that getting results vetting the results I uploaded in here it took actually 7 seconds to tell me this is malicious.

Um I got all of the same information as any other tool. The most important thing it tells me, well, there's malware in there. Please don't use it. So here you actually have like a quick response. What is in my stack? Is it secure? Can I deploy it? Um it's not based on code, so you don't have to ask, "Hey, can I have your code?" It's for the binaries. So if you are developing, you can use it before you ship to your customer. And if you're a customer, you can actually scan it before you bring it into your environment. So yeah, Katie, are there all problems solved with it? Or I know there are something or do we need to do

more? >> I think there's something that I cuz this is just one tool, right? Like there's tons of tools out there, but we we just want to show you that you can actually automate this stuff. But the question I think becomes is like it's not just about the open source stuff or like what's current. It's like, well, what about end of life? What if I have a project that I physically can't get away from, but it's so integral to my application that like I need it? Just because it's end of life, you know, it's no longer getting patches or updates, it doesn't mean people aren't still using it. So that's where I kind of want to switch to looking at like

malicious things in legacy packages because the thing is is you if you can and replace it, you probably will, but at the same time if you can't, what are you going to do? So you have to be aware of the risk you're taking on by having these packages in there that are end of life. Um and there are certain things like you should be able to do. So it's making sure like, "Hey, do we have upstream patches or things like that that's going on?" Um what errors are we getting that we are aware of that we need to document to have in our risk planning management. Um also is there compliance problems? Um personally, I don't like being illegal,

but hey guys, that is kind of like a fun world we live in now. Where you can bleed in. So, like is this going to be a legal problem with compliance that you're going to have to adapt to? Um and the other thing is is as we have seen, I brought this up before, you know, Mythos, yes, they scan all these things and we're like, "Oh my god, there's all these vulnerabilities and whatever in these 20-year-old applications." And it's like, "Well, yeah sure." They just hadn't had anything happen. It was just like crappy written code, right? So, like let's not lose focus on what this actually means. Is it actively exploited? That's the question we should all be

asking. Um so, we have started to see some of that happen in in like abandonware it's nothing new or older applications, but that's just because, hey, super integral, we can also use a genetic AI to kind of create some of this stuff now where it knows they're widely used. Um Christoph, anything you want to add to that? >> Yeah, sure. So, as I mentioned, I talk to customers all the time and I talked last year with a broadcasting company. And the lady was pretty upfront. She said, "You know what? We have that piece of software that actually our entire company, our broadcasting equipment, is based off. The two maintainers are going [snorts] to retire in 2 years.

If we shut down that software, that's it for us. So, for us it's not a question, can we fix anything or what's inside? It is really like, how do we spend time X before we have to redo it? And we came up with a few things. One of them is isolation. Can we isolate that thing as much as possible? Can we find out actually what is in there? Do we have like an S-bomb? Can we review the components? And I think for me one of the most important thing is can we put a risk towards it because without risk in software and modern IT nothing is moving because with risk is money. [clears throat] And if you don't have the correlation

that if this thing goes down, we lose our business, nobody will react. So, um again, look at what is in there, what can it do, try to establish a behavioral baseline. So, if you can find out that someone might be compromised, one of these software pieces that you kind of saw that oh, it doesn't do that normally. There are something new. Um and yes, you have to start rewriting that stuff. If you doesn't do it 40 years ago and you have it up and running for 40 years, well, now is the time before these two guys retire. Or you bring them back, right? These are like the guys like, "Yeah, I'm 70. I go back.

I got a great I got a great great package." Like I think we did that with COBOL and assembler where we brought these guys back as I you know what, we we need that knowledge. So, yeah, these are things that you also then can do with a older piece of software to get these kind of informations. Um >> So, what can you do, right? Survival toolkit. The cool thing about open source and other free tooling is there's tons of things out there that you can use, right? To kind of get ahead of some of this or that you can investigate to make sure like, "Hey, do I have a CVE? Hey, do I have malware?

Hey, can I trust this signature, right? Is this like is there the same integrity with the package maintainer had um or is there some type of tampering that's gone on? Um there's also frameworks. So, I'm actually an Open SSF ambassador, so open source secure software foundation. Yeah, that's a mouthful. Wow. Um through the Linux Foundation, but they have these different projects um that you can use. They're free tooling that will actually help like make suggestions to you to help keep you more secure. So there's things like scorecard, salsa framework where they actually do help you grow into a maturity model for how to have create secure software. So I would definitely check out those things

um but I would definitely make sure you're focusing on like signing signature signatory, you know, clarity on that and then supply chain levels are always good to know. Also the automation, right? The thing that we're seeing this right and it's a scaling problem. So we need to make sure we have controls on automation also just because of things like Shy Halud where it was automatically updating folks or infecting them with that. So we want to make sure we have controls on things like Dependabot to make sure it's not just going hog wild with it or there is some kind of way a mechanism to kind of rein it in before those things happen. Um then there's also things

like secure.it software. So that's a free tool that I know I run where you can look up these packages for free, right? So I would make sure you look into it. There's also things like CIS benchmarks. So these are also industry best practices and I'm not going to go through these cuz I know we're like up on time but please feel free to take a photo of the slide. Um So Prech off, what can you do today or on a Monday to help kind of bring this all home? >> [snorts] >> Yeah, you have to review what you're using and you have to put the risk to it. So what I see is that I think the number

between developers and security specialists is I don't know, 1 to 100. So one security specialist have to review the code of 100 developers. That's not scaling wise, that's not possible. >> [snorts] >> The next thing is like I okay, I've one guy who can do pen testing. The next question would be like, what is our most favorite software or what is the most important software? Well, what we see is that all the unimportant software pieces get hacked because they are widely distributed. Distributed. So, if you're saying I have a database and that is the most vulnerable data of my company, um but the access client to the database is on all your desktops and on that

desktop is a soft phone. Well, maybe that soft phone got hacked. Or we're talking about in OT. Oh, yeah, I have to secure that robot. I have to find out how to secure that nobody controls that robot. And if you ever walk through a floor plan and you see in a corner like a dirty, I mean really dirty little piece of PC. Well, this is the management workstation for that entire factory. And you know what it has? It has no admin password. It has all the remote access tools in the world because every different vendors that you know what I using whatever installed it on there and it has a open session so nobody locked it off or whatever.

Um so, it doesn't really matter what you do on that robot as long as you have that little dirty friend in your corner. Um so, these are the things that you kind of sort of need to review. How what is really like your exposure? How to automate? I think we need to start to automate and then there will be still something left over that you can review. And if we then have enough people to actually review that, um and we do that, I think we will more secure. So, think about that. Um don't ask what's your important data. That's important. Don't get me wrong. But what kind of access ways do we have that? What kind of software

running on these things and how do I kind of sort of make sure that nobody can have access to that? Um little bit about us our community. Um I think behind that link is everything that we share for free. >> [snorts] >> Um which you can use with a community account. Um it is now accessible via API, so you actually can as a free account have like a hundred >> thousand lookups a month? Yeah. >> Yes. >> Yep. Um for the different uh uh um repositories. Um there are several tools that you can use. Um give it a try. Give it a >> Try and break it, please. >> Bring my >> my day. >> Yeah.

>> Um and and here's the thing is we just believe in doing what's right for the community. This isn't a problem we can solve one person, you know what I mean? It This shouldn't be an individual. This is an industry-wide thing that we should all be working together on. Um so that's kind of it in a nutshell. I think the only final thing I just wanted to make sure too is please look at your your extensions. Um we're also seeing hacks come in through that way. I'll just one final story. Two years ago Disney got hacked through this where a guy tried to download an image generation tool. Fun fact, they broke into his Slack um

and got 3 terabytes of data. So that's trade secrets from them. So like Disney's huge, like Disney Cruise, they probably have a bank, I'm sure. Their parks Hulu, ESPN, whatever. So they got like months of like trade secrets and plans from it. So just please check your extensions before you download and don't do the pray method like I know sometimes we do. Um cuz I don't want to see someone else get burned from it. So check out our free tool. I think we have time for a couple questions, but thanks for hanging in THERE WITH US. >> [applause]

>> ANY QUESTIONS? WHO'S FEELING BRAVE? If not, we're happy to go. >> [snorts] >> Oh, we got one. >> You stop the creation by waiting, I don't know, 2 weeks for the for the packages to be like used by the community. Is that a a good defense in this? >> Yes. Yes. Give the community time to react to something. Don't use fresh out of the shelf whatever it is. Wait a week or two. Two weeks is actually a good wait show. Um I mean like So, here's the thing. You have to differentiate between a regular update >> Yeah. >> and a response to a hack. So, if there's like a new log for shell, don't wait 2

weeks for the patch, right? So, that's not what I'm saying. But, if it's like a new package, a new update in line, wait 2 weeks. >> So, and the other thing I would say is, you know, you can either do this all like me, all right? Run whatever version you want, or you could be like fully automated on the latest version. That's like living on the edge is what we call it. I personally prefer to like to live near the edge where you're like n minus one version. You know what I mean? Because that way you know how the community has responded. You can also look at the diff between the versions and it gives you

time. So, you don't want to live on the edge. You want to live close to it. It's just how you want to think about it. Good question. In the back. >> You mentioned uh like in your five steps, check for YARA, and then it was like create SBOM. Uh when you have these SBOMs, are you able to feed it back into these like YARA scanners and other things? Like >> Well, YARA is So, so first of all, YARA is like a text searching tool, right? It's like an uh a tool that allow you to scan for everything in a thing. So, there's no The reality is like bringing back an S-bomb would like taking that S-bomb put

like all the dependencies in that YARA rule and find out if that is somewhere >> in there. >> in in in the world or in your packages. You can use YARA for that. But what I guess what you're coming from is like CRA, I have to generate S-bomb, I have to review that. Um you can do that with any kind of database tool to be honest to say I have a big data lake with all the components I have. Um the problem I have with a database approach is that software is updating between every two and 120 days. So you kind of sort of to be on time, on point, you have to have the ability to have

versioning and that's when the most database things go out of hand by just applying to CRAs like uh okay, [snorts] now I have like 10 versions in my environment. IT ops cannot give me like the real thing that I have deployed. So you kind of sort of become in that uh mixture of where to. So yes, you can use YARA to kind of sort of search for for for dependencies. But yeah, you know what I mean? >> I >> [laughter] >> And I think final comment on this too is this is always just cuz I work with the research team, um I would be questioning like how long do you keep your malware samples for

when you are looking at these different things, right? Most companies actually age them out after 5 years. And I bring this up because a lot of the stuff we're seeing come back around now is stuff we've seen 10 years ago that have characteristics or behaviors of stuff we've seen 10 years ago. Personally, I'm waiting for bouncy castle to come back, but like, you know, that's just me. Um but that's very real. So a lot of people have aged those samples out uh because it's, you know, 10 years ago or whatever. So that's just one thing I would I would look into. Um but that's time. >> to yeah. We are out of here. They called us by the table if you want

to we can chat. Thank you for >> And check out Katie Pac and FEAR. She's next. She's awesome. >> [applause]