Worms, Tokens, and Trust: The Industrialization of Supply Chain Attacks

All right, I think we can probably get started soon. Yep. All right, first of all, welcome everyone. Welcome to the talk. Thanks for coming on a Sunday 2:00 p.m. Um it's always awesome to hang out with people that care enough about this stuff to come attend talks on a Sunday. Um so it's great to great to be here. It's my second time speaking at B at Baltimore B-Sides Charm. So happy thrilled to to have that they wanted me to come back. A little bit about me, uh if you're trying to pick where my accent is from, I'm from Aotearoa or New Zealand. Uh I'm the co-founder of Compargo. Uh we're also the CTO until 2020. Compargo

still exists. Uh I just left after 2020. I'm now a security researcher and advocate at Akido Security and you can find me anywhere on social media at the handle Advocate Mac. Uh I'm also the host of the Secure Disclosure podcast. My mom says it's her favorite podcast. She listens to every episode and highly recommends it, so you should also check that out. Um all QR codes are definitely not malicious, but scan at your own risk. Uh all right. I want to start off a little bit. This talk's going to be about the supply chain attacks. Now, supply chain attacks have been drastically on the rise at the moment. Um so I want to kind of get into some of the reasons as to

why what we're actually seeing out there in the wild and why our current systems of protection are failing us a lot. I want to start off with just a little bit of understanding the open source supply chain. I suspect that most of you in this room will be aware of the first couple of slides that I picked, but I want to get everyone up to speed Um and that's where all my good jokes are, so we'll just deal with it. >> [snorts] >> So, around about 70 to 90% of your source code that makes your application do stuff comes from open source projects, right? So, it depends on what your application does, but around about

70 to 90% kind of comes from there. And we have multiple layers of this. So, obviously we have our code that is doing what we're writing it to do, it's what unique features that we're building. And then we have the direct dependencies. Now, the direct dependencies are the ones that we've picked. We've gone on to their page on the NPM or PyPI package, we've looked at the number of stars, we decided that they're good, they do what we want, and we've picked them. We know about them. Then we have the dependencies that they use, right? Cuz dependencies use dependencies, so then we have our transitive dependencies. These ones we may not be so familiar with, and we've got less control over

these. And then way back out the bottom we have kind of foundational dependencies. Now, these are kind of transitive dependencies as well, but they're they're more or less the dependencies that are in everything. We can't really avoid them even if they're not in our language ecosystem. Uh and we'll kind of get into kind of some of that as to why. But, we have to understand all of this, and we can kind of visualize it a little bit at the start. So, we have our application, it's amazing social media for cats, whatever it is, right? And this has some open source dependencies that do things, whatever they may be, right? Connect to databases, parse information, uh parse

information about our users, whatever we're whatever we're doing. Then we have the dependencies that they have, then we have the dependencies that they have. The icons were getting too small, so I stopped at three, but it's basically around about 30 layers deep usually, somewhere like this. To make matters a little bit more confusing, we also have third-party systems that we're dealing with. Maybe we're Octa's managing our authentication, maybe Stripe's managing our payment, and all of that. Right? So, what can typically uh is as um this this is a very understandable version. We can understand what's going on and we we know what's happening. If I was to create a more accurate version of this and how it operates in real life, it

would look a little bit more like this. Uh and that is because our dependencies are dependent on each other, our third-party services are dependent on dependencies, and we basically have no hope of trying to understand what the heck is going on. So, if one of these dependencies was turned to malicious, let's just take this little red dot here. Let's give it a random name. I'll come up with something off the top of my head. I'm going to call it log for J. Um and then and then if this gets turned malicious or has a big vulnerability within it, then this has an upstream effect on anything and ultimately can have an impact on our application. Now,

there's lots of nuance in this around about that. Just because you have a dependency with a vulnerability doesn't mean that it's reachable, but understanding that is confusing as well. So, we're really at a loss for trying to understand our supply chain in our current way. Now, we've tried to come up with systems to understand this like S-BOMs software bill of materials, but it's basically a gigantic problem of understanding it, knowing what's vulnerable, and now knowing what's malicious. Um and especially now that that malicious process has really been industrialized in there. So maths. Um what we've noticed and probably everyone has noticed is a gigantic increase in the amount of supply chain attacks that we're seeing. And that is because

equations like this. So, this is actually calculated the financial impact that an attacker can have by targeting an open-source dependency. The reason I kind of put this in here is because it's scary, but it just goes to show that this isn't something that script kiddies are doing. This is a financial model that's very lucrative. So, targeting one of those components in our supply chain, whether they're targeting a vulnerability that's known or whether they're trying to inject malware, you can figure out the impact that you will have roughly on a in a financial model to find out how much resources you can put in to attacking something. Right? And what impact this does is that attackers have figured out that they can

increase the amount of resources into targeting the supply chain systems because the financial outcome is so good. Um and we can get into that. So, it's not a security conference until someone shares this meme. I know everyone's seen it before, but it's so accurate, it's ridiculous. It's It's because it's become so famous that it sparked a term, which is the Nebraska problem. So, basically, you know, if you haven't seen it, a whole cloud infrastructure systems is being held up by something that's being thanklessly maintained since 2003 in in Nebraska. Um Uh so, there's a lot of examples that we can do of what what this is in real life. This xc-utils, this was compromised by a threat actor once part

