Flame lights its own self-destruct fuse

Summary:Amid the exposure of Flame, its authors appear to be going to ground, using what control they have of the malware to force it to self-destruct and disappear (almost) without a trace.

Amid the exposure of Flame, its authors appear to be going to ground, using what control they have of the malware to force it to self-destruct and disappear (almost) without a trace.

(Burning Fuse Macro image by p.Gordon, CC BY 2.0)

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.

One other peculiar aspect of Flame's self-destruction is that, according to Symantec, Flame could have killed itself without downloading browse32.ocx.

"Previously analysed Flame code showed us a component named SUICIDE, which is functionally similar to browse32.ocx. It is unknown why the malware authors decided not to use the SUICIDE functionality, and instead makes Flame perform explicit actions based on a new module."

Although they are similar in function and both appear to miss the same temporary file, there may be more to browse32.ocx than is immediately apparent. Kaspersky Lab's Costin Raiu, noted on Twitter that there's a major bug in the module and wondered if anyone else has also found it.

Topics: Security


A Sydney, Australia-based journalist, Michael Lee covers a gamut of news in the technology space including information security, state Government initiatives, and local startups.

zdnet_core.socialButton.googleLabel Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.