Da Li’L World of DLL Exports and Entry Points, Part 6

I love looking at clusters of files, because it’s the easiest way to find patterns. In the last part of this series I focused on Nullsoft installers (DLLs!) only, and today, I will use the very same idea to describe clusters of DLL families I have generated from a very large corpora of clean samples (collected over last decade, or so).

What makes a summary like this interesting?

Some malware families like to ’emulate’ real software. They imitate clean .exe and .dll files by copypasteing their lists of imports, exports, internal strings, but then adding an extra import or export here and there; some go as far as to integrate their malicious code with the existing source code. So, the compiled embedded malicious code occupies like 5-10% of the actual binary, and the rest is all nice and dandy code ‘borrowed’ from some open source project. Detecting a malicious code inside such binaries is not trivial, but one thing that sometimes gives the badness away is that extra export. So, this post is about these extra exports…

The most popular exports combo in my sampleset is this:

148199
DllCanUnloadNow
DllGetClassObject
DllRegisterServer
DllUnregisterServer

No surprises here, it’s your traditional COM library at work.

The next two are variants of the above, but including an extra export:

27741
DllCanUnloadNow
DllGetClassObject
DllInstall
DllRegisterServer
DllUnregisterServer

24647
DllCanUnloadNow
DllGetClassObject
DllMain
DllRegisterServer
DllUnregisterServer

Now you know where it’s heading…

When you analyze a DLL, and it includes all the export functions from the sets above, BUT then export some additional functions, these functions are definitely of interest. This doesn’t mean all DLLs that export these ‘default’ sets + something extra that I am highlighting as ‘functions of interest’ are malicious. It’s just an easy win to focus on these extra exported functions first, even if just to discover that a legitimate programmer of a legitimate DLL was overzealous in over-exporting functions…

Here’s an example of a legitimate set with these ‘extras’:

2019
DeferredDeleteW
DllCanUnloadNow
DllGetClassObject
DllInstall
DllRegisterServer
DllUnregisterServer
InstallPackagesManagedW
InstallPackagesW
ReinstallPackageW
ResumeAsyncW
ResumeW
UninstallPackageW

or

1464
DllCanUnloadNow
DllGetClassForm
DllGetClassInfo
DllGetClassObject
DllGetInterface

Secondly, many of traditional DLL exports are _not_ meant to be executed from the likes of rundll32.exe.

What does it mean?

These popular DLL Export combos give you a list of functions that, if seen being invoked via command line, are most likely an indicator of something ‘funny’ going on. This is because these functions are (normally) not designed to be rundll32-friendly and are meant to be accessed programmatically only. There are exceptions, of course…. f.ex. tailored DllInstall is sometimes invoked by legitimate software and via rundll32.exe, but the main message here is that if you see rundll32.exe executing one of the non-rundll32-exe friendly functions, you better start investigating…

Last, but not least — remember that DLLs exporting via ordinals is a thing too, so keep this in mind during your analysis….

So, what other ‘healthy’ combos we can see out there?

  • QT Plug-ins export these two functions:
1847
qt_plugin_instance
qt_plugin_query_metadata
1612
gegl_module_query
gegl_module_register
  • NVIDIA Stereo API DLLs:
1582
GetStereoApi

There are many other combos like this, but in today’s era of AI knowing-it-all, ask your nearest chatGPT for the full list, mine is most likely already quite obsolete 🙂

Da Li’L World of DLL Exports and Entry Points, Part 5

The previous parts of this series were done ‘manually’. I would come across some new type of DLL and would jot down its properties so I would have a point of reference if I came across these in the future. The ‘manual’ part involved reading MSDN as well as many types of DLLs I covered are nicely described there.

There is another way to enhance the list by doing it a bit more automatically – such list could f.ex. be incorporated into your yara set, or become a part of tools like DiE.

Over 8 years ago I tried to collect a corpora of signed DLLs dropped by NullSoft installers – my list included over 2200 different DLLs. I will use this list today to show how we can create a table of interesting file properties that in turn could be converted into a detection ruleset.

Using sigcheck we can extract version info from these signed DLLs, and then enhance it by a list of exported APIs (f.ex. using pefile), and also internal DLL names. This is pretty much enough to create a decent detection data set.

Of course, these files are very old so to make the best use of this idea one would need to process a larger data set and newer files.

What is the benefit of using such ruleset? As long as files are signed and show the listed properties you may classify many clean files in an automatic fashion w/o relying on exact hashes, fuzzy hashes, or antivirus scans. And yes, as I mentioned in the past, such list of properties can be abused by malware authors, but then again — these files are actually signed, so it’s a good way to sift through the real and fake ones.