of the the Linux uh the Linux project. There's things like log4j, which I've already mentioned, and there's things like debug. So, these foundational pro- projects have all been compromised or have big vulnerabilities and they hold everything up. Uh we're getting more creative with this meme now. Every year we add something to it. This is the current version. This is version 47 of where we're at now that AI is coming in and doing something. Right? But it's getting harder and harder and harder to understand this software supply chain. But I wanted to bring this up because I actually want to go through a real-life example of like of what what what this is. And I want to go through

the example of uh a project called debug. So, debug is what we'd call a foundational project. It's part of JavaScript and it's in npm. It's one of the most popular packages on npm. So, you can see it has 476 million weekly downloads. It's got 77 versions, so it does have some version history in there. It's got eight quadrillion dependence on it uh and various different things. So, it would be pretty catastrophic, right, if this package was turned malicious. Um Which it which is exactly kind of what what happened here. Here we have uh some code from it. It's part of multiple packages that were compromised. If we look at this this is a line of code that

was added into that package. We'll go into more detail about this exact compromise. You can see here the scroll bar. So this is just showing that a package that's being used by 476 million applications on a weekly basis gets malware injected into it. Everyone that's using that can be very very vulnerable to it. And there's this not really a good way at the moment or there hasn't been a good way to be able to understand this and deal with it. Um so here we have what we call a CVE. This is from the national vulnerability database, right? Which is run by NIST. Now the NVD was created to solve the supply chain problem as it existed 15

years ago. And it did a good job at solving that 15 years ago, but it doesn't work anymore now. And I'm going to explain in more detail a little bit about that why that is. But this is basically I just bring this up to show you. This is how we know if we have something in our supply chain. So all of these open source projects they have CVE numbers if they have vulnerabilities within it or if they have malware within it. So a CVE is created. That CVE contains the vulnerability that it is and how secure it is. And then it also lets us know what versions we need to upgrade to or what versions it impacts. Um and this is

for the longest time the only real thing that we had to look into our supply chain. And we built whole sets of tools called SCA software composition analysis that were built around these databases. Those tools only work if the databases are up to date and the databases are relevant. If the databases are no longer up to date or they don't operate at a scale of which we can rely on them anymore, then the whole system that we created which did work 15 years ago doesn't really work at the moment. Uh so this was an example of malware, right? But it's not just malware that we're trying to deal with. It's also vulnerabilities. So, this is the

vulnerability this is the CVE for Log4j, probably the most famous vulnerability that we've ever had uh cuz of the gigantic impact it had in 2021. It's like our our D-Day. We all know where we were on December 2021. Um I was at a conference. No one came because everyone was busy. Um and just to get an idea, I bring this one up uh because this is a vulnerability not malware, but what attackers can do is they can target this. They can try and find instances of Log4j that are still running. And because there's so much um there's proof of concepts of how to exploit this out there, they can then run that and try and get remote code execution which

was this this was a 10 out of 10 uh vulnerability severity and also very exploitable. But I know what you're thinking. You're thinking yes, but why would anyone run the vulnerable version of Log4j? Surely that's all been updated. Well, a study was done on this. Two years after Log4j was discovered 2023, there hasn't been an updated version of the study, but two years after 30% of all applications were running vulnerable versions of Log4j. So, this just proves to show that oh my gosh, we have a long way to go. If this if the most popular and advertised vulnerability out there only got 70% of companies to upgrade to the a non-affected version in two years, then

it's going to be a pretty hard problem that we have. Now, we have things like AI which we're going to talk about how they're changing the game a little bit. Um not only in exploiting vulnerabilities, but also discovering them. Um so, it's going to be like a pretty a pretty wild a pretty wild ride and we're not really dealing with it. So, how do we deal with this at the moment? In the current system that we created, this is how it basically works. A vulnerability is found. Now, this could be from a security researcher, it could be from the maintainers themselves, it could be from a user, doesn't matter. Vulnerability is found. A CVE is then created. That process

takes a a long time, but it's submitted and it goes through a whole evaluation process. An SCA tool, software composition, will look at your application, try and find all the packages, maybe it looks at like your your package lock files, or maybe it's building something like an S-bomb. And then it evaluates that against the CVE database to try and find out, do I have any vulnerable versions? This is basically how we deal with it. So, we find malware in a package, we create a CVE, someone looks at that, they evaluate it, they create a CVE, and we have a tool that scans our infrastructure and lets us know, are we using that vulnerable package? It sounds

good. It sounds good. The problem is the time in which it is created. So, they no longer work in in an AI in an AI world. That doesn't mean we shouldn't use this, but it just means that this isn't really that effective. The time from a vulnerability being found to a CVE being published is typically 3 months. Right? And this would kind of work before because we had time to be able to responsibly disclose this to the affected parties. We had time to work out patches. And then by the time we published it to the world, right? The you know, the fixes have been made, the attackers were finding out about it at the same time as us, and it

