Hunting software supply chain malware

0:03James Wilson: Hey everyone, I'm James Wilson and welcome to this software supply chain malware focused episode of Risky Business Features. Joining me today is the co-founder of open source malware, Paul McCarty. Paul and I often exchange messages from time to time about the wild and crazy things that he's finding in compromised NPM, PyPy and other ecosystem packages. And you know, to be honest, what he finds is interesting enough, but I was really intrigued to understand how does he find this? You know, what's the end-to-end process for hunting and ferreting out this software supply chain malware and understanding what does it do?

0:43James Wilson: Who wrote this? What did they write it for? What's the intention behind this? How is their tradecraft changing? And that's exactly what we're going to dive into in this deep dive interview. We're going to start off with Paul's research methodology. Then we'll talk about what he's seeing in terms of the evolution of attacker tradecraft and what we can learn from that. And then we'll round out this episode with some practical advice for how you can mitigate the risk of becoming a supply chain attack victim. I'm going to drop you here into the interview where we started to talk about just the very start of the research.

1:18James Wilson: How do you even find a malicious package amongst these sprawling ecosystems of millions and millions and millions of packages enjoy yeah i mean how do i find it um you know i mean well first i built open source malware um you know which is the world's largest kind of threat intelligence database for this kind of stuff um and a lot of people every day like this morning i woke up and um there was like 150 new submissions from all around the world um people from Nextron and all kinds of different companies submit things, but we also detect stuff ourselves. So open source malware has a, has a very robust detection engine, but the reality is to the heart of your question is how do I find this stuff, man, this stuff is everywhere.

2:04James Wilson: Yeah. I imagined it finds you in a lot of cases. It is fricking everywhere, mate. And the thing is like, I think you just need, it's like anything else, right? You just need to know what you're looking for. Um, and that's why when I give these trainings and these workshops, like I'm going to be doing in Canberra B-sides in September, you know, like explaining to people that like, we're going to find lots and lots of brand new novel, never been seen before North Korean malware. And people are like, nah, nah, there's no way. Dude, it is everywhere. Especially when you have a threat actor like, you know, DPRK, that's just so productive.

2:43They are just spewing this stuff out. Relentless, right? Relentless. hundreds because they're using automation. They're using AI to build the automation that we all are too. So the boring part of AI, right?

2:52James Wilson: And forgive me for, this might be a dumb question, but how does open source malware differ from something like VirusTotal? Like are these same sort of things or different or what's the difference? That's a great question. I have explained what open source malware is by saying if you took BugBounty and VirusTotal and they had a baby, um you know and you know like a you know malicious package detection thrown in there for good measure too as well but um uh so there is it does kind of feel in some ways like virus total but it's very different so virus total you know you can give it urls and ips and file hashes and we'll go and find stuff and that's great i use virus total all the time but unfortunately that doesn't really give you a lot of visibility into my world the kind of software supply chain attack space you know DPRK and Russian threat actors and all the other bad guys, you know, deploying stuff in NPM and in all the other places.

3:46So I built open source malware to be, to kind of focus on that. So for example, most of our data in, in open source malware is not IPs and domains. We have lots of that too as well, but most of it's GitHub repositories, NPM packages, PyPy packages, VS code extensions. These are things that just will never exist in the virus total world. Right. Right. And moreover, a lot of the things that unfortunately work really well in the kind of classic, you know, malware analysis, binary analysis world, like file hashes, a really, really good example is file hashes are almost worthless in my world. And the reason why is this is all interpreted stuff, right?

4:28It's in GitHub. So bad guys are just pushing a new version of it all the time. and all they have to do is add another, you know, white space character or zero to the end of the file and it has a different file hash. And so tracking the file hashes, they just don't last very long. They don't really have the same value in my world that they do, you know, over in that other kind of more traditional world. So definitely to your question, took a lot of, you know, I, I learned a lot from virus total on some of these other platforms, but wanted to make something,

4:59James Wilson: you know kind of unique to my world yeah okay no that makes sense so i guess that's the place to start right you said you woke up this morning and there's there's a bunch of new submissions and things like that so um what gets submitted what do you do with them what's the triage process look like like i mean i'm imagining you don't grab this and install the package and see what happens but you know like take us through this this triage process yeah you know i've and to that point i've been doing this a long time i've been doing this before llm's made it relatively relatively easy it's still not super easy but you know it's llms and agents have made a lot of this easy and we'll talk about that today but yeah um i've been doing this a while and so i have a process that i've kind of honed over the course of many many years and so i use uh purpose-built static analysis for 90 gosh i don't know just to pull a number out of the thin air 97 98 percent of my work is purpose-built static analysis right and i think that's the important thing is that i'm not using off the shelf static analyzers i'm i'm you know using one that i build and i iterate on all the time yeah and i've built a bunch of additional kind of things that go along with it so like i have a very vibrant um deobfuscation library that i'm constantly updating um and i have something called kill chain which is another library that basically figures out the kind of execution order inside of this so i have all this kind of technology running side by side um as part of my detection fabric so i woke up this morning and had you know 150 submissions most of those were github repos a fair few npm packages and in the meantime you know osm automatically detected i don't know a couple hundred packages as well most of which are npm but you know um you know we got our smattering of pi pi pi has actually been going up interestingly enough well and so you've mentioned a couple of different languages there already so how does the static analysis tools actually deal with the broader ecosystem here of you know i guess in in the earliest of times there was node and there was typescript now you got python and py py and now you got rust you got go i mean ruby's always been there but it's you know amazingly enough we're seeing rubygems packages there so how does the static analysis deal with this multi-language landscape yeah really good question um i mean that's a really good question because it's a complex answer which is first and foremost, you kind of have to take static analysis apart and you have to think about it as like multiple different things running in parallel.

7:20So for example, one of those things is you're looking, regardless of the language, you're looking for the same kind of things and regex and behaviors, right? You're looking for, is there a URL? Is there an IP address? Is there, you know, is it importing or requiring another package or another file? Is it mentioning GitHub? There's all these kinds of things that you can do kind of uniformly across all the different languages and all the different package types. But then separate to that and running in parallel, because you don't want to do these serially because then the whole thing takes way too long.

7:53In parallel, you also have static analysis engines that are purpose built for each one of those languages. And this is not, I just want to be clear. I'm not saying this is like, you know, Semgreps AST. where they, you know, this is different. This is basically just saying, hey, how do you import something in this language? How do you import something in this language, right? What's the package manifest look like? And how are these execution order and all these kinds of things that are a little bit different for each one of these different languages. Understanding that deeply because you're at the coal face every day and then you're building your own static analysis tools to do that kind of stuff.

8:30So yeah, that's how the process works, man. Yeah, interesting. A lot of moving parts kind of running parallel.

8:37James Wilson: Tooling is, I think, an interesting topic at the moment because of what AI has done in this space. And I think we used to create tooling sometimes because we couldn't afford the off-the-shelf stuff, sometimes because the off-the-shelf stuff didn't do what we wanted it to do. We needed a certain degree of customization. But I'm seeing an emergence of tooling that is an encapsulation of what only you can do because of your deep subject research. research. So sticking with this topic of the static analysis, would you continue to maintain and create your own custom static analysis tools moving forward because it is uniquely just your insights?

