Inside the Mind of the Attacker: EDR Blind Spots and Exploits - Marvin Ngoma

It's loud. Great. All right. Good afternoon, everyone. >> Good afternoon. >> I I live in Sweden and the Nordic people are not very conversational. Um, so I was told the Dutch are a little bit more open, so please show it to me. Good afternoon. >> Afternoon. Perfect. Say hi to the person next to you. Just check if they're okay. I know it's a little bit weird, but I like to keep stuff interactive. just check on the person even if you don't know them just you're having a good time just check with them you know just make sure everyone is good I know it's after lunch sessions so it tends to be a little bit you know um there's a food

coma that kicks in as well right um all right welcome to my talk my talk is uh entitled catch me if you can how attackers outsmart edr2s how many of us work with endpoint security all right you know what I know there's going to be a lot of questions today it's almost the entire the entire room right Okay. Um, so we do know that EDR2s have evolved. They've just developed. They're doing amazing stuff in our environments and they've become a big target by attackers or for attackers, right? So um that's going to be a little bit of my focus um of of my talk today. Basically, what are attackers doing to evade those EDR2s? A little bit about myself. Uh my my name

is Amavvin GMA. I work for Elastic. Uh I'm a principal security specialist. I'm part of the global security specialist team. I'm passionate about security operations and intelligence. I've been with Elastic for about four and a half years now. Previously with IBM in the Nordics again where I did security intelligence and operations consulting. So I just love everything around intelligence and operations and basically helping organizations develop their security operations capabilities. Um I know cyber security people are very obsessed with tech but I also have hobbies. I love to travel. I love seafood. I'm a Manchester United fan. Don't laugh. Um I play bass guitar as well and I like to explore new hobbies as well. If anyone wants to connect on

LinkedIn, those are my details um in that sense. So what agenda do I have for you today? So I'll look at basically how EDR2s work. We know that they're there to stop malware from running in our environments, but we'll just take a few steps uh back and just go a little bit into the internals of how edr basically works. And then we'll go into the gist of the talk. How do attackers basically try to event the capabilities of EDR? I'll try to touch on some real uh case studies, time allowing, and then I'll close it off by just giving some practical guidelines on how you can basically do defenses. Who recognizes this wave? This is from

math and physics and sciences. What wave is this? >> Is it s or cosine? >> Is it s or cosine? Now I see who was paying attention in math class. It's a cosign. It starts half phase, right? Yeah. So it's a cosign. It's got nothing to do with my talk except for the fact that you might find this content to be very technical some of you and you might find this content to be very light for some of you that work with EDR2s. I usually get mixed feedback about this talk. Some people go like, "Oh, it was too technical." Some people go like, "Oh my god, we're expecting a little bit more." you know so it's going to be like that some parts

are going to be very technical some parts are going to be light okay the reality today is there's so many abbreviations acronyms and names within the endpoint security space right so historically we've called these tools AV antivirus if you talk to certain vendors they'll call these next generation antivirus some people call them endpoint protection platforms at elastic we call this edr so basically endpoint detection and response um some other vendor friends of ours came up with a new tag called XDR and this sometimes gets a bit confusing but let's be honest at the end of the day all we're trying to do is find malware in our environments right so that's what I think about all these names in the

industry today um my focus is going to be on ed because I think we should just call it edr from that perspective okay so in a nutshell we've we've we've grown so accustomed to antivirus us right so antivirus has gone through a lot of innovation if we can call it that and that's been driven by what we're seeing in the endpoint security space from a threat point of view right so ransomware has been on the rise we've seen botn nets we've seen polymorphic malware and different malware family types as well right so it drove AV2s to go beyond signature detections right we needed to get to a place where we can also identify zero day kind of stuff so we introduce

huristics and behavior analytics on the endpoint uh we introduced machine learning endpoint ccentric machine learning kind of capability and then some edr vendors or antivirus vendors also have what we call heats and hips so host uh based intrusion detection systems and host based uh intrusion prevention systems as well as well as firewalls but then those of you that work in the endpoint security space you were like nah this is not enough right we need a little bit more so we're looking for anti-malware and exploit prevention capabilities, right? Um, and then also we're looking for telemetry because we want that context. It's great to get an alert that malware fired, but we want a little bit more context in terms of what

