Not even a couple of weeks passed since the
discovery of Flame, with the help of colleagues from OpenDNS and GoDaddy, we were able to redirect malicious domains to our server. As a result of a detailed analysis of the information thus obtained, our experts came to the following conclusions:
• Flame command servers that operated for several years were disabled immediately after last week Kaspersky Lab uncovered the existence of a malicious program.
• Currently, more than 80 domains that are involved in transferring data to Flame command servers, which were registered in the period from 2008 to 2012, are known.
• Over the past 4 years, Flame command servers alternately located in various countries of the world, including Hong Kong, Turkey, Germany, Poland, Malaysia, Latvia, the United Kingdom and Switzerland.
• Fake registration data and various registrar companies were used to register the domains of the Flame command servers, and this activity began in 2008.
• Intruders using Flame to steal information were especially interested in office documents, PDF files, and AutoCAD drawings.
• The data uploaded to Flame command servers was encrypted using relatively simple algorithms. The stolen documents were compressed using the open source Zlib library and a modified PPDM compression algorithm.
• According to preliminary data, the 64-bit version of the Windows 7 operating system, which was previously recommended by Kaspersky Lab as one of the safest, was not affected by Flame.
Flame geography ')
What did we manage to learn?
Details about the infection method and distribution of the Flame server infrastructure can be found in our
Securelist blog post. Here we provide some statistics about the geography of distribution and the most interesting facts.
For example, here are the current Flame statistics from KSN:

Obviously, the largest number of victims of Flame is in the Middle East. It is important to note that some of the victims may use different VPN / proxy services. In such cases, infected systems may have, for example, European IP addresses, although they are physically located in the Asian region. Also, some of the "victims" may actually be machines of other researchers. However, in general, the statistics look fairly accurate and reflect the geographical distribution of infections.
What about operating systems affected by Flame? This is how the statistics obtained on the basis of the OS data of those systems where infections were detected look like:

The largest number of infections is noted on systems with Windows 7 32-bit. In second place - Windows XP. It is important to note that Flame does not work on Windows 7 64-bit, which we previously recommended as a good solution to protect against other types of threats.
Statistics from our sinkhole and from OpenDNSOur partner in this study, the company OpenDNS, has gathered together information on the dates of registration of Flame domains in recent years. You can see this animated data here:
www.opendns.com/flame-timeline
Over the last week, our server has registered many hits from infected users - below you can see statistics on their location. It is necessary to take into account that the vast majority of infected machines have already been cured with the help of antivirus programs. Thus, we see connections of those victims who, apparently, do not use antiviruses or have not updated them for a long time.
We also noticed connections from the UK, Spain, Russia and Romania, which belong to various experts, both independent and from security companies.

Below are statistics on the 10 most frequently used domains accessed by our sinkhole server:

Currently, 28 Flame-related domains are redirected to a Kaspersky Lab sync server owned by: flashupdates.info, nvidiadrivers.info, nvidiasoft.info, nvidiastream.info, rendercodec.info, syncstream.info, videosync.info, dnslocation.info, dnsmask.info, dnsportal.info, dnsupdate.info, flushdns.info, localgateway.info, pingserver.info, serveflash.info, serverss.info, autosync.info, bannerspot.in, bannerzone.in, micromedia. in, mysync.info, newsync.info, syncdomain.info, synclock.info, syncprovider.info, syncsource.info, syncupdate.info and ultrasoft.in.
Data transmitted by FlameWhen Flame connects to the synchole, it sends a POST request to identify itself. After that, a large packet of data is sent that contains a lot of “interesting” information, for example, about the version of Flame, its configuration, history of activity in the infected system, data extracted from documents, and so on.

In all the configurations we observed, the same “LifeStyle2” password was used. This password is stored in the Flame configuration file and can be changed.
The data packet uploaded to the server contains encrypted log files and other compressed information. If you decrypt this data, you can find information about the version of Flame, which is transmitted to the server.
The distribution of Flame by versions connected to our server is as follows:

Most connections were made by version 2.242, which is the one we originally discovered and analyzed. This confirms that it is the most common version of Flame. But it is not the most relevant: we see one connection from a user infected with version 2.243!
Version 2.080 is also very interesting - this is a small version of “mssecmgr.ocx” (~ 890kb), which does not contain all the modules that are available in a large 6 megabyte version. We also have a sample of this option, and we analyzed it simultaneously with a large sample.
Among the computers that connected to our Sinkhall, there are some very interesting cases: three PCs - in Lebanon, Iraq and Iran. During our Sinkhole operation, the versions of Flame on these machines changed - it is likely that the worm updated itself during this time. For example, option 2.212 changed to 2.242 in two of these cases. This indicates the existence of the still unknown C & C, which also functioned during our syncholy. Or about the unknown mechanism of updating Flame.
Among all the data extracted from the systems, the attackers clearly have an increased interest in drawings in AutoCAD. This is an interesting detail, since it is known that AutoCAD projects were also targets of the Duqu Trojan.
In addition to the DWG files that are AutoCAD projects, Flame purposefully searches for PDF and text files, as well as other documents, and creates short reference books about the files found. He also hunts for e-mail and many other types of various “interesting” (high-value) files that are listed in the worm's configuration.
The data sent to the management server is encrypted using simple XOR encryption combined with a replacement cipher. In addition, many blocks inside are compressed using Zlib and PPDM libraries.
Interestingly, the data transmitted to the server is divided into packets of 8192 bytes. This is probably done to recover from errors - it is known that the Internet in the Middle East is very slow and not very stable.
Another interesting feature of Flame is the use of SSH connections for data transfer. Apparently (despite the fact that we could not reproduce this behavior), when the Internet is working, but Flame servers are not available via SSL, it tries to use SSH.
An SSH connection is established using the Putty-based library built into the worm. Currently, the server's IP address and username / password are unknown. It is possible that they are updated via C & C and arrive only when there are temporary problems with SSL. One of the reasons for using SSH can be a common situation with a ban on SSL / HTTPS traffic in some countries, such as Iran.
Last week, Kaspersky Lab established contacts with CERTs of several countries to inform them about the Flame domains and the IP addresses of malicious servers. We want to thank these teams for helping us with this research.
If you represent a government CERT and want more information about Flame servers, please contact us at theflame@kaspersky.com.
Instead of conclusionKaspersky Lab would like to thank GoDaddy (GoDaddy Network Abuse Department) and William MacArthur, the network abuse department, for their prompt response and invaluable support for this investigation. The OpenDNS security research team (OpenDNS security research team) also provided us with valuable assistance during the investigation.