kind of worked. It doesn't really work for malware, but it's the best that we had, so we dealt with it. So, how do we kind of solve this now in an AI world? Well, we need to change the way that we do, and we need to do this in a couple of ways. One, we need to detect vulnerabilities before CVE is created because 3 months doesn't work. Um and I'll talk about how attackers can potentially find this as well. So, if attackers are doing it, we need to do it. And the next part is that we need to reduce the time of notifying and finding malware from 3 months to a matter of minutes. Because I'll explain and we'll go

through some malware attacks, and that's kind of how long we have. We have a matter of of minutes. So, we decided that we wanted to try and figure figure this out. So, we built a pipeline to be able to detect some of this. And I'm going to give you all the secret sauce behind it. We open-sourced We open-sourced a lot of this. So, it's available out there. There's nothing super secret in here. There's also nothing super complex about it from it. So, I want to start off with the first part, which is how do we detect vulnerabilities before CVE is created? And there's ways to be able to do this. Some people might say, "Oh, we just scan

everything with Miss offs." I have opinions. But that doesn't typically work because of the computational cost associated with scanning big projects. It can't work for everyone. And two, because it's still not being able to find all the vulnerabilities that we have. Humans are still very much involved in this. But let's start off with what we thought our initial concept is cuz spoiler, it does use AI in this. So, we first had a thought that we wanted to try and identify how often or we wanted to try and catch when a security change had been made at a in a in a product. And what we decided to do with this is we discovered that the

change logs were being updated before the CVEs were being created. So, someone makes a security fix. They update their change logs to say, "Hey, we solved a cross-site scripting vulnerability within this." Right? And then a couple of months later a CVE will pop up with that cross-site scripting vulnerability. Hopefully, that's how it's meant to work. So, we thought, "What if we monitor all the change logs in real time? So, that we know when a security fix has been made. It does That means that we don't have to scan all the code and waste a quadrillion tokens all the time. We can just look at what's been changed and find out based on that where the vulnerabilities are and try and

reduce that gap from 3 months to almost a couple of days. So, we want to identify the security issues. We want to check them against the vulnerability database to see has this already been reported? And if it hasn't, we're going to report it. And then finally, we're going to verify the results best that we could with actual security people as as well. Um, it wasn't so simple because we soon discovered that we ran into a lot of problems. Change logs are not in the same place, they're not centralized, they're not in a centralized format. Uh, people are very very ambiguous with languages, and often uh, you can't actually tell if something's a security issue based on just the language. You do

need to include some of the code which changed it as well. But that was what we did. Um, so just to give you a couple of examples, here's three different change logs that we were looking at. Three different formats in three different places. So there's no way that this could have been done with a static rule set because the language was too ambiguous. The format was all different, um, and scraping it was hard. So this was the perfect use case for AI. AI is famously non-deterministic, so we needed something that was non-deterministic, meaning we needed something that was able to look through gray area and actually make a determination of whether or not this is

probably a vulnerability that's been fixed uh, or not. Why why large language models? Um, we didn't do this just to be cool. Uh, basically the reasons why we we needed to use large language models was mostly because of the ambiguous language. So you could write a Once you've scraped all the data of the change logs and you put them somewhere, you could write a static rule to be like, anytime XSS or server-side request forgery or something is mentioned, let's like make a note of it. Um, but unfortunately people don't like to advertise when they fix security issues a lot. And also there's so many ways to be able to describe something. So for example here, we've got we've escaped

the selected text to avoid cross-site scripting. Okay, that's a pretty obvious. I could probably write a rule for that. But when we go that down here, we're talking about increasing the work factor from something rather to eight to quadrillion iterations. You know, I don't exactly know what that means. I'm not going to write a rule for for for that. So we needed an LLM to be able to make a determination of is this actually solving a security issue and roughly how severe is it before we give it to a human so they have all the information? So in total, we've discovered 2,106 vulnerabilities in popular open source packages. So we only looked at the top 5

million open source packages um that had no CVE numbers attached to them at the time that we discovered them. Um in 2025 alone, we discovered 1,200. So we're discovering and the rate is increasing a lot at the moment. Uh around about 40% of them were low severity. What we actually find is people don't really advertise that much when they have low severity issues. Then medium um high severity and critical and critical severity uh as well. So we had a we had pretty much what you'd expect in there uh as well. Our hypothesis when we were doing this was that oh, this is um this is just going to be a gap filler. We We knew

that some of these would never be reported to a CVE, but we figured most of them would be. Anyone want to have a guess how many of the vulnerabilities actually were reported in the end? So how many of the 2,106 vulnerabilities that we found now have CVE numbers attached to them? 60 of the Just 60? Okay, you're wrong. You're pretty right. 60%. >> [laughter] >> Um 67% were were never disclosed. 67% um were were were were never had a CVE attached to them, which is more than half. This is way more than what we thought. 92% of those of low severities were never reported. That kind of makes sense. I I can understand that more.

