1 little secret of cliconfg.dll

Most of my favorite sideloading techniques rely on some old and kinda obscure localisation/test features embedded in various programming frameworks.

This post touches on yet another one of these.

When you launch this function:

rundll32 cliconfg.dll, OnInitDialogMain

the code of the DllMain of this DLL library will try to find the following localisation RLL files:

  • C:\WINDOWS\system32\Resources\1024\cliconfg.RLL
  • C:\WINDOWS\system32\Resources\1033\cliconfg.RLL

What is surprising though, these files are loaded via a regular LoadLibrary call, which obviously leads to a code execution…

So, placing your payload in any of these two RLL files, and executing any of the APIs exported by cliconfg.dll, will lead to loading and execution of these payloads. And if you know how rundll32.exe works, and paid attention to the bit mentioning DllMain being responsible for loading these localisation libraries, you know that we can specify any API name, or ordinal number, and get the payload execution anyway, As such, as long as our RLL files are in place, any of the below invocations will load the payload:

rundll32 cliconfg.dll, foo
rundll32 cliconfg.dll, bar
rundll32 cliconfg.dll, #1
rundll32 cliconfg.dll, #3948794357847857

1 little secret of mapi32.dll

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 🙂