is the telemetry that is surrounding a very malicious um activity. So, this is my conclusion of what EDR is supposed to be. Your EDR2 is supposed to give you antimalware capability, telemetry collection capability, and then ultimately from an in incident response point of view, you want to do that response action. So let's look at the components that make up an EDR. There's primarily three components. The first one is the agent itself, the piece of software that you install on the endpoint. So basically, the agent controls and consumes data from multiple sensors. A sensor is something that is basically just sensing the stuff that's going on and then it's picking up hints on what's really going on on the

endpoint itself. The agent is also responsible for things such as alerting. So it's got detection capability or prevention capability, blocking and deception capability as well, right? Um then we talk about sensors. So sensors are just basically there to observe activity that is happening on the endpoint. So I hope you're beginning to get the gist of it, right? So the agent is what we install on the endpoint. There's a sensor component as part of the agent as well. It's sensing activity. It's a super fast processor. And then the agent has got inbuilt logic that is using that activity to see what is malicious and non-malicious in that sense. And then ultimately we get the telemetry itself. So this is the raw

data produced by a sensor or the actual endpoint itself. When you log in there's an activity that goes on. It's an activity, right? So there's a sensor that's tracking that as well. When new processes are coming on the endpoint, that's telemetry and the sensor is sensing that activity. When you create a new weight file on the endpoint, that is also an activity and the sensor is sensing all these things and then reporting it to the agent itself. Key to the telemetry is there has to be completeness in the data that we're collecting on the endpoints themselves. What do we mean by completeness? If we're tracking file activities, you want to track the entire life cycle, right?

from file creation to all the file changes that happen to a file. Ultimately, when the file is deleted, you want to be tracking that completeness of the data as well. So, we're talking file activities, it could be a process, it could be a network communication, but it has to be telemetry that is complete in terms of the story that it's telling you. So, this is where now we begin to go a little bit into the weeds. I hope I don't lose people here. Some people are already familiar with this type of architecture. But basically this is the basic composition of an EDR agent. Right? So if I start on the left hand side, you have what we call a statics a static

scanner, right? So this is basically scanning the binary files. So the services that are running on if we're talking from a Windows perspective. Um by the way, this talk is going to focus on Windows, but there's equivalent implementations on other operating systems as well. But we do know that Windows is one of the most common operating systems um in the world. So I'll stick to Windows in that sense. So you've got the static scanner, right? So there's portable executables on our endpoints that execute and you just basically want to do scanning of those PE files. And then when we come in the middle, there's what's called a kennel mode driver. So we do know that on the

endpoint, there's a user space, there's a kennel space as well. And most EDR2s also reside in the kernel in the form of a kernel driver. Some people love that, some people don't love that. It's a big debate currently whether we should be doing it um in that way. I'm a huge fan of having edrs as part of the kennel drivers. Reason being they give you raw telemetry. They give you that visibility you wouldn't really get in the user space as well. So we're getting a lot of telemetry registry activity, memory activity as well. And then we're sending that into the agent agent service itself. And then you've got a hook DL and I'll expand on what that is, but

there's a whole lot of telemetry that we're collecting. Some EDR vendors extend this basic EDR architecture. So they give you the static scanners, but they'll also give you what we call a file engine. It's just going to be monitoring file activity on the file system. And then there's also filtering that happens in in the in the context of the memory itself. Right? So everything that is running in memory, the processes, the threads and associated memory information that is also being tracked as well. Some EDR2s also give you a network engine. So every network activity that is going on on the endpoint is going to be tracked from that perspective. And then finally some EDR2s also extend this with emulators or

sandboxes. So if the EDR2 is not so sure whether a certain process is malicious or not, it will execute it in a little sandbox, do the malware analysis and then make a decision whether to allow that to continue or not. So again, different vendors give you different flavors in terms of capabilities. So far so good. You look so serious. You're scaring me. Or it's either you're paying so much attention. We'll find out at the end. Okay, so we talked about hooking DLS, right? So this is a a nice scenario of what really happens on the endpoint. There's something that is going on in the user space. And maybe I should have shown a much simpler example, but also

this is simple for those of you that work with these tools. Let's take a simple example where you want to create a word a word document on your on your laptop, right? You're creating a file. Now a file needs to be mapped to the file system as well. So you're doing that in the user space, but for you to create a file, you need permission from the kernel, right? So you still need to make a call to the kennel say hey I'm creating a a word document. So it's userland making some calls system calls into the kennel space and what most edr2s will do or av2s is basically they'll do a man in the middle and

