{"id":21101,"date":"2023-10-09T16:59:50","date_gmt":"2023-10-09T15:59:50","guid":{"rendered":"https:\/\/www.riskinsight-wavestone.com\/?p=21101"},"modified":"2023-10-09T17:00:17","modified_gmt":"2023-10-09T16:00:17","slug":"a-universal-edr-bypass-built-in-windows-10","status":"publish","type":"post","link":"https:\/\/www.riskinsight-wavestone.com\/en\/2023\/10\/a-universal-edr-bypass-built-in-windows-10\/","title":{"rendered":"A universal EDR bypass built in Windows 10"},"content":{"rendered":"\n

While studying internals of a mechanism used by all EDR software to get information about processes activities on Windows, we came across a way for malicious processes to disable the generation of some security events<\/strong> related to process interactions. This technique could be used to evade EDR software<\/strong> while performing malicious operations such as process memory dumping, code injection or process hollowing.<\/p>\n

A primer on EDR’s monitoring capacities<\/h2>\n

Usermode vs. kernelmode methods<\/h3>\n

On Windows, EDR software mainly use two categories of techniques to monitor the actions performed by the processes: user-space <\/em><\/strong>methods, like function hooking<\/strong><\/em>, which are targeting each individual process, and kernel-space <\/em><\/strong>features, which are relying on OS-provided functions<\/strong> to collect system-wide telemetry about processes activity.<\/p>\n

The first category<\/strong> can often technically be evaded by a malicious process<\/strong>, as long as it knows the exact techniques used by the EDR. Indeed, the monitoring code and the monitored code often run in the same “space”, the process’ memory,<\/strong> so it boils down to a game of cat-and-mouse between the malware and the EDR, given that each can interact or alter the code of the “opposing party”.<\/span><\/p>\n

For the second category<\/strong>, the monitoring code runs in the Windows kernel space<\/strong>, not directly accessible from any process<\/strong>, regardless of its privilege level. However, these monitoring capacities are provided by Windows itself<\/strong> to the installed security products, and all EDR software are forced to use them nearly identically to get telemetry about processes activity (how to detect malicious activity from said telemetry is obviously up to each EDR software).<\/p>\n

For more in-depth information about the subject, both types of mechanisms were notably described in our article in the 116th<\/sup> edition<\/strong> of MISC magazine ( FR (original)<\/a> or EN (translated)<\/a> ). Also, to better understand the stakes of what follows in the present article, we recommend the readers to look at our article about EDR monitoring bypasses<\/strong> in the 118th<\/sup> edition of MISC magazine ( FR (original)<\/a> or EN (translated)<\/a> ), as well as the README of our tool, EDRSandblast<\/a><\/strong>. <\/p>\n

Event Tracing for Windows – Threat Intelligence<\/h3>\n

Among the aforementioned mechanisms, Event Tracing for Windows – Threat Intelligence<\/em> (ETW-Ti for short in this article) allows the generation of events<\/strong> upon security-critical kernel operations<\/strong>, such as process creation, memory read\/write between processes, executable memory creation, etc. (see our article in MISC 116 for more details).<\/p>\n

The event feed produced by the mechanism is normally only “consumable” by security products, which need to be protected processes (PROTECTED_ANTIMALWARE_LIGHT<\/em><\/strong>), cryptographically signed as such by Microsoft.<\/p>\n

These security events’ creation is handled by the Windows kernel, and is implemented by simple calls to dedicated EtwTi<\/em>*<\/strong> functions, embedded inside each kernel function of interest. The following image shows the call to EtwTiLogReadWriteVm<\/strong> <\/em>inside the MiReadWriteVirtualMemory<\/strong> <\/em>function, the latter being responsible for memory reads and writes between processes.<\/p>\n

 <\/p>\n

\"A
EtwTiLogReadWriteVm<\/strong> <\/em>call inside MiReadWriteVirtualMemory<\/strong><\/em><\/figcaption><\/figure>\n

 <\/p>\n

Our findings<\/h2>\n

A convenient exception<\/h3>\n

Looking at the whole control flow graph of the function above, we see that the call to the ETW-Ti logging function is always performed in a successful call to MiReadWriteVirtualMemory<\/strong><\/em>, unless PsIsProcessLoggingEnabled<\/em> returns FALSE<\/em><\/strong>. <\/p>\n

This latter function, mentioned nowhere we could find in the Windows reverse-engineering literature, does the following (comments, variable names and types were reverse-engineered and\/or inferred from public debugging symbols<\/a>):<\/p>\n

\"decompiled
Reverse-engineered source code of PsIsProcessLoggingEnabled<\/strong><\/em><\/figcaption><\/figure>\n

As we can see, the function checks the state of a flag among EnableReadVmLogging<\/strong><\/em>, EnableWriteVmLogging<\/strong><\/em>, EnableThreadSuspendResumeLogging<\/strong> <\/em>and EnableProcessSuspendResumeLogging<\/strong><\/em>, indicating whether the currently performed action (among an inter-process memory read, memory write, thread suspension\/resuming or a process suspension\/resuming, respectively) should be effectively logged by ETW-Ti. These flags are located in various fields of the _EPROCESS<\/strong> <\/em>structure of the targeted process.<\/p>\n

Accessing logging flags<\/h3>\n

By cross-referencing the use of the aforementioned flags in the kernel, we found that NtQueryInformationProcess<\/strong> <\/em>and NtSetInformationProcess<\/strong> <\/em>were used to get or set the specific bits corresponding to these logging flags.<\/p>\n

While mostly undocumented, these functions have been scrutinized by Windows Internals reverse engineers (and malware developers) for a long time, since they handle the eponym system calls<\/strong> reachable from user space<\/strong>. The System Informer project<\/a> (formerly known as Process Hacker) harbors an impressive database of function prototypes, structures and enums related to Windows Internals, gathered through the years thanks to “a lot of reverse engineering and guessing”<\/em>. <\/p>\n

The prototype of the NtSetInformationProcess <\/strong><\/em>function is the following:<\/p>\n

\"Prototype
Prototype of NtSetInformationProcess<\/strong><\/em><\/figcaption><\/figure>\n

The function can be used for more than a hundred use cases, depending on the value of ProcessInformationClass<\/em>.<\/strong> The function is implemented using a huge switch-case<\/strong> statement, and the specific code touching the logging flags is located under the ProcessEnableReadWriteVmLogging<\/strong> <\/em>and ProcessEnableLogging<\/strong> <\/em>cases (undocumented constants named by System Informer’s developers).<\/p>\n

\"Reverse-engineered
Reverse-engineered source code of NtSetInformationProcess<\/strong><\/em><\/figcaption><\/figure>\n

The behavior of the code above can be reduced to the following points:<\/p>\n