The Roof Is on Fire: Tackling Flame’s C&C Servers

On Sunday, May 27 2012, the Iranian MAHER CERT posted a note announcing the discovery of a new targeted attack dubbed “Flamer”. On Monday 28 May 2012 aat 9am EST, after an investigation prompted and supported by the International Telecommunication Union, Kaspersky Lab and CrySyS Lab from Hungary announced the discovery of Flame (aka Skywiper), a sophisticated cyber-espionage toolkit primarily targeting Windows computers in the Middle East.

Several hours later, around 4PM GMT, the Flame command-and-control infrastructure, which had been operating for years, went dark.

For the past weeks, Kaspersky Lab has been closely monitoring the C&C infrastructure of Flame. In collaboration with GoDaddy and OpenDNS, we succeeded in sinkholing most of the malicious domains used by Flame for C&C and gain a unique perspective into the operation.

Before going further, Kaspersky Lab would like to thank the “GoDaddy Network Abuse Department” and to William MacArthur for their fast reaction and exceptional support of this investigation. ,b>The OpenDNS security research team also offered invaluable assistance during the course of this investigation.

Our findings from analysing the infrastructure can be found below.

Introduction

Since both Flame and Duqu appear to be targeting similar geographical regions and have been created with similar goals in mind, we will provide an analysis from the point of view of comparing the Flame C&C infrastructure with the Duqu infrastructure.

In the past, Kaspersky Lab analyzed the Duqu C&C infrastructure and found several important details, such as the attackers’ preference for CentOS, the use of SharpSSH to control the proxy servers and the huge number of hacked proxies used to hide the true identity of the attackers.

In the case of Flame, we performed a similar analysis. First of all, it’s interesting to point out a big difference from Duqu: while all the Duqu C&C proxies were CentOS Linux hosts, all of the known Flame C&C are running Ubuntu.

Additionally, while Duqu used the super stealthy way of hiding the true IP of the mothership using SSH port forwarding, Flame’s scripts are simply running on the respective servers. The reason is simple — on Monday May 28, all control scripts started returning 403/404 errors. In the case of Duqu, the real malware scripts were on a remote server and were never found.

From this point of view, we can state that the Duqu attackers were a lot more careful about hiding their activities compared to the Flame operators.

Here’s a comparison of the Duqu and Flame C&C infrastructure:

When a computer is infected with Flame, it uses a default configuration which includes 5 C&C server domains. Before contacting these servers, the malware validates the internet connection by trying to access www.microsoft.com, windowsupdate.microsoft.com and www.verisign.com using HTTPS. If the connection is successful, it will proceed to talk to the C&C domains.

In addition to the static configuration, Flame maintains a database of additional C&C servers. We have seen the additional database, which can be updated from the C&C server itself, contain 5-6 extra domains. In total, a running Flame installation can use a list of about 10 domains to try to contact the C&C. Interestingly, Flame maintains a log of activities which includes reports of connections to the C&C servers – together with timestamps.

While analysing the Flame samples recovered from the Middle East, we noticed they were trying to contact 5 different domains. Additional configuration included 6 other domains. From activity logs, we recovered 5 other domains, for a total of 11 unique domains used by our specific malware sample.

By looking at the IPs where the servers were hosted, we identified another 30 domains which were hosted on the same machines. By checking the IP history of the additional domains, we discovered another 40 domains which appear to be connected. In total, we discovered over 80 different domains which appear to belong to the Flame C&C infrastructure.

The Flame C&C domains were registered with an impressive list of fake identities and with a variety of registrars, going back as far as 2008. In general, each fake identity registered only 2-3 domains but there are some rare cases when a fake identity registered up to 4 domains.

The largest batch of Flame C&C domains was registered with GoDaddy.

Some of the fake identities used to register domains include names such as: Adrien Leroy, Arthur Vangen, George Wirtz, Gerard Caraty, Ivan Blix, Jerard Ree, Karel Schmid, Maria Weber, Mark Ploder, Mike Bassett, Paolo Calzaretta, Robert Fabous, Robert Wagmann, Romel Bottem, Ronald Dinter, Soma Mukhopadhyay, Stephane Borrail, Traian Lucescu, Werner Goetz or Will Ripmann.

