You are browsing the archive for Malware Analysis.

Sysmon doing lines, part 5

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

This is a lame, cute, not-only-sysmon evasion that is not really an evasion, but more a social engineering trick – still, it may fool some junior analysts…

As I mentioned in my older post, there are tones of URL Schemes available in Win10. When you look at them, you will most likely think that anyone using them will always use the ‘start’ command, or the ‘ShellExecute*’ APIs.

And that’s the opportunity.

If you write a launcher that leverages these built-in, very well known schemes e.g. ‘ms-settings:defaultapps’ to create a dummy ‘host’ file (e.g. ‘ms-settings’) with the ADS attached to it called according to the second part of the URL Scheme (e.g. ‘defaultapps’), you will be able to launch ‘ms-settings:defaultapps’  that is actually not a protocol, but a real PE file.

Let’s have a look at an example:

copy notepad.exe ms-settings
type <yourexe> > ms-settings:defaultapps

This will create a copy of a legitimate (and signed) notepad.exe called ‘ms-settings’ and will append the ADS ‘ms-settings:defaultapps’ that is acting as an actual payload.

All you have to do is to launch it not via ShellExec, but directly via CreateProcess, and if you place the .exe in a ‘strategically named’ folder you may end up with a sysmon log like this:

Now… show me a junior analyst that won’t conclude it’s just one of the safe URL Schemes… because…  the first result for ‘ms-settings:defaultapps’ in Google is this.

They may even test it on their systems – launching ‘ms-settings:defaultapps’ from a command line will bring this innocent window:

A simple launcher that you can use for test can be downloaded from here. It simply launches ‘ms-settings:defaultapps’ ADS in its current directory.

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.