basically do a hook. So whatever parameters you're sending into the kernel, whatever functions you're calling and the parameters that you're sending, they'll do a hook and then also monitor for the responses that come from the kernel. And if there's malicious intent, basically this is where they'll stop it. So we talked about telemetry collection. Um I work for elastic. I'm not here to market elastic, but we also collect quite a lot of telemetry on our edr2. There's a nice project on GitHub. It's called edr telemetry project. How many are familiar with it? Okay, about half the half the audience. That's really good. So, if you're wondering, hey, um the edr tools that we have on the market, what kind of

telemetry do they present you with? You can check out that uh project on GitHub. But yeah, different vendors give you different levels of visibility. And this telemetry also has an impact in terms of the anti-malware capabilities that the ADR gives you. So, we've looked at the basic composition of an agent. We've looked at the functionality of an EDR agent, right? Um but we we also see that for a long time attackers have also been coming for these tools, right? Um and basically they adapt faster than we do. So it's amazing we're innovating machine learning, you know, endpointcentric machine learning huristics and all these juicy things, but attackers are always trying to find ways on how to evade the

EDR and it's become a powerful tool as well and they know it right. So now the focus is not to attack you only but to disable the functionality of the EDR itself. So the way I look at EDR evasion I like to classify it in two categories. The first one it's the old way of doing it. I think most vendors are now u akin to these techniques. Um I think most vendors can pick up on this. The first one is on disk evasion. So mware is just basically software right? It's code that runs on our endpoints. it needs to find its way on our endpoints. Right? So in the past, evaders used packers. So this

is where they really compressed the file in such a way that it makes it hard to do analysis on that file and determine whether it's malicious or not. Then they went into the whole obiscation space as well. Basically trying to hide the code that is running within the malware files. And then they use cryptors as well. But today most of the EDR2s are able to um identify on disk evasion. The next one is in memory of fless evasion. What does this mean? So basically attackers know that the services that we're running on our endpoints that we trust especially on Windows as well. There's so many DOL files we trust. There's so many services behind some of

these DLs and they're going for those things that ideally we tag as normal traffic or as normal executions on the endpoints. And mostly they're doing this in memory, right? So going directly in memory without leaving trace on disk as well. A more modern lens to look at EDR evasion basically looks at three aspects, right? So we're looking at blinding, we're looking at blocking and we're looking at hiding. What does this mean? So the attackers will first aim to do blinding, right? Um so with blinding they're looking to stop or temper with the sensors. So activity isn't observed. So if you remember what we defined an EDR to be, one of the components was the sensor. It's sensing activity that is

going on on the endpoint. And then the agent has got that logic based on the telemetry is collecting from the sensor to make a call, right? Are these activities malicious or are they nonmalicious in that sense? But then if the sensor is not creating the telemetry, the prevention capability of the EDR is not going to work. So one of the things they try to do is to do the blinding. So the EDR agent does not really observe the data. The other aspect is blocking right. So yes telemetry is being generated but then that telemetry is not uh basically reaching the analysis pipeline. And again it's dependent on where your EDR your EDR logic resides from an

anti-malware perspective as well. And ultimately there's hiding as well. Hiding is where again they those services and the stuff that we trust on our endpoints is used for blending in right so the attackers still execute their shell code but they just blend in with those things that um we accustomed to on our endpoints so far so good I hope okay you all look too serious I'm the only one smiling okay another way to look at edr evasion is attackers also look that hey how does the configuration of your EDR operate right what are the settings and they and then is there loopholes that can be exploited in the configuration of the EDR um we've we've heard of agent

tempering attackers come in they just look at how basically you deploy your EDR and then they take certain steps to basically go for that configuration and then there's also perceptual right um you alter what the telemetry and the sensors are actually seeing right it could be some poison reasoning of the telemetry um or it just could be um basically changing the that perception and then there's a logical aspect. Um so if we trace this back to the D hooking so you look at the user space and the kennel space we said most EDR tools would do a hooking and then intercept the communication and look out for malicious activities right so there could be a logical evasion where the

