Researchers Uncover New Version of the Infamous Flame Malware

In 2012 when researchers at the security firm Kaspersky Lab publicly exposed the massive and sophisticated suite of nation-state spy tools called Flame, the attackers behind it, seemingly in a panic, swiftly shut down their operation once they realized they’d been caught. They sent a kill module to disable and erase the malware on infected machines—most of which were in the Middle East and North Africa—and also wiped command-and-control servers they had been using to communicate with them.

But now researchers at Alphabet’s Chronicle Security say they have discovered what appears to be a new version of Flame that popped up in 2014 and likely remained active until 2016. The finding shows that instead of killing their operation, the attackers simply re-tooled their spy kit and added strong encryption to make it harder to detect and reverse engineer.

“Nobody ever expected to see Flame again. We figured it was too old and expensive [for the attackers] to waste time retooling rather than … just build a whole new platform,” said Juan-Andres Guerrero-Saade, one of the Chronicle security researchers who made the discovery.

Similarly, Guerrero-Saade and his Chronicle colleague Silas Cutler, also recently uncovered evidence that Stuxnet—the sophisticated virus/worm created by the US and Israel to sabotage Iran’s nuclear program in 2007—has connections to another malware family known as Flowershop. Flowershop was operating as early as 2002, several years before Stuxnet was developed, and it appears that some of Flowershop’s code made it into a Stuxnet component, suggesting the two development teams collaborated or at the very least shared code. If true, the finding expands the number of malware families on the Stuxnet family tree. Researchers have previously found connections between Stuxnet and Flame and between Stuxnet and two other malware families known as Duqu and the Equation Group, the latter a group of tools attributed to the NSA.

The researchers say the Flame and Stuxnet discoveries are possible thanks to new tools and investigative techniques that have only become available to researchers in the last few years. These include YARA, a tool designed by a Spanish security researcher in 2007 that only started to become popular with security researchers in 2015.

YARA lets researchers create rules or search parameters to scan entire networks for code and patterns of activity or search through vast repositories of malicious and suspicious code to spot code re-use across malware families. It can also uncover other patterns and similarities that connect seemingly disparate malware families and threat actors. Such findings can provide evidence that different malware families were created by the same group or that different groups shared code or collaborated in the development of malicious tools.

“At the time [the developers] would have been re-working [Flame] in 2013, there was no code-similarity analysis,” said Guerrero-Saade. “It wasn’t scalable where I could say, here, take a …body of malware samples and find me all the things that are similar to one another. That’s something that we can do now, that Google can do now, that Kaspersky can do now."

The Chronicle researchers say their findings show how periodically reviving investigations of malware cold cases, as new investigative tools become available, can yield surprising and interesting results. They plan to present their findings today at the Kaspersky Security Analyst Summit in Singapore.

Chronicle is particularly well placed to do such investigations. The company was launched last year by its parent company Alphabet, which is also parent company to Google, and has access to a massive repository of malware and suspected malware that people have submitted to VirusTotal website over the years. VirusTotal, a free antivirus scanning website Google acquired in 2012 and that is now operated by Chronicle, aggregates dozens of antivirus scanning tools from various companies in one place; anyone can upload suspicious files to the site to see if any of the scanning engines consider it malicious. That repository of files can then be analyzed at scale by Chronicle to match malicious files and code that share similarities.

“What got [Flame] caught was essentially taking the time to do a retrospective search in the first place, and our code similarity techniques,” Guerrero-Saade says.

Flame 2.0

Flame, which is believed to have been created by Israel, has always held a lot of fascination for the research community. It was the first modular spy platform discovered in the wild, with multiple plug-ins that could be swapped out according to whatever tools were needed for each victim. It had a lot of capability that was unique at the time it was discovered, and also used a highly sophisticated technique for spreading. The attackers tricked Microsoft into issuing them a legitimate Microsoft certificate, which they used to sign their malicious files. Then they subverted the trusted Windows Update mechanism, through which Microsoft distributes patches and software upgrades to customers, to deliver those malicious files to targeted victims instead, doing so in a way that made it look like they came from Microsoft’s server. The attackers also managed a fleet of 80 command-and-control domains to communicate with infected machines until they faked Flame’s death in May 2012, pushing out the kill module to infected machines and closing shop on the command-and-control servers.

Guerrero-Saade describes the group behind Flame as “one of the most daring threat actors ever discovered.” So it made sense when he and Cutler were looking to test their theory that new research tools and techniques could help shed light on old threats to focus their retroactive investigation on Flame.

They crafted YARA rules to search the VirusTotal archive for anything resembling Flame and uncovered files that had been submitted to VirusTotal by someone in late 2016. The files had been compiled in February 2014, nineteen months after Flame 1.0 went … up in flames. None of the antivirus scanners on the website detected the new files as malicious at the time.

The original Flame attacked systems in Iran and other parts of the Middle East and had modules that would do things like turn on the internal microphone of an infected machine to record conversations the user conducted near the computer or over Skype or, using the infected computer’s Bluetooth functionality, scan for other Bluetooth-enabled devices in the vicinity, such as a mobile phone, and siphon the contacts folder from it. Unfortunately, the researchers don’t yet know what the new version of Flame is capable of doing.

The developers used strong encryption to create this version of Flame, which the Chronicle researchers so far haven’t cracked. As a result, they haven’t been able to determine yet what this new version of Flame does once it infects machines. But they hope that in going public with their findings now, the security community will collaborate to crack the encryption and perhaps uncover additional components of Flame 2.0.

Stuxshop

The second discovery the researchers made—the connection between Stuxnet and Flowershop—occurred after they created YARA rules to find anything that shared or had similar code to Stuxnet.

Flowershop was a threat actor active from 2002 to 2013 that targeted victims in the Middle East. Kaspersky Lab discovered it in 2014, but has never written publicly about it. Instead the company published a private report that went only to subscribers of its threat intelligence. Kaspersky dubbed the threat Flowershop because “flower” appeared in a number of the domain names used for its command-and-control servers. Other researchers have called it Cheshire Cat.

The YARA search they conducted showed that a component in Stuxnet that was used to manage communication between infected machines and the attackers’ command-and-control servers shared four instances of code overlap with Flowershop. The Chronicle researchers have dubbed the component Stuxshop for this reason.

In one case, the code that appears in Stuxnet and Flowershop was used by Stuxnet to determine what version of the Windows operating system was running on an infected machine. The second determined if the machine was configured with internet proxy settings. The third and fourth looked for the presence of a specific value in the machine’s registry key.

The code overlap does not pop up in any other malware, the researchers say.

“Querying a multi-petabyte collection of both goodware and malware confirmed that this code is only shared by Flowershop and Stuxshop samples,” the researchers write in a paper they’re releasing today. This, they say, supports the theory that Flowershop’s developers collaborated with the developers of Stuxnet or shared code with them.

Guerrero-Saade says there are still a lot of mysteries around their Flame and Stuxnet findings, but he says he hopes they will encourage other researchers to re-examine old threats with the new tools that are now available.

“If something that was researched by literally everyone in this space seven years ago has this much still left to be found, then I promise that a lot of the other stuff that’s getting reported on a weekly basis [is] just barely scratching the surface.”