Hi everyone,
Today, I will try my best to explain how we can disable EDR products that do not have anti-tampering protection. Before diving into the topic, it would be beneficial to briefly touch on some key concepts.
Anti-Tampering Protection:
Modern EDR/AV solutions use a protection mechanism called “anti-tampering” to safeguard their binaries (executable files). To achieve this, they monitor registry changes by utilizing kernel-level callback functions such as CmRegisterCallbackEx. This way, they attempt to prevent the deletion or modification of binary files.
Let’s keep in mind that this method applies only to EDR products that either lack anti-tampering protection or have it disabled.
Now, let’s look at how we can disable an EDR solution.
Here, the Windows registry directory “HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager” comes to our aid. What does this directory do, and why do we need it?
The “HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager” directory is a critical registry entry used by the Windows operating system to manage kernel-level operations. It is specifically designed to control processes that occur during system startup and reboot. Let’s delve a bit deeper.
The Session Manager is a component that oversees the system startup and session management in Windows. We can describe this component as the mechanism that manages file operations (such as moving, deleting, or renaming files), driver loading, and registry adjustments when the operating system starts.
So far, so good. Now what happens next?
This is where the PendingFileRenameOperations registry value comes into play. What does this do?
PendingFileRenameOperations is a predefined registry value that Windows uses to perform file operations during system startup. This value is specially recognized and processed by the operating system. In other words, it’s a standard mechanism that Windows uses during reboots to handle file operations like moving, deleting, or renaming. When the system boots, the Session Manager reads the PendingFileRenameOperations value located in the registry and performs actions accordingly.
So far, we’ve covered some key concepts. Now let’s see how we can disable the EDR.
If the user account we are using has permission to add entries to the Session Manager, we can append the commands we want to execute to the PendingFileRenameOperations registry value. Let’s give it a try.
First, I locate the directory where the EDR is running.
Next, when I try to delete the EXE file as either an authorized or unauthorized user, I encounter an “Access Denied” error. This is exactly the expected behavior.
Now, I create a new value named PendingFileRenameOperations under the Session Manager using PowerShell:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations" -Value $($((Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name PendingFileRenameOperations -ErrorAction SilentlyContinue).PendingFileRenameOperations) + "\??\C:\Program Files\Elastic\Endpoint\elastic-endpoint.exe00") -Type MultiString -Force | Out-Null
Let’s break down the parameters here:
Under the path “HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager”, we are creating a value with the name PendingFileRenameOperations using the -Name parameter.
Then, we provide the executable file path of the EDR. After the file path, we specify two zero characters (0). These zero values ensure the executable file will be deleted when the system boots up.
We use the MultiString type to define the registry value type, and then we suppress the command output from being displayed on the screen.
To summarize up to this point:
We created a PendingFileRenameOperations value under the Session Manager path and added the target EDR’s executable file to it. If the computer restarts, the system will check the PendingFileRenameOperations value under the Session Manager. It will recognize the EDR’s executable file and proceed to delete it.
Now, let’s test it. Before starting the test, I run a small AMSI bypass script. As you can see, the EDR blocks it.
Now, we restart the machine. Checking the directory where the endpoint resides, we see that the EDR’s executable file has been deleted.
Now, when I run my AMSI bypass script again, it works without any issues.
Remembering you again: You need certain privileges to try this method. You cannot write any value under the Session Manager with a regular unauthorized user account.
Until my next post, take care, and wishing you a secure day ahead!