Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


05:22 PM
Connect Directly

'Flame' Fans Notion Of More Weapons Yet To Be Found

Targeted attack looks a lot like conventional spyware, but with some major twists -- and questions about links to Stuxnet, Duqu

It's big -- 20 times the size of Stuxnet -- and it's stealthy -- operating undetected for years -- but the newly discovered Flame cyberespionage malware at its core is really just next-generation spyware.

This latest cyberweapon, which has the earmarks of a well-funded nation-state, further confirms suspicions that there are still other such attacks out there stealing information in the shadows that we can't see, security experts say. Flame doesn't use the same codebase as Stuxnet or Duqu, but there are some haunting parallels, including Iran as a prime target, a modular design akin to Duqu's, and that Flame uses the same exploits Stuxnet did. But Flame appears so far to be good old-fashioned espionage: It steals documents, takes screenshots of the victim's machine, records Skype calls, and snoops on email and instant messaging sessions.

Security researchers worldwide had a memorable Memorial Day yesterday when word got out that the new information-siphoning Trojan with worm features, known as Flame or Flamer, had been discovered infecting Windows machines in Iran, Israel, Egypt, Lebanon, Saudi Arabia, Sudan, and Syria. Iran's Computer Emergency Response Team (CERT) said in a post that Iranian PCs had been targeted and infected by Flame, and said that it had written and distributed a detection tool to "selected organizations and companies" in early May, and that it now had a removal capability as well.

In a rare move, the Iranian CERT also reached out to some members of the antivirus community with information on Flame. Mikko Hypponen, chief research officer at F-Secure, whose company had been contacted by the Iranian CERT, says he was indeed surprised to hear from them. "They emailed us, promising additional info after we had exchanged encryption keys. We sent our keys and haven't heard from them since," Hypponen says.

Chris Wysopal, CTO at Veracode, says Flame does some of the same basic things that the Back Orifice spyware did back in 1998, and BO2K, for example, such as keystroke-grabbing, screenshot-recording, and extracting files. "That's like run-of-the-mill spyware from 12 to 14 years ago," he says.

Flame adds a few modern-day twists to the spyware theme, with the ability to use a victim's Bluetooth feature to send commands to it, for example. Yet it's not necessarily about what Flame does, but how the malware is written and structured, security researchers at Kaspersky Lab and Symantec who have studied Flame samples say.

"The way the malware was structured really shows a high level of professionalism -- they have their own libraries to handle SSL, SSH, and there's a lot of data into SQL databases," says Roel Schouwenberg, senior antivirus researcher for Kaspersky Lab.

Flame's operation is unique and advanced as well. "It's very conservative in how it spreads. It only spreads via a USB or network after the attacker instructs it to do so. It may only spread once," Schouwenberg says. "And the vast majority of infections out there are actual intended targets. This isn't Stuxnet, where we saw tens of thousands of infections globally and only a handful that mattered."

That points to some serious manpower to review and manage all of the audio and other data captured, he says. It's also infecting more targets than Duqu, which went after about 50 organizations worldwide. Flame appears to be going after hundreds of different targets, and Kaspersky expects the numbers to reach more than 1,000 when all is said and done.

Given Flame's modular architecture, there could be more components out for more than just espionage, too, experts say. "Right now, all we're seeing is the cyberespionage part. But we're operating under the assumption that we haven't uncovered all of the modules out there," Kaspersky's Schouwenberg says. "It's very possible and plausible that there's a module out there that would be responsible for interacting with industrial control systems ... maybe even part of sabotage."

And Stuxnet/Duqu and Flame could be parallel efforts by the same actors, experts say. "It looks like two teams were contracted to do the same thing ... maybe for redundancy," Schouwenberg says. "The fact that they share unique exploits between them very strongly suggests a link between them."

The Budapest University of Technology and Economics' Laboratory of Cryptography and System Security (CrySys), echoed that in its analysis of Flame (PDF): "We cannot exclude the possibility that the attackers hired multiple independent development teams for the same purpose, and sKyWIper and Duqu are two independent implementations developed for the same requirement specifications."

Next Page: A Smaller But More Targeted Body Count

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

1 of 2
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This gives a new meaning to blind leading the blind.
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-16
There is a XSS vulnerability in the ticket overview screens. It's possible to collect various information by having an e-mail shown in the overview screen. Attack can be performed by sending specially crafted e-mail to the system and it doesn't require any user intraction. This issue affects: OTRS A...
PUBLISHED: 2021-06-16
A deserialization flaw was found in Apache Chainsaw versions prior to 2.1.0 which could lead to malicious code execution.
PUBLISHED: 2021-06-16
Insecure storage of sensitive information has been reported to affect QNAP NAS running myQNAPcloud Link. If exploited, this vulnerability allows remote attackers to read sensitive information by accessing the unrestricted storage mechanism. This issue affects: QNAP Systems Inc. myQNAPcloud Link vers...
PUBLISHED: 2021-06-16
Rapid7 Nexpose is vulnerable to a non-persistent cross-site scripting vulnerability affecting the Security Console's Filtered Asset Search feature. A specific search criterion and operator combination in Filtered Asset Search could have allowed a user to pass code through the provided search field. ...
PUBLISHED: 2021-06-16
tEnvoy contains the PGP, NaCl, and PBKDF2 in node.js and the browser (hashing, random, encryption, decryption, signatures, conversions), used by TogaTech.org. In versions prior to 7.0.3, the `verifyWithMessage` method of `tEnvoyNaClSigningKey` always returns `true` for any signature that has a SHA-5...