Many of these forged identities have fake addresses in Germany and Austria, notably Vienna. We do not know what is the reason why Vienna was such an attractive choice for the attackers.

Let us take a closer look at the fake registrations. For instance, let’s consider the domain “chchengine.com” which is used by the malware. It is registered to a certain “Karel Schmid”, address “rue dizerens 7, Geneva”. This is actually the address of a hotel named “Appart’Hotel Residence Dizerens”:

Here’s another example, a domain registered by a person named “Ivan Blix”.

The domain owner’s address is listed as “Koninginneweg 93, Oslo”. Searching for this address reveals there is no such place in Oslo, however, there is one in Amsterdam. Coincidentally, this is the address of another hotel, named “Apple Inn”:

All the other fake identities used addresses of hotels, various shops, organizations, doctor’s offices or simply non-existent addresses.

By collecting information on the Flame C&C infrastructure, we were able to put together a big picture into this hugely complex operation. The amount of domains and servers which were used in the Flame operation matches our previous opinion about the complexity of this malware:

The total number of known domains used by Flame for C&C and related domains is currently at more than 80. These have been registered between 2008 and 2012. During the past 4 years, servers hosting the Flame C&C infrastructure moved between Hong Kong, Turkey, Germany, Poland, Malaysia, Latvia, Switzerland, to name just a few. Such is the size of this huge operation.

Having seen the large variety of fake domains, we contacted GoDaddy and sought the redirection of all the malware domains to our sinkhole. Additionally, the OpenDNS security team supported with the redirection of malicious domains to our sinkhole in order to protect OpenDNS users.

The Flame C&C servers

If we count the IP addresses used by the Flame C&C domains during the past 4 years, eliminating the IPs of known shared hosting servers temporarily used during registration, we count up to 22 different server IPs.

Since the discovery of Flame, we got the chance to look at 5 such servers. All the servers have ports 22, 443 and 8080 open. They appear to be running Ubuntu Linux, if we are to trust the Apache and SSH headers. One of them used to have port 80 open as well, however, it was shutdown in the aftermath of the announcement of Flame.

The SSL certificates used by the Flame C&C are all self signed; the certificate of the last active domain (in Netherlands) seems to have been generated on May 18th, 2012.

Perhaps an interesting details, on Saturday June 2nd, 2012, at 20:40 GMT, a number of the Flame C&C domains which previously pointed to a server in Netherlands (91.203.214.*) have been redirected to a server in Germany (78.46.253.*).
The new server went offline on Sunday 3rd.

Statistics from KSN

The Kaspersky Security Network (KSN) is the cloud infrastructure used by Kaspersky Lab products to report telemetry and to deliver instant protection in the forms of denylists and heuristic rules designed to catch the newest threats.

We used KSN to track Flame based on the fact that it was using certain filenames which are otherwise unique to the project. Later, we obtained a sample of the malware code and used it to track the distribution around the world.

The current KSN statistics for Flame:

It’s obvious that the vast majority of targets are in the Middle East. It is important to point out that some victims might have used VPN/proxy services. In such cases, for example an infected machine could show up with a European IP while physically being located in the Middle East. Also some ‘victims’ counts might in fact be machines of other researchers. Overall though, the statistic should be exact enough to reflect the real geographical distribution of infections.

Here’s a look at the geographical distribution:

What about operating systems infected by Flame? Here’s a representation of the infections from the point of view of the specific Windows version where Flame was found:

The vast majority of Flame infections are machines running Windows 7 32 bit. Windows XP is following next. It’s important to say that Flame does not run on Windows 7 64 bit, which we previously recommended as a good solution against infections with other malware.

Statistics from Sinkhole / OpenDNS:

Our partner, OpenDNS, put together a timeline of the registration of Flame C&C domains during the past years: http://blog.opendns.com/?p=4329.

You can view their animated timeline at: https://www.opendns.com/flame-timeline/

During the past week, our sinkhole registered multiple hits from infected users – you can see a breakdown by location below. It’s important to note that the vast majority of infections have already been cleaned by AV products, so what we are seeing are victims that either do not run an AV product, or, have an outdated one.

