Who Defends The Defenders? EDR Killers Landscape Boom - Tomáš Zvara & Radek Jizba

Great. Thank you for introduction. Uh we both me and Tomas are part of the ESET malware research team specializing in ransomware research. Uh right right off the bat the ransomware research is not the subject because like the landscape is huge and we couldn't fit it in like 20 minutes that we were given. So we are trying to focus only on one specific uh tool that the ransomware affiliates use the EDR killers. Uh more so we obviously won't be able to cover everything. So use the appropriate Q&A section or seek us out afterwards. So what the hell are EDR killers? EDR killers are scripts or executables specially designed to disable cyber security products. Um um they are used by a large variety of

thread experts but mainly by ransomware affiliates uh so much so that if the ransomware if the EDR killer is successful the encryptor soon follows. uh this creates obviously a blind spot in telemetry and disables all the protection on the end point. So uh it makes it much harder to analyze anything that happens afterwards. Basically, we don't know what we don't see. And it also disables something that let's call it the anti-ransomware feature that many EDR started implementing where uh they are monitoring for large scale file operations basically changing a lot of files at once and basically stopping the um the process and re-evaluating whether it's harmful or something. But if you have the EDR killer, there is no more

protection. So this is kind of useless. Uh first of all, there are many types of EDR killers. I'll try to be really brief, but if you really want, we recently published a blog post discussing these subjects. So first type of EDR killer that we are going to talk about is the script based. This is your ordinary scripts for administration purposes on the system. uh they use uh stuff like SC delete or task scale and thanks to the um because it's like already found on the system uh it's usually like not that interesting to talk about and it's mainly in hands of less skilled ransomware affiliates. Let's say a subtype of that is something we called a safe mode killer. Uh which

in addition to all the already present administrative commands reboots the PC into a safe mode where only a limited subset of the system uh is present. EDRs are not present there. Obviously uh this approach is really rare, unreliable and kind of noisy because as I said you have to reboot the system. But yeah, in the past we have seen uh at least one of those mainly it was the direwolf dire killer which is the EDR killer used by the dire gang. Uh there's another interesting one which which is the rootkit. Uh thanks to Microsoft enforced driver signing uh rootkits are almost like the thing of the past but uh there was actually one rootkit that surfaced

last year. It was called the abyss worker uh I think discovered by the researchers from elastic and uh they managed to sign the edr killer by a stolen Chinese certificate. So that's it. And tied to the rootkits, there are also anti-root kits. Uh these used to be um kind of securityish uh programs that uh were used to defend against the rootkit u for example or PC hunter. But thanks to the uh really polished design and nice GUIs, they are actually the go-to edr killer uh for many ransomware affiliates. Uh another interesting one is the driverless one. You might ask also like how does a driverless like without kernel site components DR killer work? How can it kill a protected process?

Well, the answer is really simple. It doesn't. uh it just disables the communication between the endpoint and it back end rendering it kind of useless and the last but not least is the uh probably the most important one to be here Frank here is the bring your own vulnerable driver uh this type has like two components one is the EDR killer which is the user space one part and the other one is the uh vulnerable driver the kernel side for the rest of this presentation we are going to focus only on these uh types of killers. So how do they work? Here we have a system where the security solution is running and also we have an EDR. First things first,

EDR killer has to drop and install the vulnerable driver. In our case, the vulnerable driver was already present inside the EDR killer. Uh fun fact is that many of these vulnerable drivers that are already present inside the EDR killer are not obuscated or not hidden in any way. And if they are hidden in some way, it's usually something simple. For example, quite recently we have seen a killer called a we called it a steon killer which hit the vulnerable driver inside the resources inside the icons via the steonography algorithm. When the driver is loaded, uh the EDR killer only sends the IOCDL termination uh request for the driver and the driver because it's running inside the kernel space can

easily destroy any process it was uh like um it was told to. Um in our case, we had a vulnerable driver already inside the uh EDR killer. But this is not always the case. There is another approach where the EDR killer already uh expects the vulnerable driver to be present on the system but the vulnerable driver has to get there somewhere. So usually it's manually installed by the ransomware affiliate or threat actor. So now we know how it kind of works but how can the EDR killer find its targets? First uh that I wanted to show you is the uh number of targets is hardcoded inside the binary. Uh on the right you can see the AU killer uh which targets

the ESET processes. Uh this approach is more like a fire and forget type of deal. Um because like you can simply just run it and yeah hope it does what you think what you hope it will. Uh the issue is when the threat actor wants to kill another process then the um the EDR killer has to be recompiled and redeployed again. So this is the issue or or actually redistributed if we are talking about the malware as a service part. More about that later. Um another approach is when it's passed via the command line. Uh this approach is well not so polished as the previous one. Uh it's prone to let's say simple mistypes. Uh and but like it's more more