attackers run things in the user space and then they just bypass the hooking right so that's one way of doing um a logical aspect the last one is classification so we said the agent is the one that's got anti-malware capabilities. It's the one that makes the call. Is something malicious or not? Now, if the attacker can be so smart to evade your detection logic, then they find the leeway in because again, they're blending in and they're intercepting some of those configurations. So, let's look at the evaders toolkit. What are the different ways that attackers are doing evasion today? So, the first one is user mode hook evasion. We'll touch on that in a bit. And then

there's ETW and AMSY tempering, right? So ETW on Windows is event tracing with Windows. I hope people are familiar with that. And Amy is just basically the anti-malware scanning interface. So Microsoft on the Windows operating system because they know there's a lot of EDR vendors out there. They've actually made it super easy for you to bring your EDR as a vendor and then make it work on Windows as well. One of the interfaces they give you is the anti-malware scanning interface. So attackers basically try to temper with that interface and like we've already established they try to do memory like memory only executions and then there's low bin abuse as well. So leaving off the land binaries and then ultimately

and this we've seen become very common in the recent months in this part of the world they do can driver misuse. So bring your own vulnerable driver in that sense and we'll touch a little bit on that. So far so good easy to follow. Okay. All right. So the first one we saw um hooked DOLs and how they operate on the edrs, right? So basically again I'm just creating a Google doc file. I want it to be registered on the file system. My EDR will do the hooking. It will intercept the calls and see if I'm trying to do something malicious, if I've attached malicious macros in that document or not and things like that, right? So that's

where it happens. So the EDR observes API calls but ultimately attackers will bypass the hooks by doing direct operating system calls right. So instead of their shell code or the payload going through this hooking basically they implement techniques where they actually do a bypass or they do um a clean API restoration. So they do something malicious and then quickly clean it up um before the EDR actually picks on it. So this reduces or removes that user level visibility and ultimately they do bypass that hooking DOL. A lot of EDR vendors have moved away from hook DS and they're using um different implementations for um their EDRs. The next tool kit that we talked about is event tracing with Windows and

AMZ tempering. Right. So um with this technique basically so how many are familiar with ETW event tracing for Windows? Okay so this is great right so we've already established that the agent has got a sensor which senses activity in addition to sensing um telemetry on the endpoint most EDR vendors also depend on Windows itself and the events that the operating system creates for you. So, Windows provides you with so many channels uh for different types of data, different type of activity that is being done on the operating system itself. And most EDR vendors will consume that telemetry as part of the logic for the anti-malware as well. Right? And then these the anti-malware scanning interface basically inspect

script content. Right? So, we do know that a lot of malware is in the form of scripts as well. before they execute you can actually intercept them at kennel level in the army as well and we see that attackers try to disable or patch these components right so either they'll patch the ETW ideally it stops creating this telemetry that means you're not really getting the telemetry that you need for um your anti-malware capabilities as well so this leads to significant loss of script and event telemetry so you can't really see what the scripts are doing on your endpoints you can't really see um any telemetry coming from the operating system itself. This is um there's a nice article and I

do link to it as well. This was early in February of 2025. There was certain attacks. So this is a remote access trojan that was targeting European organizations and they basically used new techniques for army and ETW evasion as well. I would recommend it for reading for further reading. I don't want to go into the details of some of these techniques because again it might get too technical. So I'll just leave it at a high level but this is quite quite a very good read in terms of basically what attackers are doing in that ETW and tempering space. The next one is memory only execution. So remember what I said there's two categories. Attackers can

write files to disk and then u go on to try to um achieve the objective or they can actually go straight into memory. So there's certain things that are executing in memory and they try to find themselves um executing in the context of those processes and ideally those are processes that we've come to trust. So we do know that code runs entirely from memory with no on disk artifacts and then some of the techniques that attackers are are using or employing is reflective loading injection and process hollowing. I would not go through all three but I'll just touch on two of them. The first one is the PE injection right the portable executable theexe files that we have on Windows. So how do

attackers come for those executables that we've come to trust right? So the malware can copy itself or it's malicious code the shell code into an existing open process and cause it to execute. Right? So basically there's four steps. So there's a process that we trust. It's executing in memory. The first thing that I'll do is open that target process. The certain cause on the operating system um that Windows supports, open process is one of them. The second step that the attacker takes is to allocate a chunk of memory in the context of the executing process and then ultimately the attacker writes their payload into that memory space. So if you're doing process monitoring, all you're seeing is hey there's this

