Skip to content

What we know so far about the Flame Trojan


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Here’s the executive summary of what the security community knows about these bad boys, called (variously, depending on who you talk to) Flame, Flamer, or Skywiper — technically speaking.

The entire infection comprises just a handful of executables — one ‘master program’ that runs everything, and the rest payloads with specific purposes/tasks. The folks running the Crysis lab in Budapest have been publishing updated PDFs that detail everything they know. The people running Iran’s MAHER CERT, who also reported on the infection, were kind enough to send me binaries to run in a test environment. The infection distribution is apparently low: Flame-infected endpoints have been estimated by others to number in the low thousands, but I have no way to verify that.

Despite how some people have misinterpreted my initial reactions to reports about Flame, I’m not yet convinced this is the work of a nation-state—or even some sort of super-cyber-James Bondian villain. If you’ve read my work, you know I’m not a FUD-spreader, and I will continue to fight unreasonable characterizations of this — or any other — malware as some sort of digital equivalent to a mortar salvo. Flame (probably) isn’t gonna blow up a doghouse, let alone anything else more infrastructure-y.

Yet, this is (for a change) sophisticated malware, rich in features, and seems like it was apparently designed with long-term surveillance in mind, rather than quick-reward data theft. As an analyst, I find it a curiosity, more interesting than yet-another-variant-of-Zbot I see so much of, that bore me to tears. Flame is, to be blunt, not a justifiable cause for a pants-wetting panic attack — unless you suddenly discover it has been listening in on your network for years, in which case, you should still not need a change of clothes, just of passwords. Is it some kind of ultimate weapon in a sort of cyber terror campaign? Hardly. It comes across to me a lot more like a dedicated network listening post and data retrieval/manipulation engine, though it may have capabilities beyond those, which researchers haven’t explored yet.

The main executable, mssecmgr.ocx, as well as most of its executable payload components, are just conventional Windows 32-bit DLLs disguised with the file suffix of an ActiveX control — Hardly a groundbreaking masquerade technique for malware, just not very common, and not at all exotic.

Each of the payloads is packed with a common malware packer, easily identifiable using tools I’ve been using for years. The ‘master control program’ mssecmgr.ocx is not packed at all, and has signatures that identify it as a Visual C++ app and a Properties Description of Windows Authentication Client Manager. The payloads have been dressed up in full camoflauge: They all use realistic-looking data in their Properties sheets. But under a modicum of scrutiny, the mere fact they contain lists of exported function calls make it kind of obvious that these files aren’t the ActiveX controls their .ocx file suffix implies.

Some of the files exhibit weird properties. The GT2 app misinterprets the contents of one of the binary data files, boot32drv.sys, as an MPEG 2 audio file, although one with a terrible bitrate. Others have properties sheets that indicate they belong to a class of old PE files originally distributed as part of Windows 2000. All lies.

I’ve dumped the DLLs from memory, which yields a treasure trove of interesting data that deserve greater scrutiny. I’ve also got the Trojans running in both virtual and bare-metal environments. Unlike some modern malware, Flame doesn’t seem to care whether it’s running in a virtual environment, and executed just fine under VMWare and VirtualBox, though I have no idea whether the behavior I was seeing in the VMs was modified in some way. It didn’t appear to be.

Among the interesting data in the dumped DLLs was a long list of filenames and registry keys. Included in the list of 182 .exe files were the names of the Kaspersky and Symantec antivirus endpoint agents and dozens of security tools. I didn’t recognize some of the names, but I did note that files associated with several well-known AV and security products were there: F-Secure, Sophos, BlackICE, CA’s eTrust firewall, SuperAntiSpyware, ZeroSpyware, SpywareTerminator, and ZoneAlarm are prominently represented on Flame’s enemies list.

The files do, in fact, change their creation and modification dates on the fly. I’m still reading through the Crysis report, which is rich with details, and I am still catching up with what’s known about this behavior, but I did observe the files self-modify and change their modification dates from 2009-07-14 to 2002-08-29 after execution.

Crysis noted, and I also saw, the string Unidentified build, Aug 31 2011 23:15:32 in the main file, which may give an indication as to the actual creation date of the Trojan; But it could also have been put there to be intentionally misleading. The guys who made this aren’t your normally-dumb cybercrooks, so it’s safe to assume anything may have been placed there to mislead researchers.

I also observed some of the SSL traffic between the infected machine and its command-and-control server. For reasons that aren’t clear, Crysis obfuscated the domain names used by the Trojan. I’m not going to blow the cover on this just yet.

What I feel comfortable saying is that I saw the infected box ping its CnC twice each hour, regularly but not to-the-second hourly, over SSL port 443. The CnC domain points to a single IP address hosted in one of LeaseWeb‘s datacenters in the Netherlands; According to Robtex, there are a total of 18 distinct domains, all with a .info TLD, hosted on this same IP. Each of the domains is registered using DomainsByProxy, a service which permits the registrant to mask his or her identity. More interestingly, all 18 domains were first registered on one of four dates: 05-Nov-2009, 03-Aug-2009, 18-Feb-2009, and 15-Feb-2009. The one my infected machine hit was one of the earliest-registered domains in the list.

I did note the presence of most, if not all, the characteristic elements of the infection in the testbeds after starting up the “MCP”: The wave8 and wave9 devices in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 registry key; temporary files in c:\windows\temp with prefixes such as ~KWI, ~rf, ~HLV, and ~DEB; and threads hooked into winlogon and services.exe. The list keeps growing.

All in all, Flame looks to be a long-term, well-planned operation. But of course, it’s not foolproof, and it can be interrupted and removed, as Iran’s MAHER CERT team and others have discovered. I’m continuing to perform analysis on the payloads and I’ll update here with relevant new information as it becomes available.Solera blog stats

%d bloggers like this: