Thread by @domchell

Spent some time refreshing my memory on ETW TI tonight. As a red teamer it's really important to get a good understanding of what the defenders/EDRs can see. Using the excellent Havoc as an example, let's have a peak...

Firstly, to capture the ETW TI telemetry, I used - a neat little project that logs the THREATINT tasks to the system event loggithub.com/pathtofile/Sea…

Peaking in the the Sealighter log, we can see we're now receiving ETW TI telemetry, like the example below which is Edge calling the MapView apis to allocate:

In keeping with the current detection trends, this is probably legit as ETW TI gives us deep visibility in to the call stack, which traces back to backed memory:

Having a look at our injected Havoc demon, there's various events, including the VirtualProtect calls originating from thread 1080:

Probing deeper, we can see the page permissions are being flipped from PAGE_EXECUTE_READ to PAGE_READWRITE (sleep obfuscation?) based on the LastProtectionMask and ProtectionMask values:

Peering in to the call stack for this virtualprotect call we spot it originates back to unbacked memory, through ntdll to kernel space (indirect syscall or ntapi?) noting the absence of the kernel32 frame:

Popping our demon on to sleep 0, we can confirm our assumptions of the suspicious unbacked TID 1080

TLDR ETW TI gives really deep visibility to what's going on - most of the time 😉. Consuming this telemetry let's you build rules to match on sequences of events in a time window, e.g. call stack analysis for unbacked vprotect repeatedly flipping RX/RW pages could be an indicator for sleep obfs as an example. Some great reading on the direction of travel here

And final thought... applying some good targeted rules on this kind of logic, you can probably detect ALMOST every c2 on the planet 😜