Code similarity is a common and powerful way to cluster malware samples and make connections between seemingly unrelated malware families. Although it sounds simple, it is actually a complex problem and is hard to automate at scale without generating false positives. 1/
Blindly trusting code similarity can get one to make connections when there are none. This yields erroneous conclusions and can create very wrong media headlines. 2/ 
An example of wrong use of code similarity was published by Cluster25 recently, where they connect #IsaacWiper to various other malware families. cluster25.io/2022/05/03/a-s… 3/
The article uses two examples to support their similarity assessment. The problem? Both show similarity in standard libraries statically linked into the malware samples. 4/
The first one mentions the function at virtual address 100DDAE0h in the Vatet sample. This function is actually part of Microsoft’s C++ standard library implementation. We can find its reference in the virtual method table of std::num_put<wchar_t>. 5/
IDA Pro identify the function used in the second example as “try_get_function(…)”, which is part of Microsoft Visual C runtime library. Comparing the implementation with the function in the sample confirms IDA Pro is correct. 6/
To confirm a link between malware families can be established using code similarity, a researcher should verify that the similarity is on the relevant parts of the code and not on boilerplate or widely available library implementations. 7/
For example, we connected Linux/Cdorked, Linux/Ebury and Perl/Calfbot in 2014 into the single Operation Windigo welivesecurity.com/wp-content/upl… 8/
The similarity here was relevant because it was related to a unique custom string decryption routine across the three samples, one of them even being coded in a different language (Perl!). 9/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
