Category Archives: LOLBins

Beyond good ol’ Run key, Part 154

Posted on by

In this series I describe a lot of Windows persistence mechanisms. Most of them are ‘native’ to the OS, but I sometimes cover opportunities offered by popular software too. Today’s case is one of these.

Ghostscript is a superpopular:

suite of software based on an interpreter for Adobe Systems’ PostScript and Portable Document Format (PDF) page description languages

that can be found installed on many Windows endpoints today. It is often being installed as a dependent component supporting a lot of various applications, including PDF software, games, etc.

What we can find as particularly interesting from a persistence standpoint, is this Registry entry:

(HKCU|HKLM)\Software\GPL Ghostscript\<version>\GS_DLL=<DLL library>

Any software relying on Ghostscript will eventually refer to it, and load the DLL this entry points to. As such, it can be leveraged for persistence (proxy DLL).

This mechanism is described in detail here.

If you read the linked article, you will notice that there is an alternative way to set the value of GS_DLL by using the environmental variable. This feature can be abused for both persistence and lolbin activities.

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!