Additionally, we have been able to pinpoint infections in UK, Spain, Russia and Romania as being security companies.

Here’s the Top 10 domains being used by infected computers to contact our sinkhole:

Currently, the following 28 Flame-related domains are sinkholed by Kaspersky Lab:

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 uploaded to sinkhole

When Flame connects to the sinkhole, it does a POST request identifying itself. Then it uploads a bigger chunk of data, which contains a lot of “interesting” information such as malware version, malware configuration, a history of activities performed in the system, data extracted from documents and so on.

In all the configurations we have seen, the same password “LifeStyle2” is used. The password is stored in the Flame configuration file and can be changed.

The packets of data uploaded to the sinkhole contain encrypted logs and other compressed information. By decrypting the data, one can find the specific version of Flame which is reporting back to its master.

The distribution of Flame versions connecting to our sinkhole looks like the following:

Most of the victims have version 2.242, which is also the version we discovered and are analyzing. This appears to be the most popular variant. Interestingly, it’s not the most recent one, there is a victim currently infected with version 2.243!

Version 2.080 is also interesting – this is a much smaller “mssecmgr.ocx” (~890K), which is missing many of the modules present in the 6MB variants. We have a copy of this variant and we are analysing it in parallel to the larger version.

Of the computers connecting to our sinkhole, there are some very interesting cases: three computers in Lebanon, Iraq and Iran. During the sinkhole operation, the Flame versions on these machines changed; suggesting Flame upgraded itself in the process. For instance, version 2.212 became 2.242 in two of the cases. This indicates the presence of yet unknown C&Cs which were operational during the sinkholing process or an unknown updating mechanism.

Between the data extracted from systems, the attackers seem to have a high interest in AutoCAD drawings. This is an interesting detail because it is known AutoCAD drawings were also targeted by the Duqu malware. In addition to DWG files, which is the native file format of AutoCAD, the malware goes through PDF and text files and other documents and makes short text summaries. It also hunts for e-mails and many different kinds of other “interesting” (high-value) files that are specified in the malware configuration.

The data uploaded to the C&C is encrypted using a simple XOR cypher, coupled with a substitution cypher. In addition to this, many blocks inside are compressed using zlib and ppdm compression libraries.

Interestingly, the data uploaded to the sinkhole is split into packets of 8192 bytes. This is probably done for error recovery — it is known that the Internet in Middle East countries is very slow and unreliable.

Another interesting feature of Flame is the use of SSH connections to exfiltrate data. Although we haven’t been able to reproduce this behavior, it seems that when the Internet works, but the C&C servers are not reachable via SSL, it uses a SSH connection instead.

The SSH connection is established by a fully integrated Putty-based library. At the moment, the IP address of the server and the username/password scheme are not known. It’s possible they are updated from the C&C at some point and only used if there are temporary SSL problems. One of the reasons for using SSH connections could be the common banning of SSL/HTTPS traffic in countries such as Iran. If SSL is down, the malware can sometimes use SSH to contact the C&C.

During the last week, Kaspersky Lab contacted CERT’s in multiple countries to inform them about the Flame C&C domain information and IP addresses of the malicious servers. We would like to thank them for their support of this investigation.

If you are a GovCERT institution and would like to receive more information about the C2 domains, please contact us at theflame@kaspersky.com.

Summary and conclusions:

• The Flame command-and-control infrastructure, which had been operating for years, went offline immediately after our disclosure of the malware’s existence last week.
• We identified about 80 total domains which appear to belong to the Flame C&C infrastructure.
• The Flame C&C domains were registered with an impressive list of fake identities and with a variety of registrars, going back as far as 2008.
• The attackers seem to have a high interest in PDF documents, Office and AutoCad drawings.
• The data uploaded to the C&C is encrypted using relatively simple algorithms. Stolen documents are compressed using open source Zlib and modified PPDM compression.
• Flame is using SSH connections (in addition to SSL) to exfiltrate data. The SSH connection is established by a fully integrated Putty-based library.
• Windows 7 64 bit, which we previously recommended as a good solution against infections with other malware, seems to be effective against Flame