Recent research into old malware threats associated with the Stuxnet attacks against Iran's nuclear program roughly one decade ago turned up several new discoveries, including a possible fourth collaborator in the clandestine operation, as well as previously unknown versions of Flame and Duqu malware.
Today, Alphabet's cybersecurity subsidiary Chronicle revealed the findings of its researchers Juan Andres Guerrero-Saade and Silas Cutler at a Kaspersky conference in Singapore, as well as in a company blog post that was supplemented by more detailed analytical reports [1, 2, 3].
The sequence of discoveries can all be traced back to single clue, gleaned from a 2017 security presentation, that suggested a new link between
the modular cyber espionage malware known as Flame and a group of nation-state actors presumed to be involved in the Stuxnet malware attack. This attack caused programmable logic controllers to malfunction in Iran's Natanz nuclear facility, resulting in centrifuge damage that at the time set back Iran's nuclear ambitions.
The Stuxnet attackers, which Chronicle collectively calls "GOSSIPGIRL," is widely understood to include the developers of Flame and Duqu, and the Equation Group. Equation Group has been prominently linked to the NSA, while Duqu is associated with Israel, and Flame has been tied to a joint U.S.-Israeli intelligence effort.
But based on Chronicle's findings, a fourth group looks to have been involved in Stuxnet's development. This actor created an old malware called Flowershop that infected Middle Eastern targets during its period of activity from 2002-2013. The malware's code can be found within a particular Stuxnet component called Stuxshop, and was used to communicate with C2 servers, among other functionality,
"The value of this recent finding is twofold: First, it suggests that yet another team with its own malware platform was involved in the early development of Stuxnet. And secondly, it supports the view that Stuxnet is in fact the product of a modular development framework meant to enable collaboration among diverse, independent threat actors," Guerrero-Saade and Cutler state in a technical report. "Our recent findings, alongside the outstanding body of previously reported technical analysis on this threat, would place the ‘Flowershop team’ alongside Equation, Flame, and Duqu as those involved in tooling the different phases of Stuxnet as an operation active perhaps as early as 2006."
Further investigation revealed another surprise: the aforementioned Flame malware, which was thought to disappear in May 2012 after its public discovery, secretly reemerged roughly two years later in the form of Flame 2.0.
Discovered in 2012, Flame, aka sKyWIper, is historically known to target Windows-based computers based in Iran. The cyber espionage toolkit, likely used in the 2014-2016 timeframe, is capable of gathering system information, creating backdoors and propagating across enterprises via Windows Update.
"Much like the original Flame, Flame 2.0 continues to comprised of multiple submodules directed by a main orchestrator reliant on an embedded Lua VM," explains the researchers' technical report. However, this revised version added new countermeasures meant to stymie researchers, and uses AES-256 (instead of version 1.0's XOR-based ciphers) to encrypt its second-stage embedded resources. However, it's not clear what final payloads Flame 2.0 ultimately delivers.
During the course of their study, the researchers also found a previously unknown version of Duqu, a malware built from Stuxnet that's designed to steal information useful toward attacking industrial control systems.
Dubbed Duqu 1.5, this particular version appears to be a bridge between the original Duqu 1.0 threat and the more advanced Duqu 2.0 in-memory modular platform that famously infected offices at Kaspersky Lab and also targeted the P5+1 Iran nuclear talks in Switzerland. (Other past Duqu campaigns have spied on companies in Europe, Africa and the Middle East, Chronicle notes.)
Attributes found in version 1.5 "included a more bloated, experimental, multi-tier loading chain," the Chronicle blog post states. "It starts with a trojanized floppy kernel driver signed with a stolen certificate to load up a registry virtual file system (VFS), that loads an in-memory orchestrator, which then loads an on-disk VFS, to deploy a series of plug-ins for further spreading and backdoor access to infected machines."
