John UhlmannAPI-To-ETW
A ghidra script to find all ETW write metadata for each API in a PE file, including any associated public symbols.
Why?
Many ETW events are extremely useful for cyber security, but are not (well) documented. :-(
For example, the Kernel-Audit-API-Calls provider sounds interesting, but all of the events are called task_xx.
Previously, this was a manual process. Now you can run this Ghidra script on ntoskrnl.exe and grep the results...
| Function | Provider Guid | EVENT_DESCRIPTOR Symbol | Id | Version | Channel | Level | Opcode | Task | Keyword |
|---|---|---|---|---|---|---|---|---|---|
| NtSetSystemInformation | e02a841c‑75a3‑4fa7‑afc8‑ae09cf9b7f23 | KERNEL_AUDIT_API_PSSETLOADIMAGENOTIFYROUTINE | 1 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtTerminateProcess | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_TERMINATEPROCESS | 2 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtCreateSymbolicLinkObject | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_CREATESYMBOLICLINKOBJECT | 3 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtSetContextThread | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_SETCONTEXTTHREAD | 4 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtOpenProcess | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_OPENPROCESS | 5 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtAlpcOpenSenderProcess | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_OPENPROCESS | 5 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtSetSystemInformation | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_OPENPROCESS | 5 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtOpenThread | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_OPENTHREAD | 6 | 0 | 0 | 4 | 0 | 0 | 0x0 |
| NtAlpcOpenSenderThread | e02a841c-75a3-4fa7-afc8-ae09cf9b7f23 | KERNEL_AUDIT_API_OPENTHREAD | 6 | 0 | 0 | 4 | 0 | 0 | 0x0 |
:TODO: events 7 & 8 are missing. But this grep was only on a run for syscalls (not all exports) - so missed the kernel APIs like IoRegister.
Sample Output
- syscalls in ntoskrnl.exe (maxEvents=10 maxCallDepth=7 maxExportCallDepth=1)
- a full dump of all ETW events is much, much longer
How good is it?
The quality of the output depends on the quality of the decompilation. With the help of public symbols, Ghidra is pretty good out of the box for Windows binaries. But if you're not getting the results you want, some manual reversing might help.
Sometimes you'll encounter a novel design pattern not supported by the script. For example, lsasrv.dll stores provider handles in a generic table using Adelson-Velsky/Landis (AVL) trees. So, in order to automatically extract the provider guids, the script needs to understand the GenericTableAvl APIs...
I'm still missing support for some event write edge cases, but I've tried to flag these in the script output.
How do I use it?
1 Import the file
TODO
- handle classic provider registration - especially WPP
- handle classic events - TraceEvent etc
References
Inspiration
- https://github.com/hunters-forge/API-To-Event
- How do I detect technique X in Windows?, DerbyCon 2019
- https://pathtofile.run/codereview/re/python/2020/01/11/ghidra.html
- https://blog.tofile.dev/2020/01/11/ghidra.html
- https://blog.xpnsec.com/analysing-rpc-with-ghidra-neo4j/