Category Archives: Living off the land

1 little secret of sqlsrv32.dll

Posted on by

This post is not really about sqlsrv32.dll, but since it is poking in this library’s code that led me to rediscover the BidInterface interface for the third time (I even described it twice before, without anyone noticing!), it ended up in a title of this post…

Anyway, back to the rediscovery bit… I am actually quite surprised that I was able to not only rediscover it for the 3rd time, but also find a new way to abuse it. And as usual, it is the Procmon logs that did most of the work here…

When you attempt to load sqlsrv32.dll via rundll32.exe and execute any of its exported functions f.ex.:

rundll32 sqlsrv32.dll, TestDlgProc

the sqlsrv32.dll library will try to activate that aforementioned BidInterface libraries:

As we can see, not only the :Path is being looked at, but also a few more other things:

  • the full path of the executable+ its Process ID (PID)
  • the full path of the executable
  • the directory extracted from the path of the executable, with an asterisk

That’s a very granular control over the BidInterface tracing, and after testing these entries for rundll32.exe, I was able to immediately load the test DLL of my choice:

  • first we create the entry for C:\WINDOWS\system32\rundll32.exe and pointing it to c:\test\test64_dll.dll:
  • and then we launch the rundll32.exe command listed above:

Obviously, the C:\WINDOWS\system32\* entry pointing to the same library works as well:

That’s it!

1 little secret of mapi32.dll

Posted on by

The mapi32.dll is a stub DLL that acts as a proxy for MAPI API calls. Pretty much all its exported functions start with a GetProxyDllEx routine that tries very hard to find a target email client library that will deliver the requested functionality offered by a standardized MAPI interface.

The GetProxyDllEx routine is pretty complicated as it attempts to handle many cases – many of which are catering for various architectural choices Microsoft made around MAPI over last 3 decades. Okay, I lied, it’s actually more boring than complicated, and since I am always triggerhappy when it comes to quick wins, I will just describe one below.

As a side note, from a forensic perspective, the following registry entry may be of interest:

HKLM\SOFTWARE\Clients\Mail\AlwaysUseLegacyMapiRegistration

It determines how the MAPI provider DLL is being searched for. If it doesn’t exist, or the value is not 1, the search will focus primarily on the modern RoGetActivationFactory function; otherwise, it will search the MAPI providers the old-fashioned way (via Registry enumeration of HKLM\Software\Clients\Mail key).

Anyway, back to the quick win…

If we put the file mapisvc.inf in a PATH location, and attempt to load any MAPI API via rundll32.exe f.ex.:

rundll32 mapi32.dll, LaunchWizard

the mapi32.dll will try to load:

C:\Windows\System32\mapi32x.dll

This DLL may or not may be present on the OS, depending on the OS version. So it’s a bit of a Schrödinger phantom DLL. If you are lucky, and it doesn’t exist, it can be used to host a payload…

Note: the mapi32x.dll file name is hard coded and used in situations when a better MAPI DLL file cannot be found. In many cases there may be Email clients present on the system that will configure email client entries that will take precedence over mapi32x.dll, so YMMV and you simply need to test it for your specific scenario. Remember it’s a quick win, and these are usually low quality 🙂