- Kaspersky Lab discovered that a module from the early 2009-version of Stuxnet, known as “Resource 207,” was actually a Flame plugin.
- This means that when the Stuxnet worm was created in the beginning of 2009, the Flame platform already existed, and that in 2009, the source code of at least one module of Flame was used in Stuxnet.
- This module was used to spread the infection via USB drives. The code of the USB drive infection mechanism is identical in Flame and Stuxnet.
- The Flame module in Stuxnet also exploited a vulnerability which was unknown at the time and which enabled escalation of privileges, presumably MS09-025.
- Subsequently, the Flame plugin module was removed from Stuxnet in 2010 and replaced by several different modules that utilized new vulnerabilities.
- Starting from 2010, the two development teams worked independently, with the only suspected cooperation taking place in terms of exchanging the know-how about the new “zero-day” vulnerabilities.
Earlier this week, Kaspersky Labs noted that in a matter of hours after researchers had announced the discovery of Flame, the command and control infrastructure behind Flame went dark. This infrastructure was important because Flame is initially configured to contact a number of these servers and then run the control scripts that they serve. However, by 28 May — the day that Flame's details began to emerge — requests for these scripts were met with 403/404 errors, hampering efforts to learn more about the servers behind the malware.
Kaspersky Lab, with the assistance of GoDaddy and OpenDNS, attempted to sinkhole the malware; however, Symantec noted that this effort was only partially successful — Flame's authors still had control of a few command and control servers — enough to communicate with some of the infected computers.
"[Flame's authors] had retained control of their domain registration accounts, which allowed them to host these domains with a new hosting provider," Symantec wrote on its blog.
From here, infected machines received a new module from the remaining command and control servers — browse32.ocx — which has the purpose of covering Flame's tracks. It not only has a hit-list of all Flame-related files and folders to delete, but it subsequently rewrites random characters on the disk to ensure that the old data can't be retrieved.
There is one exception to the firing squad, and that is a temporary file: ~DEB93D.tmp. According to CrySyS' research (PDF), it is an encrypted file that contains a SQLite database of NetBIOS name look-ups. In theory, it would provide forensic teams with the ability to determine the names of all the computers it was able to see and possibly infect.
Researchers haven't come to an agreement as to whether sparing this file was an intended feature or an oversight by Flame's authors, but its existence is already being used as a temporary indicator for if a computer is, or was, infected by Flame.
CIO magazine gives backhanded praise to the (presumed) US programmers who made Stuxnet, and, presumably, Flame:
Even though many folks suspected Flame was made in the U.S.A., this is as close as anyone has come to saying so. As an American I feel a wee-bit of national pride. So what if our critical utilities infrastructure is less secure than my son’s piggy bank? And so what if the government’s defense and intelligence networks are more compromised than a herd of Kardashians? We made the coolest piece of malware since William Gibson invented Black Ice in Neuromancer.