Flame aka Flamer aka Skywiper is a sophisticated trojan application discovered in 2012. Since then it has been the subject of extensive analysis by malware research community. The trojan has been recognized as extraordinarily complicatied, with a modular design and advanced algorithms. The degree of Flame’s complexity raised many theories about its origins. One of the earliest reports about Flame was published by CrySyS Lab and contained mostly behavioral observations, i.e. interactions with OS, filesystem, network, interaction timings. This inspired us to delve a little bit more into its internal operations, so as to gather insight that has not, to our knowledge, yet been published.

Code injections

Code injection is a long known and popular technique employed by malware authors to distribute malicious operations into various operating system elements, ranging from ring 3 structures, such as processes & threads (thread injection, hooks) to ring 0 objects (deploying drivers, GDT hooking, overwriting kernel memory).

Thread injection can also be observed in the Flame installation process.

But in this case simple thread injection is turned into a precise tool for transfering code into other processes and threads and is used extensively throughout the bot’s lifecycle (since installation until suicide). Flame uses this technique to move and copy its elements around a victim’s operating system with a stunning agility. In course of our analysis we encountered that it employs an elaborate technique to inject some sensitive parts of code. We share the details we’ve found in this article.

Chain of injections

As we can read in the CrySyS report:

“At startup, mssecmgr.ocx is loaded as LSA Authentication Package. About 2 minutes later advnetcfg.ocx is loaded by services.exe. It is repeated every 2 to 3 minutes 3 times in total. About 2 minutes later services.exe loads nteps32.ocx from mssecmgr.ocx, and then winlogon.exe also loads nteps32.ocx. This file is loaded several times. In the meantime, explorer.exe starts 5 iexplore processes that subsequently create wpgfilter.dat.”

– CrySyS Skywiper report, Activation and propagation, Startup sequence

The fact that the explorer.exe process creates several iexplore.exe instances all of a sudden is especially interesting. Let us clarify what that means: Flame has propagated its elements through four processes in order to perform its trojan operations! We decided to investigate this process in detail.

Let us analyze, what happened in course of this process. The victims computer is compromised, among other possible vectors, through exploitation of the MS10-061 vulnerability. Upon a successful break-in, rundll32.exe module is started and ordered to load and execute Flame’s main module – mssecmgr.ocx. It performs various installation operations (including registering LSA service, so that the bot will be loaded during startup after reboot) and then finds services.exe process and injects parts of its code into it.

Now, services.exe distributes subsequent parts of code through regular injections into various elements of operating system. It also prepares and injects code for explorer.exe.

We tracked this injection in order to research its purpose. Injected thread waits for a signal from services.exe and then creates an iexplore.exe process with main thread suspended.

From now on, services.exe and iexplore.exe communicate with each other over a named pipe (in our case: PipeGx16, but this name could be constructed from randomly chosen characters and could differ among installations). A thread running in services.exe context writes its orders into the pipe. Then iexplore.exe process reads and executes them. One of the orders being executed is to connect to windowsupdate.microsoft.com, as shown in the pictures. This is a proof of one of Flame’s trojan operations – setting up covert connection. This activity might be checking for Internet connectivity or, more likely, a prelude to sophisticated man-in-the-middle attack, so called “Gadget” attack. The iexplore.exe process remains running and executing orders until PipeGx16 is being closed. After that, explorer.exe terminates iexplore.exe.

Evading detection

This is the most elaborate use of code injection we’ve seen in malware. Usually the process of executing a trojan routine (such as creating an internet covert connection) involves only one thread injection. This is true even in the case of advanced banking trojans. The Flame’s process that we analyzed involved three injections and it’s one of several evidences of its advanced architectural design. But, one may ask, why do this in such a complex way? The answer is obvious: to remain undetected for long time. Let us examine some of the significant features of Flame’s injections.

First, Internet connection is being set by the iexplore.exe process. This way Flame evades many automated checks and superficial analysis. For example, the explorer.exe process trying to setup an internet connection (which is the case in SpyEye) is a suspicious sign, because creating connections with the network is simply not its purpose; contrary to iexplore.exe, whose major purpose is to interact with the web.

Also, connection attempts made to Windows Update site is hardly going to raise an eyebrow even in restricted segments of corporate or government networks, because everyone knows that Windows systems are expected to contact that site. After all, it was supposed to be protected by “secure” cryptographic routines … which we now know were circumvented with the already mentioned Gadget attack. This is a sophisticated attack employing an excellent 0day exploit, very unlikely to be detected for a long time, as indeed turned out to be the case.

Also, the fact that iexplore.exe is being created and terminated by explorer.exe is the most natural thing! When the user launches her favourite browser, she does so via explorer.exe interface. That is why Flame uses explorer.exe as a proxy, so that process hierarchy remains completely consistent.

Summary

Flame employs the most sophisticated system of code injections we’ve observed in malware. It distributes its elements throughout the OS processes using chains of up to three injections involving up to four processes in order to perform its trojan operations. The distribution among various processes, with respect to natural process hierarchy, renders behavior-based detection very hard. This system is one of Flame’s exceptional features which allowed it to operate undetected for months and years and the reason for its widespread recognition.