{"id":8510,"date":"2023-05-12T22:50:39","date_gmt":"2023-05-12T22:50:39","guid":{"rendered":"https:\/\/www.hexacorn.com\/blog\/?p=8510"},"modified":"2023-05-12T22:50:39","modified_gmt":"2023-05-12T22:50:39","slug":"da-lil-world-of-dll-exports-and-entry-points-part-6","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2023\/05\/12\/da-lil-world-of-dll-exports-and-entry-points-part-6\/","title":{"rendered":"Da Li\u2019L World of DLL Exports and Entry Points, Part 6"},"content":{"rendered":"\n

I love looking at clusters of files, because it’s the easiest way to find patterns. In the last part<\/a> 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). <\/p>\n\n\n\n

What makes a summary like this interesting?<\/p>\n\n\n\n

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…<\/p>\n\n\n\n

The most popular exports combo in my sampleset is this:<\/p>\n\n\n\n

148199
DllCanUnloadNow
DllGetClassObject
DllRegisterServer
DllUnregisterServer<\/pre>\n\n\n\n
No surprises here, it’s your traditional COM library at work. <\/p>\n\n\n\n
The next two are variants of the above, but including an extra export:<\/p>\n\n\n\n
27741\nDllCanUnloadNow\nDllGetClassObject\nDllInstall\nDllRegisterServer\nDllUnregisterServer\n\n24647\nDllCanUnloadNow\nDllGetClassObject\nDllMain\nDllRegisterServer\nDllUnregisterServer<\/pre>\n\n\n\n
Now you know where it’s heading… <\/p>\n\n\n\n
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…<\/p>\n\n\n\n
Here’s an example of a legitimate set with these ‘extras’:<\/p>\n\n\n\n
2019
DeferredDeleteW
DllCanUnloadNow
DllGetClassObject
DllInstall
DllRegisterServer
DllUnregisterServer
InstallPackagesManagedW
InstallPackagesW
ReinstallPackageW
ResumeAsyncW
ResumeW
UninstallPackageW<\/pre>\n\n\n\n
or<\/p>\n\n\n\n
1464
DllCanUnloadNow
DllGetClassForm
DllGetClassInfo
DllGetClassObject
DllGetInterface<\/pre>\n\n\n\n
Secondly, many of traditional DLL exports are _not_ meant to be executed from the likes of rundll32.exe. <\/p>\n\n\n\n
What does it mean? <\/p>\n\n\n\n
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<\/a> 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… <\/p>\n\n\n\n
Last, but not least — remember that DLLs exporting via ordinals<\/a> is a thing too, so keep this in mind during your analysis….<\/p>\n\n\n\n
So, what other ‘healthy’ combos we can see out there?<\/p>\n\n\n\n