Category Archives: little known secrets

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 cliconfg.dll

Posted on by

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