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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Over 8 years ago I tried to collect a corpora of signed DLLs dropped by NullSoft installers – my list<\/a> 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.<\/p>\n\n\n\n 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<\/a>.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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. … Continue reading