versatile. Uh on the right you can see the I think this yeah CC protect killer which is part of the black snuffkin edr killer repository which is actually the proof of concept repository on the edr killers but a lot of red actors take inspiration from them and last but not least is something let's call it a hybrid approach where the edr killer does not know whom to kill but waits for another u let's say file to read and inside that file that there are these targets on the right you can see a small screenshot from IDA where the EDR killer called hex killiller u every 3 seconds tries to look for the logtxt I think uh and if it

finds it basically uh kills all the processes that are in that file if not seat. So now we know how they work and uh also how um who they know how to kill. Uh so who creates them? There are two main approaches. One is the DIYs. So the threat actor usually like creates it from scratch or just modifies some TOC as we shown with the abyss killer or it can be distributed as a killer uh killer as a service basically mer as a service I'll ask now to go through some practical examples about these two types. >> So thank you for the technical perspective. Now let's dive into examples from our telemetry. Uh first case study is going to be about a

war block run gang. We analyzed an intrusion uh where this uh gang deployed 17 different different uh executables with six uh different vulnerable drivers into folder called ESET. uh we observed that uh some of those executables were actually compiled 1 hour before the deployment of those executables. We already know based on attack timeline that the attacker was already in the network. So they compiled the samples on the fly as they were exploring victim's environment. Uh this is a print screen from the directory. The only thing you should take from this that it looks like complete mess. Uh so now now uh let's zoom on those newly uh fresh compiled samples. Uh here what you can see is a PDB that was

extracted from those executables. The PDB uh tells you the path that was used during compulation. So it can tell us something about uh attackers environment. Uh here we can see for example that the that uh all samples come from one project called new_2. uh and uh based on the executable names uh we can see that they are using uh multiple vulnerable drivers because uh those are the names of the drivers. Um so what's going on like they why there is one code exploiting different uh vulnerable drivers. Um so how this uh bring your own vulnerable device exploitation usually works is that those exploits are pretty simple. The driver itself contains a simple uh function that just allows termination of the

processes. So the only thing you have to do is call that function from user space using a device IO interface and submit appropriate arguments. In this case, it's usually a process ID. Uh that means that basically a lot of the functionality of killer can be moved into some template and reused for multiple drivers. Um so only thing you need to change for a different driver you need to change the driver service name that you can see here and then you need to adjust this number which is the identifies the function of the driver and then maybe uh twist bit arguments for the function and and you you are uh good to go. Already mentioned example on

GitHub blacknafkin build vd um shows this approach. So this is what we saw in those samples and those were the common uh the commonalities. Now let's look what was different in those samples. We can see that attacker is trying to modify some print messages in like pretty random way. Uh also what was uh different is uh there were minor code modifications like in this particular case you can see that there is no uh handling of close service handle going wrong whereas in this sample there is a slight modification where reductor prints some uh message and tries to handle the error. Um what this tells us is that the attacker is modifying the samples ad hoc. What we

think that attackers might be trying to do to is to do enough modifications so the samples are not triggered by maybe static rules and then it tries to run them in the victim's environment which is something that we would call a more naive approach. Now let's have a look on the other side of the spectrum. Um we will have a look at uh something that we internally call space killer. Um carpace killer is a more sophisticated more sophisticated EDR killer um that uh performs EDR disabling in uh two steps. It first unhooks the monitoring uh callbacks of security solutions and then uses a custom rootkit to terminate processes. So we already can see that the approach

is a bit more sophisticated. Besides that there are typical anti- reversing protections that are trying to forward the analysis like there is some app hashing. The samples uh uses basically access to physical memory by mapping the whole physical memory into vector and other um more advanced techniques. Um when we look into the telemetry we can see the samples always come packed with with V script. Uh V script is a commercial uh packer as a service that is offered on dark web. Um this packer was before seen with many other malware strains. Uh basically it's a preloader that allows to the payload to load straight into the memory and never touches the disk. Um if you want to

um know more details there is a public uh technical analysis of the bake script chain that ends with carpace killer provided by Cisco Talos uh with uh screenshots from assembly and everything. So it's it's it's nice thorough uh reverse engineering uh analysis. So uh the caspace killer the most recent version uses two drivers. What is interesting here that they just don't simply exploit terminate process but they use driver that allows them to have arbitrary read and write uh kernel uh primitive. to then to first blind the security solutions and later in the second stage they deploy their custom component uh that contains the termination function that is then used to also terminate the processes from our telemetry we can say that u for

this killer we also observed another previous version where uh attacker used uh another driver what is interesting that there's also this arbitrary read and write primitive um to to basically copy this functionality. So now why we think that the driver uh that the killer works uh and is provided as a service. First argument would be that uh the EDR killer itself checks for embedded uh for for the uh victim's locals and uh it uh stops execution if some of those locals are detected. Um the next example would be that there are signs of active development. They change drivers. Uh also there are messages in the code that suggest the developers are not the ones deploying the tool. So there is