executable that it's executing. It's something I'm familiar with. We're all good. But in the context of the actual code it's executing the attacker actually has managed to um infuse their shell code. Does this make sense? Okay. Basic stuff for some people. I know that. And then ultimately what you want to do is create a new thread of execution right in the remote process to execute your shell code. So there's a process and a process we know can spread the the tasks through threads as well. So one of the threads is actually going to execute the shell code and ultimately um the attacker is going to accomplish the objective. So let's do a quick recap right. So we know that processes execute

on an operating system. A process is just basically a file that is executing right. Um and when there's that execution that's happening there's certain states that the process takes. So a process can be in the new state. So you've actually just started executing something on the operating system. um it's new and then it's ready. So meaning there's memory allocated to it and it's going to be executing and there's a whole lot of other states as well. So what attackers do is they try to take advantage of these process states, right? And this leads me to what we call the process hollowing. So we looked at injection, right? So injection is a process is executing and then basically

you call an open process. So you've got access to that process. Then you write your shell code in the context of the memory of that executing process and then you call a thread to execute your shell code. In process hollowing though the attackers take a bit of a different approach, right? So the malware basically hollows out legitimate code. So again this is something that we trust that is executing on the endpoint and then we overwrite the memory space of the target process with a malicious executable. How does that work? The steps include you suspend a target process. So remember the states of a process right a process can be new can be ready can be running when it's

running it's allocated memory on the operating system on the on the endpoint right so what happens is the the attacker will suspend the target process and then secondly it will replace a malicious ex uh it will replace that with a malicious executable image. So the actual process with allocated memory has been suspended and then you replace the executable image and finally the process is resumed. Now when a legitimate process is resumed it just continues executing in the context of the memory that was allocated to it. But then when it resumes it's executing the payload that the attacker planted into the context of that process. Make sense? Okay. All right. The next one I want to talk about

is the low bein abuse. Right. where we just abuse trusted tools on the endpoints themselves. So we've already talked about you know things that we trust but what are those things? PowerShell right? How many people do PowerShell logging from a security perspective? Few hands in the room. It's painful. Let's be honest. Especially if your environment has got developers. The moment you begin to do PowerShell logging and you begin to track malicious patterns you will get a call from the people doing the CI/CD pipelines. That's just a fact, right? It's annoying. But then again, when you look at it from a blue teaming point of view, attackers are exploiting PowerShell a lot. PowerShell is powerful, but again, it also opens up

vectors where you can literally download shell code from the internet and then it's going to be run in the context of the memory of PowerShell. So if the only thing that you're doing monitoring on and logging on is PowerShell, sometimes you might not really get context into what PowerShell is executing within its memory space. Right? So there's so many documentations on how things that we trust on operating systems can be abused. Um and here basically contextual analysis is key to detection, right? I know there's a big fighter on how we do monitoring of these things in production, but again um it's really important because attackers are blending in. There's two projects that are very famous at this point, right? One is uh

living off the the land low base basically. Anyone familiar with it? Yeah. Wow. It's the entire room. This is impressive. And then there's the Unix vision as well is called get the off bins. I don't use bad language, but that's what they call it, right? So, it's GTFO bins. Um, very good for Linux as well. There's so many interesting attack vectors that are covered by the binaries that are running on Unix. and basically what we've seen in the world in terms of attackers using some of these services. So really good projects. Please check them out on GitHub and on their websites as well. There's another one that I referenced. We had a meetup yesterday. It's leaving off false

positives. Like you would never guess it, but attackers also leave off false positives, right? So usually when there's false positives in our environment, we just ignore the false positives. We don't turn off those rules that are noisy. We just say, "Oh yeah, it's always firing an alert." Right? And sometimes attackers know you're ignoring those things. So they'll try and blend in using those attack vectors. But that's a story for another day. Okay. Finally, we're going to look at kernel and driver misuse. So basically bring your own vulnerable driver. Let's just do a recap. Right. So uh okay fine. First firstly an introduction when we talk about kenno driver. So we saw the edr architecture right. Um the edr today