Medium severity 77%. High severity 52%. You can see the trend, but then actually we slightly more critical severities were not reported. So this is basically saying I fixed a security issue that is discoverable because I've published it in the change log, but I'm not going to announce it to anyone so that they could do something about it. So now people have issues in their supply chain that an attacker can exploit, but we haven't given the defenders the information that they're vulnerable. And an attacker can build a pipeline like this, right? This isn't super groundbreaking on our part. We think it's a little bit clever, but it's not like, you know, it's using an AI model.

We use foundational models. We haven't trained our own models. Uh and part of the biggest problem is that we have a lot of security researchers that actually go through this information. But this is a a big problem. And part of the reason of why supply chain attacks are happening so much is because now attackers have the ability to find things that don't have CVEs attached to them. So essentially zero days in this case have been patched, um but they they still out there. So you may be wondering, well, why why have they been patched? We're finding them once they've been patched. Why is that such an issue if it's been fixed? And the reason is is

for various reasons such as malware uh and break breaking changes is that we don't always update immediately when we don't have to. What will force us to update is if we have a critical vulnerability in our supply chain and it's reachable. So now [snorts] that we don't know that, it changes how we approach it and the attackers can use this uh as well. So this is I'm kind of call it shadow patching cuz I think it sounds better and it's all a little bit shadow AI. Officially, it's called silent patching, um which is basically when a maintainer solves a problem but doesn't actually let the world know that they've that they've they've solved it. So why why

open source vulnerabilities not disclosed? Fear of reputation, that's one of them. No one wants to submit a CVE. Also, the process kind of sucks. If anyone's submitted a CVE, it does kind of suck. It's a long It's a long especially when you've kind of already solved it and you found it yourself, you don't want to do it. Lack of resources, delegate the CVE report, lots of valid reasons of why you might not want to do that. Um and it's not just small projects. Couple of interesting findings here. Um so here we have a a Craft CMS, which is a product in PHP. This is about 3 million weekly downloads. This had a critical path reversal vulnerability

within it. It was never It was never given a CVE number. Still exists to this day. People don't know that they're vulnerable to a critical path reversal vulnerability in this in this product. We also have some other ones. Here we have 86 million downloads in this one. Another critical vulnerability in this case this decentralized um decentralization of untrusted data. So, leading towards potentially some injection style attacks. So, this is another big one. Also, no CVE on these as well for that. We do constantly check. So, we have this in a database and basically what we have here is this is what it looks like when there's no CVE. We go pre-CVE cuz we try to use

optimistic language. Um and then when there is one, for instance, this is in GitHub database a security advisory, we put the number in there when we find it as well. But what about malware? So, we talked about vulnerabilities. Kind of fun. You can see how an attacker will do it, but malware seems to be just a gigantic problem out there at the moment. So, I want to run through a compromise that we actually detected and notified. Um I've already talked a little bit about it today, but it involves a guy called Justin Non um and a couple of pretty popular packages. So, September 8th last year um Justin Non I I did a I did a podcast with him and

it's very interesting to hear how this happened. But September 8th, he's sitting at the doctor's office and he's stressed out because he's trying to do a a lot of information and he gets this email on his phone. And he It says that NPM you have to update your two-factor authentication passwords. And he's just thinking, "I'm stressed. I'm not at my laptop. I want to be able to do something useful. I can do this on my phone." So, the day before this wouldn't have worked. The day after this also wouldn't have worked. It just happened that he got this email right at a time. And the the email came from npmjs.help and not npmjs.com. Um so, it was a phishing email. This

went out to lots and lots of maintainers as as well. Josh Junon is one of the most prolific maintainers of open source projects in the JavaScript community. In total, his packages are downloaded 2.6 billion times a week. Right? So this basically covers everything. One of those projects we've already talked about, debug, but there's also uh 300 you know, 300 million. We got chalk, 300 million, uh ANSI styles, 370 million. All of these different projects that were that were there. Basically, what happened is the attacker obviously fished Josh. They stole their credentials. Obviously, they did have MFA installed, but they were able to bypass this by having a man-in-the-middle attack. You know, he was using time-based authentication.

Um and you guessed the next part, malware was installed onto all of these packages. So I want to tell you about the time frame of this happens, and this will really kind of understand the industrialization of supply chain attacks and why our old system doesn't work. So we discovered this, we notified Josh, and we published about it on the 8th of September. So this is when we made our first publication on our blog, 8th of September of hey, these packages have been compromised. Our CVE data did come up, and it came out on the 15th of September. So this is really fast. So props to the NVD for getting this out there in much faster

than they usually do. Um and I I I do want to say it sounds like I'm bashing on the NVD. The NVD uh has physical people that have to review all of this manually. It's part of the process of what it does. So but that just doesn't work because 7 days after malware was injected into this package, we first, you know, using traditional systems, we would have only just known about it then. So this doesn't help us. It particularly doesn't help us when we look at the timeline of this. 30 minutes after the breach happened, we notified Josh. We managed to This Ironically, this is our This is our a message on Blue Sky. Ironically, we