like multi- team uh multi-member team. um and intrusion exhibit high variability of TDPs which is obuscated way how to just say there are multiple thread vectors that deploy this tool. Uh so let's sum it up uh what we saw so far. Uh on one side we have do it yourself approach. We see other modifications uh pillows are unprotected. They contain PDBs and debug strings. there is not much innovation and the samples are disposable used once per per intrusion uh killer as a service on the other hand there is a continuous development samples are packed protected um they are trying to uh for the analysis and samples are uh reused in multiple interviews okay so now let's think about how it

fits the ransomware as a service uh space Um we know that uh the one responsible for um running a DRQ and and picking picking it are the affiliates. It's it's their job to uh disable security solution before the cryptor encryptor is run. Uh there is one exception to this case uh which is ransom group that was actually providing killer with their as a service offering. There is a blog post from my colleague sitting colleague sitting there. So if you are interested uh you can read read about it later. Um also uh so we see affiliates appro use both approaches do it yourself and kill it as a service. Um so if we want to uh take those intrusions and maybe

cluster together intrusions where we saw one affiliate we have to think about it a bit differently in each case. For killer as a service it's usually useful to track builds which means just identify the hashes of the sample because uh they need to pay per build. So they usually reuse the same hash in multiple intrusions. In do it yourself case, it's a bit more tricky because the payloads are usually regenerated again. So we have to find more interesting patterns like maybe embedded PDBs that give us information about attackers uh machines and so on. Um so how to protect against uh PDR killers? Um good good solution is basically to blacklist all vulnerable drivers. Unfortunately, those drivers are still

in use by u software because of backward compatibilities. So, it's uh like it's not a default solution for many systems. Uh we also suggest to detect killer's behavior rather than focusing on the static features because as we see the attackers change it. The my last advice would be to use more strict policies than what's uh by default uh provided by Windows. because uh the default option is not the most secure one. Uh you want to hard your kernel more and allow only code that you that you trust. Uh so um to end this talk on a lighter note uh recently last month Microsoft uh basically discontinued the support for these old uh drivers and starting with

the new Windows versions most of the drivers that we see used during this attack should be discontinued. So let's hope for a brighter future. Uh and I think that's it from our side. So thank you for your attention.

>> Uh any questions? >> Yeah, I have a question. Um you mentioned a couple slides back. You mentioned um of one approach uh yeah this one of one approach of um detecting uh killer behavior. What is like the patterns? >> Yeah. So, uh as Radik described the killers perform different actions like they create they for example they can drop these vulnerable drivers. Those drivers can be dropped in location like usually they are dropped in locations like C program data. It's usually not where these drivers are by default installed. So it's something that you should monitor for or you can you can write some behavioral detection as well. Then for example uh communication with with uh with vulnerable drivers. So we

have to have a sele selected subset and then you can maybe monitor if that's what your solution um allows you to do uh creation of those services. So like in installation of those vulnerable drivers is is pretty noisy. But on the other hand, yeah, like you have to basically always update the set of vulnerable drivers that you monitor or either go for more heristic rules and then like try out them. >> Okay. Um I have another question. Um you compared the DIY uh solutions with uh killer as a service. Um, which one of those solutions is more effective in your opinion? >> Um, like I would say this this left one is is pretty uh stupid.

But that's just my personal opinion. I don't like it. Um, I mean it it really depends on the system what you have, what you are running. Sometimes if like you don't have any behavioral protection then of course like do it uh DUI is going to maybe work uh because it can bypass the static rules and is it's good enough but usually like like this is this is of course more sophisticated so I would I would assume that that is also better in in most of the cases but but this is good enough that's the that's the message of the presentation. I have a question. You mentioned u monitoring the EDR killer behavior. How do you monitor it? Can you use actually

EDR to do that? And APS what are the main patterns that um that like uh decides whether uh EDR kills or >> Okay. Yeah. So uh what you can do is to monitor well you need to monitor but to the point where you get killed. So you you you see what's happening on the system before you get killed and before you get killed you have this like create all the services the driver is dropped. So there are actions that you can detect the moment this is called you are dead after that. So, so uh you are not running on the machine and there is no way how you can protect what what you can actually do in that

scenario and what usually uh these uh EDR solutions and ads do is uh I want to get to the yeah so security solution is running in user space driver is running in kernel space but usually security solutions have drivers running in kernel space as well and they restart their services. So then it's kind of like fight back and forth like who who wins. Also these vehicles usually run in sometimes they run in the loop so they like keep killing you. >> Yeah, they keep trying. >> No,

more questions. Okay, then we thank you and if you have something that you don't want to say publicly, just catch us later. And yeah, thank you.