You are browsing the archive for Malware Analysis.

logman & API Trace & lame anti-tracing trick :)

July 13, 2018 in Archaeology, Malware Analysis, Undocumented Windows Internals

As I explained in my older post I was playing around with an obscure logman functionality that could be used for API Tracing.

Using these two commands:

logman create api foo -f bincirc 
-exe c:\windows\notepad.exe
-o c:\test\notepad.etl
logman start foo

one can start tracing API calls inside the Notepad. The resulting .etl file can be then parsed with ETL Parser – a really cool tool from @HECFBlog‘s @nicoleibrahim.

When I came across it I thought API Tracing supported natively by OS is a cool and promising feature. So I thought at first… then I started digging deeper. In particular, I was curious how the functionality was implemented and why it didn’t work on Windows 10. After some poking around I think I found the answers.

The functionality is implemented via Application patching using these SDB databases:

  • c:\WINDOWS\AppPatch\sysmain.sdb – 32-bit Win7
  • c:\WINDOWS\AppPatch\AppPatch64\sysmain.sdb – 64-bit Win 7, at least in theory

When used (the actual mechanism of loading the patch is not known to me at the moment), the system loads the following files into a traced application’s process:

  • c:\WINDOWS\AppPatch\apihex86.dll (win7 32)
  • c:\WINDOWS\AppPatch\AppPatch64\apihex64.dll (win7 64), at least in theory

Example from Windows 7 32-bit:

You will find a couple of other libs loaded inside the process as well.

  • amxread.dll – API Tracing Manifest Read Library – possibly mapping APIs to their description (?) – have not spent too much time on it
  • apilogen.dll – API Tracing Log Engine – it is responsible for the actual trace writes; anyone who has too much time on their hand could try to reverse it and improve the API Trace parser, but it’s probably not worth it

With Windows 64-bit I couldn’t make it work despite ensuring all the commands were run from 64-bit processes; so… the ‘at least in theory’ bits are referring to this problem. In any case, it’s probably an obscure mechanism that is no longer supported; this leads us to…

Question #2

Windows 10 doesn’t seem to support it. I couldn’t make it work either + I don’t see the aforementioned DLLs in any of the Windows subfolders. Well, there you go. A cool functionality that never stood a chance…¬† oh well…

Last, but not least – here’s your promised anti-* trick:

  • check if your program is loading any of these listed DLLs and abort if any is found. I have added these to the list of naughty libraries even I know the usefulness is close to nil. Still, what’s documented is better understood.

And one more bit:

When the command to create API trace is called, the system adds this Reghitry key:

  • HKLM\SOFTWARE\Microsoft\Windows NT\


  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\


  • HKLM\SOFTWARE\Microsoft\Windows NT\

It survives the reboot, but the trace needs to be restarted.

Sysmon doing lines, part 4

July 7, 2018 in Anti-*, Anti-Forensics, EDR, Forensic Analysis, Incident Response, Malware Analysis

Two days ago Mark released a new version of sysmon – version 8.0. It adds new features and addresses the issue I highlighted in my previous post.

This post is not about new version of sysmon though.

It’s more about its inner workings that I looked at a while ago.

Sysmon has two primary components – sysmon driver and sysmon service process (we will skip the architectural differences between sysmon’s x86 vs. x64 versions). The first one (driver) intercepts the events, the second (service process) writes them to the Event Log in a loop, using the DeviceIoControl to talk to the driver.

If you ever patched binary in memory or on disk, you know where it is going…

The core functionality that actually logs the stuff to the Windows Event Logs is called from the inside of the sysmon.exe service process. It’s nothing unusual, but obviously it’s also a potential weakness.

Since it’s a process – it can be patched. I tried it on a file level, and the results of a single byte patch are shown below – not a single event is being logged:

Assuming the attacker detects sysmon, and can acquire the required rights to modify it – patching in memory or on disk is pretty trivial and can basically disable the functionality of the tool…

Obviously, this applies to _any_ tool and any process or component using ReportEvent or EventWrite APIs, so want to reiterate how the availability of tools bias security researchers… Sysmon is used here more as a scapegoat to demonstrate the old-school rootkit technique than a targeted crusade against this fantastic tool.

How to fix it?

Perhaps sysmon could do some sanity checks of its integrity on a driver level? – It’s much harder to modify the driver and load its patched version than an .exe (especially on 64-bit Windows). Perhaps driver could also do occasional checks if the number of Events written to Event Logs is as expected/increasing? And if the sysmon is a dependency, any admin or EDR tool using it should probably verify the integrity of the file prior to launching it? Including automation? I believe there is no generic solution here at the moment, but basic self-checks could simply rely on verifying the signatures of the file (for file patch). For in-memory patches, this is much harder as you need a dedicated code that compares images on disk vs. images¬† in-memory. You may be surprised, but some EDR solutions actually attempt to do that – it’s often much better than then ‘see-it-all’ approach that generates lots of noise.

Going back to rootkits – I used this term on purpose. Applying a single-byte patch will give you zero logging. It’s silly and easily detectable. A more complex patch could simply rootkit the bad guys activities out of the event log (just need to hook either the sysmon itself, or Event reporting APIs). As usual… whoever gets there first… wins.