EDR Killers: Live Rootkit Demo That Blinds Security Tools

All right. Well, first I want to start off with a question. Uh, we're going to be talking about EDR killers and I'm going to be doing a live technical demonstration. U, but before we start, how many here are have or are running an EDR system of some kind today? Okay, keep your hands up. those that are, how confident are you that your EDR system is seeing everything that it should see? Okay, there's some decisiveness out there. Uh there's some hesitation. That's why I'm here today. Um so, uh specifically, um we need to make a shift and we're going to uh talk about that today. uh from something that we have been doing traditionally uh my entire career uh over 25 years in

both technology and specifically cyber security. Um and uh that is uh learning how to trust in our systems and our security and how we need to shift that trust because uh there's a problem that we've historically had which is an implicit trust in our systems and our security tooling that we use to protect ourselves. And so, uh, with that, um, we're going to spend the next 20 minutes or so, uh, compromising an OS kernel, blinding an EDR, and, uh, catching it with an innovative approach that shifts the paradigm from what we've historically been given as tools to help us detect um, uh, things that are going on that we historically haven't been able to see.

But uh to get started, we want to do the fun thing first. Uh we're going to do the demo. And in this demo, it's uh an attack demo that uh is going to uh utilize a very well-known edr platform. Uh I'm going to be running the demo on a Linux uh Rocky 9.5 distribution. And I also have this innovative technology called runtime uh integrity running on this same system. All right. And uh I'm going to get something started here really quick

because it takes a second. All right. And you can see I'm a normal user here. So I'm having to I'm downloading a file from the internet. and I have to put credentials in to allow that file to be downloaded. While that file's just completed downloading, the one thing I want to focus on is uh we're looking at a EDR pane of glass here. Uh and then the new detections here, currently set at zero. I just downloaded what's called the IICAR file. If you're uh familiar or not familiar with it, what it is is a test piece of quote malware. It's not malware, but there's a signature in it uh that every security technology knows how to detect.

And so you can use it to help verify that your technology is actually functioning and detecting and and and working. So I've downloaded that. And so here in a moment, we should see this new detection tick up to one. Just proving that this EDR vendor is functional on this demo. Okay. And doing what it's supposed to be doing. Uh little bit of background about what you're seeing here to set the context is the uh the malware that I'm going to be using uh we use for red teaming as well as for education demonstration purposes. It is uh not malicious in nature. We have full control of the code, but uh it has been designed and we've developed it based

off of a realworld uh piece of malware that was discovered in 2020 out of Russia. Uh this piece of malware actually was compromising systems at uh an alarming rate and nobody could detect it. In in fact, the FBI and the NSA actually had to put out a release informing people about it. and it's called drobo rub uh was the actual malware. So we have uh created this uh red team tool that mimics a lot of the functionality not all the functionality uh but a lot of the functionality that it was using uh in in its uh campaign that uh uh it was being used for. So uh with that uh um as a part of the background here uh

maybe another minute or so to the detection I'll I'll just show you over here. This is the uh the new capability that uses an approach that we'll briefly highlight uh later on. Uh but it's also running on my system and it's showing a successful check of my system. The demo rocky is is the system. The other one is my actual laptop itself too. Uh, okay. There we go. We've got the one detection. So, the iCar file that we downloaded was detected as it should be and as we would expect it to be. All right. So, at this stage now, uh, what I want to do is go ahead and um, uh, compromise the system. Actually, let's take a look at this.

Okay. So, you can see the iicar file right there. plain in plain sight. And we're gonna look at the contents of that really quick. There is the signature in that text file that the technology knows how to detect. Okay, that'll become important here in just a minute. So, uh what I'm going to do is I'm going to remove that IICAR file from the system. And there you can see it is not there anymore. And we'll get get it cleared out. Okay. So now uh I am going to implant malware on in into this system and specifically uh this implant is going to implant into the kernel of the operating system. Okay, which is going to be you're going to hear that a lot if

you're not familiar what the kernel is. Uh basically it is the control center the brains of any operating system. Okay. uh and it makes all of the decisions and actually executes whatever your application is asking to happen whether it's looking for a file, saving a file, opening a file, um what uh sending a data packet on the to the network, anything that is done actually is occurring ultimately in the kernel which interfaces between your applications and the hardware of your of your system. Okay, so it's the control center of your operating system. So we have just implanted malware into that. So what what does that do? Just a second here. All right. So the first thing I'm going

to show you is who I am. I am the user Rocky currently on this box. That's what I'm logged in as. You saw that I'm a normal user because I had to put in my password to download a file. I don't have uh any special permissions. I'm just a standard user. Because we've implanted, we've essentially taken over control of this computer entirely, okay, as an attacker. So, we saw that our security tool could detect that download of that test file. But as soon as I compromise the system, um, at the kernel level, um, as an attacker, I control everything. Okay. So, I'm going to use what's uh you may have heard of living off the land

