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.

Possible Autostart/start mechanisms that are built-in ‘natively’ in Windows and also available by means of extra features offered by many applications go beyond typical path locations and registry keys highlighted by popular programs and scripts like Autoruns and SilentRunners. I have covered some of the non-standard persistence techniques in 2 older posts in the series here and here, but as usual – there is always more to write about.

In this post I will cover another batch of less known and possibly ‘obscure’ technique that could be potentially used for autostart/start purposes. I write ‘obscure’, because it is not a typical way of doing autostart, but let’s be honest – there is nothing really extraordinary about it – just a simple abuse of built-in features in both OS and applications.

Code-in-the-middle proxy

Long story short, it is a well known fact that many existing registry entries and files pointing to or containing code can be modified to introduce a code-in-the-middle proxy (DLL, EXE, etc.) that will be executed/loaded first instead of a legitimate entry. The original entries are preserved so that they can be transparently executed/loaded once malware is running. There are many existing examples of this technique already being used e.g. hijacks of Shell Open Command,  Image File Execution Options , etc., but it is important to remember that this technique can be extended literally to any registry key or file that is loaded either during autostart or often used by users.

Application Registration (App Paths) hijacking

Another proxy technique that could be used to hijack popular applications relies on registry entries stored under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

As per Microsoft:

The entries found under App Paths are used primarily for the following purposes:

• To map an application’s executable file name to that file’s fully qualified path.
• To pre-pend information to the PATH environment variable on a per-application, per-process basis.

A legitimate entry that can be found on many newer versions of Windows is shown below:

It is responsible for launching MS Paint program when someone tries to run it using a legacy ‘pbrush.exe’ name.

One could add a modification for e.g. calc.exe:

From now on, anytime someone tries to run calc.exe manually (e.g. via Start Menu/Run  window), Notepad will be launched. It may not be a main persistence mechanism, but could be used for re-infection purposes on systems that have been cleaned up, but not rebuilt.

You can test it (XP needed) by downloading this reg file , then applying it to your Registry and then launching Win+R and typing ‘calc’ or ‘calc.exe’ and hitting enter. Note: It doesn’t work from command line (a mistake in an older version of this post which I correct here).

Text Services (TSF)

Microsoft defines Text Services as:

Microsoft Windows Text Services Framework (TSF) is a system service available as a redistributable for Windows 2000. TSF provides a simple and scalable framework for the delivery of advanced text input and natural language technologies. TSF can be enabled in applications, or as a TSF text service. A TSF text service provides multilingual support and delivers text services such as keyboard processors, handwriting recognition, and speech recognition.

From a practical point of view, TSF offers ways to extend available input methods by allowing to install support for languages that are not natively supported by Windows. A good example of such extension is Ekaya – an extension for a Myanmar (Burmese) language.

In order for TSF to work on Windows XP, one has to enable the ‘Extended support of advanced text services to all programs’:

On Windows 7, it is enabled by default (but to install a TSF DLL one requires administrator privileges).

Examples on how to use TSF are provided in Microsoft SDK (look for ‘Samples\winui\Input\tsf\TextService’ directory). For the purpose of this article, I just picked up the simplest possible example i.e. a project from the ‘Samples\winui\Input\tsf\TextService\TextService-Step01’ subdirectory and updated it with a trivial cosmetic change – a call to OutputDebugString so that we can observe processes loading and unloading our test DLL.

BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID pvReserved)
{
  TCHAR szFileFullPath[256];
  TCHAR buf[300];
    switch (dwReason)
    {
        case DLL_PROCESS_ATTACH:

            g_hInst = hInstance;
            GetModuleFileName (NULL,szFileFullPath,256);
             _tcscpy (buf, TEXT("TSF DLL loaded: "));
             _tcscat (buf, szFileFullPath);
            OutputDebugString(buf);
            if (!InitializeCriticalSectionAndSpinCount(&g_cs, 0))
                return FALSE;

            break;

        case DLL_PROCESS_DETACH:

            GetModuleFileName (NULL,szFileFullPath,256);
             _tcscpy (buf, TEXT("TSF DLL unloaded: "));
             _tcscat (buf, szFileFullPath);
            OutputDebugString(buf);

            DeleteCriticalSection(&g_cs);

            break;
    }

    return TRUE;
}

Once registered with Regsrv32.exe:

regsvr32 TextService-Step01.dll

the DLL is now active and it will now be loaded to each new process utilizing Text Services (pretty much every single GUI application, including these already running) as can be shown via DebugView from Sysinternals.

Running a few test applications shows the following output in DebugView:

Of course, it survives the reboot and is loaded next time user logs on and applications are executed + it works under Windows 7 without any problem:

You may be wondering if there is any visual indication of the DLL being present on the system.

There is.

If you look at the legitimate software like aforementioned Ekaya – it adds a set of icons to the Language Bar:

and

It can be also seen in Text Services and Input Languages section (you can find it under Regional Settings):

There is no requirement for TSF DLLs to add extra features to the Language Bar, so the Text Services and Input Languages section under Regional Settings is the only place where it is possible to spot the loaded DLL – for our test sample it looks like this:

DLL load order

This is a trick relying on  DLL load order – it has been covered on many security blogs in last 2 years so I just mention it for completeness – there are many DLLs that can be ‘injected’ into a loading process of many popular programs. Two of them: fxsst.dll and ntshrui.dll have been covered by Nick Harbour from Mandiant in his posts from July 2010 and June 2011.

IIS Server Extensions (ISAPI filters)

In my older post I mentioned plugins and various extensions that can be loaded into various applications. There are really a lot of possibilities here, including multum of popular software, Windows Shell extensions, aforementioned Text services, IME, URL handlers, and so on and so forth. There are also possibilities of writing server environment-specific extensions e.g. ISAPI filters: As per the information on the page

Every ISAPI filter is contained in a separate DLL that must export two entry-point functions, GetFilterVersionand HttpFilterProc, and optionally export the TerminateFilter function. The metabase property, FilterLoadOrder, contains a list of all filters that IIS loads when the Web service is started.

 AppCertDlls

This is also a known technique – it has been researched and published by EP_X0FF in 2007 on sysinternals forum. There were a few follow-up posts about it, and a sample code can be found here, here and here. If you are interested you may also read ReactOS code that implements this feature here (search for ‘BasepIsProcessAllowed’).

Using a slightly modified code from one of the posts, we can build a DLL to demonstrate how it works.

First we need to add a registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls

then any REG_EXPAND_SZ value pointing to a DLL we have built.

 Now we need to restart the system to ensure a system-wide coverage. For testing purposes, it is okay to restart Windows Explorer so that it can refresh its internal program state to include these DLL in a process creation sequence. Or, one can simply launch cmd.exe and then run programs from command line to observe the DLL being loaded into each newly created process:

 You may be wondering how it works under 64-bit system. It works pretty well.

In fact, you can register both 32-bit and 64-bit DLLs as a notification on a 64-bit system:

to ensure notifications will be processed for both 64-bit and 32-bit programs:

That’s all ! Thanks for reading!