Time for the 5th part. Today it’s about the Phantom DLLs Hijacking (do not confuse it with ‘DLL Search Order Hijacking’ where order in which paths are searched for is abused).

Windows is a huge operating system and not all components are cleaned up every new release. Thanks to that, there is a lot of legacy code that due to its age and changes in the structure of the operating system no longer work, or are simply left alone – probably just an implementation of the good ol’ rule at work – if it doesn’t break, don’t touch it.

Many Windows applications residing in the system32 directory are not used on daily basis – some of them indeed look like legacy apps (you can still run syncapp.exe on your Windows XP copy to enjoy the Briefcase experience :)), and some of them may be used only in specific configurations (e.g. NT Backup). The mechanisms that some of these legitimate applications use often cater for different scenarios and environments and… thanks to that, they can be often exploited.

Toying around with system32 executables I came across a few legitimate applications that may work as a hidden persistence mechanism . The ‘features’ I am describing are not new, and are identical with the fxsst.dll trick mentioned in the 3rd part of the series and described by Mandiant in detail. The idea is simple – some programs attempt to load specifically named libraries that are some sort of extension, or plugins and in some cases debugging tools – and they can continue to run, even if these DLLs implementing this extra functionality are not present.

Here’s a list of pairs I came across (and I bet there is more; note, some of these may work on other OS versions as well – usually the same code is used across many consecutive OS versions):

ntbackup.exe and edbbcli.dll (Windows XP)

Ntbackup is a Backup Utility for Windows (available on XP, but not 7). When launched it starts a Backup or Restore Wizard.

The interesting thing is that when loaded, this .exe is also attempting to load a library called:

•  %windir%\system32\edbbcli.dll

Thus, dropping such named DLL and making ntbackup run every time Windows starts either by using Scheduled job or using any of the well-known Autorun mechanisms one can achieve quite a stealthy code execution.

ntbackup.exe and esebcli2.dll (Windows XP)

The situation is exactly the same here; anytime ntbackup launches, it attempts to load the esebcli2.dll DLL from the following location:

• %windir%\system32\esebcli2.dll

The legitimate mechanism of loading these two NT Backup DLLs is explained here.

mrt.exe and bcrypt.dll (Windows XP)

MRT is a Malicious Software Removal Tool. When launched, it attempts to load bcrypt.dll; thus, dropping it in the system32 directory on XP will lead to (somehow ironic) execution of the code:

• %windir%\system32\bcrypt.dll

The bcrypt.dll doesn’t exist on XP, but it does on Windows 7, so this trick will only work on older Windows.

sessmgr.exe and SalemHook.dll (Windows XP)

Yet another binary that can load a targeted DLL is a Remote Desktop Help Session Manager executable on Windows XP. Once launched, it tries to load the following DLL:

• %windir%\system32\SalemHook.dll

certreq.exe and msfte.dll (Windows 7)

Certreq is a tool that allows to work with certificates. When launched it attempts to load the following DLL:

• %windir%\system32\msfte.dll

certreq.exe and msTracer.dll (Windows 7)

Certreq seems to like non-existing DLLs as it also attempts to load the following DLL:

• %windir%\system32\msTracer.dll

FXSCOVER.exe and TPPrnUIENU.dll (Windows 7)

This tool is a Fax Cover Page Editor. When loaded, it attempts to load the following DLL

• %windir%\system32\spool\DRIVERS\W32X86\3\TPPrnUIENU.dll

The name of the DLL (TPPrnUIENU.dll) suggests that:

• It is a companion to %windir%\system32\spool\drivers\w32x86\3\TPPrnUI.DLL (there are plenty of %windir%\system32\spool\drivers\w32x86\3\TPPrnUI*.dll files, but not the TPPrnUIENU.dll)
• The ENU in the file name indicates it is a Satellite DLL used in localization and it’s providing data for the English language (the other TPPrnUI*.dll present on the system use other language identifiers e.g. TPPrnUIfra.dll, TPPrnUIita.dll)

In theory, these Satellite DLLs are resource-only DLLs, but the TPPrnUI.DLL is using a LoadLibraryW to load them –  a big mistake, since the LoadLibraryW calls DllMain of the loaded DLL (LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE is a better choice here). Hence, a code execution.

dxdiag.exe and DXGIDebug.dll (Windows 7)

dxdiag.exe is a DirectX Diagnostic tool. When executed, it attempts to load the following DLL (for debugging purposes as a part of DXGI framework):

• %windir%\system32\DXGIDebug.dll

msinfo32.exe and fveapi.dll (Windows 8.1)

The msinfo32.exe is a system information tool. When executed, it will try to load the following DLL:

• %windir%\system32\fveapi.dll

Interestingly, this DLL is present on Windows 7 and Windows 8, but not present on Windows 8.1 (in default installation). The DLLs description is Microsoft Vista BitLocker Drive Encryption API and it offers access to BitLocker API.

narrator.exe and MSTTSLocEnUS.DLL (Windows 8)

Last one on the list is Narrator.exe that attempts to load the following DLL:

• %windir%\system32\speech\engines\tts\MSTTSLocEnUS.DLL

Again, then file naming suggests localization gone wrong.

32-bit processes, Wow64.dll and Wow64Log.dll (Windows 7 64-bit)

This is not a process-specific autorun mechanism, but a system-wide way of introducing a DLL into all 32-bit processes running under control of WOW64 by dropping the following 64-bit DLL on the 64-bit Windows 7.

• %windir%\system32\Wow64Log.dll

