EDR Evasion 101 in a Professional Hacker Red Team

very much.

>> Okay, >> I guess we can start now. Um, hello everyone. My name is Andre Lima. Uh, this is uh EDR evasion uh 111, you know, professional hacker red team. Uh, just a quick slide on myself. Uh I'm a red team lead uh and researcher. Um and yeah, I started working in Portugal. Uh then moved to Australia and now here with family. Um and yeah, if you want to go deeper into uh stuff and what I think about red teams and such, I've been recently a guest at a control panel uh podcast uh with Vernon. Um so yeah, that's the QR code for the podcast. the so yeah uh not going to go deeply into

this because I'm in a bit of a hurry um but yeah we're going to talk about edrs just quickly quick notes on names um edr endpoint detection and response basically tool that's uh the agent that will be running on your computer and doing all the detection part um then you have extended detection and response uh XDR which basically requires usually uh is some sort of cross platform functionality uh Linux their operating systems blah blah and u centralized um um um synchronization and management um and then you have MDR uh which is usually a third party sock team or some sort of sock team that will uh be managing the whole thing for you uh and

providing some sort of more advanced uh analysis on the alerts and all that. Um we are definitely just talking about EDRs. Uh so from the perspective of the red team trying to bypass the whole thing inside a computer to do red team red team stuff. So how does an edr work? Um obviously it depends on the level of soph sophistication of the software itself. But uh most modern ones will, this is an oversimplification, but they will have basically sensors that you can think of as hooks into specific functionalities uh of the operating system. And then the agent will have the static and dynamic analysis capabilities and will uh depending on the triggers that comes from these sensors will deploy uh

analyzing um that specific uh memory region or process whatever. Uh so in a nutshell that's pretty much what you're looking at. Uh also just a quick note on um uh there's not one thing that will get you that will trigger an edr u as in trigger the detection of your payload. Usually uh there are a bunch of stuff that will increase the level of suspiciousness. Um and so it goes from greenish and goes into the red area. uh and it depends on EDR. They will have set the bar at different stages around the orange and red and so we'll trigger then um and this is one of the reasons why techniques such as process migration is

so important because when if you just start your executable uh let's say whatever.exe exe and you uh start doing weird stuff, the fact that you started a not signed application uh um process that will do suspicious things uh will just start piling up to in this graph and will easily get you into the red zone. uh as opposed to you doing process migration, migrating uh your code, your shell code for example, whatever payload, DLL and whatnot uh into another process uh and then starting doing things inside in the context of that process. Um you will have uh if you think about if you're a rootkit uh that if you're simulating a rootkit uh you probably

want to go into something like explorer.exe exe because then accessing the hard drive is pretty normal. Um, and if the EDR is seeing that, oh, XY exe all of a sudden is reaching out to all these files, that's kind of typical behavior that happens uh very often. Um, so the suspicion will be a lot lower. And if you want to reach out to the network, if you do it from explorer.exe, that's suspicious. If you do it from a newly started process, that's suspicious. But if you do it from MS Edge, from Firefox, from Chrome, then that tends to be a lot more normal behavior. So yeah, the it's gradual. It's not one definitive thing that will

get you picked up. So just to go into the components um uh sensors if you will um of the EDR, you have the minifilter driver. This is basically not to go into technical detail because it gets very complicated but uh windows have the structure that the requests for file systems in terms of reading files um accessing, writing uh whatever executing um all go through this uh process um where uh the mini filters will be in the middle and we'll be able to um as call back functions kind of execute code and process whatever. Um, a typical example is uh the Bit Locker uh mini filter which will encrypt everything and decrypt everything decrypt every encrypt

everything that goes down and is written onto the hard drive and when you trying to access that data and it comes back up it decrypts it in the middle. So that's a typical mini filter. Um and of course EDRs will have that and they will detect it. uh they have to keep it above obviously Bit Locker because you don't want to analyze the data after it's been um uh encrypted but uh you will have the the the uh the EDR mini filter above it and it will analyze the payload to see what uh what is this file that has just been written uh or put into the uh file system. So that's uh mini filters. Then

you have kernel mode driver which will add a lot more information in terms of kernel um um into the EDR part. Uh there are callbacks in the kernel that you can have that you can set up programmatically where you will um as soon as a new process comes up uh or whatever and that information will be conveyed to the EDR and it will tell the EDR hey this is a new process that just started and these are the parameters go analyze it and do whatever you want um and figure out if it's a good thing or a bad thing and that's how the EDRs will typically know magically that a new process has started uh is through these

