Connect with us

Hi, what are you looking for?

SecurityWeekSecurityWeek

Cyberwarfare

Security Researchers Connect Flame Malware to Stuxnet

Following the initial discovery of the Flame malware, researchers originally believed there was no significant similarity between its code and development methods and those of the Tilded platform, the development platform that Stuxnet and Duqu are based on.

Following the initial discovery of the Flame malware, researchers originally believed there was no significant similarity between its code and development methods and those of the Tilded platform, the development platform that Stuxnet and Duqu are based on.

Characteristics including the massive 20 MB size of Flame, the use of LUA programming language, and use of many modules in order to maximize its capabilities, were all indications that Flame was not connected to Duqu or Stuxnet’s creators.

Today, however, Kaspersky researchers are saying that some previously unknown facts have emerged that completely transform the current view of how Stuxnet was created and its link with Flame.

According to Kaspersky Lab, new evidence “proves without a doubt, that the ‘Tilded’ platform is indeed connected to the Flame platform.”

While similarities between Flame and Stuxnet may be minimal from what has been learned so far, this latest research shows that the creators cooperated at least once during the early stages of development.

According to Kaspersky researchers, an early version of Stuxnet that appeared to be created in June 2009 contains a module known as “Resource 207”, an encrypted DLL file that contains an executable file that is 351,768 bytes in size and named “atmpsvcn.ocx”. Interestingly, a subsequent version of Stuxnet that was found in 2010 surfaced with Resource 207 module completely removed.

Advertisement. Scroll to continue reading.

This is where the connection between code previously used in Stuxnet connects with the code used in Flame.

“The list of striking resemblances includes the names of mutually exclusive objects, the algorithm used to decrypt strings, and the similar approaches to file naming,” the security firm explained.

“More than that, most sections of code appear to be identical or similar in the respective Stuxnet and Flame modules, which leads to the conclusion that the exchange between Flame and the Duqu/Stuxnet teams was done in a form of source code (i.e. not in binary form). The primary functionality of the Stuxnet “Resource 207” module was distributing the infection from one machine to another, using the removable USB drives and exploiting the vulnerability in Windows kernel to obtain escalation of privileges within the system. The code which is responsible for distribution of malware using USB drives is completely identical to the one used in Flame.” 

From the analysis so far, the Kaspersky team has come to several conclusions:

• By the time Stuxnet was created (in January-June 2009), the Flame platform was already in existence

• 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, at the time, was a true 0-day. This enabled an escalation of privileges, presumably exploiting MS09-025, which has since been fixed.

• After 2009, the evolution of the Flame platform continued independently from Stuxnet.

Based on these conclusions, Kaspersky researchers say two independent developer teams have been in existence, each of which has been developing its own platform since at least 2007-2008.

“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,” said Alexander Gostev, Chief Security Expert, Kaspersky Lab. “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.”

While the newly-discovered facts show some connection between the two cyber weapons, Kaspersky researchers are still confident that Flame and Tilded are completely different platforms.

“They each have different architectures with their own unique tricks that were used to infect systems and execute primary tasks,” Gostev adds. “The projects were indeed separate and independent from each other. However, the new findings that reveal how the teams shared source code of at least one module in the early stages of development prove that the groups cooperated at least once. What we have found is very strong evidence that Stuxnet/Duqu and Flame cyber-weapons are connected”.

Just last month it was revealed through a New York Times report, citing a book written by one of its reporters, that the Obama administration was behind the Stuxnet attacks. Based on this new research and the prime targets (infections) of Flame being Iran and other middle east countries, can we conclude that the U.S. is also behind Flame? 

Written By

For more than 15 years, Mike Lennon has been closely monitoring the threat landscape and analyzing trends in the National Security and enterprise cybersecurity space. In his role at SecurityWeek, he oversees the editorial direction of the publication and is founder and director of several leading cybersecurity industry conferences around the world.

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing for the latest cybersecurity threats, trends, and expert insights.

Click to comment

Trending

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Today’s attackers are no longer breaking in — they’re logging in. Join this live webinar as we break down the modern identity attack chain and examine how recent breaches exploited weaknesses in authentication, identity verification, and access management processes.

Register

AI has accelerated both sides of the fight. Adversaries are weaponizing vulnerabilities faster, while defenders are racing to ship detections and configurations. Join this live webinar as we explore how to prove your controls actually hold against new threats, map your security maturity, and unite breach simulation with automated pentesting into a single, coordinated program.

Register

People on the Move

Stephen Garcia has been named Chief Information Security Officer at BreachRx.

Kasper Lindgaard has been appointed Vice President of Security Strategy at CoreView.

Chaim Mazal has been named Chief Information Security Officer at GitLab.

More People On The Move

Expert Insights

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest cybersecurity news, threats, and expert insights. Unsubscribe at any time.