9:18James Wilson: Or is this just, I do it because I've kind of got it when I don't want to have to pay for those expensive tools? Oh man, there's so much I want to say to this. This is a great, all right. So first, yes, I will continue to double down on my own custom built tools and And I'm constantly adding new stuff to it as I see threat actors change and new things come in. I go for a swim and something pops into my head. I'm like, oh, my God, I need to add that to whatever part of the process. But I also think that, to your point, there's a couple other things here that are interesting that I think are also worth talking about.

9:52The fact that the frontier models, I'm using the frontier models like everybody else is. And the reality is the frontier models, while they might not remember the code they've written for me, they remember the shape and the function and the the profile of what i've built and you see that then the next time somebody asks for something right so because i've gone and built some of these things you know unfortunately it makes it a little bit easier for the next person to come along and do that because the shape and the kind of function is known inside the mothership right um so uh there's that um and that's why we see a lot of the you know tools kind of using the same kind of functions and whatnot.

10:31And we even see this with bad guys. Like, for example, Team PCP, they put a CIS detection. So this is one of those geo-location detection things to identify whether or not it's running in one of the CIS Russian-friendly states. Well, the reality is nobody in Team PCP actually is there. So they didn't put it there. Why was it there? It was there because Claude or whatever they were using put it there. It's like, oh, you're running network? Here you go. Here's the CIS function. You need that, right? Yeah, go make sure you don't hack the Russians. That's good malware. You're absolutely right. And somebody actually asked Team PCP that on Twitter, and they came up with this bullshit answer response, which was like, oh, you know, we have some members that are in there, and we wanted to make sure they're protected.

11:13We're just, you know, Claude just added it for them. And they're like, oh, okay, I guess that's good. Or they didn't, well, they probably didn't see it because nobody's looking at their code anymore.

11:21James Wilson: Yeah. But there's one more thing here that I just want to tack on here. The other problem, James, is you have a lot of people that are not subject matter experts that leverage and lean on the AI, the agents to build stuff for them. But ultimately they don't really understand the problem, you know, if like they would, if they had been at the call phase for years, kind of banging on it. Right. And so what they do is they build kind of simplistic or surface level tools. And I'm seeing this a lot right now. I've talked to a couple of startup founders that are playing in this space. And when you ask them what their background is, they don't have any background in it.

11:54And then you look at their tool. And you're like, oh, well, I can see that you didn't have the subject matter expertise because it's clearly not in your tool. So I think that's a big part of it too, is that, you know, leveraging the automatic build and this magic that we have now, right, to create these tools for us. But, you know, they have to kind of revolve around the subject matter expertise that the author is bringing to that creation process.

12:18James Wilson: Yeah. I think it's a large language model can builds you the same tools that everyone else can have built for them. What you bring to the table is the stuff that only you know, the techniques that only you have honed over the years, right? But that's, I think that if I'm reading it correctly, there's a very powerful combination here of getting a large language model to do the grunt work for you, but ensuring that it's doing, still doing things that only you can do because it's the knowledge that you've got, right? Right. Yeah. I mean, you have the howitzer, but you have to know how to like aim the howitzer and how the angle and all those other things.

12:52I love to fall back in these military metaphors because I'm American and that's just what we've been built up to do. Sorry. But you need that team that knows how to aim the Howard CERN, how big and blah, blah, blah, and all those things I have no idea. But in the same way, you need that subject matter expertise behind the LLMs building these tools.

13:12James Wilson: Right. Okay. So getting back on track here, you've got your static analysis tools that gives you the sense of, I guess that is looking for the paradigms and the signals and the tells in a given package that is going to give you that initial signal of, hey, yeah, this thing worthy of another look. But there's a heck of a gap here going from static tools that are telling you there's something funky here because it's doing an import of a package. There's a URL involved. It looks like there's a secondary loader, et cetera, to the research you publish where you're like, oh, my goodness, these DPRK guys are now using this amazing technique for the C2.

13:44James Wilson: So I feel like we're still at like step two of 750 here. So what happens after the static analysis? 100%. But you're right. Static analysis is at the beginning. Well, yes and no. Because, you know, most of the time, each one of those stages, if it's using an interpreted component, you know, typically JavaScript, each one of those is going to be highly obfuscated. And so, you know, you're using, you're falling back on these tools as you're processing through each one of the stages. And this gets really kind of interesting because North Korea, for example, you know, their typical kind of contagious interview kill chain is typically five or six stages.

14:22There's like two or three stages that are just bash. This is in the traditional kind of historical 2023, 2024, 2025, you know, attacks that they were doing.

14:33James Wilson: Like almost like a precursor of click fix, right? Here's the things we need you to run for this coding interview. Yeah. Well, the Bash basically would identify which operating system it was and then would go through all the machination to set up the Python or JavaScript environment to then download Beaver Tail, Otter Cookie, or Invisible Ferret, which are kind of the three classic tools that they used. But now they're doing more of that. They've basically front-loaded their attacks with a much more efficient JavaScript loader. um so this is like the the otter tail the side of the otter tail i'm making up new ones um the latest iterations otter cookie which basically kind of compressed ladder stages and so they don't have to spend the same amount of time setting up the environment so there's very little bash for example to set up you know you need to download node and you know get it set up and all that kind of stuff you don't need to do that um or you need to do less of it and to your point about you know like the ethereum changes i see because i see so much of this like i am i see more net new north korean malware i'm not going to say than anybody else in the world jams but i see it i see a lot of it every week and so what happened is as i'm looking through as i'm looking at the latest set of packages and things to come down the pipeline i'm like wait a second this is not classic ether hiding this is like ether hiding is a technique that dpr came up with last year, which basically uses one of three blockchains, Tron, Aptos, and Binance Smart Contract to hide the next stage, right?

16:15And it does that because each one of those three has like this little weird memo field that is mutable. You can change it. Every time you make a transaction, you basically can write into that. Whereas the payload itself, you can't. It's immutable. so they were using um aptos tron and in bsc and they were using it the complexity of like they use one and then the other and then the other they just made it more and more complex and then all of a sudden i'm looking at a new piece of malware i'm like wait this is talking to ethereum directly like what's going on here and so this is how this whole thing about null receiver started i just saw a new stage two and i was like well let me dig into this right what's going on here.

16:55And sure enough, it was DPRK coming up with a new way to hide stage two.

16:59James Wilson: So, and, you know, I'm super excited to get into the, um, the, what are you seeing? But, but in terms of, I'm still at a little bit of a gap of knowledge here in terms of when you go from static analysis to then finding these neat and novel uses of Ethereum, is this just you sitting down, pouring over the code? Like, is there more tooling here? No. Yeah. I'm glad. Thanks for bringing that up. Cause like I, this has always been one of my biggest problems, right? My biggest failings, James, is that because I'm just so in it, I forget that everybody else doesn't just automatically know this stuff, right?

17:32And this happens with my co-founder all the time. Like, oh yeah, wait, I'm sorry. I got it. I have to remember. I have to explain myself because you're not in my brain. So yeah, the way it typically works is that you'll have the start of the kill chain will be an NPM package or a GitHub repo, right? This is particularly true for Contagious Interview and all the different versions of Contagious Interview. Because there's now like five or six different sub-campaigns under Contagious Interview. But the point is they're still targeting people, software engineers, mostly that are working crypto, but now as they're running out of targets and as their receipts are going down, right like as they're making less money they have to widen their search now to like to software engineers and other people that are not necessarily working in crypto but anyhow as they target you with a github repository that github repository or the npm package will have an obfuscated javascript payload in it that's stage one and uh like i said before stage two historically stage two and three and maybe even four would be these kind of bash or PowerShell scripts to set up the environment.

