Today I will talk about something that can be called ‘the god of all persistence mechanisms’. One that is so powerful that can use pretty much any .exe on your system as a persistence mechanism.

It’s called dotlocal (.local).

If you run Process Monitor often enough you will (sooner or later) discover that anytime you launch an .exe the system will always try to find a file or a directory called <filename.exe>.local.

That – my friend – is a debugging feature.

It is a redirection mechanism designed to test COM objects and pretty much means that if either a file or directory named <filename.exe>.local exists the OS will understand it as a ‘testing in progress’ signal and will attempt to load DLLs from a different directory than usual. In other words, it will search for dependent DLL libraries in a path different from the typical DLL search order. This allows us to intercept pretty much any DLL dependency we wish except for these that are listed under KnownDLLs registry key (HKLM\CurrentControlSet\Control\Session Manager\KnownDlls).

For the sake of a demo, I will show you a very stupid example using the least malicious program on your system called… Notepad.

Notepad relies on a couple of libraries, most of them are present on the Known DLLs list (can’t be abused unless you remove them from the Registry and reboot the system); except for comctl32.dll. This library has many versions and thanks to that requires a dedicated entry in the manifest solving the so-called DLL hell problem:

<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>

The practical implication of this manifest file is that OS will try to load the following comctl32.dll file (on Windows XP)

x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll

located inside the Windows directory (c:\WINDOWS\WinSxS\).

Introducing a directory c:\windows\system32\notepad.exe.local we can force the OS to leverage the dotlocal ‘feature’ and load the following ‘malicious’ library instead:

c:\WINDOWS\system32\notepad.exe.local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll

It works on Windows 10 too, except that it will be loaded from a different path:

c:\WINDOWS\system32\notepad.exe.local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.9841.0_none_38d154a85935aa0a\comctl32.dll

The following example shows the moment of a malicious DLL loaded via dotlocal mechanism into a Notepad session on Windows 10.

Notepad obviously crashes, cuz I was lazy and just implemented a dummy comctl32.dll, but in a real-case scenario one could hide the presence of such a malicious DLL by using it as a proxy and redirecting all API calls to the legitimate comctl32.dll DLL.

In other words, dropping the malicious comctl32.dll in these directories on respective systems will ensure that these malicious DLLs are loaded anytime someone starts Notepad.

Now, for the scary part. Notepad was a stupid example as it requires admin rights to write to c:\WINDOWS\system32\notepad.exe.local\ on Windows 10, but any file outside of areas protected by system is a much easier target.