techniques. I'm using the kill command, which is a valid Linux command to typically kills a process or or whatnot on the system. But I'm actually instead of just running the kill command, I'm going to put some signals on the end of the command that you can see there that are actually communicating command and control to my malware. It's not going to run the kill command. It's actually going to do something different. Okay, so here we go. We're just going to run that. And now I'm going to look at who I am. I'm now root. Okay, I just ran a privilege escalation against Linux and elevated myself out of a standard user to a full root user on the box. So now I

have complete uh operational control um as a root user. Okay, so that's the first thing that an attacker will try to do. Um, however they've got in initially, once they gain a foothold, credential harvesting, fishing, whatever the case may be, vulnerability, zero day, um, once they gain a hold, even as a standard user, they're going to try to elevate privileges to change their context and have uh, uh, more capability on the box. So, the next thing that an attacker is going to do is we're going to look at the colonel message log and we're going to see in here the malware we called rogue. Okay? So, you're going to see a bunch of entries in here called that that say rogue and

things after the fact that is actually logging the things that were done to the system when I implanted and I privilege escalated. Okay, so great. That's what we want. We want to see that stuff in our log files. Well, the attacker doesn't want that. So again, we're going to use command and control and tell our malware to offiscate our log file, modify the log file. Right? So in this case, for demonstration purposes, nothing to see here. Uh we've over overwritten the log file. Uh the attacker is not going to obviously do that. uh they're going to redact what they're doing in the logs and or they're going to replay the log file to make it look like it's normal

activity that's actually going on thereby hiding the real activity that they're doing on the box. Meanwhile, your security tools that are relying on logs or whatever have no idea. So this is one mechanism of blinding your security tooling because now you're not really seeing what's actually happening on the box. All right. So from there, we've kind of figured out a way to cover our tracks now. Um, so we can do some more things. So we're going to download that same file that we did at the beginning again that was detected by our very popular EDR. But this time we're doing something different. As we download the file, we've invoked through this script our malware to interact with the download.

Okay, so you can think of this as an attacker. Now, let's get more I I need more tooling on this box to continue to do what I want to do accomplish. Okay. Uh so in this case that IICAR file is where not there right. Uh so where is it? Well the attacker using the malware is actually hidden a user space piece of uh uh code or in this case a file. Right? So h how do we know it's there? Because in this demo, I'm allowing us to call up the bits of the file to show you the signature that we previously saw, even though the file is invisible to us. This is important because at this point

now, an attacker has new malware on the box and the system itself does not know that this piece of malware is on the box that we downloaded. Has no clue. Well, if the system doesn't know that there's malware on the box, how are our security tools going to know that there's malware on the box? It won't. Because our security tools rely on the information being provided by the system itself about what's there, where it's at, how you know what's running, all the what processes, what ports are open, what all that information. The system is what is telling our security tooling what is act what what's happening on the box from its from the systems perspective. Okay.

So we know that this is here um but nothing else does. Um an attacker again is not going to let you pull the bits off the they're going to hide it where you can't even see the bits even if you typed in you know asking for the contents. Okay. Um, so now we have additional tooling. We can do e extra things, but now we're hidden even more. Our tooling is hidden. Um, so what about uh network activity? Well, here's a bunch of processes running on my system. One of interest that we're going to focus on is SSH. Oh, we've got an SSH server running on our system here, listening on port 22TCP as we would expect. Uh, great. Um,

however, maybe an attacker installs this. Maybe they install it silently. Again, removing all evidence that this has been installed. And um, as an attacker, I want to

completely hide SSH. Okay. So again, it's not hiding it just from the operator me. It's actually hiding it from the system itself. Right? So now in this list, same list as above, you don't see SSH. What's even more critical about this type of a capability is not only is it hidden from the system, but let's say you have a hostbased firewall set up on your system. That hostbased firewall, it doesn't know that port 22 is there because the system doesn't know that it's there. So you now have even if you have rules in your firewall blocking communication, it doesn't matter because the system doesn't know how to block it because it can't see that that is there

actually. Okay. Um, and then finally to end out the demo here. Um,

remember I said we called it rogue. So there is our piece of malware visible running in memory. You can see how much how many bytes it's consuming of memory. Uh and um, as an attacker, that's not a good thing to have that hanging around. So, again, I tell my malware, take care of that for me. And now my malware is completely invisible. Okay. uh what we're you know what you're seeing here um this is what is going on when we hear about ransomware uh data breaches these things are occurring even with mature security programs in place right trying to use defense and depth trying to use you know the best of the tools on you know that are out there yet we still

see ransomware more and data breach being successful. Why? Because of what this demonstration is showing is that we are overly um trusting in the systems and the tools that we're using because historically there is a a a flaw essentially in um security architecture and the way things have always been. Okay. And and we need to address that. uh to to to really um stop these types of attacks from occurring. So um really quick uh the other thing to highlight is back to new detections. Our EDR system saw nothing that we did during that entire demonstration. Okay. Uh completely blind to all of that. We implanted malware, took over the kernel, we modified the system in

