It’s actually 99th, because I forgot one part on the way 🙂

This is one more persistence method based on a built-in set of features. This time the culprit is the Policy Manager.

Browsing through the PolicyManager key located here:

• HKLM\Software\Microsoft\PolicyManager\

we can spot many interesting entries, often multiple-level deep:

Some of them include entries that are of our interest:

• PreCheckDLLPath
• transportDllPath

The good news is that not all entries have them a.k.a. they are optional. And it turns out that these allows to provide additional utility libraries that in turn will be loaded by Policy Manager components (policymanager.dll) when this DLL itself is utilized.

I couldn’t come up with a quick& dirty way to load the test dll, so I cheated by starting the procmon, setting up the filters, and letting it go for some time. After awhile I caught the first process accessing these entries:

The harvesting may be easier on a system connected to the domain (policies deployment/access is more frequent).

It’s probably not an understatement if I say that for every single DLL that Windows OS ships with, and one that functionality it provides I sort of understand (at least on a high level), there are probably hundreds, if no more, that I still have absolutely no clue about. This makes picking random code attractive, because there is always something new to discover.

This is exactly what led me to discovering this possible persistence technique. I am saying ‘possible’, because I am almost certain it works, yet I have no way to test it in my hardware/software set up.

Have you ever heard of dafDockingProvider.dll?

Hmm. Me neither.

The ‘daf’ bit stands for ‘Device Association Framework’. The Registry entries associated with this framework are themselves a very good persistence mechanism candidate – most of these libraries could be potentially trojanized:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Device Association Framework

The dafDockingProvider.dll library seems be responsible for support of docking. And its code includes an interesting routine – it loads a number of so-called Docking Providers. They are loaded from the following Registry entry:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WirelessDocking\DockingProviderDLLs

The values from this location are enumerated, and DLLs they point to – loaded. The only caveat is that the libraries are loaded with LoadLibraryExW that uses the LOAD_LIBRARY_SEARCH_SYSTEM32 flag, so the files need to be in a system directory. The DLLs are expected to export these two functions:

• InitializeDockingProvider
• ShutdownDockingProvider

The only homework left to do is to test it on a system with a wireless docking station… If you happen to make it work, please let me know. Thakns!