um uh kernel mode driver uh callbacks. So yeah, then you have obviously network filter which um as the name says will analyze stuff going in and out the network which is very useful cuz even sometimes even when you're successful at bypassing the EDR locally uh through the mini filter and the kernel mode driver if you're reaching out I don't know uh metas-loits on your network and it's using a default um certificate um then that type of stuff will be usually detected ed by the network filter and it will say okay so this gu is doing something with manasloit we definitely don't want that so let's uh check on what's is this process that's starting this

communication and all that and you have the elam driver that's the early launch anti-malware um this is more related to rootkits uh boot kits sorry um but yeah it's a bit out of scope of u edr evasion 101 it's a bit more advanced but yeah just so you and also ETW um that's the event tracing for Windows um and yeah that's a lot of logging um information that goes into uh processing all the information so for EDRs now approaches to evasion um you you can think of it as if you think about the agent uh with a bunch of sensors throughout the whole system you can think of it as trying to disable one or multiple sensors so then you can act

on whatever. Uh if you are able, for example, to disable the the sensor that detects that a new process uh has started, you can then start as many processes as you want and it probably will not trigger an analysis of DDR onto that payload. Um of course you can do that with mini filters, whatever. Um but also you can think about disabling the agent responsible for the scanning. So even if a sensor is triggered but it sends the information back to the EDR but EDR is not running for whatever reason then uh you're good to go. I'm actually going to show you um uh something uh like that. Um or you can just simply not care u because you are

invested in techniques that will bypass the sensors and uh just avoid detection altogether. I'm kind of going to have a walk through through that whole process with that. Just full disclaimer, uh this is not the full encyclopedia on EDR evasion. Uh it doesn't mean that just because I'm showing you something, it doesn't mean it's the best solution. It's just a solution. And I'm going to most importantly uh explain the logic behind it and not so much this is how the Bible says it should be kind of stuff. This is not at all that uh but just so you can understand the logic and feel free to ask questions at any point in time. Um so yeah first things first uh figure

out what um in which area uh are you developing uh the payload for um this might seem like you have a lot of freedom but sometimes what most of the times especially in the industry what you try to emulate is mostly what the attackers are trying to do. So obviously most people will use Windows um so Windows will be the most where you find more viruses and all that. Uh so typically you will have to have some sort of skill set in developing malware in Windows. Um Linux is also a thing that can be a specialization. Uh there's definitely very few people doing for example stuff like root kits in Linux. Um and uh yeah then you have to figure

out the assembly as well. Uh 64 is usually the most common one but ARM obviously is becoming a thing. um and yeah, the language that you want to deploy in it. Uh C.NET tends to be a bit less sus and uh in terms of like um uh how likely it is to be a malware because it m mixes up a lot better with the whole environment. Uh but you can do stuff with C as well. That's just fine. Especially if you're doing process migration, injecting yourself into other processes, like who cares? Uh Rust is the new thing. Um there not big advantages I think uh happy to be convinced otherwise but uh of developing stuff in Rust um because

if people are uh doing hashes on payloads just blindly then uh yeah that's the better worst way to go about it. Uh I I do a lot of Rust. Uh I'm a huge fan of Rust, but for other reasons, high performance, fuzzing, blah blah, uh other research areas, but in terms of developing malware, it's not exactly big big big advantage there. Um but definitely something you should learn. Uh most specifically, there's a lot of malware that is going to start being developed on that and you need to understand it blah blah advantages and all that. So yeah, huge fan of Rust. um also understand that uh there's uh the what I like to call the dynamics of

specialization because most of you I would assume are students um you you need to understand that the simple dynamics of if I decide if I know nothing and I decide to become a Windows specialist it will probably take me rough numbers two three four five years uh in order for me to know more than the majority of people in this room. If I decide to go do something very niche such as hardware hacking in probably one week I will know more than uh most people in this room. So it depends on the area and that's where people will often come to me and say so should I learn like x64 or ARM? I'm like learn both. What are you talking about?

Uh if you oh but R is complicated go figure it out. that's just time and you will uh be really good at it. Uh it's always an advantage and just go for these things. Um I draw the line. There is a realistic approach to it. I draw the line and I started um many years ago started writing rootkits in Linux and I was like fascinated by by the cap capabilities that I had and all that. Um but then I was like wait like do I want to spend a lot of time on this or just jump into Windows and become really good with Windows and then I started developing root kits and Windows and all that. And

at this point, human brain like in the consulting world, they sell people as experts and they pretend that that's something that you can just I learned something and then you can package that, put it in a freezer and at any point in time you can just pop it out and you're magically the expert. In truth, if you're actually an expert at anything, you know that doesn't work exactly that way. I will dig deep into I don't know ARM or something and if I don't touch it for six months, I will know nothing about it. um at at some point. Um so yeah uh just understand that uh the dynamics of specialization but yeah just a quick tip now uh quick uh note as well