various ways so that we could stay hidden and invisible. Uh, and our technologies that we rely on had no visibility of that. All right, we're going to flip over to just demonstrate really quickly runtime integrity. What did it see? You can see We got red. Okay. Um, it did not fool this capability. We know that our system now lacks integrity. Okay, we're going we'll talk about that a little bit. As a matter of fact, not only do we know that it lacks integrity, but we know exactly where the modifications of the system occurred that caused it to fail integrity. Okay, so some breadcrumbs for memory forensics and and things like that if you want to

go down that route. But ultimately the high signal good or bad becomes extremely critical when we're fighting zero days and those types of things that are um essentially defeating or causing our security tooling and our systems uh to lack integrity and and be ineffective. All right.

Uh, let's see. Let's go back over to here. So, so let's look at this here. Um, what does that demo have to do with anything and EDR killers? Well, this is a report um that was just released last month, not even a month ago by ESET Research where they essentially uh and you can go find this and read, you know, it's much it's a pretty lengthy report, but they talk about having found in the wild almost 90 EDR killers. Okay, they're actively being used and they're in the hands of any ransomware gang that's being used. Okay, the techniques that I just demonstrated, those are the types of techniques that these EDR killers are using. Okay, what once used to be

thought of as nation state attacker quality and capability, um those capabilities are now in the common criminals hands. The barrier to entry is getting lower to do sophisticated attacks like this. Um, as a matter of fact, uh, rans the ransomware gangs themselves, EDR killers are now a common part of their toolkit in every operation that they do. Okay. What are EDR killers? They're designed specifically to target your security stack, make it ineffective, even disable it. Uh, sometimes they'll they'll disable it um, uh, and people don't know about it. Other times they don't disable it. They let it look like we just showed that it's still running. Everything's good. It's it's functioning when really it's not functioning any longer the way that

you're expecting it to function. They've altered it. Um so we went through an attack sequence on the right uh uh there. But on the on the left hand side, you can see the uh a sample list and a timeline of these EDR killers. Okay. Back in 2022, there was a number of them that came out and they have continuously grown over 90 now. You know, they continue to uh create new ones. Uh 2026, you can see uh four have already been uh named uh as different ones. And so uh they continue to evolve and use them because they're successful, right? And because they give this level of access specifically to kernel to uh do things

like disabling or inhibiting your security tooling specifically and then that lets them fly uh um more freely undetected. So why why is this happening? Why is it possible for this to be happening? Why when you're spending however much you're spending on your security program, you know, small budget to the largest budgets, is it still successful? It's because of a fundamental flaw we've always had, which is an assumption. And that assumption is all of our security tooling trusts in the operating system and that the kernel is okay by default. It implicitly trusts that. It asks what's happening and it assumes that whatever current that is that response is back to the tool that that is trusted

and that is okay and and and it's good, right? And then the tool uses that to make decisions and and identify things and and whatnot. The the problem becomes uh it's not that we should throw away EDR or detection and monitoring technologies. the the reality is we just need to stop blindly trusting them. And so we need to somehow enhance our ability to be able to trust the system and that it is in a uh proper state and also when it's in a proper state we can have more confidence that our security tooling is actually seeing what it's supposed to be seeing and has not been modified or altered in some way. Uh so this is a

a larger uh view of of how an operating system works. Essentially if you can get into this kernel space below everything else and this is where the attackers love to dwell because they go invisible when they can get there and they persist and they that's why you hear in the news the big headlines of being there for you know months or even years without being detected is because they've gotten down into this space. So, how do you know right now if your security tool has or hasn't been blinded or bypassed? Ultimately, our old way and our historic way is an event-based uh monitoring and detection approach. The all of our tools are built for known bad threats. It's like a

haystack and you're looking, our tools are tearing through that haystack looking for these needles, but the needles are based on previously known bad things happening. Um, the problem with that is they don't know what they don't know. They don't know the unknown. They don't know the new zeroday exploit that allows something to happen because it's never been seen before until they discover it and then they, you know, eventually try to bake in some form of detection technology because they've seen it. But if they don't haven't seen it before, that's where the problem is. So we need to switch to a state-based approach. The state-based approach isn't based on knowing what the bad is. It's you don't even have to have ever seen

bad before. What it is doing is it's verifying that a system is functioning only the way that it was designed and intended to function especially at the kernel level. And so we're looking for um what is good what is the system supposed to be and measuring and m and and uh um ensuring that that system is only the way it's supposed to be especially at the kernel level. So, it's not detection, it's verification that something is what it is supposed to be. And my last uh uh few seconds here, um another analogy is uh our night sky, uh a constellation, the Big Dipper. We know what it looks like. We know where it's located. You can go out and you can

always look and find it and it's the same all the time. Runtime integrity is the same thing but in software. If on the right hand side, if our shape or the location of the Big Dipper was to change, we would immediately know something terribly wrong has happened in our universe. We don't have to know what moved the star in in that. We just need to definitely know that it happened, right? And that's the difference that runtime integrity brings is knowing whether something is what it's supposed to be or has um lost that shape that is expected to be. So in closing, what I'd like to leave with you is we need to stop trusting and

we need to start verifying. We need to know, can we trust our system? Is it doing and is it working the way that it was only designed to work? And by doing so, we can expose when that changes. And when that changes is when the bad things happen. And with that, I conclude and thank you.