were lucky. There's no formal system of like notifying people, right? They might have a security email, but when something like this is happening, you're you're you're kind of freaking out, especially something so big. So, we messaged Josh everywhere that he had. If if MySpace still existed, we'd be messaging him on MySpace. Um but he told us that the only reason why he actually got this notification is because he doesn't really use Blue Sky so much. It was the only app that had notifications turned on because it doesn't come get any. So, he was So, at the doctor's, he got on this notification. 4 hours it took for Josh to regain access to his account. Now, basically,

within 4 hours, he had to communicate with NPM cuz all of his passwords and emails have been updated. But 4 4 hours afterwards, he did get access back to his to to his account. 4 and 1/2 hours after that, the malware was removed. This whole [snorts] attack lasted 4 and 1/2 hours. So, when I'm going back to the 3 months of the NVD, you can see how short this cycle now is uh from that. So, what was the impact of 4 and 1/2 hours? Is this Is this a celebratory story? Absolutely not. This could have had pretty catastrophic effects. Um but we know what happened after 4 and 1/2 hours because Wiz did some post

analysis of this, and they published it. They found the malware in 10% of all of their cloud accounts of all of their customers' cloud accounts. So, in 4 and 1/2 hours, this malware had spread to 10% of cloud accounts, roughly. There's a little bit of like language uh o- of that, but this gives us a pretty good idea of where it is. 99% of cloud accounts had some exposure to it, which meant that they were using one of the uh the packages. So, if you're thinking to yourself that this won't affect me cuz I don't use JavaScript, right? I use C++, real language. No. Um uh th- this still has an impact because if you're using

things like cloud accounts, your CI/CD pipelines, the things that you're relying on use these packages. So, you still have exposure to this even if you're not using the languages that they're after. But this just goes to show how quickly something like this can actually spread. So, it's malware but it's spreading at the the scale of AI because this is how fast we're updating everything at the moment. And we're seeing AI grow astronomically. So, this is a a chart of how much malicious packages we're actually seeing out there in the wild. And you can kind of see how quickly we're we're increasing the output of malicious packages. This may be malicious packages that we've compromised or attackers have

compromised. It may be malicious packages that they're creating for the purpose of being malicious. Um and there's various different methods of doing that. But we can see how quickly this is actually uh impacting uh impacting everything. And a lot of this comes down to the fact that we gave script kiddies superpowers when it comes to AI. Now, anyone with absolutely no knowledge of how to code can write malware and write effective malware using uh models, uh using generative code, or they can develop an exploit to a known problem in a package. So, we have now reduced the level of what used to be reserved for very sophisticated actors uh and they still exist, but they also

have superpowers. But we've also given the script kiddies superpowers as well. So, everyone now has a superpowers to be able to kind of create these malicious packages. And that's what we're seeing growing out there in the wild. And we're seeing it all the time. This year, Axious Trivy Checkmarx um have have all been compromised through these these malicious malware campaigns. Um so, we're definitely seeing this in in reality. So, we adopted a similar approach of like, how do we detect malware using LLMs and try and bridge this gap in a similar way that we might have done with detecting vulnerabilities. Um and again, we we had a simple hypothesis, uh, but this is a really good use case for for

AI and I'll kind of explain why. Here I have a a vulnerability. This is a very basic SQL injection vulnerability. I'm using untrusted data. I'm using it directly in a query, right? So, we can drop a table or do whatever we need to do in here. This is deterministic, meaning that if I'm finding vulnerabilities, I still want to have deterministic rule sets to find those vulnerabilities. If this exists in my code, you can have an argument of how vulnerable this is, is it connected to a real database, or how sensitive that information is, or yada yada yada, but you can't argue that this isn't a risk. So, this is a yes or no. Malware is

non-deterministic. So, for example, here's some example of malware. What makes this malware is kind of this disgusting stuff down the bottom, right? It's heavily obfuscated, right? It's encoded in base 64, or they're using weird language, or they're not it's not readable to humans. All of that is an indication of malware, but there's perfectly legitimate reasons of why you would want to obfuscate your code 64. There's There's reasons for it. They're using uh an external domain and using a function like eval in JavaScript is pretty strong indication that it's going to be malware because of eval, you're taking an external payload and you're using it immediately. That's pretty dodgy, but there are legitimate reasons for you that that function

exists for a reason. So, every indication that there is malware has an indication is there's a perfectly legitimate use case for it. So, that means that we can't really write rules for this. NPM alone gets 30 thousand package versions a day. So, even if you have a low false positive rate, if you're using static rule sets and trying to evaluate if something's manual if something's malware, and you're doing this manually, it's still going to be far too long. So, that's why LLM is really good because it can be injected in there and actually make a determination based on kind of non-deterministic factors that it's malware. So, we have base 64 code, we also have external domains, and when we

compile that base 64 code, it does dodgy things. Therefore, I think this is malware. So, that is the way that we can actually start using this. So, that's what we started doing. Um using it, our kind of process of doing this is we scan multiple sources. So, I've talked a lot about NPM because it's it's a part that's in there, but we also scan things like PiPi or even VS Code or VSX. All of these different places that we have packages or tools within our our data set. We scan every single one of those versions for malware. We don't do this with AI. We scan it with static tools. We use OpenGrok, which is open source static

