ETW on Windows 11 - Initial thoughts
Windows 11 and ETW
This week I had planned to travel interstate to introduce my daughter to her grandma for the first time, but as Australia goes into lockdown, we’re staying home, which meant I had some time to check out the Windows 11 dev preview.
By most accounts, Windows 11 is mostly a UI refresh, with the changes to the kernel and underlying components not too different from what we’ve seen in previous major Windows 10 releases. Nonetheless, I thought it could be interesting to check out what new ETW Providers and events are coming along with the upgrade.
Jdu2600 has a great project to extract all manifest-based and mof-based ETW Providers and Events, outputting them to TSV files. I used this project to create a snapshot from the current latest version of Windows (19043.1081), then compare this to the Windows 11 preview version (22000.51).
I’ve blogged in the past about using git to compare windows updates. Using the same technique, here’s the commit on GitHub to visualise the changes: https://github.com/pathtofile/Windows10EtwEvents/commit/5e9d0d.
Observations
Below are some of my quick observations on the changes. Some of the changes were already present in Windows 10 Dev Previews that have now been rolled into Windows 11, and some may be “backported” to Windows 10 when the next update occurs.
TPM and SecureBoot Events
Windows 11 is introducing some new minimum hardware requirements. One of these is requiring a TPM 2.0 capable CPU. It’s not a surprise then that new events have been added to the TPM Provider, and that TPM-related fields have been added to Providers such as Microsoft-Windows-BitLocker-API and Microsoft-Windows-Kernel-Boot.
Microsoft-Windows-Kernel-Boot also has some new events that look related to SecureBoot/SystemGuard/System Management Mode(SMM).
New Threat-Intelligence Fields
These some new fields to the virtual memory events in the Microsoft-Windows-Threat-Intelligence Provider. These look to be logging details related to the Virtual Address Descriptors (VADs).
Using the Threat-Intelligence Provider requires an Anti-Malware Protected Process, which I’ve written previously about the various ways to achieve this.
KERNEL_MODE_RETURN_MISMATCH events
The Microsoft-Windows-Security-Mitigations Provider has been updated
with an event KERNEL_MITIGATION_TASK_CONTROL_PROTECTION_KERNEL_MODE_RETURN_MISMATCH. This seems to compliment the existing event KERNEL_MITIGATION_TASK_CONTROL_PROTECTION_USER_MODE_RETURN_MISMATCH, which may mean this event is related to Kernel Control Flow Guard(kCFG).
New Crash Dump Events
There are several new Providers and events related to Crash Dumps. Microsoft-Windows-Kernel-Dump has been created with events related to the crash dump policy being altered. It’s not unheard of for malware to disable crash dumps before attempting kernel injection or doing anything super dodgy, so these sounds like very useful events to have.
There has been a similar set of policy-altering related events added to Microsoft-Windows-Kernel-LiveDump.
A New ETW Provider Microsoft-Windows-WerKernel has been created, with two CreateReport events.
New Winsock-Sockets Provider
There is a new Provider related to socket creation: Microsoft-Windows-Winsock-Sockets. While there are other WinSock
providers already, this one has events around the POSIX-like socket interface, with events for SockSetOpt, SockBind, etc. I wonder if this
has anything to do with the newly-announced eBPF For Windows project.
Observing Changes
I had wanted to test the changes around Crash Dumps, however, I was unable to get any of the new policy-related or WERKernel events to log the event log,
nor to my own ETW Tracer Sealighter. As the Policy UI just changes some registry keys, with the actual change taking effect on reboot, the events might
only be observable if you have an ETW Tracer running very early in the Windows Boot cycle, such as an Early Launch Antimalware driver.
The Microsoft-Windows-Winsock-Sockets Provider was much easier to check. I first ran Sealighter using a basic config:
{
"session_properties": {
"session_name": "Sealighter-Trace",
"output_format": "stdout"
},
"user_traces": [
{
"trace_name": "sockets",
"provider_name": "Microsoft-Windows-Winsock-Sockets"
}
]
}
Then ran a simple PowerShell script to start a TCP listener:
$ep = new-object System.Net.IPEndPoint([ipaddress]"172.29.116.236",8888)
$l = new-object System.Net.Sockets.TcpListener $ep
$l.start()
Sure enough, we see several events, including this one for the socket binding:
{
"header": {
"activity_id": "{98292896-6D8A-0001-C52C-2A988A6DD701}",
"event_flags": 576,
"event_id": 12,
"event_name": "",
"event_opcode": 2,
"event_version": 0,
"process_id": 4288,
"provider_name": "Microsoft-Windows-Winsock-Sockets",
"task_name": "SockBind",
"thread_id": 7432,
"timestamp": "2021-06-30 08:48:19Z",
"trace_name": "sockets"
},
"properties": {
"Address": "020022B8AC1D74EC0000000000000000",
"AddressLength": 16,
"ErrorCode": "00000000",
"FailurePoint": "00000000",
"Socket": "0x42C"
},
"property_types": {
"Address": "BINARY",
"AddressLength": "UINT32",
"ErrorCode": "OTHER",
"FailurePoint": "OTHER",
"Socket": "POINTER"
}
}
Translating the Address bytes was easy enough to do in Python:
import binascii, struct, socket
text = "020022B8AC1D74EC0000000000000000"
data = binascii.unhexlify(text)
port = socket.ntohs(struct.unpack("<H", data[2:4])[0])
ip_nums = struct.unpack("<BBBB", data[4:8])
ip_addr = ".".join([str(x) for x in ip_nums])
print(f"Address {ip_addr}:{port}")
Which Prints out Address 172.29.116.236:8888, as expected. This event could be useful to detect the creation
of a malicious network listener, before a connection is actually made to it (which would trigger other events already in Windows 10).
Conclusion
The changes appear to be in line with ETW’s continual growth, and While nothing is incredibly different, there are still some interesting changes, such as the Crash Dump Policy events.