most of the edr2s are basically kenno drivers. So, Windows allows them. They sign and say, "Hey, this is legitimate. It's elastic agent. We allow it to be run on Windows operating systems." Could be Microsoft Defender, could be CrowdStrike, whatever you want to use, right? But basically, the EDR of today is that kennel driver, but has it has to be signed, right? It has it has to be something that you trust to really run within the kennel space of your endpoint. with kernel and driver misuse bas basically attackers are looking at a way of bringing vulnerable signed drivers to be loaded into your kernel and ultimately get system level privileges and then do the disabling of

your edrs as well. So basically they'll disable bypass the kernel callbacks um and you're not receiving telemetry as as we've already seen and then the attacker basically gains freedom to execute whatever they want to execute on the operating system itself. So that EDR either loses deep visibility and detection capability or sometimes it's fully uninstalled as well. And we've seen real life stories where EDR2s have been completely wiped out by vulnerable drivers within the kennel space. I like visuals. So this is just a visual. Again, we're looking at the user mode and the kenno mode. Right? So we already know that from an operating system perspective. The user mode is where we basically do random standard

user activity as well. So you do have user mode drivers and then there's also a concept of ko mode drivers. A driver that is residing within the kernel either needs to be signed by Microsoft in most cases or you need to also have like some sort of PKI public key infrastructure where you can also um have signed stuff running within the context of the kennel mode itself. So let's look at an example right what would an attacker do from a vulnerable driver perspective. So the first step is the always t you know our users right we always say human beings are the weakest link in our organizations and we see it even with vulnerable drivers. So the

initial part is that initial access compromise credentials credential dumping fishing attacks those low hanging things but ultimately we know that attackers want to do privilege escalation on our endpoints. So they find an initial access point also try to find a vector where they do a bit of that privilege escalation and then once they get those privilege privileged um privileges the high privileges they'll basically do a driver installation. So again Microsoft are great but sometimes the model doesn't work because sometimes they do sign things that actually have vulnerabilities in them. So attackers spend a bit of time just looking at hey what is it that Microsoft has signed off to be run on Windows machines that runs

with high privileges right and this is where the whole patching game comes into the play but once they identify that vulner vulnerable driver they'll install it since they've got high privileges from step two and then they'll use it they'll see hey what rights does this vulnerable driver have can it fully uninstall stuff on the endpoint or can it actually modify certain kennel structures so certain drivers are very powerful vulnerb vulnerable drivers, they'll fully and totally uninstall the EDR or actually they'll play around with those structures and ultimately you want to disable the security controls. Make sense? Okay. Okay. So, just a few examples, real life examples. How many are familiar with NATO lock shields? How many have played

netto lock shields? Okay. At least half you've played in lock shields. I love lock shields. If you haven't, try and see if you can play in your team. I know the Netherlands takes part in lockshoots as well. We've supported lock shields for the past four years I think. Yeah, about four years. We saw this last year. One of the teams were supporting during lock shields. So for those of you that don't know what lock shields is, um NATO member countries have got um this cyber security exercise, arguably the biggest cyber defense exercise in the world where they just train member countries to defend your critical infrastructure. So usually it's red team versus blue team. It's a sim it's real systems but

it's not production systems right so we've taken part and what we saw last year and this happens in real life as well we get calls every day as elastic attackers were trying to do evasion of our EDR one of the ways that they try to do this is you can see all the smileys at least they were nice enough it's nothing very disturbing no yeah at least it was just fire icons but they did log poisoning right and they tried to basically stop the telemetry collection of the agent itself. So when we saw this in the exercise um it was a bit worrying and funny as well but you see that red teamers and the guy we we had a chat

with the guy that did this. He's a red teamer in real life as well and he said his objective was to actually evade elastic defend. Now you'll meet different red teamers. They're trying to evade other EDR2s as well. But again this is just a real life example of people that are actually trying to do evasion of EDR2s. There's also another tool that we saw this year in lock shields. It's called edr silencer. How many are familiar with edr silencer? Okay, a few hands in the room. Um this is another hobby project from another red teamer. But basically again what they're just trying to do is that blinding and blocking of telemetry that's being produced by the edr tools

as well. So we're seeing a lot of these things coming up is close to home. Um attackers are actually trying to disable your EDR. So what can we do um in terms of avoiding EDR evasion right? So the first one is turn on script block and script logging as well. I know this is painful in terms of logging what your scripts are doing but we need to do it. So log whatever is happening with your PowerShell log whatever is your VBS scripts are doing in your environment your bash scripts. we need to have a bit of visibility into um what the scripts are doing within our environments because those are huge vectors that attackers are doing and then apply