analyzer, and we cast a really wide net of anything that's dodgy, anything that's base 64, anything that uses a val, anything that has an external domain going into it. And we can cast a really wide net because then it gets filtered out by LLMs, which make a determination or give us a score of how likely it is to be malware. It's either definitely malware, it probably is malware, in which case it will go to a human or it's definitely not malware. Um you know, and this it's a legitimate software. So, that's what the LLM validation does here, and that's how we can actually start to reduce this gap. That's how we're able to find that

package and notify Josh within 30 minutes of it being turned malicious because we had a whole process and pipeline put in place to be able to find it um going through through that. We still use human validation for anything that doesn't fit a certain criteria because we don't want to shut down pipelines or freak anyone out for malware. Um but we're also uh uh really satisfied with the results that we get from this. There's also some other indications as well. If you look on NPM, things like that the LLM will use is is it popular? Is there 47 versions in the last 5 minutes? You know, these types of things are there spelling mistakes? Do the

names match? Does the GitHub repository match where it's coming from? Again, this is all NPM, but

>> Test, test. Woah, yep, there we are. Very loud. Great. >> [snorts] >> Um, so in total we find 6,000 malicious packages every month in various different places um from there. So we found 131,000 malicious packages. Some of this, you know, just to not be a fear monger, if a lot of these packages are from people like security researchers trying to prove things like dependency confusion or typo squatting vulnerabilities. So not all of these 131,000 packages that we found uh legitimately from nation-state threat actors trying to destroy the world. Um, I do uh I do want to go back to the just-do-it example of debug and chores because most what happens when 10% of the of the

internet is compromised. Now, I famously thought the internet was going to die when this happened and I said that very vocally, which was later uh teased a lot when the internet didn't die. Um, and so why didn't the internet die with this? Well, at the reason is is that the threat actors in this case were just kind of stupid. I don't think they ever intended to get a uh to get a person like Josh to actually compromise so they panicked and they quickly injected crypto stealers in there. But they were very specific crypto stealers. It was a crypto stealer that only stole uh from browser-based wallets during a transaction. So someone would have to have a browser-based wallet installed,

make a transaction during that 4 and 1/2 hour time frame or when the malware is installed, and then, you know, their crypto was stolen. They made a a grand total of $700 uh from compromising this. And they would have caused millions and millions of dollars in damages of all of us absolutely freaking out and ruining everyone's days for the next couple of days trying to figure out if we have this. Now, there's much more serious indicators of this. We've seen the things like the Shah Halud worm that's came that's come out which was self-propagating, stealing credentials. The Trivy compromise was was much worse cuz they're stealing credentials and doing things. So, it's not We're not

always that lucky. This one was just very, very big in what we do. So, how do we solve this? So, we created a database which is very public for both vulnerabilities and malware. Uh it's called Intel uh at Akito Intel. And basically, what we do is we publish all of the findings that we we discover in real time. Um and then we need a way to be able to block malicious packages. What a threat actors are famously doing right now is they're targeting developers more than cloud accounts. So, it used to be they'd be targeting trying to get access into your cloud infrastructure. Now, they've figured out that actually an easier path is to target the developer of them installing

the malware on their machine and stealing the developer credentials. So, we need a way to stop a developer from installing a package or stopping a CI/CD pipeline updating packages or whatever it is if that package is malicious. And so, that's kind of what we built with Akito Safe Chain. This is an open-source product. It's very, very simple. It You install it in your machine or in your infrastructure as it's being built. And whenever you run npm install or various different commands that are installing packages, it first checks to see if there's malware in there and it blocks them. It also has a forced timeout of around about uh I think it's 24 hours. So, it won't install anything that's 24

out that that has been updated in the last 24 hours just to give you a buffer zone because there is a time there's still a little time delay of when something's published. It's not always 30 minutes. And then, it'll also check if it's malicious and then remove it. And this gives you coverage for most of the supply chain attacks that will happen out there, particularly in places like npm uh when you put them there. And it The great thing about it is that when you install this, you just install it. So, you You actually need to change your workflow. It just runs as like an alias. So, whenever you're doing NPM install, it invokes um Safe Chain and then Safe

Chain will run and run in that process. So, nothing actually has to change. And so, this is kind of how we can actually start get getting on top of of of malware in these areas. So, as I said, is it just NPM? I talked a lot about NPM because it's kind of like the biggest area at the moment, but it's definitely not. So, most of our packages where we find on NPM, we have 180,000 uh NPM packages that are malicious in our database. Then we also have Python from PyPI. But as I said, VS Code and Open VSX. Although these don't have a lot of packages within them coming in at the same rate that we have, this is actually

a really prominent layer prominent place for attackers to be targeting right now. Especially in places like Open VSX. So, the VS Code you're familiar with, it's an IDE where you write code. You can have extensions for it. There's the VS Code Marketplace, but when VS Code clones became popular, like Cursor or Windsurf, they needed their own marketplace cuz they couldn't share the VS Code Marketplace. So then VSX was created. And naturally, VSX didn't have as much security like guardrails up as VS Code. So, we started seeing huge amounts of malicious packages. They've also moved to VS Code because it's easy to bypass some of those things because discovering malware is non-deterministic and you can't block everything that