that I'm going to go very quickly um to attack surface recon. It's a bunch of commands. Basically, you have to do this in order to try to map out what are the processes that are running um uh that belong to the whatever EDR that you're testing um that you're trying to bypass. Um by the way, I'm in my labs. I'm basically going to use Defender. Uh this is not to say it's better or worse. I'm not making that comparison. I a scientist at the end of the day, so I would have to be very thorough. So I don't like to be unfair here. Um but uh yeah, so I'm targeting Defender, but you kind of have to do this work uh in

whatever EDR you're targeting uh in. But uh yeah, just trying to figure out what processes, what services, what files, what drivers does it map to in the hard drive and all that stuff. That's uh um a whole recon process that can go very very deep. So yeah, uh F uh TMC that's for minifilters and you can see the uh WD filter is up there with a higher altitude because I believe the Bit Locker one is the file crypt below. Uh so it makes sense to be at a higher altitude so it analyzes the data before uh it goes into the encryption part. But um yeah, just getting information about the mini filter, getting information about

processes, blah blah, all this stuff. And then I get the information about the specific version that is running. And you might ask, but do I care about the version? I just want to bypass the thing. Like who cares? But the thing is if you know the version you can go into C program data Microsoft Windows Defender platform and the version will be the folder name and you can get the exact versions of the the EDR engine and the execs blah blah whatever it uses. And this is super important because this uh there are levels to this analysis this recon. You can do a very basic recon such as I just showed you with a simple commands or you can actually try

to reverse engineer the whole um payloads from the EDR and try to see exactly what they're doing. The deeper you go and the more things you'll find blah blah all this stuff and you often find bugs in these. So yeah, now let's start with bypassing static analysis. Um this comes down to avoiding being detected by uh Yara type of rules. um where you kind of know what to expect um in terms of detection engineering um and then you try to obiscate the code uh to bypass it. Quite frankly, this is the easiest one. um you just write some C C# whatever you want uh code and uh you can even have interpreter type of payloads

in there that are spit out by MSF Venom for example or whatever C2 you want and if you just let it like that it will be detected but uh immediately as soon as it touches the hard drive uh but if you just do a basic offiscation uh you won't um also just a quick note uh understand as well what is your goal because a lot of times you try to complicate things because you learn it a specific way. Oh yeah that it's interpreter that I have to use or whatever metas-ploit and then you try to spit it uh to use it and instead like interpreter has a ton of functionality and the price you're paying is that that

will most likely be detected at some point. So the question is if you're just doing a red team and the goal is just to steal I don't know a flag because you agreed to that with the client to prove that you could access like a specific server uh or just access a file or somebody you know exactly what you're doing. You can write very small shell code that will address exactly that and will bypass everything because if you write your own shell code you won't be detected. Uh so yeah just uh to highlight the goal part. Uh um now payload one that I developed uh that I wrote was uh is known uh shell code and

no static analysis protection. Uh going to start going a bit faster otherwise I won't be able to finish but uh yeah that's uh very basic code. You'll see the shell code is in the buff uh array uh and I do very basic process uh migration there. And yeah, the code is being generated with the MSF venom. That's the shell code. And lo and behold, if you just do that, you will get you will trigger the EDR every day of the week. So, uh now on the payload 2, uh there is known shell code still, but uh the stat there's static analysis protection and dynamic analysis protection. And on this one uh the dynamic analysis protect uh

the start the static uh analysis protection is basically a very simple zor key encryption and uh a lot of people just one second. Um so yeah that's the the code that will you have the payload above and that's the code that decrypts the thing before actually running it. And people try usually tend to assume that oh but uh this is very basic Andre like anyone will be able to analyze this. The thing is you have to distinguish between two types of detection. One is automatic detection which you definitely are are actually trying to avoid and the other one is will a really good u malware analyst figure out what I'm doing. A really good malware analyst will always

figure out what you're doing. They figured out what stuckset was doing. They will always figure it out. But the realistic time frame for that to happen is it has to go through a bunch of automat automatic tools that will then say, "Okay, we can't figure out what this is doing." So it put it on the pipeline for someone who has a life, who has a job, and is stuck in traffic and is stressed with life. then goes in there and lo and behold, one month, two months goes by and then okay, yeah, this does something and I've used my really good skills and then it flags it uh onto something. Uh and then you might be

