I must admit that finding new paths that could be exploited as a persistence mechanism is a silly hobby of mine. When I started this series I thought that a few posts will suffice, but to my surprise it’s already #11. For your convenience, these are links to the older posts::

• Beyond good ol’ Run key, Part 1
• Beyond good ol’ Run key, Part 2
• Beyond good ol’ Run key, Part 3
• Beyond good ol’ Run key, Part 4
• Beyond good ol’ Run key, Part 5
• Beyond good ol’ Run key, Part 6
• Beyond good ol’ Run key, Part 7
• Beyond good ol’ Run key, Part 8
• Beyond good ol’ Run key, Part 9
• Beyond good ol’ Run key, Part 10

You may also want to have a look at ‘A Collection of Autostart Locations’ – a very large and comprehensive list of autostart entries collected by Tony Klein

• http://gladiator-antivirus.com/forum/index.php?showtopic=24610

Back to the #11.

In the part #10 (Office Test) I mentioned that Microsoft products seem to be heavily integrated with various testing platforms. I also referenced various aspects of performance analysis, profiling, monitoring and debugging in parts #4 (various debuggers), #6 (VBA Monitors), #7 (OAClient). There is one more trick that we can add to the list – legitimate, developer-friendly profiling mechanisms that can be enabled on non-developer systems and… act as a persistence mechanism.

The profiling mechanisms described further require a persistent environment variable to be set. This can be achieved by setting the respective values under HKCU or HKLM:

• HKEY_CURRENT_USER\Environment
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

The values that need to be placed under the Environment keys depend on the profiling mechanism – these are listed below:

• JS_PROFILER – Active Script Profiling (I believe it was introduced in IE 8.0)

• COR_ENABLE_PROFILING & COR_PROFILER & COR_PROFILER_PATH &
  COMPLUS_ProfAPI_ProfilerCompatibilitySetting &
  CORECLR_ENABLE_PROFILING & CORECLR_PROFILER &  CORECLR_PROFILER_PATH
  – .NET Profiling
  see also
  Registry-Free Profiler Startup and Attach
  Writing a Profiler for Silverlight 4
  CLRProfiler V4 and
  Writing a Profiler of Windows Store apps (PDF)

Example for JS_PROFILER:

Adding the following Registry entries:

[HKEY_CLASSES_ROOT\CLSID\{12345678-1234-1234-1234-123456789abc}\InprocServer32]
@=hex(2):63,00,3A,00,5C,00,74,00,65,00,73,00,74,00,5C,00,74,00,65,00,\
  73,00,74,00,2E,00,64,00,6C,00,6C,00,00,00

[HKEY_CURRENT_USER\Environment]
"JS_PROFILER"="{12345678-1234-1234-1234-123456789abc}"

will ensure that c:\test\test.dll (added as a REG_EXPAND_SZ value using ‘@=hex(2):…’) is loaded anytime Internet Explorer is executed or its control instantiated (JS_PROFILER is used internally by JSCRIPT*.DLLs – they handle scripting and they are used by Internet Explorer).

There is no doubt that Microsoft products are a subject to a lot of testing – this is understandable as it’s undeniably the most used office software in the world. It’s hard to imagine software packages that complex to be completely separated from the platform/modules that are used to testing them – it’s not a surprise then that references to various Microsoft testing platforms or modules can be found in strings or Process Monitor logs. One of them is called Oasys (Office Automation System) and I discussed it in the 7th part of the series. This is not the only one though and this short post will talk about yet another trick (or two) that are most-likely side-effects of deep integration with testing platforms – they can be both used to load a phantom DLL anytime Office programs start, and in some cases when other programs do as well.

Office 2007, 2010 and 2013

Adding a key/value pair shown below to the Registry will guarantee that the test.dll will load anytime Office 2007, 2010 or 2013 programs are started (e.g. WinWord, Excel):

[HKEY_CURRENT_USER\Software\Microsoft\Office Test\Special\Perf]
@="C:\\test\\test.dll"

Interestingly, sometimes the DLL will be also loaded when e.g. Internet Explorer launches – as long as one of the office plugins is loaded into IE (and the plugin’s code or its libraries refer to the aforementioned Office Test value). There are most likely other cases since Office COM objects can be easily instantiated from other software.

The respective global key exists under the HKLM branch i.e. HKLM\SOFTWARE\Microsoft\Office Test\Special\Perf.

Office 2010 and WinWord

Adding a key/value pair shown below to Registry will guarantee that instead of a WWLIB.DLL that is distributed with Office 2010 a different DLL will be loaded instead anytime WinWord starts – a DLL named WWLIBcxm.DLL.

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word]
"CxmDll"=dword:00000001

In other words, placing a custom WWLIBcxm.DLL in the Office directory (or any listed under PATH) will do the trick. Note that such DLL will need to act as a proxy for WWLIB.DLL – otherwise the WinWord won’t load (it requires WWLIB.DLL to work).