Researchers find direct link between Flame, Stuxnet malware

Shared source code, says Kaspersky Lab

Security researchers today said that they have found a direct link between the notorious Stuxnet worm and the more-recently-discovered Flame espionage malware, indicating that the two teams cooperated and collaborated.

The news ties Flame to the U.S. and Israeli governments, which reportedly designed and launched Stuxnet in an attempt to sabotage Iran's nuclear program.

"We're very confident that the Flame team shared some of their source code with the Stuxnet group," Roel Schouwenberg, a senior researcher with Moscow-based Kaspersky Lab, said in an online presentation early Monday about the company's findings. "It's conclusive proof that the two worked together, at least once."

Stuxnet, a powerful cyberweapon that crippled parts of Iran's nuclear fuel enrichment effort, was first discovered in mid-2010, but researchers later traced its first variant, and first attack, to June 2009.

Flame's timeline is more murky, but most researchers agree that it goes back at least to 2010.

Today, Kaspersky said that its analysis shows that Flame harks back to no later than the summer of 2008, perhaps earlier.

The two pieces of malware -- Flame for reconnaissance, Stuxnet for attack -- each included a module that appears to originate from the same source code, likely written by a single programmer. That module was used to infect Windows PCs through USB flash drives, and exploited a vulnerability that was patched in June 2009.

When the attack code module was written, however, the vulnerability Microsoft fixed in MS09-025 was still unpatched, and thus a "zero-day" bug. At the time it quashed the flaw, Microsoft said it had not been used in the wild.

Not true, said Kaspersky: The elevation-of-privilege exploit of a Windows kernel vulnerability had been used by both the first version of Stuxnet and early editions of Flame. "The [attack] module had a creation date of February 2009," said Schouwenberg. "It exploited a zero-day at the time of creation, and most likely at the time of Stuxnet's deployment."

That variant, dubbed "Stuxnet.a," was relatively unsuccessful or ultra-quiet, or both, according to researchers. It wasn't until 2010's Stuxnet.b that researchers stumbled upon the worm.

Kaspersky dug into its detection logs last week to look for possible evidence of a link between Flame and Stuxnet, and found one.

"Flame was a kick-starter," Schouwenberg said, explaining the use of the code similar to both Stuxnet and Flame. "In 2010, the Stuxnet group removed that [module], and each team went their separate ways."

Schouwenberg said he wasn't sure why the Stuxnet group pulled the attack module, but speculated that it was because Microsoft patched it several months after its creation. Later versions of Stuxnet relied on a different -- and at the time also unpatched -- vulnerability to do the work of the yanked module. "It was no longer needed, and maybe [the Stuxnet team] did not want to jeopardize the Flame operation."

Samples of Flame found by researchers last month, however, also contained the code.

In a detailed blog post, Kaspersky spelled out the similarities between the modules in both pieces of malware.

Differences are small but still significant, because they show that the Flame authors -- who did their work before Stuxnet's makers by Kaspersky's timeline -- probably shared the source code of the module, not just an executable file.

And that's important.

"[Flame's developers] shared their intellectual property with Stuxnet, which is huge news," said Schouwenberg, arguing that the former had to know they were doing so and thus dismissing the idea that a mutually-known third party -- perhaps the employers of both teams -- was the origin of the code sharing.

"In any kind of software endeavor, you don't share your source code with just anyone," Schouwenberg said. "Source code is your ultimate possession. It's your source of income, actually. So we're really quite sure that the Flame team had to have approved the sharing of the code."

Previously, Kaspersky and other security firms had said that the evidence showed the two groups were funded by the same organization. Today's revelations proves that, and more, Schouwenberg said.

"This shows that the Flame and Stuxnet operations were parallel projects," said Schouwenberg. "And now we're 100% sure that they worked together."

Research done by other security firms backs up Kaspersky's take of today.

In February 2011, for example, Symantec outlined the multiple waves of Stuxnet attacks, and using date stamps on the code, said that the first campaign infected PCs just 12 hours after Stuxnet was compiled.

At the time Symantec disclosed its research, Liam O Murchu, director of operations with the company's security response team, said that the nearly-instantaneous bulls-eye meant that the attackers planned carefully, and had pinpointed their targets long before they had wrapped up their work.

Under that theory, Flame would have been the tool that had scouted out the Windows machines or networks later targeted and attacked by Stuxnet.

Kaspersky's new research also ups the number of previously-unknown, or zero-day, vulnerabilities exploited by Stuxnet from four to five. When Stuxnet was first dissected, the fact that it used four, much less five, zero-days was considered astounding, and evidence of the sophistication of the worm and its need to have been funded by a well-heeled organization, such as a government.

"The significance shows that there was more than one team, and that they worked together at one point," said Vitaly Kamluk, Kaspersky's chief malware expert. "Further research may tell us more about the whole organization of the project."

Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld. Follow Gregg on Twitter at @gkeizer, on Google+ or subscribe to Gregg's RSS feed. His email address is

See more by Gregg Keizer on

Read more about malware and vulnerabilities in Computerworld's Malware and Vulnerabilities Topic Center.

Join the CSO newsletter!

Error: Please check your email address.
Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Gregg Keizer

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts