Attacks/Breaches
5/31/2012
11:27 AM
Connect Directly
RSS
E-Mail
50%
50%

Flame Malware's Ties To Stuxnet, Duqu: Details Emerge

All three pieces of malware seemingly commissioned by the same entity and developed on the same platform, but by different groups of developers, security researchers say.

Three of the most high-profile pieces of malware to have been discovered in the past two years have been Stuxnet, Duqu, and as of this week, Flame. Now, researchers are suggesting that whoever commissioned Stuxnet and Duqu also ordered up Flame.

"We believe Flame was written by a different team of programmers but commissioned by the same larger entity," Roel Schouwenberg, a security researcher at Kaspersky Labs, told The New York Times. But he declined to name the larger entity--or nation states--that he thought had commissioned Duqu.

If the three different malicious applications share a common origin, each appears to have been designed for a different purpose. Duqu, for example, was cyber-espionage malware created "to act as a backdoor into the system and facilitate the theft of private information," said Kaspersky Lab security researcher Ryan Naraine in a blog post. The private information in question, according to Kaspersky Lab, included nuclear facility blueprints and industrial control system schematics. Duqu was first discovered in September 2011.

[ What do we know about Flame? See Flame FAQ: 11 Facts About Complex Malware. ]

According to Kaspersky Lab, Duqu's developers appeared to keep to Jerusalem time, and notably didn't work on the Jewish Sabbath--occurring between Friday evening and Saturday evening--in which some Jews observe a day of rest, The New York Times reported Wednesday.

Meanwhile, Stuxnet--first discovered in June 2010--was designed to sabotage the high-frequency convertor drives used in a single uranium enrichment facility in Iran. Notably, the malware adjusted the speed of the drives to run at very high and low frequencies, while reporting normal behavior via the industrial control system software interface that ran the machines. The result was destroyed centrifuges and uranium that hadn't been enriched.

Kaspersky Lab researchers last year had already noted that Stuxnet and Duqu appeared to have been developed by the same team, on the same platform, which appears to have been used between 2007 and 2011. Furthermore, they suspected that additional malware--even if it hadn't yet been found--would have also been created using the platform. Timing-wise, according to AlienVault, Flame fits into that scenario, as at least one component in Flame was first compiled in 2008, while later modules date from 2009, 2010, and 2011.

While the Stuxnet malware was designed to spread automatically, the Duqu Trojan would only infect PCs when ordered to do so via its command-and-control channel. Likewise, the Flame malware--which may have infected just 1,000 PCs--only spread to designated PCs, which made it tough for security vendors to spot or stop. "Flame has been operating under the radar for at least two years, which counter-intuitively may partially be attributed to its large size," according to a blog post from Websense.

Another similarity between the three pieces of malware is that while they might be complex, and all targeted known zero-day vulnerabilities--which can be purchased on the black market--they used coding capabilities that had been seen before. (Although in the case of Stuxnet, no one had ever seen such capabilities being used by malware to cause physical damage.) "While it really doesn't do anything we haven't seen before in other malware attacks, what's really interesting is that it weaves multiple techniques together and dynamically applies them, based on the capabilities of the infected system," according to Websense.

Researchers are continuing to study Flame to unravel how it works, and the task is made difficult by the malware's size. Notably, it starts out with an initial infection that's between 900 K and 6 MB in size, but which can grow to 20 MB after additional modules have been loaded onto a PC. "This is a lot of code, and a lot of possibility," said Bob Reny, a systems engineer at network access control vendor ForeScout Technologies, via email.

"The number of different components in W32.Flamer is difficult to grasp," according to an analysis from Symantec. "The threat is a well-designed platform including, among other things, a Web server, a database server, and secure shell communications. It includes a scripting interpreter which allows the attackers to easily deploy updated functionality through various scripts. These scripts are split up into 'apps' and the attackers even appear to have something equivalent to an 'app store' from where they can retrieve new apps containing malicious functionality."

Another interesting new Flame finding suggests that its builders may have been native English speakers. According to an analysis from Alexander Gostev at Kaspersky Lab, units in various modules sport names such as Beetlejuice (discovers nearby Bluetooth devices), Microbe (records audio), Infectmedia (infects USB drives), Euphoria (launches Flame), Limbo (creates backdoor on system), Frog (infects predefined accounts on machine), Weasel (lists the computer's directory), Gator (connects to C&C server), and Suicide (removes all files connected to Flame). Meanwhile, the purpose of other discovered units in modules, sporting with names such as Bunny, Driller, Headache, and Gadget, has yet to be determined.

Security information and event monitoring technology has been available for years, but the information can be hard to mine. In our SIEM Success report, we provide a step-by-step guide to make the most of your SIEM system. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AustinIT
50%
50%
AustinIT,
User Rank: Apprentice
6/1/2012 | 6:29:52 PM
re: Flame Malware's Ties To Stuxnet, Duqu: Details Emerge
Not rogue, but apparently working for the US and Israeli governments, according to my IW sources of course... :))
Mathew
50%
50%
Mathew,
User Rank: Apprentice
6/1/2012 | 5:04:53 PM
re: Flame Malware's Ties To Stuxnet, Duqu: Details Emerge
Are you saying some Apple developers may have gone rogue? :)
AustinIT
50%
50%
AustinIT,
User Rank: Apprentice
5/31/2012 | 8:33:36 PM
re: Flame Malware's Ties To Stuxnet, Duqu: Details Emerge
Some of those module "names" are earily similar to Apple product and feature names. Maybe Apple developers are your culprit... ;>)
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.