Beyond good ol’ Run key, Part 79

June 10, 2018 in Autostart (Persistence), Living off the land, LOLBins

This persistence post targets users of Total Commander (TC).

I love TC and have been using it for many years. Quite frankly… I really can’t imagine working on Windows w/o using this tool, and I really pity anyone who is using Windows Explorer either by choice or by force. The other good alternative to TC is FAR, but its far (unintended pun) less popular, and definitely not present in the corporate environment as much as TC…


Being so popular makes TC an obvious target and since it has such a rich functionality it’s very easy to abuse these features to stay on the system persistently.

There are many ways to do it… I doubt I can cover all of them, but let’s jot down some notes:

  • The system of plug-ins is an easy target, so I will skip its description as it’s boring (okay, you just drop a DLL into TC’s plug-in directory and ensure it’s registered to handle some filetypes, of viewer, etc.). These are officially supported plug-in types:
    • Packer Plug-ins
    • File-system Plug-ins
    • Lister Plug-ins
    • Content Plug-ins
    • (note that existing plugins can be swapped, or be a subject to side-loading issues, etc.)
  • Not many people know about it, but the TC accepts command line arguments, including:
    • /i=name.ini – a different location of wincmd.ini file; a changed .ini file may include some extras
    • /INSTALLDRIVERQ- installs ‘cglptnt’ service pointing to C:\WINDOWS\system32\DRIVERS\cglptnt.sys that is copied there by TC – this file could be swapped
  • The next one is one that I kinda like as an idea as it’s quite subtle
    • TC offers a really cool functionality that allows you to quickly ‘jump to the directory’ from the menu
    • The function is activated by the CTRL+D keyboard shortcut
    • The actual ‘jump’ is implemented via a ‘cd’ command, so every new directory added to the menu will have a Command set to ‘cd <directory’:
    • You can change this ‘cd’ command to e.g. c:\windows\system32\calc.exe
    • Next time someone attempts to change the directory to Windows, the calculator will be spawn:
    • The caveat is that the directory itself is not changed in such case – I guess malware could send that sequence of keys to TC to force the directory change or simply modify the entry back to its original content and user would be none the wiser – the command would work the second time they try; since it’s not a typical persistence (it only works when the menu is used), it could be used as a ‘backup’
  • The TC can handle some UAC kinda graciously
    • For example, if you want to enter c:\Windows\CSC directory, you will get this message box:
    • Hitting ‘As Administrator’ will engage Tcmadmin.exe program that is located in the TC program directory; swapping this program with your own will make TC launch your own program anytime it handles UAC business

There are probably many other ways… and as a side note, since TC includes a native client for (S)FTP, it can be used to download/upload stuff as well…

So, in a way, TC is an ultimate… LOLBIN.

There you have it… but want to emphasize one thing – this post is not to scaremonger  you – TC is awesome and consider purchasing it, and… keeping an eye on its config files…

Logman, the Windows volverine

June 9, 2018 in Malware Analysis, Undocumented Windows Internals


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.


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 🙁


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…


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”

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 🙁