detected months later after you've developed the payload. So there's a realistic thing uh and this uh you might think, oh, but this is actually really basic like are you sure like automatic tools are not detecting this? Well, you can always over complicate it a little bit, but people tend to come up with these, oh, we we should lose use like AES or some really military grade encryption. Um, that some really advanced stuff and it's usually more mostly people trying to show off how smart they are by over complicating things. Uh, and I hate that. But, um, to I'm very scientific based. I don't do more than I have to. uh and I need to understand like if I see an EDR

detecting something then I know it's detecting it then I need to push forward but I won't do that and just waste my time because if you do that you can infinitely just spend time on everywhere and this is admission from Microsoft uh I have the link below where they um uh yeah themselves are saying uh at this point we're generally past uh this is a basic zor encryption uh just for context uh this is an MZ why you should use Hamzy blog from Microsoft and they um uh they're basically showing you how to encode the script more and more to the point that they get to the most advanced one version which is the zor uh one bite

zor encryption uh which is exactly what I'm doing in my mower uh payload and they go they then go uh at this point we're generally past what antiviruses uh antivirus engines will emulate or detect. So we won't necessarily detect what what this script is doing. That is admission because and if you think about it, it makes perfect sense. It's not like it's already a tremendous amount of work for an EDR to just go through every single uh memory page uh on the operating system or the suspicious ones at least new ones and so on and analyze all those bits and al together. If you think they're doing that and they're uh um encoding that with all the possible

256 keys in one bite uh for one zor to see all the variations of it. Not a chance. That's not realistic. That is not happening. So again don't over complicate. Um you can make a bit more complex version of this but you don't need to. Now to talk about the um bypass bypassing dynamic analysis uh there's a whole bunch of techniques. I'm not going to go into each of them. Uh but I wanted to highlight um there is one that is uh where the image is very small. I'm going to zoom in it in soon but uh it's reach out to non-existing URL. The whole point is that uh once you double click on an

executor or you started the process, it will basically um it will um start a sandbox uh edr will have a sandbox that will run the thing for a couple of seconds, a few seconds, depends on edr and it will look at all the the Windows API functions that it's calling and try to figure out if it's doing something suspicious. Very basic trick that I use. For example, back in the day, people would use a lot of sleep just to delay that process and after like if you use a sleep of 3 seconds and the sandbox uh has is only running for 2 seconds, it's not going to detect uh before you start doing bad stuff, it's not going to

detect it. So what people do is they start uh what EDR started doing is they just emulate the sleep and there's no sleep inside the um the sandbox. So it just starts, jumps to sleep and executes right away. So what you do as a malware writer is you set up a time uh time stamp before you get the the time and uh date uh before and you run a sleep uh of 2 seconds for example and then you get the time uh right after and then you compare those two times that you caught u u before and after and if it's roughly in the range of 2 seconds you know that the sleep was actually executed uh

properly not inside a sandbox and if you notice that it's a lot lower than the 2 seconds then you know something fishy is going on someone is hooking something. So that is how you detect uh that's a one way one of a million ways to detect that you're running inside a sandbox. Uh another interesting way is the sandbox will emulate uh behavior and it cannot implement the whole operating system obviously inside the sandbox. So it will do fake stuff like if you ask for uh www.banana1824.com banana 1824.com it will that probably doesn't exist definitely but it will say yeah it does exist it went well and you will keep running so by doing that that randomly

generated URL you will and if it says it does exist when you know it doesn't exist you will know that something fish is going on that you're probably being inside a sandbox so you don't execute you just do an exit or return zero or whatever now I just wanted to highlight something interesting which is in W cry. A lot of people uh assume that um there is um uh a fa failsafe um uh feature into it. Let me show you that. Show that.

Okay.

>> Um, yeah. Let me just quickly uh http I think it's here. No, let's go to the cross reference. Yeah, there you go. So if you look at this piece of code, it establishes a URL which is a randomly generated one and the um it comes here and it checks if it did work and if it did work which it shouldn't uh it will just stop execution because it assumes that it's inside a sandbox. Now the thing is people looked at this and people assumed that it's a fail safe like it's a responsible party that decided to do this so that and the person who detected this uh first analyzed this malware uh malware tech I

want to say I forgot his name a British guy um but uh he um uh just registered this and made it exist so that when it actually ran uh it stopped basically stopped this whole um uh ransomware from running but people automatically assume that you did this because you're a responsible actor. So therefore they assume that oh you're the United States of Americas of the world. Okay. But um the the whole point is that this is typical uh sandbox u uh bypass uh behavior. And so my point is you don't know uh maybe it's just an irresponsible one but they were doing their sandbox evasion.