looks like malware because most of it isn't. Um and also lots of other areas in there as well. So, you can kind of check that that all out. Uh what I thought I would be funny is to go through some of the malware that we've actually found uh using our system. Um the greatest hits, if you want if you will, and to talk about just kind of what threat actors are actually up there and what does malware actually look like in real life. So, the first one is the stupidest malware that I've ever discovered we've ever discovered, but it's also kind of great. Um and also very close to fooled me. So, this one is from North Korea, the

Lazarus group, and there was a there was in a index.js file, there was this code. And we stood and looked at this, and we were like, "Ah, we've got a false positive. Like, there's nothing malicious in here at all. Uh can anyone notice the indication that there may be something malicious? Yes, the scroll bar. Um [snorts] so, all they had done is this was the actual malware, and they were using eval, a dangerous function, calling their their um calling a payload, and running it. Um and essentially, they just used white spaces to move it off screen. Uh which sounds stupid, but almost worked, because at some point we all just we open up the the the the code view, and

we're like, "Oh, there's nothing here. Like, false positive." Uh we did manage to look, cuz we had a very strong indicator. Um so, this is here. Once you download that payload, so once you go to this address, and you take the package, uh it does everything that you'd expect North Korean malware to do. So again it's doing things like trying to steal cryptocurrency. Um these are all browser-based cryptocurrency wallets. It's trying to install a persistent backdoor. It's trying to steal your session cookies, your session tokens, and your passwords. And it's searching for other crypto assets. And it's installing keychains, and it does a backdoor. So, it's really really nasty once you actually get it on. It kind of

does everything. Um which is really hilarious to see that such sophisticated malware is being obfuscated through white spaces. Um and it almost worked. So, uh that says something. But, this one was kind of great. Um the biggest potential impact that we discovered is not actually debugging chalk. I think the biggest impact of what we discovered was actually cryptocurrency. Um so, Ripple, or XRP, is a a cryptocurrency. It's one of the largest cryptocurrencies in the world. I think it's the sixth largest cryptocurrency. And this here is the official Ripple SDK. So, if you wanted to have a cryptocurrency exchange, then at some point, you need to communicate with the cryptocurrency ledger, with the Ripple ledger. So, that's very complicated hard. Ripple

built an SDK so that you could easily communicate with the Ripple ledger from there. Obviously, this is a big target. It had at the time 130,000 weekly downloads, which isn't like a huge number when we've talked about billions, but I think 130,000 of those were probably very very high value targets cuz we're dealing with cryptocurrency. So, what actually happened? Well, we noticed that this function was added in here check validity of seed and it just looked really with got an external domain here as well and they had compromised a developer token. So, they had either purchased a developer token from the dark web which is a very common way of these actually get seeded or they had stolen

developer credentials in other areas. In this case, it was a developer that no longer worked for Ripple and they injected this this malware in here. It was a check validity of seed kind of function that was malicious and you can see what it's trying to do. It's trying to steal private keys. Why this would have potentially had the biggest impact is because how this worked was if this had been installed on a cryptocurrency exchange and someone had made any connection with the Ripple SDK, then this malware would have run. What this malware did is try and steal access to cryptocurrency wallets. But what it didn't do is it wasn't trying to steal access to XRP wallets.

It was any cryptocurrency wallets that were in there. So, this wouldn't have drained your XRP wallet. It would have drained all your wallets. So, this would have had a fundamental impact on kind of cryptocurrency and how we I kind of understand it because it could have had an absolutely massive impact. I do want to give Ripple a shout out though because we've never worked with someone with such fast communication as their security team as when we reached out, we had a war room open within a few minutes of discovering this. We don't accept we don't well, we do accept. We don't we don't like demand or request bug bounties, but Ripple did give us a big bug bounty

for this one. So, it went into the researcher party fund and we had a great Christmas party last year. You can kind of see some other stuff. This is the main when it was registered, other areas like that as well. And then once we pull that apart, you can kind of see the check validity of seed here function being used in various different ways. This one is kind of fun, the most beautiful malware. This is the most sophisticated malware that we're we're seeing. We first discovered this in March last year, so it's more than a year old, but it's still a big threat today and they're reusing the same technique in multiple different areas. It's been called multiple different

things. I have a few opinions on that. You will no doubt hear them. But [snorts] let's have a look at it. So, obviously you can't really see this, but basically what's happening on is here we have some code and essentially what this code is doing is it's trying to decode a base 64 string among other things on this line, which I will blow up. So, here at line four it's saying like let's decode this from base 64, but you'll notice it is one character in there. Why would someone want to try and decode one character from base 64? And it's because it is not one character. In fact, hidden behind the ear is many many characters and they

were using something called Unicode steganography, which is taking invisible non-printed characters through them. So, when we actually open this up in something that can view Unicode characters, you see all of these characters here that are actually missing. These are behind that one that one character. What these are are Unicode PUAs and these are characters that you can define through your project. So, you can actually uh label what you want this character to be through the process. That means that you we don't know what this malware does until we run it because then through the running process as characters are defined and then the malware is un kind of is is discovered through that. But this is a really beautiful way of

