Category Archives: Anti-Forensics

ShimBad the Sailor, Part 3

Posted on by

Windows 11 brings us a lot of new Shim-related goodies and it makes sense to cover at least some of them.

In the second part of this series I listed a number of process names that are treated in a special way by the existing shim database entries.

It turns out that the list of these process names has been extended by at least two:

  • SdbMergeTestEntry_Added_Exe_Item.exe
  • SdbMergeTestEntry_Added_Exe_Item_InboxApp.exe

In other words, when you run a program that is named like the two aforementioned entries, you will get these messages:

Additionally, Windows 11 binaries handling shims include references to a list of folders that may be of some interest:

  • %windir%\apppatch\AcPluginDlls\Plugin
  • %windir%\apppatch\AcPluginDlls\PluginWow
  • %windir%\apppatch\AcPluginDlls\PluginWowAMD64
  • %windir%\apppatch\AcPluginDlls\PluginWowARM
  • %windir%\apppatch\AcPluginDlls\PluginWowARM64
  • %windir%\apppatch\AcPluginDlls\PluginWowX86

The Windows 11 installations I saw so far include these test Ac plugins:

  • c:\WINDOWS\apppatch\AcPluginDlls\Plugin\AcPlugin_Test.dll
  • c:\WINDOWS\apppatch\AcPluginDlls\Plugin\AcPlugin_Test2.dll
  • c:\WINDOWS\apppatch\AcPluginDlls\PluginWowX86\AcPlugin_Test.dll
  • c:\WINDOWS\apppatch\AcPluginDlls\PluginWowX86\AcPlugin_Test2.dll

The code referencing these directories resides in a few system libraries:

  • apphelp.dll
  • pcasvc.dll
  • appraiser.dll

but I have not explored yet how they work. As of now, I assume this is a lesser-known Shim Database enhancement mechanism that could be potentially leveraged for persistence and stealth code injection…

String analysis for n00bs

Posted on by

I like to demo this little windows executable to everyone who thinks they are doing the reverse engineering bit right, by using available automated static and dynamic analysis tools, and trusting them blindly.

The sample is a PE32 that is 2560 bytes long. Running ‘strings’ over it produces these results:

!This program cannot be run in DOS mode.
Rich
.text
`.rdata
@.data
8/u
ExitProcess
GetCommandLineA
kernel32.dll
GetStdHandle
WriteFile
Hello World!

Running it from a CLI gives us the following text being printed out to the STDOUT:

Hello World!

One can say that both static and dynamic analysis give us the same output. Based on this info it’s kinda obvious to conclude that this small binary is a simple CLI program that prints out ‘Hello World!’ when executed.

Except, only code analysis can help us to determine that the program behaves differently if we pass a ‘/h’ argument to it.

In such case, the dynamic analysis will show that the following string is being printed out to the STDOUT:

Hello Baby!!

Static analysis was done right. Default dynamic analysis was done right. And code analysis was done right too. It’s just the automation that failed.

Just a reminder that we can’t blindly trust the automation, because it only sees the obvious. And command line arguments are not the only way to trigger execution of a different branch of code. It could be a guard rail of any sort: time of the day, locale of the OS, delayed payload, payload downloaded from a site that is not available atm, etc.

in the interest of full disclosure: I have not ‘analyzed’ this sample with any AI framework, so am still hopeful that at least some of them would see through this little mischief.