Beyond good ol’ Run key, Part 24

January 13, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

Ability to load a DLL of your choice anytime someone is connecting to the internet is something that definitely deserves some attention. This is why I will describe here yet another obscure mechanism that can be abused for malicious purposes. Courtesy of Winsock 2 library (ws2_32.dll).

When Winsock library connects to the internet it ‘talks’ to various service providers and probes them for connectivity services. It’s actually pretty complex and I won’t pretend that I fully understand what’s going on there yet there is one thing which this library does that I do understand :)

At some stage it attempts to load a DLL as specified by the following Registry key:

HKLM\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\AutodialDLL

This key is quite obscure and Microsoft only describes it in a context of a very old vulnerability MS06-041.

Turns out that the AutodialDLL entry points to a DLL that WinSock will load anytime it connects to the internet.

The DLL needs to export 3 functions:

  • WSAttemptAutodialAddr
  • WSAttemptAutodialName
  • WSNoteSuccessfulHostentLookup

The result of loading the following registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters] "AutodialDLL"="c:\\temp\\foo.dll"

and dropping the file

c:\temp\foo.dll

(the DLL exports the aforementioned APIs) can be seen below:

autodial_1

The screenshot was taken from a Windows XP system – I simply opened and closed Internet Explorer.

Of course, it works on Windows 10 too – just access to HKLM is slightly more difficult :)

autodial_2

 

Beyond good ol’ Run key, Part 23

January 9, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

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.

notepad10

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.

notepad10_2

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.