This trick has been discovered and described in detail by Wallied Assar on his blog earlier this year.

While Wow64Log.dll appears to be made available with a purpose of being a legitimate logging feature, it can be abused as a persistent mechanism as well.

Last three articles about various startup/autostart methods covered a lot of different well- and less-known techniques for ‘staying alive’. Many of them are actively used by malware and ‘normal’ software; some are just ideas that are worth describing because… luck favors a prepared mind. If you haven’t read them previously, you can do so by visiting these links: Part 1, Part 2, Part 3.

In today’s post I will cover some more techniques including hijacking of various debuggers and some more obscure ways of ‘survival’. I think this is probably the lamest part of the series so far, because the techniques are old-school and amateurish, but luckily it is not the last one, so stay tuned for Part 5 🙂

Hijacking debuggers

The list of debuggers one can replace on the system is as follows:

• Standalone Debugger (32- and 64- bit)

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\AeDebug]
Debugger = PATH

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\
Windows NT\CurrentVersion\AeDebug]
Debugger = PATH

• .NET Debugger (32- and 64- bit)

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
DbgManagedDebugger = PATH 

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
DbgManagedDebugger = PATH

• Script Debugger

[HKEY_CLASSES_ROOT\CLSID\
{834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]
@=PATH

Registering itself as a Script Debugger
The Windows Script Debugger (WSD) is a standalone tool that one can use to actively debug their scripts (e.g. vbs). Once installed, a developer can run one of the following commands:

• cscript /x script.vbs

or

• wscript /x script.vbs

to debug the script.

The name of the executable that is used as a debugger is stored inside the following key

• [HKEY_CLASSES_ROOT\CLSID\
  {834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]

and on a system where the WSD is installed may look like this:

• [HKEY_CLASSES_ROOT\CLSID\
  {834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]
  @="C:\\Program Files\\Microsoft Script Debugger\\msscrdbg.exe"

One could replace the script debugger path to lead its own executable anytime the debugger is launched and this way making it kinda persistent on the system. Kinda, as the .exe will be executed only on rare occasion when the debugger is actually being installed (developer’s or power user’s machine).

Other issue is that the launching of the script debugger takes more steps than just looking up the value n the registry and launching the appropriate application.

When VBScript tries to find the debugger it talks to few COM components first (e.g. Process Debug Manager) so in order to make it work, one would need to also register these COM components (if you want to know more details, install WSD and see registry changes associated with the installation).

Hijacking Process Debug Manager

The alternative persistence mechanism could hijack one of these COM components that VBScript ‘talks to’ and replace its server path to point to a malicious file. The DLL does not even need to implement any COM functionality and it’s enough for it to be a simple, loadable library. The Process Debug Manager that I mentioned earlier could do the trick here. Its CLSID’s value on a system where WSD is installed is shown below:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\
{78A51822-51F4-11D0-8F20-00805F2CD064}\InprocServer32]
@="C:\\WINDOWS\\system32\\pdm.dll"

Pointing InprocServer32 to a malicious DLL would load anytime VBScript (or any other module) is ‘consulting’ ProcessDebugManager.

ServiceDll Hijack

Many entries under

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services]

can be hijacked by swapping their ServiceDll parameter to point to a malicious entry. e.g. the Remote Access Service registry entry

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
  Services\RemoteAccess\Parameters]

normally points to

• %SystemRoot%\System32\mprdim.dll

but it can be changed to point to a malicious component. There are many default services that could be hijacked this way.

Mapi32 Stub Library

Older versions of Outlook 2007 allowed to add extra functionality to Outlook by means of installing a custom version of mapi32.dll in the system directory as explained in this article.

The relevant Mapi32.dll Stub Registry Settings are provided in the Registry in the following location:

• [HKEY_LOCAL_MACHINE\Software\Clients\Mail::(default)]

  • DLLPath

    Full path to the Simple MAPI provider DLL.

  • DLLPathEx

    Full path to the MAPI provider DLL. Provider DLLs that support both Simple MAPI and MAPI must have both keys set.

Obviously, this mechanism is a perfect target for abuse.

Hijacking Client executables

The Registering Programs with Client Types article from Microsoft explains on ‘how to register a program in the Windows registry as one of the following client types: browser, email, media playback, instant messaging, or virtual machine for Java.’. Looking at the registry entries associated with these registration we can find the following key:

• [HKEY_LOCAL_MACHINE\Software\Clients\]

Many applications listed under this key can be hijacked e.g. Mail program contain keys that point to executables::

• [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Windows Mail\InstallInfo]

  • HideIconsCommand

  • ReinstallCommand

  • ShowIconsCommand

Windows 2000 Welcome

Installation of Windows 2000 always ends up with the “Getting Started with Windows 2000” window shown on the screen after the system restarts. User has an option to disable it, but the box is ticked ON by default.

The window shows up as a result of welcome.exe being executed from the following location:

• C:\WINNT\Welcome.exe

The flag that determines whether the welcome.exe is executed or not is stored in the following Registry location:

• [HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\
  tips\Show: 0x00000001]

Replacing welcome.exe and ensuring the value of Show is equal to 1 will make the C:\WINNT\Welcome.exe execute every time system starts.

Well, not quite.

If the file is replaced, it will be ‘magically’ restored from the following location:

• c:\WINNT\system32\dllcache\welcome.exe

So, the malware needs to be copied into 2 locations, and… the Windows File Protection needs to be disabled as well 🙂

Thanks for reading and see you in the Part 5.