18:44And then it would pull another JavaScript malicious payload, and then that would do a bunch more stealing. And then it would pull a Python payload, which was Invisible Ferret, and that's where persistence happened. But something that's always been really unique about DPRK in particular is they are stealing s*** at every stage. They don't waste a stage to steal stuff. Right. They, cause they, cause they know, cause they know they're like, well, this could, and we see this all the time where it's like, it gets to stage three, but then it never gets to stage four because there's a mitigation or, you know, the developer caught it or whatever the case, or they, they used open source malware and we told them about it, whatever.

19:24Uh, and so DPRK knows that. And so their philosophy is I'm going to info steal and crypto steal at every stage, but as totally opportunistically, just why not? Why not? I mean, honestly, why not? Right? Yeah. Because they, the, I think they came to this realization that like early on in the kind of contagious interview in Operation Dream Job that came before that, that they don't necessarily have to plan for persistence, which is ironic because there's now this whole persistent side to the North Korean, you know, software supply chain attacks that nobody's really talking about except open source malware.

20:05But getting back to the kill chain, it used to be this kind of complex thing. And what happened is in 2025 at stage three, DPRK plugged in this thing called ether hiding, which was hiding the next stage in one of these three blockchains. The problem with that is just a lot of things going on and like they're using and it just was fiddly. And people knew they were reusing the same blockchain addresses because that's kind of how it worked. And so then if you knew about that, you could just read those memo fields and you would see when they were changing it. So that's when I identified null receiver, which is the latest version of this, which is much leaner and it's very smart.

20:53James Wilson: I'd love to say I'm acting dumb here, but I really actually don't know this place well enough. So you're getting legitimate like, but I don't get it. So a couple of questions. Obfuscation, right? We've talked about this a bunch of times. What does that actually look like? Is there types of obfuscation that still prevent analysis or is this like just a solved problem? Cute that you tried to obfuscate it, but ain't nothing going to get in my way. Yeah, so obfuscation is a big deal. It's the single biggest thing, you know, like me and, and, you know, other, other peers that I have, like Charlie at, um, uh, Akito and, you know, Masha at Ox and everybody else.

21:35Obfuscation is the single biggest thing that slows us down, which is why, you know, North Korea and all the other good threat actors use it. So let's just talk about obfuscation at a high level. First, I think for people that aren't in software engineering, they think that obfuscation equals malicious. And I'm here to tell you that is absolutely not the case. Lots and lots of legitimate software engineers obfuscate, especially their JavaScript, because JavaScript, it's an interpreted language. It runs in your browser. If you know how to look at it, you can find the code. And so what they do is they minimize it and they compress it and they obfuscate it so they're hiding the business logic.

22:16And this has become a very common thing. So unfortunately, just because you see a piece of JavaScript in an NPM package or whatever is obfuscated does not mean it's malicious. But there are half a dozen kind of major kind of ways that you can obfuscate code. and each language kind of sets itself up for different types of obfuscation. But in the JavaScript world, there's three or four kind of techniques that North Korea uses a lot. Now, here's the problem. You think if it's only three or four, then it's a solved problem, to your question. But it's not because they constantly are kind of changing the ways and the order and all kinds of other things.

23:02And base 64 and hex encoding still are absolutely a part of that because those are just additional things they can throw in to kind of then hide something that's behind it. So it's basically figuring out in what order do they encode this and obfuscate it and then figuring out how to undo that to get it back to as close to human readable source code as possible, which is computationally and time. I'm, you know, it's heavy. It's a heavy process.

23:34James Wilson: Interesting. So it is a lossy process, right? This is kind of akin to disassembling a binary. You get back pseudocode C. It looks and you can reason with it and you can understand it. But I guess this is the heart of what I was trying to get to is this is, I was trying to understand is obfuscation and deobfuscation almost like an encryption thing where, you know, what you decrypt is lossless and you get it all back. But instead, I think what I'm hearing is it is a, it is a lossy conversion. So two follow-up questions for me is how bad can that loss be? Like is there still obfuscation techniques that you just, through no amount of compute or expertise, can you get back something that is a high enough fidelity representation of the original source to even work with?

24:16James Wilson: And then just also on the nature of different types of obfuscation, I get it that obfuscation does not equal malice. But before you go through that computational expensive process of deobfuscating, are there signs or signals even in the obfuscated version of it that makes you go, yeah, this is obfuscated, but it's obfuscated in this way that just makes me go, I want to look at this a little bit more. To that last point, yes. There are tells that you can, like a really good example is if they use XOR, the XOR key will be in the version of it that comes to you, right? And that's typically a great indicator that you can use for detection.

24:58Detection engineers can, and DPRK, for example, has got a whole host of these kind of complicated alphanumeric campaigns, which ironically are kind of similar to what you see with like marketing UTM code. So being able to basically attribute, I shit you not, James. They're trying to attribute a specific successful thing to a group of humans that are North Korean might be living in Russia. They might be in China. There's all kinds of different places that they hang out. And basically that's their way of kind of observing what is working and what's not. And so they put, they always, almost always, they put these campaign markers on their, and sometimes when you can find those just in the delivered obfuscated payload, and then it makes it really easy to go, oh, this is, you know, blah, blah, blah, blah.

25:49And really easy to find that but they're also getting smart now and they realize that that's what we're detecting on so basically now dprk is throwing one last base 64 uh on top of it right so you can't see the string but you see that it's base 64 and like i see a big blob of base 64 so what they've gotten smart now they chunk out the base 64 and they do all these kind of complicated ways oh my god it's just

26:15James Wilson: yeah so so there's lengths there's a length of um i guess there's lengths that a legitimate software engineer or company would go to to obfuscate their code but but you can get a tell from the fact that this has gone next level and next level and next level to know that it's um know that it's worth looking into but then uh i i come back to the lossy versus lossless thing here are those extra layers making it harder and harder to get a high fidelity you know a version of the code out of it. How often do you deobfuscate something and just go, there's no chance I can make sense of this? Almost never.

26:52And LLMs, frankly, have made that part a lot easier. And I'm sure bad guys are going to find ways to run that too as well. But the reality is that that last mile of deobfuscation has become much easier with LLMs. But yeah, I mean, And it is often a lossy process. It's almost always a lossy process. And one of the most common techniques that is used, one of the most common obfuscation techniques is string or variable replacement. So basically what they do is that, James, you're a software engineer and you say, hey, this function basically pulls a value from an API array and does this thing. And so you name your function what it does, right?

27:34James Wilson: Yeah, yeah, yeah. So what really simplistic string replacement obfuscation does it just replaces that with just this randomly generated hex string so you will never get that back but what happens is uh if you know what you're doing and you've been doing this a while you can build deobfuscation techniques that um and the lms will do a lot of this for you but basically what they do is they look at the once they kind of get it back to the closest thing to human readable code they see what the function kind of does and then they basically that your deobfuscation engine will then rename those strings but it will never be what it started out as because that's gone yeah it's it's it's still pattern matching and it's it's an approximation so all right so i think i'm getting close to a full picture here to sort of unleash you and let you get into all the things you're seeing at the moment but um static analysis gives you to tell that this is worth looking at deobfuscation even before you deobfuscate the signals there that someone's gone to an nth degree that that is sort of unexplainable by commercial rationality you do the deobfuscation you get back that you know um somewhat lossy representation of what the original code was is there other steps involved here either before or after you get that code that that helps you actually do the analysis or are we now at the point where this is paul mccarty at his desk written through code to make sense of this and look for the interesting work um yeah i mean there are um so a really good example is like so if this is a crypto stealer.

