At the beginning, I am convinced that a good EDR product is more and more important to increase the endpoint visibility and to develop a better understanding of your own system environment. However, before purchasing a product, an objective and autonomous evaluation should be carried out, to get a feeling about the real strengths and weaknesses of a product. For your information, when I talk about EDR products in this blog post, I always refer to products which also include an antivirus module for prevention (AV/EPP/EDR).
Also, I would like to point out, that this is only my personal research and everyone is responsible for their own activities during a penetration test, red team engagement, etc. and must take care about his actions.
In this article, our main focus is not on bypassing EDR products, rather we focus on the ATT&CK technique T1562.001: Impair Defenses: Disable or Modify Tools. In the first step we focus on, to get a deeper understanding of the different EDR components and their functionality in Windows user space and kernel space. Therefore, we will take a closer look at:
- EDR Windows user space components, to understand their respective tasks and the functional connection between them:
- Process Protected Light (PPL) processes
- Protected services (ELAM service)
- Registry keys
- EDR Windows kernel space components, to understand their respective tasks, the functional connection between them and the functional connection or relationship to the respective user space components:
- Kernel callback functions
- Minifilter drivers
In the second step, we use the gained knowledge to disable the main functionalities from an EDR, step by step, by targeted, controlled tampering of specific key components from the EDR in user space and kernel space. I will show the steps with a well known EDR product, but on the one hand I would like to point out, that the shown strategy is not based on weaknesses on the part of the EDR vendor and on the other hand, this way works with several different EDR products. If you are searching for zero days, this isn’t the right place. Rather, the goal of this blog post is, to gain a better technical understanding from the functionality of EDR products on Windows. Furthermore, I would like to say that this article covers only a part of the complexity of an EDR product, represents only a snapshot and I make no claim to accuracy and completeness.
Even if a red team has already gained privileged access to a system (local admin, system account etc.), most EDR products can still be very annoying in case of TTP prevention and detection. The simpliest way would be, trying to uninstall the respective EDR. But normally if the blue team has done their homework correctly, uninstallation without the uninstall password is not possible. Indepent of this, we want to find different ways. to disable the main functionalities from an EDR and find a way, to permantently avoid:
- Prevention by the antivirus module, especially in case of dynamically and in-memory prevention based on API-Hooking
- Among other things, it is important to find a way to disable the user space dll injection, which is responsible for the implementation of the user space API-hooking
- Detections and especially getting rid of the footprint based on the telemetry which the EDR collects on the host
- We have to identfiy and disable permanently the component which is responsible that the EDR can collect telemetry (executed processes etc.) on the endpoint
- Host isolation of the compromised endpoint
- Therefore we have to identify and disable permanently the EDR component on the compromised host, which allows the blue team to isolate the host by using the host isolation feature in the web console
- Real time response
- We want to avoid, that the blue team can use the real time response feature (remote shell) and connect to the compromised host. Therefore we want to identify the responsible EDR component and disable it permanently
- Recovery of partly tampered EDR
- Depending on the product the blue team has the possibility to use some kind of repair or update function to recover a partly tampered EDR. Also in this case, we want to identify the responsible component and disable it
Give me a scenario?
Imagine you have achieved unprivileged access to a Windows client, for example by a phishing mail or similar. In the second step, because of an exploit or simply a misconfiguration, you are able to escalate from an unprivileged user (medium integrity) to a privileged user (high integrity) or at least system integrity. Having a closer look on the open processes on the compromised endpoint, you could observe, that another user from interest has an open user session with processes, which manage their threads in high integrity level. If you believe it or not, in my case the open user session was from one of the domains admins. Because one of our defined goals with the customer could be, to check if we are able to achieve domain admin privileges, we want to take that low hanging fruit to escalate from a privileged local user to domain admin, for example by:
- Dumping the lsass memory and get the NTLM hash or maybe clear text credentials
- Or use access token manipulation to the steal the token from a process (high integrity) from the open domain admin user session
But on the respective, compromised endpoint is a tough EDR product installed and we do not want to be unnecessarily loud and create alerts by triggering the EDR product. Otherwise the blue team will realize that the endpoint is possibly compromised and will cut the network connectivity of the endpoint by using the host isolation feature in the EDR web console. Because of that, we start to dig deeper in the world of EDRs in our lab. Prerequisite! For every key activity we need at least a privileged user (high integrity), except the case you are very, very lucky and already a vulnerable driver is loaded on the compromised endpoint 😉 (more on later).
First Step: EDR processes
In the first step we can identify the EDR process(es) by using process explorer and try to terminate the respective process(es). But hopefully the EDR process(es) are executed as protected process light (PPL-PS_PROTECTED_ANTIMALWARE_LIGHT (0x31)) process. Because of that, even if we execute process explorer in system integrity, we are still not allowed to access the address memory of the EDR PPL process from user space. Nevertheless there are a few ways to remove temporary the PPL flag from the respective PPL process and terminate the not longer protected process. Depending on the product it could also be possible, to directly terminate the PPL process with process explorer (more on later). Creds to @CCob to inform me about the following known possibilities in case of dealing with PPL processes from red team perspective:
- Using a trusted installer
- Using another protected process
- Using a vulnerable device driver to get access to kernel space
Because of we have already achieved system privileges, but we don’t have the possibility to use a trusted installer or another PPL process, we will use the concept of a vulnerable (device) driver to get access to kernel space and try to terminate the protected EDR PPL process . As additional information, there is also an interesting possibility to deal with PPL from user space. To learn more about that , I highly recommend to have a closer look on the amazing blog from Clement Labro (@itm4n):
But as already mentioned, in our case we will use a vulnerable driver like the Rtcore64.sys to get access to kernel space. To understand the concept of using a vulnerable driver, it is important to know, that compared to code in user space, there is no address memory isolation between different code in kernel space. In the picture below we see, that (device) driver code is placed in kernel space. And because the Rtcore64.sys driver has a vulnerabilty which is also called a Null DACL access, if the vulnerable driver is loaded, even an unprivileged user (medium integrity) is allowed to access code in kernel space. As mentioned in the introduction, in case of the red team or attacker is very lucky and a vulnerable driver with a Null DACL access is already loaded, privilege escalation from a local unprivileged user (medium integrity) to a privileged user (high integrity) to access kernel space wouldn’t be necessary. Much more details about the rtcore64 vulnerablitly can be found here.
To remove the PPL flag from the protected EDR process, or to directly terminate the protected EDR process, the following tools among others are available. Please beware, that the execution of the default variant of that tools will create with a high probability alerts in the antivirus module from the EDR product. In most cases, the antivirus will trigger on signatures in the default code. Because of that you have to modify the code or should remove or obfuscate relevant signatures to bypass the antivirus.
- By executing PPL Killer as a privileged user, we can load the vulnerable device driver Rtcore64.sys into the kernel and by that we get full access to kernel space. In the case of extreme luck (depends on the perspective) and the vulnerable device driver Rtcore64 or another driver (have a look on screwed drivers github repository from eclypsium) would be already loaded, you don’t need to load the device driver again and you should theoretically already have full access to kernel space (also as unprivileged user in medium integrity). The reason for tht, (as you can see in the picture above) the vulnerable device driver acts as a (vulnerable) bridge from user space to kernel space. And because there is no process isolation in kernel space (compared to user space) you have full access to kernel space by having access to the code of the vulnerable device driver which is placed in kernel land.
- Another possibilty would be, to use mimikatz and its own device driver mimidrv.sys to get access to kernel land
- Also you can execute this version of Process Hacker in a privileged context (high- or system integrity) to load Process Hackers own device driver (KProcessHacker3). After loading the driver, depending on the respective EDR product, it is not necessary to first remove the PPL flag from the EDR process and then terminate the process. Instead you can directly terminate the process or the process tree by using the process termination function in Process Hacker. Whether this works or not, depends on the EDR product.
Conclusion process tampering
Normally EDR processes are executed as PPL processes in Windows user space. Because of that, despite the red team has system privileges, the PPL process can’t be terminated from user space. But there a still ways which allow us to remove the PPL flag and terminate the unprotected process. One way could be, using the concept of a vulnerable driver. This allows us to get access to kernel space, remove the PPL flag and terminate the EDR process in the system session (session 0). But in many tests with different products I could observe, that this termination is mostly only temporary and the terminated processes are again executed a few seconds later. Because of that, there must be another EDR component in user space or kernel space, which protects the EDR PPL process(es) against permanently disabling by termination of the PPL process. This means, to reach our previously defined goals in the introduction, we have to do more research on EDRs.
Second Step: EDR services
In this section we take a closer look at EDR services in user space, which is connected to the EDR PPL process in the previous section. The picture below shows us, that the EDR service is the component, which is responsible to protect the connected PPL process against tampering attempts. In other words, if the PPL process was terminated, the connected service will restart the respective PPL process again and again. Therefore the PPL process termination is at the moment only temporary. In several tests with several products I could observe, that depending on the product, it takes more or less time from process termination back to a running PPL process.
It would just be logical, to try, to stop the EDR service and then terminate the connected EDR process to achieve a permanent disabling of the user space EDR component (which exist of the EDR service and the EDR PPL process). But normally the EDR service is executed as a protected service and by that, even in system integrity it isn’t possible to pause, stop or disable the EDR service. EDRs have a separate kernel component which is called an ELAM (Early Launch Anti Malware) driver, which is responsible for initializing the EDR service as a protected service. For this reason, the protected service is often colloquially referred to as ELAM service. In this blog post I do not want to go deeply into the function of an ELAM driver, so I have written a separate blog post for this. Compared to protected processes, at the moment I don’t know about a way to stop the protected services under Windows. The picture below shows us, similar to the PPL processes, that even in system integrity we are not able to stop or pause the protected service
Conclusion service tampering
In this section we have learned, the EDR uses in Windows user space a component, which is called a protected service. The initialization of the protected service is done by the ELAM driver which is a separate component from the EDR in the Windows kernel space. Because of that, even in system integrity in user space, at the moment we are not able to disable, stop or pause the protected service. Furthermore we have learned, that the protected service is responsible to protect the EDR PPL process against tampering attempts. One interesting observation in case of a well known product, I was able to observe an interesting behaviour in context of PPL process termination. After terminating the PPL process a few times, the connected, protected EDR service did crash and the EDR user space component wasn’t longer registered in the Windows security center. In this case it was possible to permantly crash/disable the EDRs user space component. But with the most EDR products this is not possible. Now we know about the relationship between protected service and PPL processes in context of an EDR, but still we are fare away to reach our goal, to permanently disable the main functionalities from an EDR by targeted, controlled tampering. Therefore we have to dig deeper and take the next step in our EDR tampering journey.
Third Step: EDR registry keys
In the third step we have a closer look at interesting registry keys, sub keys and entries from an EDR product. For an easily navigation to the for us important EDR registry keys, you can use process explorer, double click on the EDR process and use the explore button (Autostart Location). Normally you will find the EDR reg keys of interest in the area Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. By taking a closer look at the registry keys from the EDR user space component (protected service and PPL process), we could identify the two following interesting entries:
- REG_DWORD: LaunchProtected
- REG_DWORD: Start
The LaunchProtected DWORD could be used, to have influence if the EDR user space processes should be be executed as PPL process or not. But no matter if we would permanently remove the PPL flag from the EDR processes, by setting the right value to the to the respective DWORD, we would still not be able to reach a permanently termination of the EDR process. Why, because the process would still gets restarted by the protected service (recovery function). Because of that, we focus more on the Start entry DWORD. In our case the Start entry from the EDR user space component has the default value 2 which is equal to Autoload. This means, the Start entry is responsible for the initialization of the protected EDR service on startup, which is in turn responsible for initialization and protecting the connected EDR PPL process, against permanently disabling by process termination. In the next step we could try, to simply change the value from the EDR Start DWORD from 2 to 4, which would be equal to disabled. If I understand the relationship between EDR processes, EDR services and EDR registry keys correctly, we should be able, to permanently disable the EDR user space component, by setting the value 4 to the Start DWORD in the EDR user space component registry key. But there is one problem, similar to protected services and PPL processes, even in system integrity in user space, we are not allowed to make changes to the value of the entries in the EDR registry key neither to the registry key itself . It looks like, there is another protection mechanism or EDR component in user space or kernel space, which protects the EDR registry keys against tampering attempts. At the moment we do not know which kind of protection mechanism or EDR component is responsible for this.
Also important for the red team. If the EDR reg keys protection mechanism is active, depending on the respective EDR product (and EDR configuration), you will possibly create an registry key tampering alert in the web console from the EDR. This would be very bad, since you can expect with a high probability, that the blue team will use the host isolation function in the EDR web console to cut the network connectivity and you will lose your connection (command and control channel) to the compromised endpoint.
Conclusion registry key tampering
In this section we have learned more about the realationship between EDRs PPL processes, protected services and reg keys. We saw, that tampering the Start entry of the user space component reg key could be the key element to permantly disable the protected service and by that also the connected EDR PPL process. We can try to change the value from the Start entry from 2 to 4, which would be equal to disabled. But also in system integrity context we are not allowed to do that and possibly create an alert in der EDR web console.
Interim Status user space tampering
In the last three sections we have learned a little bit about the different user space components from an EDR in Windows, which are consisting of PPL process(es), protected service and registry keys. We are able to reach a temporary termination of the PPL process, but a few seconds later the PPL process gets initialzed again trough the protected service. The protected service is initialized as protected service through the ELAM driver and at the moment we have no possibilty to disable, stop or pause the service. For generally starting the protected service is the Start entry in the respective user space components registry key responsible. But also with system privileges we are not allowed to make changes to the EDR reg keys or entries, because the are protected by a at the moment unknown mechanism. This means, until now we are not able to reach our previously defined goals to permanently disable the main functionalities from an EDR. But on the other hand, the picture below shows us, that we have gained a lot of knowledge about the functionality from the different EDR components in user space and their relationship. In other words, we have to be persistent in research and find in the next step the EDR component which is responisble to protect the EDR registry keys against tampering attempts. I think, if we are able to change the value in the Start entry from the EDR user space service from 2 to 4, we can disable the user space service permanently.
Fourth Step: EDR Kernel Components
In addition to the user space component, EDR products under Windows also have different kernel components such as different drivers like the ELAM driver and a filter driver or, more specifically, a minifilter driver. Furthermore the EDR product can use the minifilter driver to register different typ of kernel callback routines. In this blog post we have a closer look at the relationship between minifilter drivers, kernel callbacks and the relationship between them and several user space components from the EDR.
By the introduction of Kernel Patch Protection aka PatchGuard (with Windows XP x64 service pack 3), antivirus and EDR products officially are not longer allowed (except Patch Guard bypassing) to use kernel space hooking like SSDT hooking. Because of that, most products have to use user space Dll injection to realize user space API-hooking instead. But despite that banishment from Windows kernel space, the products can use the mechanism of kernel callback routines, register different typ of callbacks to realize different typ of prevention and detection tasks. This are some callback routines which most products are using:
- Used by EDRs to collect telemetry about newly created processes and prevent/detect in combination with user space API-hooking the execution of malicous code
- Furthermore this routine is used to realize user space Dll injection itself, which realizes the ability for user space API-hooking by injecting a separate hooking.dll into every process in user space.
- Used by EDRs for observe Dll mapping and to prevent/detect attempts in case of mapping a malicous image into the address memory of an user space process
- Used by EDRs to prevent/detect attempts of malicious process injections from one process to another one
In our case, we have a closer look a the ProcessNotify routine which is responsible to initialize user space Dll injection/API-hooking. By combining user space API-hooking and getting informed in case of a new process is created, I like to say, that by that, the EDR has a realtively high process- or endpoint visibility.
To patch or remove a registered callback from an EDR product, we can again use the concept of a vulnerable driver to get access to kernel space. The kernel space is definitely a very sensitiv area, but in many different test cases in my lab with different products, I was not able to observe any kernel crashes or BSODs. In case of you have achieved access to kernel space, you can use a tool like CheekyBlinder from @brsn76945860 to identify which callback routines are registered by the EDR. In the next step, because we want permanently get rid of user space Dll injection/API-hooking we can patch or remove the registered ProcessNotify callback from the EDR. Patching the ProcessNotify routine has the consequence, that the EDR do not longer inject his own hooking.dll into the address memory into processes in user space. Thereby the EDR could not longer use user space API-hooking to analyze executed code in context of the originally hooked native APIs. For this a simply experiment can be done. In the first step, start a windows command shell (cmd.exe) and use process explorer do have a look at the loaded Dlls in the address memory of the cmd.exe process. If the EDR is using user space API-hooking you will find a separate Dll from the EDR product which is responsible for API-hooking. In the second step, get access to kernel space, patch the ProcessNotify routine, start another cmd.exe and check it again with process explorer. Compared to the first windows command shell, you will see, that in the second one the hooking.dll from the EDR is not longer injected.
Patching the ProcessNotify routine brings also the consequence, that the EDR is not longer able to collect telemetry when a new process is created. Thereby the threat hunter could get in big trouble, because from the point of patching the callback, telemetry based threat hunting is not longer possible or at least not plausible.
Very important in our case, EDRs can use kernel callback routines to protect their own registry keys in user space against tampering attempts. Remeber, one of our goals in the user space section was, to identify which component do protect the EDR reg keys against tampering. Depending on the product they use for example the callback CmRegisterCallback, but I also could observe, that some products do use the ProcessNotify routine to protect their registry keys.
By having again a closer look at the registry key from the EDR user space service (remember user space section), the picture below shows us, that system account should be allowed to make changes to the reg keys because of having full control. But because of the protection trought the registered callback, even the system account is not allowed to make changes to the entries of the reg key.
At this point I would say, we check our hypothesis of registered callback routines and reg key protection and try to tamper the registry key from the EDR user space component to permanently disable the user space component (which exist of the protected service and the PPL process). As already mentioned, we need access to kernel space. Therefor we can use the POC CheekyBlinder from @brsn76945860 and do the following steps:
- List the registered ProcessNotify callbacks
- Patch/remove them, open the registry as privileged user
- Search for the registry key of the EDR user space component
- Search in the reg key for the START entry, change the value for the DWORD from 2 to 4 (4 is equal to disabled)
- Reboot the host.
- After the reboot , the EDR user space service should now be permanently disabled.
This means, the protected service is not longer initialized and thereby also the connected PPL process is not longer initialized. In other words, we are now able to permanently, targeted, controlled disabling the EDR user space component. To check this out, have a look at the first demo.
Conclusion EDR Kernel Callback tampering
In the first demo we saw, that in the first step executing mimikatz was prevented by the antivirus module from the EDR. Also we could observe, that despite system intgerity context, we are not allowed to disable the PPL process and the protected service or change the value for the START entry in the EDR user space service registry key. Because of that, we temporary removed the registered ProcessNotify callback from the EDR. The consequence was, that user space DLL injection was disabled and by that also user space API-hooking. After patching the callback routine it was not longer a problem to execute mimikatz.exe. Also we achieved a success in disabling the possibility of telemetry collection in case of execute processes on the compromised machine. This means, if the threat hunter would use the web console to hunt for mimikatz.exe after we have removed the ProcessNotify routine, he will not find any executed mimikatz.exe processes.
Until now we have achieve a part goal, but from red team perspective it is still to less and inefficient, why? Because after changing the value for START entry from the EDR user space service to 4, we have to reboot the machine. Otherwise the status of the protected service will not change to disabled. But despite the permaently disabled EDR user space service, we face the following problems:
- After the neccessary reboot, the EDR re-registers all previously removed callback routines.
- Thereby in case of re-registering the ProcessNotify routine this brings the consequence, that user space DLL injection is again working and by that also user space API-hooking. In other words, we were not able to reach a permanently disabling of user space API-hooking.
- Furthermore, the EDR can again collect telemetry on the compromised endpoint.
- The host isolaton feature can still be used by the blue team, to isloate our compromised machine.
- The blue team can still use the real time response feature and connect to the compromised machine via EDR remote shell.
Also the EDR recovery feature can still be used by the blue team, to recover a partly tampered EDR sensor. In this case this means, they can use the recovery feature to repair the partly tampered sensor and bring back the Windows user space service. But by taking a look at the picture below, we see, that until now we have achieved a solid understanding of the relationship between the EDR user space components. We are on the right path to permanently disable the EDR in user space and kernel space, but we have to do a little bit more research in the last step of this blog post.
Final Step: EDR Minifilter Driver
In the last part of this blog post, we will identify (depending on the product) the key element which allows us to permanently disable the main functionality from an EDR and reach all of our goals which we have defined in the introduction. Therefor we have a closer look at the EDR kernel component which is called a file system driver or more precised a minifilter driver (in case of there is a dependency on the fltmgr.sys driver), because of the following reasons:
- Regardless if we have successfully, permanently disabled the EDRs user space component, the minifilter driver from the EDR is still registered and active.
- The minifilter driver could be responsible for the kernel callback registration in general or at least responsible for the re-registration after a reboot.
- In our case remember, we have changed the value for the START entry in the EDR user space component from 2 to 4 and did a necessary reboot. Otherwise the status from the protected service would not change to disabled. After the restart, the minifilter did re-register the remove ProcessNotify callback.
- Therfore in context of the ProcessNotify callback, the minifilter is responsible that we were not able in the previous steps to reach a permanently disabling of the user space DLL injection/API-hooking
- Furthermore, he is responsible in contex of LoadImageNotify for observing malicious DLL mapping and ThreadNotify to prevent/detect malicous process injections.
- Furthermore, the minifilter builds with the registration of the kernel callbacks, the base for telemetry collection und further for telemetry based threat hunting.
- The minfilter could be also responisble to realize the feature of host isloation
- Further more he could be responsible to realize real time response and the EDR remote shell feature
- Also he could be responsible to realize the EDR sensor recovery feature, to bring back a partly tampered sensor
Derived from that, the EDR minifilter driver seems like to be the key element to reach our goal from targetd, controlled permanently disaabling the main functionalities from an EDR product. Compared to the user space component (protected service and PPL process) the minifilter is not relying on a service. By taking a closer look at all of the registry keys from the EDR, we see that the minifilter driver has his own reg key which is responsible for the initialization behavior from the minifilter. Also in this case the initialization behavior is controlled by the DWORD Start entry. Therefor we use the same concept as have used in case of permanently disabling the user space component to permanently disable the initialization from the EDR minifilter driver. Again, we us the POC cheekyblinder and do the following steps
- Load the Rtcore64.sys driver
- List the registered ProcessNotify callbacks
- Patch/remove them, open the registry as privileged user
- Search for the registry key of the EDR miniflilter driver
- Search in the minifilter reg key for the START entry, change the value for the DWORD to 4 (4 is equal to disabled)
- Reboot the host.
- After the reboot , the EDR miniflter driver should now be permanently disabled.
To check this out, have a look at the second demo.
Conclusion EDR minifilter driver tampering
In the second demo we saw, that depending on the EDR product, the minifilter driver could be the key element for targeted, controlled, permanently disabling of the EDRs main functionalities. This means by disabling the initialization of the minifilter we are able to permanently avoid:
- Callback registration in generell
- User space DLL injection/API-hooking in generell
- Prevention by the antivirus module based on kernel callbacks and user space DLL injection/API-hooking (especially dynamic and in-memory)
- Detections by the EDR module based on kernel callbacks and user space DLL injection/API-hooking (especially dynamic and in-memory)
- Getting rid of the footprint on the compromised machine
- EDR Registry key protection
- Host isolation feature on the compromised machine
- Real time response and EDR remote shell feature on the compromised machine
- EDR recovery feature on the compromised machine
As additional information, depending on the respective EDR product, if you are able to disable the initialization of the EDR minifilter driver, you don’t must care longer about the EDR user space component (protected service). Also if the protected service is still running, but the EDR minifilter driver is not longer registered in kernel space, depending on the EDR, the main functionalities in context of the antivirus- and the EDR module are no longer given. In the picture below we see, that the EDR minifilter driver isn’t longer running, the EDR isn’t longer registered in the Windows security center, but the protected service is still active. If you are more interested in protected services in context of EDR products you should take a look on my other article EDR, a closer look on protected services .
Conclusion EDR tampering on Windows
If or how it is possible to successfully disable an EDR product by targeted, controlled tampering of specific EDR components in user space and kernel space depends strongly on the EDR product itself. In different tests with different products I could observe, that the shown strategy applies to more products in Windows. Very important, this is not a vulnerabilty in the EDRs itself, much more this is a thing about the Windows architecture. I ask myself, how could we mitigate this disabling concept with the help from the Windows architecture. It would be very interesting, if would be a possibility for EDR vendors in the future, to provide a EDR component by using the Virtual-based Security (Hypervisor).
3 Key Take-aways
At the end what could we use as some key take-aways?
- Despite successful tampering, EDR do raise the bar more and more
- EDR tampering is a very isolated process -> always think about whole attack chain
- EDR tampering under Windows is not based on vulnerabilities in EDR products
- Rather, we see that all manufacturers must adapt to the rules of the Windows OS architecture -> same (official) rules for every EDR vendor
- Despite the best (EDR) product, don’t rely too heavy on them!
- Gradually start hardening your Windows environment
- Think about the onion layer principle