So definitely going to speed this up. But most importantly, as soon as you know anything specific about the the the your targets in your machine, uh then you are it's basically game over. Uh if you know the host name, if you know the domain you're supposed to run in, uh um any type of specific information, you're good. So yeah, that's the sleep trick that I was showing you. Um and yeah when I run it I just um have there the process ID so that I could then oh so one thing uh I was expecting defender to detect this and it didn't the because I was expecting that it would do some sort of memory scanning and because it's a

known uh shell code it would detect it now it didn't uh which was a surprise so I kind of find like another tool which is a piece received from uh Hasher Razette um on GitHub. She's amazing. Does amazing tools and um I use the tool and lo and behold total suspicious is one. So you can see that it does detect the thing. >> We're now over time skip to the last slide. >> Okay. Um so yeah, just putting it all together. uh custom shell code uh which luckily Trim is going to present uh uh after so you jump into more details about this uh yeah I won't show you the demo but um yeah I'm using keystone

engine here just in Python to uh emulate it and it spits out the the shell code and when I try to use that instead then you see that there is no uh suspicious code anymore and uh yeah just uh also highlighting the fact that because I wrote my own shell code, there's this hash uh algorithm that you can write that everyone in the world that writes shell code usually just copy paste stuff and especially if you'll notice this if you use AI, it will give you that algorithm and the the algorithm is basically to find out strings like um API functions like create process A for example. uh but the thing is you don't want to have that the name of the

function to go and check on the DLL to find it and then call it. So what you do is you compact that into a hashing algorithm. So you have just four bytes and you then calculate for each string that you find the hash and you compare those hash and if the hashes match it means you're and the right API that you want to call. Now everyone in the world use what is called a rotate write 13 algorithm for whatever reason someone decided and everyone else copy paste for it. Um, now because I was converting my old shell codes from 32-bit to 64-bit, I just looked at that and I out of the blue I just decided, let me make this

fun and just write my own algorithm which has which I made up. The advantage is um, every malware analyst in the world knows that they can grab one of those hashes that they find in shell codes and they can Google them and they will find oh that's great process, oh that's close handle, oh that's and they will know what the shell code is doing. as opposed to mine where uh you check for the hash and you will find nothing. So there is zero clue. So that's a big advantage in developing your own shell code. And um yeah, I won't have time uh for this. Uh yeah, I wanted to demo basically uh um there's a legitimate

driver from uh uh an EDR called AVAST uh a few years ago that f was found a vulnerability in that you can install it and it has the functionality of a rootkit killer. So it will kill any process that you send a process ID to. I was going to show you how to do the reverse engineering binary ninja but whatever. Uh could show you guys if you're interested just ping me later. But um yeah, you can then figure out how to contact this uh driver and tell it to kill other processes and I can kill uh stuff like defender itself, MS MP engine. But yeah, that's a demo for another day. So yeah, I don't go into a lot of

details in rootkits because you can uh go to YouTube and you'll find a few u previous presentations of mine uh on other B sites also in Lisbon and also the professional side of it as basically proper documentation. Uh if you don't documentation that just means you're not experienced uh because no matter how smart you are, no matter how good memory you think you are, you're not memorizing this whole thing. You have to have proper documentation system uh in order to go through it. And the automation part I'm not going to go into because there was a presentation as well. So besides Oslo uh so yeah just a quick tip I'm going to make this simple. Um uh yeah master

reverse engineering skill set that is the basic language of it. I noticed that today I can understand very uh advanced concepts whatever is thrown to at me because I understand my I have really solid background in reverse engineering. I have done courses on rootkit and the instructor was doing what I deemed as some sort of dark magic that I could not understand on wind debugger blah blah and lo and behold it wasn't that I wasn't smart enough it's just I didn't have the gripe background so I went back and I studied reverse engineering to the point where I went back to the program again to material I was like oh that's what he meant. So again the biggest tip

here definitely uh ADR um reverse engineering uh yeah just wanted to show you a few really good books if you're starting definitely the ID pro uh the Windows kernel programming is also amazing for you to write kernel drivers on Windows uh practical reverse engineering is also amazing for you to learn to analyze rootkits and such u yeah just read them if you can uh yeah some YouTube stuff that's hasharat um the author from the tool that I use PC OA Labs is the best reverse engineering uh channel on YouTube by far. Um the other ones are fun. Anush Sony has a bunch of stuff on binary ninja which I'm a fan of. We can talk about it later if you want. And

yeah, thank you very much. You can reach out to me on LinkedIn. Uh the QR code and uh if I see you on secrets festival, I'll be presenting there. Uh malware detection with hypervisor one. Um yeah the type of hyper. So thank you Andre. Good.