In my older post I mentioned TestHooks in a context of Windows Update. Studying Windows 10 binaries brings more interesting findings. Few days ago I stumbled upon Test_TestHookIndex string inside explorer.exe and almost immediately I asked about it on Twitter. This is because googling brought only one interesting hit – a blog post from… 2013. I couldn’t believe that in last 7 years no one else looked at it. Hmm…
One of my fav. researchers @0gtweet jumped on it straight away and we had a quick exchange about possibilities. We concluded that there may be some persistence trick hiding there, somewhere. The TestHook values seem to be overriding some flags for the actual tasks executed by Windows Explorer.
I am a bit lazy these days (thx covid). So, to help with research I kicked off Procmon with a filter for TestHook, and then ran it with booting enabled and restarted my VM box.
One of the first findings after the system restart was that Procmon highlighted a missing file RdvTestHooks.dll – quick google confirmed that this find has been already covered in this nice blog post – a beautiful example of a phantom DLL.
As for the Registry entries I got these (this is a subset from Explorer only, but there is more from more processes!):
So, the the string I found inside Windows Explorer is actually referenced during run-time and that makes it interesting. Looking at the code in IDA confirmed that @0gtweet‘s feel about these reg entries was also spot on. BUT. As far as I can tell all these Windows Explorer entries are DWORDs so we can’t change too much there (in terms of providing a path to a test DLL, or whatever). And the settings appear to be affecting tasks executed by Windows Explorer during start and tagged as follows:
PreRoamingTasks
PreShellTasks
ShellInitTasks
UserOobeTasks
PreStartTasks
PostStartTasks
BasicCXHTasks
While I was not able to find a way to (ab)use these, this is yet another unfinished research…
I like extracting data from many samples because this way I often discover new things. Combing through a set of manifest files I have extracted from a large sampleset of good samples was an interesting exercise and brought a few interesting findings.
Manifest files I came across were saved as plain text, Unicode 16 LE, and utf8. Some were malformed, some used incorrect data, others included commented out manifest sections and sometimes the commented out parts would use HTML entities to represent opening and closing brackets. Quotation marks vs. apostrophes, boilerplate values (e.g. name = “CompanyName.ProductName.YourApplication”, name = “YourCompanyName.YourDivision.YourApp”, etc.), and typos (e.g. “schema-microsoft-com:asm.v3”, or “urn:schemas-microsoft.com:asm.v3”).
I tried to see if I can find any publicKeyToken outliers — these are often used to reference a specific library version – the most popular being comctl32.dll v6.0 enabling visual styles back in the days when it still mattered (publicKeyToken=”6595b64144ccf1df”).
Quick histogram of publicKeyToken values shows a small number of unique values, some of which are kinda questionable (e.g. empty, zeroed, or using a reference):
Another target of these analysis were URIs. These constantly pop up during memdump analysis and knowing a list of clean ones can save us some time. Here’s a list I extracted (including these prefixed with ‘urn’):
Finally, attributes (note, some may only exist within comments, that is, between <!–…-> not the actual manifest XML):
name iid version clsid progid hash description proxyStubClsid32 tlbid Id numMethods publicKeyToken task message language value xmlns processorArchitecture uiAccess level type class file standalone inType encoding mask flags manifestVersion threadingModel keywords size chid runtimeVersion guid xmlns:asmv3 company optional outType helpdir xmlns:co.v2 copyright allowDelayedBinding opcode xmlns:asmv2 length xmlns:ms_asmv3 buildType hashalg parameters xmlns:adlcp xsi:schemaLocation xmlns:cmp culture xmlns:ms_asmv1 profile xmlns:ms_windowsSettings xmlns:xsi baseInterface majorVersion face xmlns:xsd miscStatusContent resourceFileName xmlns:asmv1 isolation dependencyType servicePackMajor xmlns:co.v1 channel xmlns:lom assemblyname xmlns:ms_asmv2 messageFileName xmlns:ms_compatibility template xmlns:mssv2 minorVersion miscStatus enabled asmv2:product product
And last, but not least… this classic paper [PDF warning] from 2006 on manifest file abuse was yet another reason I looked at manifest files en masse. I speculated that maybe, maybe, maybe, maybe there are some signed executables that take advantage of manifest’ file tag as described in the document:
and inadvertently may become a vehicle for a ‘by design’ manifest-based DLL side-loading. The scenario would play like this: you run a signed executable that uses a manifest leveraging the file tag and you provide it the malicious DLL named as the manifest expects and place it in a current directory. Should work?
After grepping the manifest files for <file tag I found quite a few of them. So many that I can’t paste it here. But you can view them here.
