Another shorter blogpost. This week I focused on improving the user experience and I up the difficulty level to nightmare.
1. Quality of life updates
In my last blogpost I demonstrated the full attack chain which lead to Mimikatz being executed undetected. I also mentioned I would dive into ETW and add functionality to patch it to the Interceptor driver. After time considerations and given that there are plenty of other tools out there to take care of ETW, I have decided to instead focus on Quality of Life updates for the InterceptorCLI as well as convert it into a Beacon Object File (BOF) so that all the components may be executed in memory via Beacon.
The first big improvement is to rework the commands to be more intuitive and convenient. It’s now possible to provide multiple values to a command, making it much easier to patch multiple callbacks. Even if that’s too much manual labour, the -patch module command will take care of all callbacks associated with the provided drivers.
Next, I added support for vendor recognition and vendor based actions. The vendors and their associated driver modules are taken from SadProcessor’s Invoke-EDRCheck.ps1 and expanded by myself with modules I’ve come across during this internship. It’s now possible to automatically detect different EDR modules present on a target system and take action by automatically patching them using the -patch vendor command. An overview of all supported vendors can be obtained using the -list vendors command.
2. Bigger fish to fry
With ESET Internet Security defeated, it’s also time to move on to more advanced testing. Thus far, I’ve only tested against consumer grade Anti-Virus products and not commercial EDR/AV platforms. I spent some time setting up and playing with OpenEDR and Comodo Endpoint Protection.
To my surprise, once I had loaded the Interceptor driver, Comodo Security would detect a new driver has been loaded, most likely using ImageLoad callbacks, and refresh its own modules to restore protection and undo any potential tampering. Subsequently, any I/O requests to Interceptor are blocked by Comodo Security resulting in a “Access denied” message. The current version of InterceptorCLI makes use of various WIN32 API calls, including DeviceIoControl() to contact Interceptor. To try and combat this issue, I’m converting InterceptorCLI to a BOF which will use direct syscalls. I suspect Comodo Security uses a minifilter to inspect and block I/O requests rather than relying on user land hooks, but I’ve yet to confirm this.
Contrary to Comodo Security, I ran into issues getting OpenEDR to work properly with the Comodo platform and generate alerts. While I try and troubleshoot this problem, I’ve meanwhile installed and configured Wazuh, which is another open source EDR platform.
3. Conclusion
The final 2 weeks of my internship are approaching rather quickly which means it’s time to conclude development and start testing. I hope to get various commercial EDR/AV platforms working properly to fully test the entire attack chain, but the Interceptor driver in particular, so I can add improvements and identify any shortcomings and limitations so they may be addressed in the future.