High Level Overview of EDR technologies

Process Creation

• EDRs look at parent child relationships to detect potential malicious activity, for example, should Word be spawning PowerShell? EDRs look at these relationships and find malicious activity based on this. They also may look at arguments, environment variables etc.

• This is exposed in the kernel via image loads and callbacks

• EDRs may subscribe to these events to get insight into this

• These callbacks and image loads include

• pic from: https://blog.redbluepurple.io/windows-security-research/kernel-tracing-injection-detection

PsSetCreateProcessNotifyRoutine()
PsSetCreatethreadNotifyRoutine()
PsSetLoadImageNotifyRoutine()

AMSI

• This is used to detect .NET malware like C# PowerShell, VBS, jscript etc.

• In these processes, there is going to be a language provider loaded into memory which converts the raw source code of the script to machine instructions for the process itself

• these providers send potentially dangerous code into the amsi.dll loaded in the process, amsi.dll will then send this data to providers, which decide if the code is malicious or not

• The default provider in windows is MsMpEng.exe, but EDRs have been implementing their own providers and such(via some COM RPC magic shit). They communicate via RPC

Event Logging

• Events that get reported to svchost.exe

• Let's take powershell.exe as an example

• Powershell.exe has a System.Management.Automation.dll which is the powershell .NET implementation

• When certain events in System.Management.Automation.dll

  happen, it will get reported with EventWriteTransfer(), which will get traced down to EtwEventWrite(), and then into NtTraceEvent() which is a kernel syscall

• Then, the kernel has the event information which it then sends to Eventlog Service which then spits out the logs back into the user

Userland Hooking

• Injects a dll which hooks certain "potentially malicious functions" to see their behavior and deduce if they are malicious or not

• For example, we can hook NtWriteVirtualMemory and scan the buffer passed to it at runtime

• Pic from: https://www.ired.team/offensive-security/defense-evasion/bypassing-cylance-and-other-avs-edrs-by-unhooking-windows-apis

Process Memory Scanning

• scanning process memory for malicious signatures.

• The scans can be triggered on specific events for example:

  • Scanning RWX regions

  • After a certain time period

  • After a process is created

  • etc.

• Note that this is very resource intensive, and periodic scanners can't do full memory scans in short intervals

EtwTi

• A way to have kernel level telemetry into common process injection APIs

• EtwTi is a kernel level instrumentation which does this

• APIs will trace down to the kernel, and go into a EtwTi function which goes to an ETW provider called Microsoft-Windows-Threat-Intelligence which then deduces if it is malicious or not

• EtwTi is only available to processes running with PPL-Antimalware

• for more info: https://blog.redbluepurple.io/windows-security-research/kernel-tracing-injection-detection

Misc

• EDRs can dump process memory, grab files, and in the worst case, isolate a host from a network for detection and forensics.

• Least frequency analysis, EDRs find the odd one out and investigate to see if its malware. For example, all users run edge, but one runs chrome, and the chrome instance spawns a unknown binary from temp, chances are is that this is malware(shit example).

• EDRs can integrate with VirusTotal, and have some detection logic from there