kind of off skating it. But, it does not stop there. It gets way weirder. Uh so, then we obviously pulled that payload in. We ran that project in a sandbox, and we got this here. We got this file. Uh and in here, we got another base 64 string. We decoded this base 64 string, and it gave us a Google Calendar invite. So, then we go to that Google Calendar invite, and we get another base 64 string in the title. That base 64 string gave us the location to our final boss payload, which was at here. Once you downloaded that, it did all kinds of nasty things from it, and it installed a rat, a remote access Trojan, that basically

tried to get persistent access to your machine or your infrastructure that you're running in. So, this doesn't actually stop there. So, this started off in NPM. Um the name of this the name of this um malware is called Glass Worm, and I'm real mad about it. Um basically, because it's had a long life. So, we first discovered this in March. Uh you can kind of go back through the documentation and see that. In October 17, we also discovered that they had moved from NPM to VS Code. Uh the same day. We published a day earlier, but it would have been discovered at the same time. I'm not indicating that they stole it at all, but another security uh company called

Koi named named the made a big publication and named it Glass Worm. Because they named it and they had a way better PR team, they got a whole bunch of press, and now we have to call it Glass Worm. Uh which I'm real mad about it, but it's nothing to do. It's no shade on Koi. They are they're helping helping the community with malware as well. Uh I'm just mad that I have to call it their name because their PR team was better. Um and to be fair, we didn't even have a name for it. So, now we name all the malware because of this. So, when we find it, we give it little pet names.

Um but, then they actually shifted again. So, they moved from NPM to VS Code and like VSX uh marketplaces, and then they moved to GitHub. And I only have a few minutes left, but I can actually show you this because in March this year, this malware came back and then started infecting it in GitHub. So, we can actually see this in GitHub where we search for the indicators of this. We can see all of these repositories that have actually been owned by this. Now, they would have done this by using the tokens that they had gathered through their other campaigns. So, through their campaigns, they would have gathered a whole bunch of GitHub access tokens. So, that's how from NPM, they

would have gathered probably tokens to publish in the VS Code marketplace. And then from there, they were able to develop tokens from GitHub. So, that's why they're able to keep moving through these different ecosystems using the the packages that we have. So, here Oh, I want to go back. This is just the repository. I want the file itself. So, here is the indicator. This is the new Glassware malware. And if we copy this and put it somewhere in here, if we decode this, what you'll be looking for is this area here. And so, here we can see that there's no characters in this. But if we view it, here is the information. And then right

at that place that forms, we see all of these Unicode characters in here as well. And so, you can see the the the the names that we're given. So, you can actually kind of look at this malware in real life. And this is And this is what I And you can see it's quite a lot bigger than than obviously >> [laughter] >> what it was before. So, there's a lot hidden in in there as well. Uh yeah, so that's just what that is. Um yeah, that's the end of it. I also have a lab in 15 minutes in the Cloud Village. If anyone want to learn how to do server-side request forgery uh and try and solve some some

vulnerabilities, you're welcome to come along. But that's the end of my talk. I'm happy to take some questions. I got 2 minutes for questions. Um but I'll happy to hang around. Uh and if you want to come to my lab, that would be cool as well. So, thank you very much. >> [applause] >> Yeah, you had a question?

Yes, that's a very good point. So, signing So, what one thing that's noticed in places like NPM is that a lot of the time the code comes from, um developer tokens, which are kind of injected at at NPM. But, how the process should work is it should come from GitHub or their CI/CD pipeline and then get published to NPM. And you can validate this through a signing process. In all the cases where these packages are compromised, or in a lot of the ones here, there are ways to get around this, but most of the time if if you install that, then someone can't just take a developer token and try and publish without that signature.

So, that is a very strong way to prevent your package from getting compromised. Unfortunately, it doesn't do anything for a package that you're using from getting compromised because this requires them. Yep.

Yep. Yeah, so there's a lot There's a lot that NPM could theoretically do. The problem is is that the scale of which NPM do is once you start enforcing things like this, you you realistically 5 probably 10% max of people I in processing signing processes like this. So, when you're looking at NPM, if you look at what they have like their most important north north star metrics, it's not we want to be the package manager with the least amount of package with least amount of malware, it's we want to be the package manager with all of the packages. So, when you start putting in there, it goes against their core busi- their core business kind of logic. I would

personally like to see that because I think that the disruption that we're facing at the moment is suitable for drastic change. But, I could also understand why they won't enforce that. But, the pathway is there. There's also lots of that they also changed uh the policies on long-lived tokens, which is really good. Um and they're doing some other things as well. But, attackers are also getting very very sneaky with this and this is also why there was huge volume in NPM last year and why we're moving into like VS Code this year and other places. So, yeah, it's a it's a challenge um for for for sure. All right, I have to uh I have to shut

up, but uh thank you all. I'll hang around for a few minutes and then I have to head off to my lab, but uh thanks for listening. I appreciate it. I hope you had a great conference and uh look forward to chatting to you all. Thanks.