You are browsing the archive for Sandboxing.

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?

Quick & Dirty Sysmon Replacement aka Process Hacker logging

March 14, 2020 in Malware Analysis, Prevention, Random ideas, Reversing, Sandboxing

Sysmon is great, no doubt. However… very often an overkill.

Yes, you’ve read this right. I say: who cares about registry writes, process access, driver or module loads, etc. ? What if we just want to log running processes?

Process Hacker comes to our rescue.

The recent versions of this tool include a very handy logging capability that is available not only from a GUI level (CTRL+L keyboard shortcut), but also helps to write stuff that is ‘happening’ directly to a log file – yes, as it happens.

I find it very useful as it helps to monitor unusual activity of the system w/o engaging the full-blown capabilities of Sysmon (performance!). And yes, I do know how weird it sounds… Sysmon cures everything…

How do we set our Process Hacker instance to deliver all this goodness?

We first run Process Hacker with our Admin creds. Then we open Hacker \ Options menu item:

Then choose one of the ‘Notification’ options and either leave it as it is (log everything) or we write down our own rules that can either include or exclude certain paths….

In the below example we include all the process names:

and then we exclude notepad*.exe:

We can include/exclude both processes and services. This is awesome. It’s simple, it’s working.

And if you are curious where the information about these is stored, look for a `ProcessHacker.exe.settings.xml`file that lists the following:

  <setting name="ProcessHacker.ExtendedNotifications.LogFileName">LOGFILEPATH</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ProcessList">PROCESSLIST</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ServiceList">SERVICELIST</setting>

where PROCESSLIST/SERVICELIST has a form of:

  • \e<pattern for exclusion
  • \i<pattern for exclusion

That’s it really… Nothing ground breaking, but a very handy tool for quick & dirty investigations. I find it most useful to detect ‘funny’ Windows 10 services that start ‘out of nowhere’. I then… usually kill them. One by one, you may eventually kill’em all…

Oh yeah.. it may help with malware analysis too 😉 but somehow.. the analysis techniques and priorities changed a lot over last few years…