Threat-Intel with GLIMPS technology
Threat-Intel with GLIMPS technology
You’ve probably already heard of Mirai: it’s a well-known and widespread botnet, the sources of which are publicly available on GitHub. There are versions of it for many architectures, and multiple variants. This makes it a very good case study for GLIMPS: we can recompile it ourselves for different architectures, compilers and compilation options, in order to measure the performance of our technology. Below you can see the result obtained when analyzing a file. It was an instance of Mirai for amd64, compiled with GCC.
By observing the results, we can see that this sample of Mirai was already present in the base (sha256 identical first ascended). Our sample has a 100% correlation with itself, which is quite reassuring ! But it is also correlated with other samples of mirai, which although different (the hash of the code is different from the analyzed file) are still 100% correlated. In fact, the GLIMPS technology allows us to free ourselves from the artifacts induced by the compilation process. From the concept-code point of view, we can see that the 2 samples are identical. Our binary would be detected as a mirai malware even if the first sample had not been present in the database. This is one of the interests of GLIMPS-Malware: it is not necessary to have the signatures of each variant of a malware to detect them: a few versions will be more than enough to detect all the variants, including those that have not yet been created or detected. You can also have a look at our Use Case “Detection and characterization of unknown malware” on this subject”.
What about Threat Intell
Firstly, our sample of Mirai has indeed been detected as an exemplar of the Mirai family… But what is also very interesting in this result is that we also see another family appearing: the correlation rate is of course lower (15%), but GLIMPS-Malware tells us that Mirai is also close to copies of the Bashlite family. Digging a little deeper, we find information in the documentation confirming that Bashlite was Mirai’s ancestor. It is therefore logical that the 2 have some code in common, which GLIMPS-Malware has detected. We wanted to find out for sure… time to use our favorite reverse engineering software… GLIMPS-Audit of course !
Fast analysis by reverse-engineering... with GLIMPS-Audit !
Our Mirai sample has no debug symbol. However, for bashlite, the attacker had forgotten to remove the debug symbols. First step, use GLIMPS-Audit! We will then be able to retrieve the bashlite documentation in our mirai sample.
Comparing our 2 binaries, we find 25 so-called “trusted” associations:
If we observe a random function in Ida, we can see that, even if in detail the assembler code is not identical, it is indeed the same code, and that both probably come from the same original source (in the specific case of this function that we have selected because it is particularly large, allowing the human eye to quickly see the similarities). Here, a hash-based technique would necessarily have failed: in a function of this size with different compiler versions, it is almost impossible that all the instructions are strictly identical.
In the specific case of Mirai, for which a version of the sources is available on Github, we can even go much further: whatever sample we want to analyze, it is easy to retrieve all the symbols from the public version by compiling it with the debug symbols. We could leave this exercise to the reader… But don’t worry, GLIMPS-Malware does it automatically for you !
Conclusion
We have seen how GLIMPS-Malware and GLIMPS-Audit could be used effectively in a complementary way in a Threat-Intel approach.