Analysis on the Flame
It is the first time that we are faced with such a situation: our research team has been analyzing Flame worm for almost one month and we plan to continue. When Stuxnet broke out, we attempted to carry out long-term analysis, but due to certain limits, we stopped the analysis after 10 days. After the research of Stuxnet, Duqu, and Flame, we gradually find that as a traditional antivirus enterprise, we need innovation when faced with challenges and reform.
Traditional malware usually aims at infecting more computers, but gradually, attackers are driven by economic interests. The malware they develop is with specific functionalities and small sizes. As a result, it is not difficult to analyze such malware. From another perspective, though the interests-driven attackers create many serious threats, such as Trojans and botnets, the balance between attackers and antivirus vendors is still there. Antivirus teams can use the malware capture system and the automatic backend analysis platform to process lots of malware. Sometimes, new detection rules can be extracted from samples even without manual assistance. Then, the rules can be added to antivirus products. Gradually, we become more and more dependent on sandboxes and other automatic systems. Some people even think virus analysis engineers are not doing their jobs.
However, when serious threats such as Stuxnet and Flame appear, the situation becomes totally different. Users begin to ask “what does it do” and “how can we avoid similar attacks” instead of “how to detect it” and “is your product effective”. Such a situation requires us not to totally depend on the analysis streamline, but to devote ourselves to locale observation, environment simulation and detailed backend analysis.
Flame has large quantities of files and a large size. Being similar to the APT malware that we process earlier, Flame has various modules and a very complex architecture. It can perfectly hide itself in the system, and avoid the detection of antivirus products. Its encrypted modules can help hide important information. Such complex and large malware plays a big role in APT attacks. Once it finds that the system is not the specified target, it would exit and delete all the traces, so it seldom breaks out in large quantities. Flame depends heavily on lots of configuration information and remote control. By the time users find it, it usually has finished its missions. We are used to analyzing single virus samples; depend on automatic analysis and disassembly results; and add some sample tags wit hash values. Such methods seem to be outdated when we are confronted with malware like Flame.
Faced with so many samples and derivative files, we allocate the work clearly. We cooperate like ants, with each member analyzing one module and recording the analysis results in a timely fashion. We don’t expect to finally get a big research report; instead, we hope that we can collect our findings step by step, and then provide some reference for defending such attacks. The whole analysis is divided into two parts. One is the analysis of the main module which is 6MB. We devote lots of time to analyzing it, including its encryption algorithm, string information and the whole structure. The other part is the analysis of other modules. We found that some modules have the same functionalities, such as collecting information, traversing processes, and capturing screenshots. We also found some other interesting information. But we are now still in hallway there.
We will continue the analysis of Flame, and continuously update the latest research results to this report in a timely fashion. Though difficult, it is happy and meaningful to stick to this research, especially when with our friends.
The full analysis report of the Flame can be downloaded from here.