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. 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:

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