29:05Basically, if the intent of the NPM package, the GitHub repo is to steal crypto, or there's a lot of like WhatsApp, you know, payment stuff going on right now. So basically, once you figure out what the author's intent was, there's additional steps that you can build into your process. And this is where the magic starts to happen. So I want to be a little bit, a little bit hazy here. But, you know, once you understand where they're kind of going, then there's other things you kind of kind of bring in you know again to take it that last mile and and and automatically kind of not automatically but um you know find that additional kind of context that makes that final deobfuscation understanding and rendering of it um uh strong i'm a good example of that for example is if you see where this is going if this is just like if this is kind of Because in Southeast Asia right now, there's just all this WhatsApp payment fraud.

30:01There's just so much of it. Indonesia, Vietnam, Thailand, Cambodia. It's just everywhere. So if you see that it's kind of going that way, if your engine understands that, then it can start to look for – there's going to be a WhatsApp credentials there. If they're using Discord, you understand what the shape of those and how they're going to call out to those. You understand there's going to be a curl. Is it going to have a post? Is it going to be a get? like those are things that you can look for that take you to that next step without having to take it all the way to perfectly human readable code um so yeah there's more you could do there yeah

30:36James Wilson: yeah so you mentioned intent which is interesting it made me wonder do you have like a um a finite state machine a methodology in your mind here right because in intent intent strikes me as like a step in a process where you go okay we've we've triaged the malware okay we've got the deal of confiscated code. We've looked through, here's the elements that we're seeing. Here's what this looks like it does. At some point you're going to say, okay, I've got the intent of the person. And that seems to be a big sort of key unlock as to where you go next. But is this, I guess I'm asking, was that term used just as a kind of a throwaway thing or is this, is it, is it actually part of a broader systemic sort of like state machine of how you, you research?

31:18Yeah. I mean, And 100 % it is absolutely like the, my process involves understanding where this malicious thing is going. Is it trying to steal WhatsApp? Is it, you know, trying to steal crypto, whatever the case may be, figuring that out and then being able to kind of leverage very specific kind of functions to, you know, to tease out that last bit of it. So absolutely the intent is super important. and it's computationally necessary because if you throw all of your functions at every single thing, you're getting back a lot of noise, but it's also taking that much longer because you've got to throw everything at it, right?

31:56If you can quickly figure out what the intent of the author is, what is this thing, what is this malicious thing trying to do? What is it trying to steal? Because ultimately there's always like this, you know, when you're doing, when you're pen testing, there's always like a source and a sink, right? You can kind of figure out the same thing in the execution order because it's like, it's going to exfil at some point, right? And you just got to figure out. So that's the end of it, where it exfills. And then at the beginning of it is where the entry point is. And if you can just kind of tie those two things together through the execution order, and sure, it's going to go over here and do this under.

32:24But if you can figure that out, then you just save yourself a bunch of time. And most importantly, James, you don't have to analyze all that additional stuff because DPRK and other threat actors will throw a bunch of filler, huge files at you to make you spend a bunch of tokens, money on tokens. And if you're not doing what I'm talking about, then you're wasting a bunch of time and energy and money.

32:48James Wilson: Well, again, that brings us back to tooling, right? This is where not all tooling is equal. And I think that's going to be the emerging sort of trend over the next couple of months is these frontier models, be it the guardrails or whatever else, they've kind of, I think, hit a bit of a plateau in capabilities. And what's really unlocking is people like yourself. And I've just, I got a conversation with James Kettle that I just published where he was taking his research methodology and getting AI to find stuff he'd never thought of before. But the average, even the average researcher is not going to have those results and they're not going to have it with a one shot because this comes down to your inbuilt subject matter expertise.

33:25James Wilson: Just sticking on intent for a second, what do you do when you just simply cannot work out the intent of something, but it's got all the signals of doing bad stuff? Oh my God, this is like, I'll, I'll text my co-founder and I'll be like, Oh my God, this thing is so dodgy. I 100 % know this thing is malicious as I just don't know what it's doing yet. Like, it's just so frustrating. And I will just, the answer to your question, James is I will bird dog the out of it. I will just, I just will go so deep on it and waste so much time. Here's the thing though, is that when that happens, because I've doing, been doing this a while, right?

34:00When that happens, I immediately stop and I say, okay, what can I automate that I just did? Well, all that manual stuff I just did, what can I automate out of that? And so I stop and I don't, you know, I finished documentation because one thing I've learned is that I need to finish the blog post or the document, whatever that is before I move on to the next thing. Cause otherwise I'll never get finished. But, um, and I immediately then go and try to add that into my process to automate it. And that's why, you know, all of my big things, kill chain and the deobfuscation engine and all that kind of stuff is constantly iterating and evolving and I'm adding stuff to it, you know, because of this process.

34:37I force myself to stop and add it back into the process whenever I can. Sometimes you can't.

34:42James Wilson: Yeah. And I think, you know, I'm setting up a bit of a segue here into what you're seeing, but malware that has all the hallmarks of being dodgy, but you just can't work out the intent. There's going to be two buckets in there. There's going to be, you can't work out the intent because it was just badly coded and just someone vibe-coded it and forgot to give the proper goal to the LLM maybe, then there's going to be the stuff that's truly novel and is worth your time really, really getting to the in-depth, the depth of what the true intent is. Is there an increase in the number of times where after having gone down the absolute rabbit hole with a piece of malware that you just desperately wanted to understand, that you've gotten to almost like this moment of disappointment and being like, really?

35:24James Wilson: That's all? Just, you know? and does that happen more often now because of vibe coding all that sort of stuff or yes yeah 100 % I don't want to say all the time but yes it happens quite a bit yeah you will also see you know moments of brilliance in some of this vibe coded stuff you're like oh that's genuinely not something I've ever seen before that's really smart and then right next to it will be the stupidest thing in the world like the worst opsec or whatever like I'm looking at a Vietnamese piece of malware right now and I have the guy's name why because he put it in his telegram account right it's like in his telegram like come on dude um so yeah vibe coding has from a from an attacker's perspective vibe coding is both both their biggest uplift they've ever had ever because it does all the heavy lifting for him but it's also the downfall i am finding so many opsec mistakes i'm finding oh oh my god something that's becoming very, very common.

36:24I don't know why, but it seems like it's mostly a Southeast Asian thing. I've seen a few other places is people will use their GitHub account to store the payload. And so, and it's a private repo. So they have to include a pat, their own pat in the malware to pull the payload out of there. And it's like, and I guess I've said this before. I think a lot of times they do that because they just feel so protected, right? In many of these countries, what they're doing is not illegal, especially if they're not doing it to people in their own country. And so they just feel, it's not like you and I, like if, if I were to write a malicious NPM package, put it out there, I'd be worried, right?

37:03I don't want to go to jail, right? I got a family, but they just don't think that way. And so what you and I see as an OPSEC mistake to them is just the path of least resistance, right? It's just was, yeah, it was just easier for me to use my own GitHub account. Didn't want to spin up another one. So I just did it. And I'll put the pad in there but old mate that put the pad in there doesn't know to scope his pad and so now i can see all of his private repos right like very useful very useful which actually has been very useful because they're not usually working on one thing they're working on multiple things so then you're getting intel and the other things that they're looking at and the other people collaborating

