You are browsing the archive for Compromise Detection.

Beyond good ol’ Run key, Part 15

August 4, 2014 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis

Today I am going to show you yet another debugging mechanism that allows to load a couple of phantom DLLs.

This time the culprit is DirectX.

The DirectX is pretty much a standard for programming anything that is multimedia-related on Windows. Since this includes games, animations, demos, as well as video players, picture viewers, etc. the phantom DLLs (they are debug DLLs in this case) can be easily made persistent because they will be loaded anytime one of such DirectX-aware applications starts.

Dropping one (or both) of these DLLs:

  • d3d8d.dll
  • d3d9d.dll

in one of the directories covered by the PATH variable and adding the following Registry Entry

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D]
@=""
"LoadDebugRuntime"=dword:00000001

will ensure that these DLLs will be loaded anytime a Direct X (its component called Direct 3D) is being used by some application. They are loaded by respective Direct X versions (8 or 9).

To test on XP (DirectX version 8 still is being used by dxdiag):

  • Add the registry entry
  • Drop test d3d8d.dll and d3d9d.dll into e.g. c:\windows\system32 directory
  • Run dxdiag
  • Go to Display tab
  • Click Test Direct 3D
  • You should see that d3d9d.dll is loaded when dxdiag starts and d3d8d.dll loads when you test Direct 3D feature on the Display tab

To test on Win 7 (DirectX version 8 doesn’t seem to be used by dxdiag, but DLLs are present and applications loading Direct X 8 libraries will _still_ load the DLLs):

  • Add the registry entry
  • Drop test d3d9d.dll into e.g. c:\windows\system32 directory
  • Run dxdiag
  • You should see that d3d9d.dll is loaded when dxdiag starts

In other words, it should work on all OSes that have the Direct X 8 or 9 installed.

You may be wondering if the same trick works for newer versions of DirectX.

It does.

The naming convention stays the same (e.g. d3d10d.dll, d3d11d.dll), but the major change is that:

  • The loading is not system-wide (or, more specifically DirectX-ecosystem wide), but application specific, hence a different registry entry is being used to load these DLLs
    • e.g. for dxdiag it would be
      • HKEY_CURRENT_USER\Software\
         Microsoft\Direct3D\dxdiag\
         D3D10LoadDebugRuntime=1
  • The DLLs (e.g. d3d10d.dll) are loaded only under very specific circumstances (only a couple of Direct X functions related to shaders load the debug DLLs) so chance for it to be a successful persistent mechanism are much lower
    • I guess the DLLs are used to test performance of the graphic primitives, but I have no programming experience with Direct X so can only speculate here

Beyond good ol’ Run key, Part 14

July 8, 2014 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

I have mentioned in my older posts that tracing, logging, debugging and various plugins, extensions and internal performance testing and development tools can be used and abused as a persistence mechanism; today’s topic is yet another list of phantom DLLs – this time courtesy of Windows Problem Reporting.

When applications crash on newer versions of Windows the WerFault.exe program is executed (subject to system’s settings); when launched at some stage it will try to locate and load the following files:

  • dbghelp.dll
  • ext.dll
  • exts.dll
  • ntsdexts.dll
  • uext.dll
  • wow64log.dll

The last one on the list may look familiar, I mentioned it in the part 5.

These DLLs are various debugger extensions that WerFault tries ‘to talk to’ when the crash occurs; the paths that WerFault is walking through is according to the Extension DLL search path – I believe this path is hard coded inside WerFault and can’t be changed (that could be yet another way to fool WerFault to look for the DLLs in other directories), but can be changed if the extensions are loaded from under WinDbg or other compatible with them debugger.