Microsoft driver block list updates as well. So it's okay for things to be signed by Microsoft but also just monitor for hey does micros Microsoft still trust some of these things to run on our endpoints as well. Really really important. I know it sounds easy on paper but in reality it's such a very hard thing to do. And then the other thing is monitor your agent heartbeat. We've seen the crucial part that the agent plays in terms of EDR. You just always want to make sure that your EDR or your agent is always checking in home, right? So it's alive and doing what it's expected to do. Um and then also we saw that ETW and the AMSY, so

the antimalware scanning interface, the one that scans the scripts and also the ETW telemetry can be tempered with. So you just want to have temper hands as well. Microsoft are really good with telemetry. So if some of these channels have been disabled or these capabilities have been disabled, there's a way of actually getting event codes that actually um give you a hint into um that activity happening. And then also you want to baseline and monitor low bin usage, right? So we saw that there's certain binaries and services that run on our endpoints that attackers are going for. So similar to the PowerShell logging, you just want to make sure that you're monitoring some of these aspects.

I'll not go so much into all these uh parts. The third last one is hunting for read, write and execute allocations and remote threads. Um and this is in the context of processes, right? So you just want to make sure that your ed capability can also uh just basically monitor what are the threads doing, what are processes doing on the endpoints, are they trying to do certain things in the context of other processes as well. So this is something that a lot of EDR tools are doing but just make sure that these capabilities are actually turned on as well. Okay, with that I just want to end it with some recommended reading. This is how many are familiar with this

book evading EDR. Matt hand now you're familiar with it. Okay, few hands. If you're interested in this topic, this is a very good book. I think it's arguably the best book I've seen on evading EDR. There's a lot of references about elastic. So I like it even more because of that because I love elastic. Um and then also the technical review of this book is one of our uh VPs within the endpoint security space as well. Really good book, really nice concepts. I urge you to um read up on it. There's a lot of public writeups on ETW and ARMS and driver abuse and legend tempering as well. And then even if you're using another vendor, please check their

threat research and also their community blogs because most of the vendors are actually doing continuous monitoring of what's going on. We have our own sec elastic security labs as well. There's a lot that we're doing in the EDR evasion space as well. So please have a look at some of the work that we're doing from that perspective. With that I can say that's all folks. Any questions?

Thank you. Thank you, Marvin. Are there any questions, guys? >> Yeah. >> Okay. All right. No tough questions. Thanks a lot. Thank you. Thank you. >> Oh, was that a question then? Oh, okay. Damn, I thought I got away with it. Oh my god. No tough questions. They're recording. You know, this is going on YouTube. So I'm curious what your opinion is on um an EDR living in or operating in the well user space or kernel space. >> I was I wish I'd put money on it. I knew that would be the first question. Every time I give this talk that's the question that comes up. Uh so you got the question right? So should we

continue having EDR2s operating in the kennel space or should we let EDR2s operate within the user space? It's a tough one. I personally, this is my personal opinion, um I I think we should continue having EDR2s operating in the canel space. Uh reason being it's a no-brainer. They it just gives us so much access to easily identify malicious stuff. The user space is such a very unprivileged space. It's not even interesting from an attacker perspective as well, right? Because I mean, yes, user space, less privileges. There's not so much you can do to change and alter the functioning of the endpoint itself. So again attackers if we operate in the user space attackers always find their

way in the kennel space and if you're in the user space and then in the kennel space it it's so hard to monitor you know from a less privileged position monitoring what's so privileged it's like it's a private party and you're not invited but the attackers are invited right so I I do understand the problem now is if we as edr vendors operate in the kennel space then you need to install us with multiple privileges so if we not so good in terms of our own sanity checking and we're abused. We've seen I think the previous talk or the talk before that the OT talk spoke about you know the npm package compromise that's been happening in the past few

months. So if you're an either vendor and you're using those npm packages there's a supply chain attack and I'm operating in the kennel space of your machines then I'm bringing a risk to your organization as well. So, it's a bit of a it's a tricky situation, but ultimately I think the benefits of of operating in the kennel space outweigh the benefits of EDR being in the user space. >> I share that opinion, but I'm curious why Microsoft >> out of the K. Now, I've been I've been tracking that as well. Um I would say as long as EDR vendors get special treatment even if we operate in the user space I don't care what Microsoft do as

