{
	"id": "6ee4832e-e4d7-4505-99be-7638079d0dba",
	"created_at": "2026-04-06T00:13:01.154909Z",
	"updated_at": "2026-04-10T03:22:13.104268Z",
	"deleted_at": null,
	"sha1_hash": "b4982b1aa74a18d3af0c2a07c22c9ef7ba59a506",
	"title": "Beyond good ol’ Run key, Part 10",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 40874,
	"plain_text": "Beyond good ol’ Run key, Part 10\r\nPublished: 2014-04-16 · Archived: 2026-04-05 18:25:16 UTC\r\nThere is no doubt that Microsoft products are a subject to a lot of testing – this is understandable as it’s undeniably\r\nthe most used office software in the world. It’s hard to imagine software packages that complex to be completely\r\nseparated from the platform/modules that are used to testing them – it’s not a surprise then that references to\r\nvarious Microsoft testing platforms or modules can be found in strings or Process Monitor logs. One of them is\r\ncalled Oasys (Office Automation System) and I discussed it in the 7th part of the series. This is not the only one\r\nthough and this short post will talk about yet another trick (or two) that are most-likely side-effects of deep\r\nintegration with testing platforms – they can be both used to load a phantom DLL anytime Office programs start,\r\nand in some cases when other programs do as well.\r\nOffice 2007, 2010 and 2013\r\nAdding a key/value pair shown below to the Registry will guarantee that the test.dll will load anytime Office\r\n2007, 2010 or 2013 programs are started (e.g. WinWord, Excel):\r\n[HKEY_CURRENT_USER\\Software\\Microsoft\\Office Test\\Special\\Perf]\r\n@=\"C:\\\\test\\\\test.dll\"\r\nInterestingly, sometimes the DLL will be also loaded when e.g. Internet Explorer launches – as long as one of the\r\noffice plugins is loaded into IE (and the plugin’s code or its libraries refer to the aforementioned Office Test\r\nvalue). There are most likely other cases since Office COM objects can be easily instantiated from other software.\r\nThe respective global key exists under the HKLM branch i.e. HKLM\\SOFTWARE\\Microsoft\\Office\r\nTest\\Special\\Perf.\r\nOffice 2010 and WinWord\r\nAdding a key/value pair shown below to Registry will guarantee that instead of a WWLIB.DLL that is distributed\r\nwith Office 2010 a different DLL will be loaded instead anytime WinWord starts – a DLL named\r\nWWLIBcxm.DLL.\r\n[HKEY_CURRENT_USER\\Software\\Microsoft\\Office\\14.0\\Word]\r\n\"CxmDll\"=dword:00000001\r\nIn other words, placing a custom WWLIBcxm.DLL in the Office directory (or any listed under PATH) will do the\r\ntrick. Note that such DLL will need to act as a proxy for WWLIB.DLL – otherwise the WinWord won’t load (it\r\nrequires WWLIB.DLL to work).\r\nhttp://www.hexacorn.com/blog/2014/04/16/beyond-good-ol-run-key-part-10/\r\nPage 1 of 2\n\nSource: http://www.hexacorn.com/blog/2014/04/16/beyond-good-ol-run-key-part-10/\r\nhttp://www.hexacorn.com/blog/2014/04/16/beyond-good-ol-run-key-part-10/\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://www.hexacorn.com/blog/2014/04/16/beyond-good-ol-run-key-part-10/"
	],
	"report_names": [
		"beyond-good-ol-run-key-part-10"
	],
	"threat_actors": [],
	"ts_created_at": 1775434381,
	"ts_updated_at": 1775791333,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b4982b1aa74a18d3af0c2a07c22c9ef7ba59a506.pdf",
		"text": "https://archive.orkl.eu/b4982b1aa74a18d3af0c2a07c22c9ef7ba59a506.txt",
		"img": "https://archive.orkl.eu/b4982b1aa74a18d3af0c2a07c22c9ef7ba59a506.jpg"
	}
}