37:41James Wilson: with them so it's it's all really good intel okay so now we shift into the what are you seeing and i think there's two aspects to this there's what are you seeing in terms of malware in general like where's it heading what's the trends but then to that point around you know vibe coding making for some uh hilarious mistakes and and sometimes some disappointments as to really that's all this was but where's the good work where's the stuff that you get to the end of the the full tear down and just go ah beautiful gotta hand it to them right so so maybe we start with just the industry trends in general like what is what's the most the malware state of the union in 2026 right now all right let's do this um i i think the first thing i'm seeing is that um you know there's the smash and grab single kind of payload stuff and that's becoming more popular too as well but because it's easy to write but more threat actors because of being able to leverage llms and agents are building multi-stage attack chains right and they're doing this for a number of reasons right and you and i were talking about that that ruby gems um we call it um yeah something maker i forget so many so many campaigns now i'm forgetting them all but you know they used five different languages inside of that kill chain.

39:02Um, and whether that was one person or multiple people, that's not the point here. The point is that each one of those things is itself separately usable across different attacks, right? So by using it, by adding these portable functions, when one gets burned, they just plug a new thing in there and then they move on. Right. Um, so, uh, the first thing is I'm seeing an increase in multi-stage attacks across all levels of maturity. The most newbie, you know, wannabe threat actor that doesn't even realize that what they're doing might be illegal all the way up to, you know, the nation state threat actors.

39:41They're all adding multiple stages, which on one hand seems dumb because then it's more places for things to fall apart. But it's also gives them the flexibility that, like I said, if something gets burned or if something breaks or whatever.

39:53James Wilson: Yeah, it's modular, right? I was thinking back to the teardown I did on the Karuna Exploit kit, and it blew me away how that was so modular such that if any one of the little primitives got snapped and was patched, you didn't have to recreate the whole kill chain. You just had to say, well, now we need a right primitive in WebKit that can work with this sort of each end of the chain. But the thing with software engineering, when a new paradigm takes over or a new language becomes a new hotness or a new way of doing things becomes the norm. You can sort of trace the origin of these things, right?

40:27James Wilson: Someone prominence made a blog post about it. That's gotten some traction. They've done some talks. That's made a noise, right? You can find the lineage. But how does this work in an area where it's malware? Like, let's take this example where you're seeing modular architecture being done with multistage chains in malware. But how did that become the norm? I don't think we can just blame this on, oh, it's what AI suggests and everyone's using AI, so that's why it came about, right? How's knowledge being shared amongst this, what I would assume is an otherwise rather isolated and fractured ecosystem?

41:01Well, I think a lot of it, honestly, and I'm about to speculate, James, so let's just be clear. I'm speculating based on my experience. I think a lot of it is just organic for the threat actors. So basically what I mean by that is that what happens is they start out by building a simplistic one shot kind of singular attack, right? Yeah. It gets burned and they're like, oh, now I got to build another one. Right. So then go and build another one. And then that gets popped. And then they realize, well, okay, if I maybe make it a couple of stages, then even the first one gets burned and the second one will last.

41:33And that's exactly what happens. And DPRK has been doing this for years and years and years. And if you look at the kill chain, the typical DPRK kill chain, which is anywhere between four and seven stages, right? The stuff at the beginning is what iterates on a lot versus at the end, the persistence layer, which is still to this day, often invisible ferret, right? Which like I actually pulled apart the source code about a year ago from an attack and looked at the source code. It was exactly the same sample in 2025 that I'd seen in 2023. Literally, the source code had not changed a single iota.

42:10All they had done is they had just now wrapped it up in Pi installer to make it an executable, to make it more portable, right? So at the very end of the kill chain, that stuff doesn't have to evolve very quickly, right? What has to evolve and be changing constantly is the stuff at the beginning because that's what we find. That's what we detect, right? And this is why organically threat actors will often just kind of land in this multi-stage kind of format and methodology. There's another reason for it too as well, which I call the Taco Bell theory, which is, you ready for this?

42:44James Wilson: I'm so ready. I've been using this for years. Taco Bell, which by the way is failing here in Australia, but anyhow, they only have like six or seven ingredients. Like there's cheese, there's refried beans, there's sour cream, there's tortillas. Like there's only a few ingredients, right? But they make like 8 ,000 different menu items based on those, you know, six or seven ingredients total, like lettuce and onions, right? They just make all these things out of it, right? And that's the same thing that DPRK is doing. So they have these like six or, you know, seven stages. And what they can do is they can mix it up, right?

43:17They can change it up. And we see that all the time. I'll be looking at two different NPM packages deployed on the same day, and they will look different once you get into the guts of them, right? Ultimately, when you pull back, they're all going to be using those same six or seven ingredients, but they can change it up. And that's the important part because they're constantly just trying to like stay not detected long enough to pwn the most number of people to compromise the largest grouping of victims. So that modularity allows them to plug and play these things in. So, for example, when I found null receiver, the second package I looked at that was using it had null receiver at stage two, but then it called an IP and that IP immediately called ether hiding.

44:03So in the same kill chain, they were using ether hiding, which they'd been using since 2025 and this brand new technique. Well, guess what? Since then, ether hiding is mostly gone and now it's just null receiver. And then it pops out IP addresses and some custom domains and all the kind of usual stuff at the end.

44:20James Wilson: Interesting. but that allows them to kind of mix and match. And what that does, especially if they're adding those, those campaign markers to each, each version of that, they can tell, Oh, this one over here, this particular concoction lasted on NPM for a month. We got a month's worth of compromise out of it. So that, that package, that burrito or that enchilada or whatever, that's the successful one. And then I'll just, they'll really double down on that. And then as people like me and, you know, Akito and Ox and all the other companies out there, you know, see that pattern and that becomes less successful to them, they'll start looking for those other ones.

44:57And that's why they have to have those campaign markers on each one. Like literally each package will have a campaign marker on it.

45:06James Wilson: Each component so that they can track the success of it and determine it. So something you said there, it makes sense, right? What you said there, I think, is that the modularity is not like a learned technique. it's an inevitable discovery out of their own needs but it almost sounded like you were drawing a correlation between the complexity and the level of engineering that goes into the earlier stages of the of the chain versus the latter stages am i right in saying that the novelty the really awesome work the stuff that just makes you go chef's kiss great work tends to be at that early end of the stage and as you go towards the end of the stage just get like less and less interesting, less and less good work, or am I drawing the wrong sort of inference here?

45:50Well, I mean, that's one inference you can pull from it. And I agree. The way you just described it, I would agree with what you said. I would also say, though, I would counter by saying, you know, those latter stages that don't change a lot, invisible ferret not changing a whole lot itself, the source code itself, the way they package it up has. But that's because it's really successful. That was their go-to persistence. And they're using that now as part of pollen rider. Like we haven't even talked about pollen rider yet about how they're using that persistence, but yeah, you're right. Like, I mean, the, the, they have to throw more new stuff at that shifting left, right?

46:26Like still to steal a term here. Um, I, you know, I, I termed a, uh, coined a term yesterday, actually. Um, I said, instead of go to market, go to target, they have to figure out a new way to get, go to target. Right. Um, this is, this is the startup entrepreneur and the researcher just combining this weird baby. But anyhow, they have to find these ever new unique ways to get their stuff to successfully drop and run on victims' machines. And so they tend to use the same motions. Like VS Code, for Contagious Interview, VS Code is still the dominant way that they do that initial compromise, that initial infection vector is still via VS code because it freaking works.

