Back to Stuxnet: the missing link

Two weeks ago, when we announced the discovery of the Flame malware we said that we saw no strong similarity between its code and programming style with that of the Tilded platform which Stuxnet and Duqu are based on.

Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics. For instance, Flame never uses system drivers, while Stuxnet and Duqu’s main method of loading modules for execution is via a kernel driver.

But it turns out we were wrong. Wrong, in that we believed Flame and Stuxnet were two unrelated projects.

Our research unearthed some previously unknown facts that completely transform the current view of how Stuxnet was created and its link with Flame.

The Flame inside Stuxnet

First of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010.

The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies.

Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants.

The main differences were:

• The 2009 variant didn’t use the MS10-046 LNK file vulnerability
• In 2009, Stuxnet only had one driver file; in 2010 there were two (the second was added specifically to work with the LNK vulnerability)
• In 2009, Stuxnet used a special trick with the “autorun.inf” file to infect USB drives.

All the other differences involve minor modifications to Stuxnet’s internal structure – some modules were deleted and their functions transferred to other modules.

The most significant of those changes involved “resource 207”.

Resource “207” is 520,192 bytes in size and can be found in the 2009 version of Stuxnet. It was later dropped altogether in the 2010 version, its code merged into other modules.

List of resources in the March 2010 variant of Stuxnet

List of resources in the 2009 variant of Stuxnet

Despite the fact that Stuxnet has been the subject of in-depth analysis by numerous companies and experts and lots has been written about its structure, for some reason, the mysterious “resource 207” from 2009 has gone largely unnoticed. But it turns out that this is the missing link between Flame and Stuxnet, two seemingly completely unrelated projects.

The Tocy story

In October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s.

With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”.

When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a.

Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection.

Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet.

Resource 207

Resource 207 is an encrypted DLL file that contains another PE file inside (351,768 bytes).

Information about the date of the module’s creation

Information about the file in the resource 207

This PE file, 351,768 bytes in size, is actually a Flame plugin.

Or, to be more precise, "proto-Flame" – a module that obviously has a lot in common with the current version of “mssecmgr.ocx” and which had evolved into Flame by 2012.

We think it’s actually possible to talk about a ‘Flame’ platform, and that this particular module was created based on its source code.

A few days ago on Twitter I saw a rather humorous tweet that said Flame was so “hardcore” that a whole Stuxnet was contained in its bases. It turns out that Stuxnet’s resources actually contain a Flame platform component!

The correlations with the current variations of Flame include the following:

• Mutex names: TH_POOL_SHD_PQOMGMN_%dSYNCMTX and TH_POOL_SHD_MTX_GMN94XQ_%d
• String decryption algorithm
• Mangled class names: ?AVnxys_uwip and so on.
• Similar name to that used in the Flame architecture - with .ocx files (atmpsvcn.ocx)

Moreover, the file contains hallmarks that were earlier considered exclusive to Stuxnet:

• Names of “trigger” files: %temp%\dat3A.tmp & snsm7551.tmp
• Utilitarian module parsing functions and their interrelation and architecture
• Principles for assembling function return codes
• Similar shellcode style
• Structure for describing the version of vulnerable operating systems and checking algorithm
• Its own import

This is atmpsvcn.ocx – a Flame platform module inside Stuxnet.

Interestingly, the current variants of Flame rely on the dat3C.tmp file, whereas the Flame module inside Stuxnet used the “dat3a.tmp” file as an identifier to flag its presence in the system. One can wonder if there was also a “dat3b.tmp” somewhere in time.

Whole pieces of code from the latest Flame modules are identical to the code in atmpvsvcn.ocx. Of course, the most obvious similarity is the mutex names:

TH_POOL_SHD_PQOMGMN_%dSYNCMTX
TH_POOL_SHD_MTX_GMN94XQ_%d

Moreover, there are other known Flame modules using mutex TH_POOL_SHD_MTX_FSW95XQ_%d, that we have dated to 2010, e.g. comspol32.ocx.

The matches are even more impressive at the code level:

getdecrypted function from Resource 207

getdecrypted function from mssecmgr.ocx

