Hiding process creation and cmd line with a long com…

March 29, 2020 in Anti-Forensics, Compromise Detection, EDR

How long is the command line buffer?

Depends on a program…

How much of command line do Sysmon, 4688 events log?

A finite amount.

‘Depends’ minus ‘finite’ == opportunity.

Re-visiting my old Sysmon demo where I’ve shown how to hide long command lines I thought that it would be interesting to check a different idea:

  • Write a program A that launches program B
  • Program A passes a very long command line to program B
  • Program B retrieves the command line and prints out last 5 characters only

The idea was to check if we can use the end of that long buffer as a covert channel for two processes to exchange some data (lame IPC)…

After testing it with 4688 and Sysmon enabled I spotted two things:

  • 4688 completely missed the process B creation
  • Sysmon log truncated the last bits of the command line (these 5 characters!!!) with ellipsis.

The pic below shows how 4688 log looks like:

  • We can see the invocation of the program A (first event 4688), followed by conhost.exe and then Program B is not logged at all.
  • Then we see program termination – Program A, Program B, and conhost.exe.

Sysmon logged a long command line, but the last bits are truncated and replaced by the ellipsis:

This is the invocation of ProgramB that I used (via CreateProcess):

 buffer dw 'p','r','o','g','r','a','m','B',' '
 dw 32698 dup(0FABEh)
 dw 'h','e','l','l','o'
 dw 0

and this is what ProgramB shows:

ShimBad the Sailor, Part 2

March 20, 2020 in Anti-Forensics, Reversing, Sandboxing

This part is more about archaeology than anything else.

The built-in SHIM database includes a number of test shims, which I will cover below.

On Windows XP, you will find these two:

So, if you happen to name your executable one of these:

  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismTestApp.exe

you can immediately see their effect after you try to run them on XP:

WindowsXPAppsHelpMechanismBlockedTestApp.exe

WindowsXPAppsHelpMechanismTestApp.exe

On Win7 we got a few more:

  • AppsHelpMechanismTestAppBadMsg.exe
  • AppsHelpMechanismTestAppBadMsgBlocked.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismTestApp.exe

The first one runs with no issues.

The second one is blocked without any indication.

The visible messages are as follows:

WindowsXPAppsHelpMechanismBlockedTestApp.exe

WindowsXPAppsHelpMechanismTestApp.exe

Finally, on Win10 it goes as follows:

  • AppsHelpMechanismTestAppBadMsg.exe
  • AppsHelpMechanismTestAppBadMsgBlocked.exe
  • BlockedTestApp_AMD64.exe
  • BlockedTestApp_AMD64_ANY.exe
  • BlockedTestApp_WOW64.exe
  • BlockedTestApp_X86_AMD64.exe
  • BlockedTestApp_X86_ANY.exe
  • BlockedTestApp_X86_WOW.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp2.exe
  • WindowsXPAppsHelpMechanismBlockedTestAppSpecific.exe

and visible outputs are:

AppsHelpMechanismTestAppBadMsgBlocked.exe /
BlockedTestApp_WOW64.exe /
BlockedTestApp_X86_AMD64.exe /
BlockedTestApp_X86_ANY.exe /
BlockedTestApp_X86_WOW.exe /
WindowsXPAppsHelpMechanismBlockedTestApp.exe /
WindowsXPAppsHelpMechanismBlockedTestApp2.exe /
WindowsXPAppsHelpMechanismBlockedTestAppSpecific.exe

Okay. That’s it.

Hmm not really… digging through internals of SDB on Windows 10 one more time I gathered the following (and hopefully complete) list of all the the test suite items:

  • AppsHelpMechanismTestAppBadMsg.exe
  • AppsHelpMechanismTestAppBadMsgBlocked.exe
  • BlockedTestApp_AMD64.exe
  • BlockedTestApp_AMD64_ANY.exe
  • BlockedTestApp_WOW64.exe
  • BlockedTestApp_X86_AMD64.exe
  • BlockedTestApp_X86_ANY.exe
  • BlockedTestApp_X86_WOW.exe
  • WICAMockAppReinstallUpgrade.exe
  • WICAMockAppReinstallUpgrade2.exe
  • WICAMockAppReinstallUpgrade3.exe
  • WICAMockAppReinstallUpgradeInfo.exe
  • WICAMockAppReinstallUpgradeWarn.exe
  • WICAMockAppReinstallUpgradeWarnBackup.exe
  • WindowsTH_BlockedSetupTestApp.exe
  • WindowsTH_TestApp_HardBlock_FWLink.exe
  • WindowsTH_TestApp_HardBlock_KBArticle.exe
  • WindowsTH_TestApp_HardBlock_NoInfo.exe
  • WindowsTH_TestApp_HardBlock_StoreId.exe
  • WindowsTH_TestApp_HardBlock_Wildcard1.exe
  • WindowsTH_TestApp_HardBlock_Wildcard2.exe
  • WindowsTH_TestApp_SoftBlock_FWLink.exe
  • WindowsTH_TestApp_SoftBlock_KBArticle.exe
  • WindowsTH_TestApp_SoftBlock_NoInfo.exe
  • WindowsTH_TestApp_SoftBlock_StoreId.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp.exe
  • WindowsXPAppsHelpMechanismBlockedTestApp2.exe
  • WindowsXPAppsHelpMechanismBlockedTestAppSpecific.exe
  • WindowsXPAppsHelpMechanismTestApp.exe
  • WindowsXPAppsHelpMechanismTestApp2.exe
  • WindowsXPAppsHelpMechanismTestAppSpecific.exe

So, how could you use it for malicious purposes? I dunno… One thought I have is about emulators. If you created a child process using one of these names (creation of such process should fail by SHIM design), could you use the successful exitcode from that process to detect an emulator?