47:15It just works, man. Why, you know. But the way they hide it, you know, I don't know. They're changing some of it, but some of it doesn't have to change because it just works. Like they use, what they'll do is they create a directory full of like 60 or 70 font files. And one of those font files will actually not be a font file, James. It'll be malicious JavaScript that's got a, you know, a TTF suffix on it, right? And they call that and execute it in VS Code. And that pattern they've been using successfully for months since like at least February of this year. And they're not changing that at all.

47:52James Wilson: Yeah, it's just, it was something that sort of fascinated me to think about the, I guess the dynamics of the level of effort is going into the early parts of the kill chain, which means that there is a high amount of rotation. These things get caught. They've got to iterate on them. It's just interesting to consider that the most interesting work here is also being done in the most disposable and high-churn area. And so you're kind of ripping through all these novel things that will pass you by if you're not paying attention, which I think is a good point to sort of let's actually delve into some of these examples here of the really awesome work.

48:28James Wilson: You've messaged me a few times about DPRK and the ether hiding. There was a thing you sent me this morning about Pollen Rider and the persistence. I think the persistence thing, let's, let's save that for sort of the wrap up around, you know, what do people need to understand and do, but let's delve into, you know, okay. What is, what is, what does amazing look like here? What, what's the kind of, what's the level of engineering that makes you go, damn, that was good. Oh man. I was just a lot of, I mean, it's like when you see enough of it, it kind of gets a little bit boring, even when they're changing because you just see so much of it.

49:03Right. So like when I, when I originally started working on DPRK, I was just constantly like, oh, whoa. Oh, whoa. And even though now like null receiver, very is brand new and sure that was unique. But my expectation is that they're going to be doing other kind of things there at stage two because they have to write there. Our detection of their bad stuff is getting more successful. We're detecting it more often. but their use and their knowledge of blockchain is yeah i mean it is impressive i'm not gonna i don't know what other word to use james it's just really impressive like the way they figured out how ether hiding like like most of the people i know that are like you know crypto defi people didn't realize that aptos and tron had these little you know memo widgets right like that's just, that's really unique.

49:57And so they just really understand crypto really, really well. And I think that brings up an interesting ancillary, which is DPRK, because they steal so much crypto, they want to use things that are crypto. They want to pay for all their bad stuff. They want to pay for their VPN and crypto. They want to pay for their virtualization or their VPS and crypto, right? So they're basically going to go to all those vendors that accept crypto because then they can use it without being lossy on their, you know, they don't have to convert it to fiat and whatnot. And so what happens is I'm spending a lot of time now to your point, like figuring out where are they going to go?

50:34Where are these new vendors and these new platforms and things they're going to use because that accepts crypto. A really good example of this is that I noticed a DPRK campaign had used GoDaddy for its registrar, which you don't see very often. And I was like, okay, that's really weird. And I started looking into it. And it turns out there's this whole ecosystem of payment providers that will let you take your existing crypto, Monero and all the other ones, right? And pay for things for companies that don't accept crypto. And a good example is this company called Moon, Moon Payments, Pay With Moon.

51:12And I didn't even know that whole ecosystem existed. So to answer your question in kind of a convoluted way, you know, I think watching where they're going and trying to figure out like a detective ahead of time, I'm trying to wind them, you know, I'm trying to aim in front of them so that I can, they're out there doing this stuff and I can be there, you know, just after they are to catch it or hopefully maybe even early to catch it. So I think that's where I spend a lot of my time now. And I really kind of appreciate their innovation is finding ways and new platforms to abuse, to abuse.

51:49James Wilson: That's a lot of it. Okay. So, uh, DPRK has got their specialization in crypto, but who else specializes in what? Like what's the, what's the ancillary there for Russian actors for the Southeast Asians? Yeah. Uh, well, all right. So like the Vietnamese and, and Cambodian and Thai threat actors, Laotian threat actors, that almost uniformly, you know, this is a generalization, James, but almost uniformly is going to be payments. They just want to steal payments at the payment. So basically they target mobile app. So when they're doing their software supply chain attacks, they are almost singularly focused on kind of mobile platforms and, you know, APIs and all this kind of space.

52:30So like there's all these WhatsApp things like Bailey's that they're attacking constantly. So, and you know that this gets back to our conversation about intent. If you know that those threat actors want to steal payment in that mobile space, then you know what to kind of, you know, the shape and the form of the things to look for to find it. Chinese threat actors, very, very different, right? Now you do have, you do have TPRK and other threat actors, you know, based in China and, you know, that's all fine and good. but Chinese threat actors, when they're building software supply chain attacks, just, it just looks different.

53:07They're not looking for crypto. Um, they're looking to steal things. They're looking for, uh, either smash and grab, uh, just to grab, you know, intellectual property. I'm oversimplifying it cause it's more complex than this, but, um, or, or separately, they're looking to have enough persistence so that they can get in and kind of figure out is there something good here right so it's just a very different if you're looking at a genuine chinese software supply chain attack component versus a known north korean one you just know you're going to come at those in two very different ways interesting yeah again because

53:43James Wilson: they've got different intent but also it's interesting to hear their different expertise around the ecosystems right so different actors are learning in depth different parts of their stack that I guess suits and serves that intent. So before we dive into, you know, what does the business, what does the defender need to do with this? Anything else you want to cover on the, like just mind-blowingly good tradecraft in malware? Oh, wow. This one is, it's been done for a while, but I just thought it was very creative. Basically DPRK and others have done this now too as well. So DPRK came up with this technique where basically what they would do is they would create this really simplistic rotation where they would take something, they would base 64 encode it, they would flip it, they would reverse it, and then they would XOR it, and then they would just do that again and again and again and again.

54:34And initially, that was 32 times, and then it was 64 times, and then it was 128 times. And the whole purpose of this, James, was to make your sandboxing analysis of that thing run out of memory. That was the whole intent right because you run this in a sandbox it's in a container it has a limited you know defined amount of memory and the whole intent here was to make this thing oom that was the intent and i just thought it's just so brutally like efficient it's not really kind of mind i mean like reversing like like you know that's as old as it gets right but it was effective because it was computationally heavy and you had to store all this thing all this stuff in memory You had to create this crazy hash of all these different versions in memory, which then exhausted memory.

55:21I thought that was really brutal and impressive in its own way and got the job done.

55:29James Wilson: This is the perfect setup for, I think, where we go for the last section of this, which is, if I think back to what we've covered so far, this has been an evolution of the static analysis that gives you the tell that there's something potentially malicious about a package. Then we talked about how you take that package, deobfuscate it, all the challenges you've got there to even get to the point of understanding what does this thing do. You then focus on the intent, right? It's one thing to know what it does. Then you've got to try to work out, yeah, but why? Why do this? What's the intent behind it?

55:56James Wilson: From that intent, you can begin to do two interesting things. You can start to classify, you know, either the, I guess, the group's motivations. but but also the thing that i found really interesting as you were explaining that was this idea of the intent and you were talking about the dprk there the intent of what they want to do in the crypto space and the fact that they are so well versed in crypto and they leverage that for what they want to do for c2 and other communication that allows you to start to think of how you get ahead of them but also what you just said there around that technique of like getting the container that's the sandbox to out of memory die well that's them trying to get ahead of you because they know what your intention is so this leads us to the point of now we i've got to ask you to step out of your world of research and and understanding the intent and where you want to go put yourself in the in the shoes of a defender that is at the mercy of these attacks hitting them and and their developers in the supply chain etc what can what can they do what do they learn from your research here and what's the sort of, I've come to work at 9am on Monday morning and my project for this week is we're going to improve our defenses against this incredible wave of malware that is out there and hitting us.

