WEBVTT

00:00:00.800 --> 00:00:05.770
ETW is a technology provided by Microsoft that can be used to

00:00:05.770 --> 00:00:09.350
consume events occurring on a system in real time.

00:00:09.740 --> 00:00:13.500
Microsoft has numerous providers, which we can consume events from.

00:00:13.500 --> 00:00:16.770
In the context of antivirus and EDR software,

00:00:16.770 --> 00:00:21.650
the Microsoft Windows Threat Intelligence provider is particularly useful.

00:00:22.040 --> 00:00:26.020
The types of events which are logged by this ETW provider

00:00:26.030 --> 00:00:28.760
relate to thread and memory operations.

00:00:30.140 --> 00:00:32.650
The logging occurs from inside the kernel,

00:00:32.720 --> 00:00:36.370
at least for the Microsoft Windows Threat Intelligence provider,

00:00:36.440 --> 00:00:41.250
which makes it harder to bypass than the user‑mode API monitoring constructs,

00:00:41.250 --> 00:00:43.060
which we covered previously.

00:00:44.240 --> 00:00:48.860
Let's take a closer look at the Microsoft Threat Intelligence ETW provider.

00:00:49.340 --> 00:00:51.670
I have already started the shell code runner,

00:00:51.680 --> 00:00:55.080
which we wrote previously, and it has already been initialized.

00:00:55.080 --> 00:00:58.930
In order to consume the events provided by the Microsoft

00:00:58.930 --> 00:01:03.460
Windows Threat Intelligence provider, I chose a tool called sealighter,

00:01:03.630 --> 00:01:05.850
which is freely available on GitHub.

00:01:06.440 --> 00:01:10.230
I started the tracing session just before running our shell code runner.

00:01:10.510 --> 00:01:14.660
If we take a look at the events which were logged during the tracing session,

00:01:15.040 --> 00:01:17.990
we can find that an event which seems to relate to

00:01:17.990 --> 00:01:20.050
memory allocations was triggered.

00:01:20.440 --> 00:01:21.850
If we take a closer look,

00:01:21.860 --> 00:01:25.750
you will see that the BaseAddress of the memory allocation was logged,

00:01:25.750 --> 00:01:30.190
as well as the process_id and the ProtectionMask, which was used.

00:01:30.360 --> 00:01:32.300
You may recall that read, write,

00:01:32.300 --> 00:01:37.180
and execute memory permissions can be represented by value of hex 40,

00:01:37.290 --> 00:01:40.860
which corresponds to the decimal value 64.

00:01:41.340 --> 00:01:45.130
You may also recall that our shell code runner allocates a read,

00:01:45.130 --> 00:01:49.150
write, execute memory buffer to hold our stage's shell code.

00:01:49.460 --> 00:01:54.310
If we open Process Hacker, a tool which is also freely available on the internet,

00:01:54.470 --> 00:01:56.680
and we open our shell code runner process,

00:01:56.680 --> 00:02:00.730
we can go to the memory view and scroll down until we find

00:02:00.730 --> 00:02:04.950
the corresponding memory BaseAddress, which we saw in the ETW logs.

00:02:05.440 --> 00:02:08.360
If we double‑click, we can view the memory content

00:02:08.370 --> 00:02:11.020
at that address. And sure enough,

00:02:11.030 --> 00:02:14.050
if we check the last couple of bytes in this memory region,

00:02:14.540 --> 00:02:17.560
you will notice that this lines up perfectly with the shell

00:02:17.560 --> 00:02:19.870
code we placed in our shell code runner.

00:02:20.000 --> 00:02:23.810
This demonstrates how useful this log data can be to an antivirus

00:02:23.810 --> 00:02:26.510
solution, which could easily trigger in memory scans for

00:02:26.510 --> 00:02:29.920
signatures, such as precomputed ROT13 hashes.

00:02:30.340 --> 00:02:33.740
It could also use all this data for heuristic analysis.

00:02:34.020 --> 00:02:35.510
As explained previously,

00:02:35.620 --> 00:02:38.600
the logging occurs from within the kernel and is therefore

00:02:38.600 --> 00:02:42.200
more resilient to various tampering techniques we will cover

00:02:42.210 --> 00:02:46.360
when bypassing API monitoring, which typically occurs in user land.