The art of underDLLoading

In my previous post I created a posh artisan .exe file ornamented with a large number of intricate system32 DLL imports. The process of building that file was painful – before I even managed to run the final executable I had to troubleshoot a number issues – many of which I didn’t even expect (missing DLLs, missing manifest, random crashes, etc.).

In the process of sculpting it I decided to kick off a parallel mini project that would look at the problem from a different angle — instead of a single file, I decided to generate a lot of test executable files, where each of these files would import just ONE single DLL from the system32 directory + the kernel32 as I needed it for its ExitProcess API. I then ran all these compiled files one by one. The original idea was to isolate and troubleshoot problematic DLLs, but to my surprise, I got some other interesting results.

First of all, with the real-time detection on, Windows Defender started picking up on some of these executables one by one:

Linking to dpnaddr.dll, dpnathlp.dll, dpnet.dll, dpnhpast.dll, dpnhupnp.dll, dpnlobby.dll causes an interesting side-effect. When you run an .exe that links to any of these libraries, you get a DirectPlay Windows Features install dialog box:

This is a result of svchost.exe hosting Program Compatibility Assistant Service (C:\Windows\system32\svchost.exe -k LocalSystemNetworkRestricted -p -s PcaSvc) launching this dialog via fondue.exe:

Fondue.exe /enable-feature:DirectPlay /show-caller /top-most /caller-name:"test_<dllname>.exe"

This looks like a shim at work, but I have not verified it. And no, we cannot launch our own fondue.exe here as far as I can tell 🙁

Many other test files fail too, for many different reasons:

We can extract crash details from the Windows Event Logs/Applications:

When you start experimenting with a PE file format itself, there are no limits. By playing around with its frivolous structure we can create a lot of interesting and unexpected results.

Technical debt of C:\Windows\System path

Thanks to @sixtyvividtails who corrected a mistake I made in the earlier version of the post

Updated post

One of a less known paths that is being searched when the libraries are loaded is C:\Windows\System.

Anytime the search for a library kicks off, the following system directories are being searched:

  • C:\Windows\System32\
  • C:\Windows\System\

We can clearly see this in Procmon when we try to test the POC from my post about UpdateAPI.dll:

So, that old 16-bit legacy path is still there, even if practically no one is using it today. As such, we can use this path to drop at least some of the payloads there.