57:12James Wilson: Let's get in the defenders' shoes now. What do they got to do? All right. This is a great segue. Well, first, if you're so inclined, come to one of my trainings, whether it's in Canberra, B-Size, right? Which by the way are free. All the trainings I'm doing this year 100 of them are free um which i mean i need to look at that because i do have a mortgage and a family and stuff like that the economics of that will only last so long but yeah exactly here i don't know i'm i'm driven to the point of of of uh you know not really thinking about the financial outcome but um well this is exactly why this is the point to talk about this right is that you are so driven to get this message out there to to raise the awareness of this but what i'm not sure, again, I'm approaching this from just my, I don't get it standpoint is what is that thing people have got to do?

57:57James Wilson: What are you driven to get people to do? Yeah. Well, I mean, I think the first thing is just the most obvious thing, which is just to understand that this is a risk. Like the whole, and particularly with DPRK and Paul and Ryan and the whole persistence thing, I've just been frustrated because I've been talking about this for a while and nobody's really, to me, it doesn't feel like organizations are really doing that much about it. Like EDR vendors are not evolving. Like the reality is that EDR doesn't catch this stuff. So, you know, you've got 500 developers inside your organization. You've mandated that they all have EDR running on their machines and they might, or they might not, they might have exclusions, but all that aside, the reality is that's not catching this stuff.

58:36Right. So, um, what can you do? You can come to one of my, my trainings. You can kind of figure out what the threat looks like, what the risks looks like. Um, but you can also, you know, sign up for open source mailwares, you know, free feeds. We've got a bunch of free feeds that people can call on. People all around the world pull our free feeds every day. We've got over a thousand, sorry, over a million API calls per day. So there's that.

58:57James Wilson: Wow. Yeah, I'm very proud of that. That's all free. Like, you know, that million API calls is all free, which I'm also paying for, but that aside. Beyond that, though, realize that there are, there's two types of software risk. The first is vulnerabilities, right? Basically, developers have accidentally added, and this is when you're doing your research, James, on the Apple ecosystem. Basically, what you're shaking out there are accidental vulnerabilities. They were not added there with malicious intent. The problem we have, though, is our whole industry is focused almost explicitly on just vulnerable software risk.

59:40They really don't think about the fact that there's this other type of risk, which is the malicious intent, which is bad guys trying to compromise you. And, you know, I'm sorry, but, you know, if you try to handle both of those risks inside of the same kind of ecosystem in the same team, that's a very difficult thing. Like one team is handling just basically this backlog of all this vulnerable software that we all have, right? It's 8 ,000 bazillion JavaScript CVs that we've all got. And that's a big job. And I'm not saying don't do that. But you also need to, I mean, I'm going to call it out. We need to start building teams to understand and can look for this malicious threat too, right?

1:00:19So kind of pulling subject matter expertise out of SecOps and incident response teams into this kind of software engineering space, right? We started at the top of this talk talking about this weird kind of space between the two. I think that's the biggest single takeaway is understand that if you don't have this expertise inside of your organization, there's not a lot of products out there. You can use open source malware and you can do that stuff, but EDR is not going to help you. You need to build this capability inside of your organization. So understanding the risk is important.

1:00:56James Wilson: and this is something that's been on my mind is that there's um so much talk in the news cycle over the last couple of weeks of microsoft has released their patch tuesday with 400 patches that's as many as that you know that's their new record and you know apple's 26.6 300 patches right everyone is talking about this release came out with this number of patches and i'm increasingly feeling like there's a message to be told here which is the bug count is one thing the point you just made there is that what really matters is who's your adversary? How interested are they in those bugs? How are they thinking about turning against?

1:01:31James Wilson: Who's the malicious actor and what are they doing? Is that the right way to think about that? Yeah. Let me posit this in a different way. Let me say it this way. The reality is that data shows us that typically less than 5 % of all vulnerabilities, right? Less than 5 % of all CVEs are actually attackable in any given platform, whether that's Microsoft or wherever, right? So a very small percentage of those vulnerabilities are actually exploitable. And this is why reachability exists. Like Socket and everybody else, Socket and Endor and everybody else have built reachability to kind of narrow this number of things that you have to look at.

1:02:06And that's great. But the reality is that less than 5 % of those are actually exploitable. Now look at the other type of risk, which is to your point, 100 % of them are actually real risks, right? So like, but we've all of our budgets go to the former and not the latter. And I'm just saying, you know, like, I mean, I know I've got an agenda because I'm clearly in this other space. But the reality is that I think we need to kind of look at where our budgets are going and understand that, like, you're spending a lot of money right now. And I'm not saying you shouldn't trying to address vulnerability risk for stuff that we know has like less than a 5 % exploitability, right?

1:02:43Versus over here, you know, you're not really doing a whole lot. And 100 % of those are a problem for your organization.

1:02:50James Wilson: Yeah. And that's an internal facing thing that the companies need to look at for their own software. But I think they also need to look at it across their vendor landscape as well and start to think, you know, what's the conversation that's happening within Fortinet? I'll pick our, you know, favorite, you know, target here. It's Wednesday, so it's another Fortinet bug. But I did also just want to come back to one thing and play a bit of devil's advocate here, right? You said, you know, EDR is not going to catch this. there's going to be people listening to this that go well my edr will i got this really good edr my vendor rock solid i got a good contract with them i love the account manager he's really good so um you know break their hearts why is edr not going to cash yeah you're ready for this james yeah i'm ready my answer to those people is come at me bro the reality is that your edr will catch a vanishingly small number of these JavaScript or Python attacks.

1:03:45James Wilson: But why? It's pretty straightforward, right? EDR is not built to track this highly iterative, interpreted malware, right? Will it see that Py installer version of invisible ferret at the end of the kill? Maybe, right? But by that point, you've already been hit by two or three different info stealers before that, crypto stealers and info stealers before that. So yeah, the EDR isn't capturing it because A, there's file hashes, as we talked about at the top of this thing, are just mostly worthless exercise inside of interpreted malware. And B, the EDR engines, the behavior that they look for, the AI that they're famous for, it's very different.

1:04:30You look at ransomware, the behavior that's happening behind the scene where a bunch of files on your machine are all getting encrypted, that's what they're built to understand and look for. This one-off thing where it's like, hey, let me go and look for a bunch of files and then X fill them in one motion. That's not what EDR is good for, right? And I know because I like look at them all the time. The reality is like I drop samples into VirusTotal. I have EDR running on my machine. I have got EDR running on my sandboxes. And I know. And this is not me picking on EDR. It's just to say it was built to solve a different problem.

1:05:02And that problem is really important.

1:05:04James Wilson: Well, that's what I was thinking, right? This is a charitable and defensible argument we're making here. We're not just picking fun at EDR as something that's worthless. It is, you know, it was designed to catch a class of, you know, typically binary driven, heavily, you know, Cisco laden stuff that you can watch, right? When that thing starts, as you said, when it starts encrypting a bunch of files and doing that stuff, Cool, catch that. But we're talking about info stealers here that are looking, feeling, and acting like legitimate JavaScript that's executing, legitimate package installs and scripts, right?

