So… 5..7 range it is. <\/p>\n\n\n\n
Anything outside of it is probably… mildly interesting. Why ‘mildly’? These numbers are good for Microsoft compilers\/PE files, but files built with non-Microsoft compilers will have to fall into a different bucket. Compiler detection is critical here and only if we do so, we can correlate average number of PE sections in ‘good’ files generated by that specific compiler. Think Delphi\/Embarcadero, mingw, Go, Nim, Zig, Rust, PyInstaller, etc.. Non-trivial \ud83d\ude41<\/p>\n\n\n\n
PE Sections are for beginners tho. Really no point spending much time on them, because the PE profiling landscape has changed a lot over last 15 years. Luckily, there are many other properties of ‘good’ files that are worth discussing.<\/p>\n\n\n\n
First, the PDB paths. Same as with malware, we can collect a large corpora of these and create a cluster of ‘reverse-logic’ yara rules. That is, if the yara hits and the file contains one of the legitimate-looking PDB file names\/paths it is most likely good! It is a terribly naive assumption of course, I mean to believe that all files with legitimate PDB paths are good, but… why not, for starters. <\/p>\n\n\n\n
For instance, if the file is not detected by any AV, and contains unique PDB strings that look like one of these clean PDB paths (on a curated list) then it’s highly possible it is, indeed a clean one! Right?<\/p>\n\n\n\n
And together with other characteristic of good PE files we may craft a little bit more complex yara rules that could all be good indicators of file goodness w\/o losing flexibility (e.g. work across multiple versions of the same file).<\/p>\n\n\n\n
I don’t want to burn ‘good’ yara rules in public, because this kills the whole idea described above, so I won’t be posting too many examples (more about it later as well), but let’s have a look at this PDB path:<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2022\/02\/pdb1.png\")
<\/a><\/figure><\/div>\n\n\n\nIf it is was malware, you would write a Yara signature for it, right?<\/p>\n\n\n\n
You can do the same for ‘good’ files.<\/p>\n\n\n\n
The second idea is focused on GUIDs. <\/p>\n\n\n\n
Many clean files come as COM libraries and their GUIDs referenced by their type libraries are unique. One could create another set of ‘reverse-logic’ yara rules for these, and this way discover ‘good, clean files that reference them. It could be an occurrence of GUID in a string format, either ANSI or Unicode as well as its binary representation. <\/p>\n\n\n\n
Again, the assumption here is that bad guys don’t use the same GUIDs in their poly-\/meta-morphic generators (yet). See it for yourself – the below GUID has only few Google hits<\/a> and (until this post) was a good indicator of ‘goodness’:<\/p>\n\n\n\n Next, we can look at resources. Many legitimate executable files embed ‘branded’ icons. We know these are already being leveraged by some bad guys, but having a large set of these ‘good’ icons extracted from many clean samples can help to push samples that include them into different pipelines. <\/p>\n\n\n\n And these, especially, if matched with characteristics of import\/export tables, their hashes, or other basic file properties like size, number of sections and their names, or even a matching subset of strings, plus version information, number of localized strings, entropy, signatures, etc. can form unique descriptors of ‘goodness’. <\/p>\n\n\n\n Can these be abused? 100% . This is why I am not making results of this research public.<\/p>\n\n\n\n And it is for sure that ‘good’ files follow patterns, they don’t change that much and we can exploit that. And since these properties can be extracted automatically, this is in fact, a great place for machine learning (unlike actual malware)! What if what we need is a ML\/AI algo that learns from ‘good files’ ? Yes, it’s not a new concept, but how much of this kinda research is actually made public (especially the algorithmic part)? With this series I plan to bring some of my personal research to the public eye with a hope it can inspire more work in this space. <\/p>\n\n\n\n And coming back to what I mentioned earlier – I do face a dilemma. I have collected many of these artifacts and statistics during my spelunking, but I don’t think it’s a good idea to share them publicly. I think there actually is a scope for a DST debate same as there is for OST and at this moment in time I believe some artifacts or their collections, “defensive” findings if you will, should be shared within trusted circles only!!!<\/p>\n\n\n\n Yes, it’s a 180 degree change of my stance compared to say 10 years ago, but we live in strange times. If I publish a list of all clean PDB paths, clean GUIDs, clusters of legitimate icons it’s a given that the next generation of malware will immediately re-use them in their creations! And some Red Teams may use that too. <\/p>\n\n\n\n So, it’s a No. <\/p>\n\n\n\n I am also worried about unfair players in the corporate space who will simply acquire this data for free and use it in their commercial offerings, both on defensive and offensive side.<\/p>\n\n\n\n So, this is a No, too. <\/p>\n\n\n\n Yup, good sharing times are over, sorry.<\/p>\n\n\n\n Where does it leave us?<\/p>\n\n\n\n I guess there is not much that can be done here…<\/p>\n","protected":false},"excerpt":{"rendered":" Most of (anti-) malware researchers focus on malware samples, because… it’s only natural in this line of work. For a while now I try to focus on the opposite – the good, ‘clean’ files (primarily PE file format). While it … Continue reading ![\"\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2022\/02\/guid1-1024x163.png\")
<\/a><\/figure>\n\n\n\n