Answer the question using: https://www.kitploit.com/2021/05/hookdump-security-product-hook-detection.html
Learning Points
- There are different ways to "hook"
- We should compare in terms of "Attack-Factor"
Resources
- Low level discussion of Sysmon Driver https://github.com/trustedsec/SysmonCommunityGuide/blob/master/the-sysmon-driver.md
- An Empirical Assessment of Endpoint Detection and Response Systems against Advanced Persistent Threats Attack Vectors
YJ's Documentation
Learning points from resources provided
Prior to answering the question for this goal, I first read up on the materials provided by Jym i.e. Empirical Assessment of EDRs against ATPs. This article was an interesting read as they made use of various diverse attack scenarios to assess the efficacy of EDRs against detecting and preventing APTs.
The following attack vectors were used in the experiment:
- A .cpl file: A DLL file which can be executed by double-clicking under the context of the rundll32 LOLBINS which can execute code maliciously under its context.
- A legitimate Microsoft (MS) Teams installation that will load a malicious DLL.
- An unsigned PE executable file that will execute process injection.
- A HTA file infused with executable VBS code.
The table below showcases the aggregated results of the attacks for each EDR:
Based on the results, we can see that no EDR solution was able to successfully detect and prevent all four attack vectors that were deployed. This shows that state-of-the-art EDR solutions are still imperfect and will remain so as it is impossible to detect and prevent ALL attacks. Unfortunately, no solution can provide complete security for an organization. One could deploy multiple solutions to provide maximum security but that is not feasible e.g. high costs/resources.
Another point to note from this article is that commercials EDRs rely heavily on kernel callbacks and userland hooks to collect information. More information about hooking can be found in the section below.
Moral of the story: Commercial EDRs make use of kernel callbacks/userland hooks to gather information. As seen in the results, even state-of-the-art EDR solutions are unable to detect and prevent basic PE attacks.
What if the 4 attacks were executed on OpenEDR?
If the 4 attacks were executed on a machine with OpenEDR installed, it is likely that all will be detected by OpenEDR.
Type 1 - CPL, DLL & EXE
CPL, DLL & EXE fall under Type-1 i.e. foreign compiled files. As seen from https://www.notion.so/jymcheong/1-Payload-Delivery-Code-Execution-Type-1-68580b4b44be4056a8c2ad9e442e0616, OpenEDR blocks the execution of Type 1 files by making all executable files read-only for users. The files need to be owned by Administrators/SYSTEM group in order to bypass OpenEDR's Type-1 protection mechanism. However, this would require the attacker to have elevated rights in the first place.
Expected result: CPL, DLL & EXE attacks will be unsuccessful and alerts will be raised.
Type 2 - HTA
On the other hand, HTA falls under Type-2 i.e. scripts. The HTA file will be detected by OpenEDR due to its unusual process sequence i.e. browser > mshta.exe lineage. As of now, OpenEDR does not block the execution of Type-2 scripts, meaning that it is possible for such scripts to evade protection but NOT detection. One solution for this is to pair OpenEDR with a Network Detection & Response Layer. Once the presence of C2 is confirmed, analysts can can then automate a process kill.
Expected result: Possible that execution of HTA is successful but alerts will be raised.
Real world example:
What is hooking?
Hooking is a technique commonly used by EDR tools to intercept a function call and redirect the flow of code execution to the EDR. This allows the EDR to monitor the execution flow that occurs in a process, gather information for behavior-based analytics and detect suspicious and malicious activity. This results in more accurate detection rates of post-initial compromise techniques (i.e. code execution) as well as post-exploitation techniques (i.e. privilege escalation, lateral movement or ransomware activity).
Resources:
Is Sysmon a 'hooker'?
According to https://github.com/trustedsec/SysmonCommunityGuide/blob/master/the-sysmon-driver.md, it states that the Sysmon driver will hook into Windows APIs and leverage Event Tracing for Windows (ETW) to capture the information on the actions it wants to monitor. To confirm whether Sysmon is a 'hooker', we will make use of a hook detection tool called HookDump.
Building HookDump
In order to build HookDump, you will first need to install Visual Studio 2019 and CMake.
Follow this link to install CMake in VS 2019: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=msvc-160#installation
Follow this link on how to build a CMake project: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=msvc-160#building-cmake-projects
If the build is successful, you should find HookDump.exe in the x64-Debug folder.
Running HookDump
This is the result after running HookDump:
The result from HookDump contradicts what was written in https://github.com/trustedsec/SysmonCommunityGuide/blob/master/the-sysmon-driver.md. The GitHub documentation states that Sysmon driver will hook into Windows APIs but yet 0 hooks were detected from HookDump. As documented in HookDump's GitHub, it is able to detect 4 types of hooks i.e. JMP, WOW, EAT & GPA. This led me to think that the reason why HookDump was unable to detect any hooks was because Sysmon was not using any of these 4 hooks.
You can refer to Jym's documentation for a more in-depth analysis on how the Sysmon driver works. In short, Sysmon relies on kernel callback functions to be notified of events. After the Sysmon driver is loaded at system startup, it registers kernel notifications callbacks. The registration of kernel notification callbacks involve a kernel function called NtTraceEvent, which is called by any user mode process that wants to report an event. This diagram visualizes the notification process i.e. ReportEventW → EtwEventWriteTransfer → NtTraceEvent:
Based on what was gathered, it proves that Sysmon does not make use of any of the hooks that HookDump can detect.
Jym's Comment
I explained in the comments.. in the context of OpenEDR type-1 protection bypass... so long u r SYSTEM process or u r DOMAIN admin (not local admin)... your file will be owned as SYSTEM or Administrators group respectively... so if such a file runs.. DFPM.exe will happily let it run. In other words, Type-3 (privilege escalation exploit) > Type 1 (because file written as SYSTEM or Administrators Group). Another possible path is.. within Domain Admin endpoint... Type 2 (UAC bypass port to let's say powershell or C# loaded by powershell) > Type 1 (eg. install DLL or even overwrite sethc.exe with cmd.exe, sticky key backdoor, once widely use to RDP in without credentials revealed popularly by RSA threat intel)Also because we have Protection vs Detection ⇒ 1,1 , 1,0, 0,1 & 0,0 combinations, which correspond to that legend in that table screenshot. The thing about the other COTS is, they are mostly cloud signature-base (they can say it's AI, ML, Deep Learning n all that blah, end of the day, it is still a form of signature). So if you have some new LOL techniques, it is MOST likely 0,0: didn't protect AND didn't detect.
Whereas with OpenEDR, even without cloud. So long profiling is done properly, then high chance we will at least be 0,1 because OpenEDR is based on First-Sighting. And that's quite a long shot for attacker to immediately get SYSTEM & drop a file. Usually, that happens after you reconn internally to know exactly which exploit to use to escalate, as you have experienced earlier. Anyway I really appreciate you took the effort to think through if those attacks were to be used against an endpoint with OpenEDR.
In your earlier track, you did not spend too much time profiling because you wanted to settle the goal items. But since we are into this topic. I just quickly go through. Your deployment scenario can be 1 of 2: Fresh network, you put in OpenEDR or any EDR. Already running network, then you put in some kind of EDR. Either way, when you first put in such sensors, the typical process is to turn it to DETECTION mode, for the sake of Threat Hunting & "tuning" (for those AI, ML or whatever analytics based products).
But when I design this, the main intention is still for NEW projects. From a business standpoint, why give the money to other vendors when we have our own locally developed product & that we can quality control & build up capability? So in such a new network, when admin, test engineers do their things, profiling is already learning what programs they would launch, what background processes that will ensue & so on. If it is really a close network, the profiling so even cover they do updates like Microsoft WSUS through what terminals n what not.
The challenge is when selling to existing networks which COULD already be DIRTY or compromised. The challenge the industry face today, is the way Threat Hunting is frame to form hypothesis, then find data to prove & disprove, is NOT an easy feat. Especially when you are totally new, so which creates this vicious cycle of NOT ENOUGH TALENTS problem. So all that Code-Execution mental-model, 3-Tenets n so on, is to help address this lack. Such that even yourself, a year 1 intern, can get up to speed quickly & I have proven it. And I will prove it again with another incoming intern.
Based on https://zeroperil.co.uk/hookdump/, I gathered that HookDump works on the approach of looking beyond NTDLL & also any DLLs that may be loaded eg. by Explorer.exe. Whereas in the high-level write up at https://github.com/trustedsec/SysmonCommunityGuide/blob/master/the-sysmon-driver.md, Sysmon is not really based on such a mechanism like most EDR to redirect certain monitored APIs to their EDR dll or system-services. So if you further read https://www.ired.team/offensive-security/defense-evasion/bypassing-cylance-and-other-avs-edrs-by-unhooking-windows-apis & also follow certain folks on twitter, there's actually a Github repo that documents which EDR is hooking which Windows API, so for the purpose of re-tooling (eg. red-teaming or even if you are the bad guy/gal) to use certain APIs that are not monitored to achieve similar or same outcome (eg. deliver shellcodes).
From the Sysmon driver description, which is rather high-level, I think the key aspect to note is:
And then you need to refer back to the Sysmon configuration schema & re-look at this again... for instance, CreateRemoteThread monitoring... it should be related to the mechanism of registering kernel notifications (even others event type like: networkConnect, Registry write, basically what the configuration Schema can include or exclude, the driver has to register some kind of kernel notification) , because the subsequent layers are related to file activities (all volumes), caching of events until event collection & filtering service starts, then into Windows Event logging sub-system. And if I understand it correctly, this kernel notification approach is not like some JMP detour as with COTS EDR, such that it can be bypass within user-land.
Or another way to say it, HookDump is not really digging into the registration of Kernel Notification Callbacks, but looking more for JMP (& the 3 other types of hooks as you mentioned) & also examining DLL entry points (a form of delta analysis in real-time):
...achieved by loading each DLL examined twice, once using LoadLibrary and secondly by reading from disk into a buffer. Exported functions are resolved in both loaded copies, several instructions are disassembled from both copies and then the instructions are compared. Using this method HookDump can detect hooks in the first second or third instruction of a function... quote from https://zeroperil.co.uk/hookdump/
Another perspective is, HookDump is run much later than Sysmon.. which (registration of Kernel Notification Callbacks) already started during boot time. Some of these EDR hooks are done is real-time. By saying this, I am also implying that Kernel Notification callbacks are not like what COTS EDR do (eg. JMP detour based) & is something else altogether. I could be wrong, so if you can find more info to prove/disprove, that would be good.
So what is/are the key points about this exercise?
- We know that COTS EDR can be bypass due to the way they are designed, the question becomes how prevalent & the level of difficulty (the attack factor, eg. need to escalate privilege? if no need, then it is quite problematic right?)
- Win API is a huge surface areas, EDRs are not hooking everything, there are "blind spots" functions which for instance malware can use to deliver shell-codes or write into memory of another target process
- Beyond Unmanaged APIs , there's also Managed (.NET) approach to call unmanaged "blind spots" (APIs that are not monitored)
- When evading, what is the initial Code-Execution method(s)? Relate to your earlier track of spoofing BOTH lineage & commandline.
More Resources
- https://github.com/Mr-Un1k0d3r/EDRs - that product hooking enumeration that I shared in the earlier para
- This is not to say Kernel Notification Callbacks is "superior", but it takes other methods to circumvent: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7338165/ - the exact details are documented under the section: Notification Routines
- https://blog.dylan.codes/evading-sysmon-and-windows-event-logging/ ← this digs really deep into how Sysmon gets it's notifications, but even if we don't fully understand all that blah... which is ok since neither can I. What we can see however, is that it is little to do with memory JMPs n what not. It rests upon the interaction between Kernel-Mode NtTraceEvent → EtwEventWriteTransfer (Sysmon side). And if you really go read through the entire "silencing" details, you will notice author used a EXE. So means if attacker is going to do that with OpenEDR installed, dead-on-disk-write. So, the entire attack have to be delivered without PEs & not tripping new Sequence & CommandLine sightings & IN PRIVILEGED ADMIN context.
What if memory is scrambled in a way...
Such that it like a trap to be tripped by some of these techniques that tries to tamper with process memory? https://www.morphisec.com/products/ is based on this principle of Moving Target Defense. Have a look at their stuff (high-level marketing). If you are curious, another approach is to find out the patents held by a company: https://patents.justia.com/assignee/morphisec-information-security-2014-ltd