1:05:40James Wilson: It's very difficult to even think about how you would apply the same heuristics and models in an EDR sense. Even when you do have persistence, when you've been unlucky enough to get Out of Cookie version 5 or Invisible Ferret and you've got persistence on your machine, that process is just a node process. It's just a Python process. And you're a developer, probably. So you just have a lot of other Python and node processes that look the same, right? And EDR is not smart enough to be able to pick those up because that's just not the problem that was built to solve. So getting back to your question, what do people do about it?

1:06:18Realize that those class of tools are important. Solve for a different problem. You need to start thinking about, how do I solve for this problem, which is malicious, you know, software supply chain attacks. And, you know, unfortunately, the solutions that we have in this space are pretty early. You know, things like package firewalls. Socket's got one. Makito's got one. You know, lots of people have them. But ultimately, those firewalls, all they do is wrap around your package manager. So when you call UV or PIP or NPM, all it's doing is calling their tool, which then goes and looks up a thing.

1:06:53If you just call the actual absolute path in your machine for the package manager, you've just bypassed that package. Right, right.

1:07:01James Wilson: It's almost like an opt-in on a system of it works as long as your devs are all doing it. But that's a heck of an assumption. And to that point, package firewalls are important. I think it's part of the solution. All I'm saying here is that you just have to realize that there's got to be a different set of solutions that you address this malicious software risk rather than the other kind of things that we've been talking about. Right. And even if we take the case of the package firewalls there, I 100 % agree, right? They're good products and they do what they do. But it is also such a clear theory of victory for a threat actor and it becomes an arms race.

1:07:34James Wilson: And ultimately, this will sort of asymptotically get to the point where they just get so good at creating new malware so fast, it spreads so fast that space and time negates the ability of a package firewall to catch up. But that can sort of lead you into the deep, dark depression of, well, okay, do we just assume breach then and we just get really good at rotating the keys. Like, is that the fallback that we've got to have in mind? Well, I mean, frankly, it's part of, it's part of, I mean, the honest answer is yes, but also more, right? Like the reality is that if you have not got processes at your organization that assume that one of your developers' machines is going to get compromised via one of these software supply chain tech and you don't have a way to deal with that, then that's something you need to start looking at right away.

1:08:25They will get compromised, and you will have a machine that's got persistence on it, and your EDR is not going to pick it up. What do you do then, right? And also, there's the developer's machine, but then there's also your CI pipelines, and there's a bunch of other places where these attacks happen. What are you doing there, right? Right. So, yeah, understanding the problem, where it happens is one of the reasons I'm out here being yappy.

1:08:49James Wilson: Well, okay. So, so very last thing, and then we're going to wrap this up. You know, you talked there about what to do as like proactive and reactive sort of measures, but there was an interesting message you sent me this morning about Pollen Rider, where folks are actually having trouble even getting rid of the thing, right? So what, what's happening there? Let me give you – I'll give you the 30-second background on Pondrider. So basically all those contagious interview, you know, fake LinkedIn recruiter campaigns that were successful over the – you know, contagious interviews and going since 2023, a large number of those have ended up with persistence on developers' machines all around the world.

1:09:30And basically what happened is – so TPRK didn't really account for that. They built their attacks to steal crypto, right? They're holding up, by some accounts, 50 % of their GDP is just stolen crypto,$2.2 billion last year alone. But they didn't really account for that. They just wanted to steal crypto. But then the thing is that they had persistence on a bunch of these machines. And so I could just imagine this roundtable that was happening in Pyeongpang where they're like, what do we do with all this persistence we've got? And they came up with this really smart idea, which has been brutally efficient, which is they just basically use those compromised machines.

1:10:09And they don't always necessarily have access to the victim's GitHub credentials or NPM credentials. Sometimes they do, and sometimes they don't, James. But what they do have is they do have control of the machine. So basically what they do is they use control of that machine to then drop malicious JavaScript payloads into like all the Git repos on that person's machine. and then if they don't have access to github or npm credentials what they do is they just wait for old mate to just do their job which is to push code out to github and guess what their payload just flies along with it it just rides along right because they're using forced commits um so they're basically just overwriting a malicious payload on top of an existing commit and that's brutal because when you look at the source code the commit timestamp is you know from two months ago or three years ago or whatever.

1:10:59And so for people that don't understand that those commit timestamps are easily faked, they look at that and say, oh, we don't have any problem here. You know, this is three-year-old code, no issue there. You take a look at it and you realize bad guys wrote a payload into it last night, but it still shows a timestamp from three years ago. And you've now pushed that up into your repo. And so what we're seeing here, to get back to your question, is that all these developers that have been compromised and as they work on all these open source projects and stuff like that, it's just kind of bleeding out and more and more people are getting compromised via this.

1:11:32And when a lot of these people are working on multiple projects, you know, a lot of freelancers have been affected, for example. And then it gets into actual, you know, production, you know, companies, production systems and whatnot. When, when these teams find, and I'm laughing and I shouldn't be, because I'm not trying to be disrespectful, But when they find that they've been compromised and they try to address it, they just get re-compromised because they don't realize the payloads are in, you know, VS, their VS code repos and their, and their GitHub repos. And it's just all those places. So they go on, I have screenshots and I've got people that are hitting me up.

1:12:09They're like, I got a new MacBook and I'm infected again. It's like, yeah, it may, it's not your MacBook. I mean, it was, but it got infected from the Git repo that you just, you got your brand new GitHub, your brand new MacBook. book. And the first thing you do is get clone all of your projects and boom, you're done again. And this happens, um, you know, to the teams and you just see it again and again and again. And we're not really addressing this as a culture when we assume that thousands, tens of thousands, and soon it'll be larger than that of people in GitHub are compromised, don't know how to get rid of it.

1:12:44And they're just spreading this infection to a whole bunch of other people. That's not a threat we've ever really faced before, man. Yeah.

1:12:51James Wilson: I was just imagining that team meeting in Pyongyang where it's like, okay, what's the next item on the agenda? Oh, persistence has worked surprisingly well. Yeah. You know, the propagation method actually got us persistence. We weren't imagining what do we do? Well, what do we do? Let's persist the propagation even more than ever before. And hence, this is where we're at, right? In another universe, you could imagine, or maybe this universe, you could imagine that it actually just happened totally organically like somebody was you know somebody was compromised and you know just organically they spread it and then dprk was like oh my gosh like we didn't even think about this we didn't even like contemplate that and suddenly now this thing is exploding now to be clear pollen rider is a very specific like you know they're doing this on purpose right but that's not to say that originally they didn't see this kind of happen organically and thought oh maybe we need to double down and spend some time and double down on this and now it's just taking off.

1:13:48It's everywhere. And the problem too, is that we're seeing that go modules and NPM packages and all kinds of other things are being infected because they have access to your machine. They can push into your GitHub repos. And guess what? All of those, you know, your PHP packages on Packagist and your go modules and the go modules registry, those are all GitHub repos. And those have all been now compromised with these malicious payloads. This thing is just a self-replicating me and my co-founder like it's a worm but we just don't want to call it a worm like it's just this worm-like but different yeah it's a different kind of uh virality or um

1:14:26James Wilson: uh propagation here it's it's hard to quite find the right term but uh paul let's uh let's wrap it up there you've taken us through your techniques the day in the life of a malware researcher we've talked about then the interesting things that you're seeing the trends and also the where the really great workers. And we've rounded out with some, hopefully, pretty practical advice for folks to think about, not just new ways that you've got to solve this, but even just thinking about your existing tooling, how do you be more prepared? And so hopefully folks find this useful. And mate, thank you very much for spending the time with me.

1:14:58Thanks, James. Appreciate it, buddy. Cheers, mate.