The searching activity can be easily observed using a Process Monitor and on my test system Windows 8.1 it is walking through a couple of C:\Windows\ sub-directories; the list below is a combined list from both 32- and 64-bit versions:

  • C:\Windows\ext.dll
  • C:\Windows\exts.dll
  • C:\Windows\ntsdexts.dll
  • C:\Windows\System32\ext.dll
  • C:\Windows\System32\exts.dll
  • C:\Windows\System32\ntsdexts.dll
  • C:\Windows\system32\pri\dbghelp.dll
  • C:\Windows\system32\pri\ext.dll
  • C:\Windows\system32\pri\exts.dll
  • C:\Windows\system32\pri\ntsdexts.dll
  • C:\Windows\system32\pri\uext.dll
  • C:\Windows\System32\uext.dll
  • C:\Windows\System32\wbem\ext.dll
  • C:\Windows\System32\wbem\exts.dll
  • C:\Windows\System32\wbem\ntsdexts.dll
  • C:\Windows\System32\wbem\uext.dll
  • C:\Windows\System32\WindowsPowerShell\v1.0\ext.dll
  • C:\Windows\System32\WindowsPowerShell\v1.0\exts.dll
  • C:\Windows\System32\WindowsPowerShell\v1.0\ntsdexts.dll
  • C:\Windows\System32\WindowsPowerShell\v1.0\uext.dll
  • C:\Windows\system32\winext\arcade\dbghelp.dll
  • C:\Windows\system32\winext\arcade\ext.dll
  • C:\Windows\system32\winext\arcade\exts.dll
  • C:\Windows\system32\winext\arcade\ntsdexts.dll
  • C:\Windows\system32\winext\arcade\uext.dll
  • C:\Windows\system32\winext\dbghelp.dll
  • C:\Windows\system32\winext\ext.dll
  • C:\Windows\system32\winext\exts.dll
  • C:\Windows\system32\winext\ntsdexts.dll
  • C:\Windows\system32\winext\uext.dll
  • C:\Windows\system32\WINXP\dbghelp.dll
  • C:\Windows\system32\WINXP\ext.dll
  • C:\Windows\system32\WINXP\exts.dll
  • C:\Windows\system32\WINXP\ntsdexts.dll
  • C:\Windows\system32\WINXP\uext.dll
  • C:\Windows\System32\wow64log.dll
  • C:\Windows\SysWOW64\ext.dll
  • C:\Windows\SysWOW64\exts.dll
  • C:\Windows\SysWOW64\ntsdexts.dll
  • C:\Windows\SysWOW64\pri\dbghelp.dll
  • C:\Windows\SysWOW64\pri\ext.dll
  • C:\Windows\SysWOW64\pri\exts.dll
  • C:\Windows\SysWOW64\pri\ntsdexts.dll
  • C:\Windows\SysWOW64\pri\uext.dll
  • C:\Windows\SysWOW64\uext.dll
  • C:\Windows\SysWOW64\wbem\ext.dll
  • C:\Windows\SysWOW64\wbem\exts.dll
  • C:\Windows\SysWOW64\wbem\ntsdexts.dll
  • C:\Windows\SysWOW64\wbem\uext.dll
  • C:\Windows\SysWOW64\WindowsPowerShell\v1.0\ext.dll
  • C:\Windows\SysWOW64\WindowsPowerShell\v1.0\exts.dll
  • C:\Windows\SysWOW64\WindowsPowerShell\v1.0\ntsdexts.dll
  • C:\Windows\SysWOW64\WindowsPowerShell\v1.0\uext.dll
  • C:\Windows\SysWOW64\winext\arcade\dbghelp.dll
  • C:\Windows\SysWOW64\winext\arcade\ext.dll
  • C:\Windows\SysWOW64\winext\arcade\exts.dll
  • C:\Windows\SysWOW64\winext\arcade\ntsdexts.dll
  • C:\Windows\SysWOW64\winext\arcade\uext.dll
  • C:\Windows\SysWOW64\winext\dbghelp.dll
  • C:\Windows\SysWOW64\winext\ext.dll
  • C:\Windows\SysWOW64\winext\exts.dll
  • C:\Windows\SysWOW64\winext\ntsdexts.dll
  • C:\Windows\SysWOW64\winext\uext.dll
  • C:\Windows\SysWOW64\WINXP\dbghelp.dll
  • C:\Windows\SysWOW64\WINXP\ext.dll
  • C:\Windows\SysWOW64\WINXP\exts.dll
  • C:\Windows\SysWOW64\WINXP\ntsdexts.dll
  • C:\Windows\SysWOW64\WINXP\uext.dll
  • C:\Windows\uext.dll

Writing to the Windows directory is more difficult nowadays than it was in the past, but with a growing number of tricks used to escalate privileges one should not blindly assume that these files are not going to be there, because of the directory ACLs.

To test, drop a DLL into one of these locations and crash some app – WerFault will do the rest :-)