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.

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).

Using Jumplists as an autostart mechanism is possible, but requires users to actually use this feature for this persistence trick to be successful. There is obviously a better way of persuading users to execute stuff and that is by manipulating the pinned applications themselves.

Microsoft doesn’t document the interface used by the Pinned Apps, but others do. Windows folks do it on purpose – pretty much any exposed element of GUI has been abused in the past in many ways so protecting the taskbar and pinned apps is definitely in the user’s best interest. Still, there are already documented ways to modify the Pinned Apps list – one can use a script published by Microsoft itself on the MSDN blog back in 2009; there also seems to be a way of modifying the list of pinned apps during the DASH process by modifying the entries under the following key:

• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\TBDEn

To test the idea, I wrote a small test app that ‘talks’ to Pinned Apps directly and swaps the pinned app’s target executable path to one that is potentially malicious. The program enumerates the pinned apps, checks if the link points to internet explorer and then replaces the pinned app with one that points to c:\test\malware.exe. The ‘malware.exe’ is actually a copy of ‘iexplore.exe’ (I was too lazy to create my own test app with the icon identical to Internet Explorer’s).

The path change can be confirmed by checking the properties of the first pinned application on the Taskbar:

The list of links for all pinned apps before and after the modification are shown below (pinenum.exe is a small tool that enumerates all pinned apps):

 For obvious reasons, I won’t release the code publicly.