Update
Coincidentally, @HECFBlog @nicoleibrahim released a tool ETL Parser that helps to at last extract raw buffers and as a result it produces a CSV file with data that can be analyzed row by row. This is the closest so far that I have seen for a tool to be able to help analyze the output of api trace log. Have a look at the screenshot:
Old Post
Almost everyone is excited about .etl files that are produced as a result of Event Tracing for Windows.
Almost, because not me.
This feature is so rich in … features. Except it’s only for MS internal consumption. At least, it seems to be the case in some very really interesting… well… cases…
…
It all started when I looked at the logman tool command line arguments; one that immediately caught my attention was this one:
logman create api
Aha… A basic API Monitor!
But not only that. It allows to run API Monitoring across different systems!!!
Oh… this could be a nice covert channel to transfer data between systems. Write one piece that constantly calls a monitored API and feeds it with the data to transfer, and then – on the other end – collect this data on the other system using logman tool. You could definitely implement it in a duplex set-up too.
Simple.
So I thought.
First, I immediately tested the ‘create api’ bit it and it worked like a charm:
logman create api foo -f bincirc -exe c:\windows\notepad.exe -o c:\test\notepad.etl logman start foo
Now you have to simply run Notepad.exe (c:\windows\notepad.exe) and the .etl log will be created&updated as long as notepad.exe runs; the example content of the binary .etl file is as follows:
You can clearly see the APIs being recorded when Notepad is running:
- RegisterClassW with the Unicode class ‘OleMainThreadWndClass’
- GetAppCompatFlags2
- IsProcessDPIAware
- GdiReleaseDC
- etc.
The only problem remaining:
– how to convert this binary blob into something more readable?
After googling around, I discovered that the tool basically embraces the api tracng functionality offered by the IApiTracingDataCollector interface. When you read into the docs of this interface you will soon realize that logman’s command line argument ‘-f’ that is supposed to determine the file type for the output file can be only… binary. So any attempts to specify TSV, or CSV will fail 🙁
Okay.
Since I couldn’t bite it from this end, I started looking at Windows Performance Analyzer (WPA) and other tracing and trace conversion tools.
No matter which one I used, I could only get a basic flow of the events, but w/o these interesting gore details of each API call:
It’s all nice and eye candy, but the problem is already visible:
– if you don’t know how to parse, you simply don’t.
As a last resort I tried ‘tracerpt’:
tracerpt <log> -o <output> -of CSV
.. and it provided a similar enigmatic output:
Some more googling around and now I know I need to get a .PDB file for the api trace provider, or some other schema files that will allow WPA to parse it properly…
Sigh…
The provider’s GUID is 7535aef9-4a3b-482b-91eb-25db0299995d.
It is nowhere to be found.
Eventually I gave up & I asked on Twitter.
Unfortunately, Alex Ionescu, and Zac Brown are both pessimistic 🙁 Still, I am grateful to them for chipping in and providing the useful feedback – if they can’t do it, I guess we explored all the ‘normal’ possibilities.
But then I am thinking… so… if it is an internal schema, then there is only one way out.
Brute-Force attack.
I may cover it in the next post.
From the blue team’s perspective, if you want to detect logman’s activity, in particular api tracing, you may be interested in this process tree:
The example command line arguments from my VM test run are as follows:
- C:\Windows\system32\svchost.exe -k netsvcs
- taskeng.exe {A7B77AA7-00E9-45C4-92C5-31C3868DB30D} S-1-5-18:NT AUTHORITY\System:Service:
- C:\Windows\system32\rundll32.exe C:\Windows\system32\pla.dll,PlaHost “foo” “0x934_0x91c_0x2a045dff88a”
- taskeng.exe {A7B77AA7-00E9-45C4-92C5-31C3868DB30D} S-1-5-18:NT AUTHORITY\System:Service:
One thing is also worth mentioning – many logman command line option talk about running some task when some event happens; at first I thought it may be a new persistence mechanism, until I realized the tasks names required by these commands are task names registered using a Task Scheduler. So… yet another fail on the documentation, as it is very cryptic and talks about these various traces in a very superficial way 🙁