long as they still give us access from the user space to get into the telemetry that we need from the kennel space. If they can also have an interface where they provide what we need in the kennel space in user space great but the problem with that is what's the difference right so there's no difference at the end of the day right because we still need to have that visibility into the kernel space the beauty with what they're trying to do is if we are compromised as an edr um I don't know how they implement this but they're trying to really minimize what we can do in the kennel space I don't I don't know we'll see how it

evolves Microsoft. >> We blame Microsoft. Yes. I know we're recording this, but yes. No, I'm just kidding, but yeah. Um, that's just my opinion on it. Very good question, by the way. All right. Any other questions? >> More question. >> Any more? >> I was hoping he doesn't raise his hand. I told him yesterday, no questions from you. Okay. >> Marvin, thank you for the talk. It was really interesting to listen to. Uh my first question is uh I think from my perspective my EDR if I install it should definitely detect any privilege escalation uh exploitations. What's the problem in doing that? So why still we have uh these vectors applicable in real life scenarios? That's a very good

question. I think security is not static. Security is dynamic. Right? And then also one of the things that we tend to usually forget is technology in general is created to create a better experience for the end user. So the focus for me is always going to be innovation before security. And as long as innovation always comes before security, there's always going to be vectors to do things such as privilege escalation. So as edr vendors u we can catch up as much as we can but attack as well as find a way in because again tech is a very constantly changing space and I think privilege escalation will continue um even if we have very good

protections in that sense. >> Uh let me let me clarify. So I think that if if we have uh some unprivileged process which spawned u highprivileged process that should be detected detection is yes it will be and this is why I said when you start doing PowerShell logging it usually causes a lot of noise especially if you're an environment with a lot of developers because in most times developers also will be operating in the user space legitimately also want to do things in the kennel space using powershell when we look at it from a security perspective we will get that alert. Hey, there's a user that started PowerShell and it did something in the background

that went into a privileged state. So again, it's usability versus cyber security in that sense, right? And I I don't see that ending. So I think the EDR tools will be able to tag that. But the question is what's the context of that alert? Is it a true positive? Is it a false positive? If it's a developer doing it, then it's a true positive. But again, I mean, it's a yeah, it's a true positive and well, false positive, but it's a legit thing that they're doing. But then also, it could be that another time the attacker does a compromise of the developer and does the very same thing. And that's where it becomes a little bit of a cut and mouse kind of

scenario. It's going to be a tough one. And that's why, yeah, we talked about this at the meetup. Those of you that were there yesterday, there's a lot of context you need to bring into your workflows. Just try to understand, is it a developer? And maybe in real time also just check hey are you the one that actually did this in real time a slack message or a team's message from a soul perspective as well but it's a whole topic on its own but generally speaking I don't see these things stopping anytime soon. >> Okay. Thank you. Uh may I ask another question? >> Yeah we have time. >> Do we do we we have time? Oh

>> uh next question is uh did you have you observed any uh time based attacks like um for example as far as I know EDR always work with events uh based on or limited by some time frame. So if do you know let's say a way how we can still detect those tank based attacks uh except using sandbox because obviously there we can um how to say that uh we can skip those long sleeves delays and so on but can you do that in real time? >> That's a good question. a little bit of a tough question, but uh yeah. Yeah, let me get back to you on that one. From an EDR perspective, it's going

to be a bit tough and that's why for me it's like uh I've met security teams that depend on EDR only. I don't agree with that. I've met security teams that depend on CM only or analytic platforms only. I don't agree with that. I think the two complement themselves. And the reason why I like that is the EDR is going to do on endpoint prevention and stop things before they actually achieve their objective. But you still need that telemetry that I talked about ending in your analytic platform cuz that's where now you can build nice detections that are able to detect things such as that cuz most telemetry also comes with time stamps, right? the original time stamp

on the endpoint itself, timestamps on when you picked up the telemetry in your analytic platform. And it just allows you to still establish an sort of an after the-act kind of approach. So if the EDR is not able to detect the time based attacks, I don't know if Elastic does that. I need to check. But again, if you're collecting the telemetry, I always think it's easy to create the detections that can detect for those scenarios. >> Thank you. >> Thanks for the question. >> Thanks again for the talk. It was amazing. >> Thank you very much. >> Please give him a round of applause.