ETW is a technology provided by Microsoft that can be used to
consume events occurring on a system in real time.
Microsoft has numerous providers, which we can consume events from.
In the context of antivirus and EDR software,
the Microsoft Windows Threat Intelligence provider is particularly useful.
The types of events which are logged by this ETW provider
relate to thread and memory operations.
The logging occurs from inside the kernel,
at least for the Microsoft Windows Threat Intelligence provider,
which makes it harder to bypass than the user‑mode API monitoring constructs,
which we covered previously.
Let's take a closer look at the Microsoft Threat Intelligence ETW provider.
I have already started the shell code runner,
which we wrote previously, and it has already been initialized.
In order to consume the events provided by the Microsoft
Windows Threat Intelligence provider, I chose a tool called sealighter,
which is freely available on GitHub.
I started the tracing session just before running our shell code runner.
If we take a look at the events which were logged during the tracing session,
we can find that an event which seems to relate to
memory allocations was triggered.
If we take a closer look,
you will see that the BaseAddress of the memory allocation was logged,
as well as the process_id and the ProtectionMask, which was used.
You may recall that read, write,
and execute memory permissions can be represented by value of hex 40,
which corresponds to the decimal value 64.
You may also recall that our shell code runner allocates a read,
write, execute memory buffer to hold our stage's shell code.
If we open Process Hacker, a tool which is also freely available on the internet,
and we open our shell code runner process,
we can go to the memory view and scroll down until we find
the corresponding memory BaseAddress, which we saw in the ETW logs.
If we double‑click, we can view the memory content
at that address. And sure enough,
if we check the last couple of bytes in this memory region,
you will notice that this lines up perfectly with the shell
code we placed in our shell code runner.
This demonstrates how useful this log data can be to an antivirus
solution, which could easily trigger in memory scans for
signatures, such as precomputed ROT13 hashes.
It could also use all this data for heuristic analysis.
As explained previously,
the logging occurs from within the kernel and is therefore
more resilient to various tampering techniques we will cover
when bypassing API monitoring, which typically occurs in user land.