DecrypString function from Resource 207

DecryptString function from mssecmgr.ocx

DecryptString function from browse32.ocx (the Flame uninstaller module circulating in May-June 2012)

Mutex used in Resource 207

Mutex used in mssecmgr.ocx

Resource 207’s main functionality was to ensure Stuxnet propagation to removable USB drives via autorun.inf, as well as to exploit a then-unknown vulnerability in win32k.sys to escalate privileges in the system at stage of infection from USB drive.

Map of resources in Stuxnet 2009

Spreading via autorun.inf is another trick that the Stuxnet 2009 version and the current variants of Flame have in common. Resource 207 operates as an infector of removable drives, copying “Flame” module as “autorun.inf” file to removable media and adding a special real autorun.inf file at end of PE file. The Main body of Stuxnet copied to USB drive as “~XTRVWp.dat” file.
The PE file is correctly processed by the operating system as real autorun.inf and hence the module is executed when an infected device is accessed.

After this, the Flame module loads ~XTRVWp.dat (main Stuxnet body) from the USB drive and injects it to system process via using EoP vulnerability.

This particular code, which exactly matches the code in resource 207, is currently used by Flame, where it is executed by the “Autorun_infector” module.

An old 0-day

The Stuxnet Resouce 207 Flame-module contains an Escalation of Privilege exploit and is using it at stage of infection from USB drive for injecting main Stuxnet body to system processes. This is of interest in its own right.

The exploit code in the file atmpsvcn.ocx is similar to that which we, Kaspersky Lab, found in the 2010 versions of Stuxnet and which was subsequently addressed by the MS10-073 patch. The code’s style, logic and details of its implementation were the same in the 2009 and 2010 code. Clearly, these two pieces of exploit code were written by the same programmer.

However, a different exploit targeting a different vulnerability, which was older and was patched by 2010, was used in the 2009 version of Stuxnet.

At the time when “resource 207” was created (February 2009), the vulnerability was not publicly known and was thus, it was a true 0-day vulnerability.

Essentially, the vulnerability consists of the absence of input data checking, allowing the NtUserRegisterClassExWOW() function to overwrite a WORD of data beyond the allocated memory range in win32k.

The function’s address in the _gpsi structure is overwritten with the address of the shellcode in two steps. Then the NtUserMessageCall() function is called, which passes control to the shellcode with kernel-level privileges.

Neither function is exported to user mode, which means that addresses and parameters for calling services directly can be found by parsing modules on disk (user32&win32k).

This vulnerability description is strikingly similar to that of vulnerability “Windows Kernel Could Allow Elevation of Privilege (968537)”, which was closed in June 2009 with patch MS09-025; however, we are still analyzing the code and can’t provide a 100% confirmation of this as yet.

The main function exploiting the EoP vulnerability in Stuxnet 2009

The main function exploiting the EoP vulnerability in Stuxnet 2010

Code used to call controlled functions in the 2009 vulnerability

Code used to call controlled functions in the MS010-073 vulnerability

Conclusions

Our analysis suggest several important conclusions, which we summarize below:

• By the time Stuxnet was created (in January-June 2009), the Flame platform was already in existence (we currently date its creation to no later than summer 2008) and already had modular structure.
• The Stuxnet code of 2009 used a module built on the Flame platform, probably created specifically to operate as part of Stuxnet.
• The module was removed from Stuxnet in 2010 due to the addition of a new method of propagation (vulnerability MS10-046) instead of the “old” autorun.inf
• The Flame module in Stuxnet exploited a vulnerability which was unknown at the time, a true 0-day. This enabled an escalation of privileges, presumably exploiting MS09-025
• After 2009, the evolution of the Flame platform continued independently from Stuxnet.

The above conclusions point to the existence of two independent developer teams, which can be referred to as ”Team F” (Flame) and ”Team D” (Tilded). Each of these teams has been developing its own platform since 2007-2008 at the latest.

In 2009, part of the code from the Flame platform was used in Stuxnet. We believe that source code was used, rather than complete binary modules. Since 2010, the platforms have been developing independently from each other, although there has been interaction at least at the level of exploiting the same vulnerabilities.