The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1

Back to Stuxnet: the missing link

Kaspersky Lab Expert
Posted June 11, 13:30  GMT
Tags: Stuxnet, Vulnerabilities and exploits, Flame, Cyber weapon, Cyber espionage

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:

  • 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:


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


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.


Oldest first
Threaded view


2012 Jun 11, 19:32


http://www.prevx.com/filenames/1302415679693314105-X1/DAT3B.TMP.EXE.html -- related?



2012 Jun 11, 19:32

Quick question

Alex: Did you get personal security (bodyguard) as analyze this software is quite risky.



2012 Jun 11, 20:02


This so called "Bundestrojaner" appeared in Germany has similiar functionality as Flame. Corelated?



2012 Jun 11, 22:24

Re: Bundestrojaner

"Bundestrojaner" is only ransom...



2012 Jun 11, 23:13

Re: Re: Bundestrojaner

I think you missed something...
http://www.securelist.com/en/blog/208193167/Federal_Trojan_s_got_a_Big_Bro ther



2012 Jun 12, 17:52

Re: Re: Re: Bundestrojaner

indeed, is a special case; doubt that it has a large population
GEMA Ransirac more...


Jeff H.

2012 Jun 12, 17:50

Re: Bundestrojaner

I have studied the FLAME virus not from its technical implementations, but from a psychological analasys point of view, I have to conclude this.

looking at the big picture, there are only three nations in the world who can achieve this kind of coop work.
A contractor certainly was involved making FLAME happen in the first place.

The three nations I am talking about is Germany at number 1 as prime suspect with the scientific expert knowledge of designing(BND), the second suspect would be the United Kingdom for security and quality assurance(Secret Service aka MI6), and the third suspect would be the Israel Secret Agency Mossad perhaps for distripution.

The brain behind the espionage project can be no other than the USA NSA. A coop link to Russia is as far as I am concerned out of scope. Neither Japan (I think).

My assumptions are based on historical data how secret agencies act and implement and develop strategies.

At this point it is theory at best, but we are against something too big to ever find out who it was.

What we need is global awareness that such things never will stop. In fact, these things will get even worst. What we have seen with FLAME, is not even the tip of the iceberg.



2012 Jun 11, 21:31


Stuxnet dropper -
MD5: 2fb979eb3e8d8b1571cdd0df334279 69
SHA1: 46104bf26300a5fb7a4f799d80e141 b95465d0cc
File size: 611840 bytes

Decrypted [with resources] -
MD5: 2f4e30a497ae6183aabfe8ba23068c 1b
SHA1: 1df6ae2a5594ab29a6e60b6d929612 8b1f9fd980
File size: 1603072 bytes



2012 Jun 12, 00:02


First team base in US and second Israel...



2012 Jun 12, 15:43

Hands up!

Hands up, you and your team are great! I love reading this, please keep up the good work Aleks!



2012 Jun 13, 03:01

Looking at the cute file names in Flame, I would characterize them all as mild slang that only a female native American speaker -- the project coordinator -- would use. These are not the words of a person raised in Australia, Canada, Ireland, New Zealand or the British Isles and certainly not of someone who spoke English as a second language. (Of course that person could have emigrated to another country long before Flame was underway.)

At the time credit was being taken publicly for Stuxnet, DARPA announced their large, long-standing research program for creating offensive malware architectures, while distancing themselves contemptuously from the deployment side. I don't see large defense contractors having the skill set to write actual hacker modules, that would make a whole lot more sense for people on the security software side (who know the 'literature' and could provide for example the list in Flame of 346 things that avoid triggering anti-virus software).

The timeline here is silent detection but not annoucement of Flame a couple years back, followed by this spring's Stuxnet braggadocio, followed immediately by Flame announcement, followed immediately by every security software firm in the world saying they caught it years ago, followed by silence about their largest single customer, the government, who would have been really really annoyed by a 2010 announcement.


Apira Prima

2012 Jul 18, 03:23

Re: and 1 more question

* "... the cute file names ... that only a female native American speaker ... would use."
: True, but not necessarily female

* "... every security software firm in the world saying they caught it years ago, followed by silence about their largest single customer, the government, who would have been really really annoyed by a 2010 announcement."
: True, sadly
______________________________ __________________

After all I read about 'Flame-Deployment',like...

1) 'Yet Not Closed Security-holes' in Windows (let open deliberately)
2) Additional 'Faked/Stolen' Microsoft certificates
3) Some 6 to 10MB package-downloads from faked Microsoft update-servers (initial infection, not network)

... so, after that and similar strange information from other sites, including their own stupid justifications, my question is:

"What exactly is MICROSOFT(c) doing there?"
or "Why is the CIA visiting all the time?"
or even "What has Microsoft Update to do with HOME SECURITY?"

Good Night, and Good Luck

Edited by Apira Prima, 2012 Jul 18, 03:41

If you would like to comment on this article you must first

Bookmark and Share