Interconnection of Gauss with Stuxnet, Duqu & Flame

Last week, reports of a new malware named Gauss emerged, a complex threat that has attracted a lot of media attention due to its links to Stuxnet and Flame and its geographical distribution. Since ESET has added detection for this threat, we are seeing geographical distribution of detection reports similar to those detailed by Kaspersky. The countries with the biggest impact are, in order, Lebanon, Israel and Palestine. In this blog post, we analyze the connections and similarities in programming between Stuxnet, Duqu and Flame.
The first thing that one can notice while analyzing Gauss is the abundance of object-oriented structures that makes it difficult to comprehend the malware functionality. The most prominent examples of malware that employ an object-oriented approach are Stuxnet, Duqu and Flame. Due to the complex logic of these threats, using object oriented programming is a reasonable way to efficiently implement their functionality. Stuxnet, Duqu and Flame utilize specific frameworks that are shown on the figure below:

Figure 1 ­– Stuxnet and Flame frameworks

The complexity of implementation of Gauss  is less than that of Flame, for instance. Even if you consider, for example, the size of the main module of Gauss (wmiqry32.dll) we can see that roughly 30% of size of its code section is devoted to standard library routines as shown on the diagram below:

Figure 2 – Gauss main module layout

For Flame this number is several times lower. If we arrange these threats according to its complexity then we will get the following picture (Gauss’s encrypted payload isn’t considered since we aren’t aware of its content):

Figure 3 – The threats arranged according to its complexity

Although Gauss shares some features with Stuxnet and Flame there is some evidence that this is another kind of malware rather than one based on either the Stuxnet or Flame framework. This conjecture is based on the binary analysis of the modules of Gauss and below we will present several arguments supporting this idea.
In tables 1 and 2 you can see the results of comparison of several modules of Gauss with Stuxnet and Flame. These data are obtained with the BinDiff plugin for the IDA Pro disassembler that allows us to estimate how similar the two modules are to each other.
Table 1 – Similarity of Gauss modules to Stuxnet

Table 2 – Similarity of Gauss modules to Flame

From the data contained in tables it may be concluded that Gauss is even closer to Stuxnet than to Flame. These data were also confirmed during manual analysis of the malware. For instance, we found the same structures handling string objects, memory buffers, streams and other elements in both Stuxnet and Gauss, whereas Flame utilized other structures to work with such elements.
Based on the binary analysis the only thing that Gauss shares with Flame is the way it encrypts the strings inside the binary module. But the decryption algorithms implemented in the malware are also rather different. In the figures below decryption algorithms of strings in Gauss and Flame are presented:

Figure 4 – Gauss String Decryption Algorithm

Figure 5 – Flame String Decryption Algorithm

Other features of the malware such as injection technique, configuration information storage, and so on are also different. Stuxnet and Flame employ rather complex injection mechanisms that allow them to bypass security software. They create the illusion of a legally loaded module to bypass HIPS-like systems. Unlike them Gauss utilizes rather a simple and straightforward injection technique. It merely allocates a memory buffer in the target process address space and copies the path to the module to inject into it:

Figure 6 – Gauss injection technique

Then it creates a remote thread by calling CreateRemoteThread API routine that executes only the routine LoadLibtatyW as shown in self-explanatory figure below:

Figure 7 – Decompilation of the code injecting a module

Another differentiator is that Flame implements quite complex configuration information storage as described in one of our blogs posts: “Flame: in-depth code analysis of mssecmgr.ocx”. The configuration information of Gauss has nothing in common with that of Flame and is stored in the registry value TimeStampForUI of HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability key as binary data and is easily parsed.
In our previous blog post we wrote about reconstructing the Flame framework as a composition of objects implementing a specific interface:

Figure 8 – Flame Framework Architecture

We haven’t found this architecture in any of the Gauss modules we analyzed. The only Gauss module that contains a piece of code implementing objects similar, in a rudimentary way, to one found in Flame is winshell.ocx, but there is no implementation of the framework comparable to figure 6.
As a result it may be concluded that Gauss is another standalone kind of malware, although it is quite possible that its developers are somehow connected with developers of Stuxnet and Flame. It borrows some features from these other malware but it may not be classified as something that is based on either a Stuxnet or Flame framework.

by Eugene Rodionov, Malware Researcher

http://blog.eset.com/2012/08/15/interconnection-of-gauss-with-stuxnet-duqu-flame