Malware & Threats

Flame Command & Control Domains Registered in 2008

Flame Used Microsoft Certificate

Flame’s controlled burn through computer systems around the world may have started with command and control (C&C) domains registered as early as 2008, according to Kaspersky Lab researchers.

<p style="text-align: center;"><img src="/sites/default/files/Flame-Malware-Risk.jpg" alt="Flame Used Microsoft Certificate" title="Flame Used Microsoft Certificate" width="650" height="237" style="text-align: center;" /></p><p>Flame's controlled burn through computer systems around the world may have started with command and control (C&C) domains registered as early as 2008, according to Kaspersky Lab researchers.</p>

Flame’s controlled burn through computer systems around the world may have started with command and control (C&C) domains registered as early as 2008, according to Kaspersky Lab researchers.

Described as a sophisticated toolkit for cyber-espionage, Flame has primarily hit computers in the Middle East. Though Flame was initially thought by many to have first appeared in 2010, the findings from Kaspersky Lab – in combination with the report from the Laboratory of Cryptography and System Security at the Budapest University of Technology and Economics stating the main component of the malware had been observed in the wild in 2007 – offers more evidence that it may have been under the radar much longer.

Kaspersky Lab, which is working with OpenDNS to pull the covers away from the Flame malware, revealed today that more than 80 different C&C domains were used in the Flame operation. According to Kaspersky, the Flame C&C domains were registered with a variety of registrars by someone using fake identities. Generally, each fake identity registered two or three domains, but in some cases as many as four were registered by a single identity.

Many of the forged identities have fake addresses in Germany and Austria. The addresses can be traced to a number of locations, including everything from hotels to doctor’s offices to non-existent places.

“The command and control infrastructure basically went down (last) Monday,” said Roel Schouwenberg, senior researcher at Kaspersky Lab. “However we noticed some victims connecting with a newer version…over the week. So even while the command and control infrastructure was down, these victims were somehow updated.”

This fact points to several theories, he said. For one, it is possible all of the command and control domains have not been discovered. But it is also possible Flame has an update mechanism security researchers have not yet identified.

“We don’t yet have all modules that are out there, so there could be some elements to Flame, to the big Flame operation, that we haven’t yet uncovered,” Schouwenberg said.

Just recently, Microsoft revealed that components of the Flame malware were signed with a certificate that chained up to the Microsoft Enforced Licensing Intermediate PCA certificate authority – and ultimately the Microsoft Root Authority. According to Microsoft, this code-signing certificate came through the Terminal Server Licensing Service Microsoft operates to issue certificates to customers for ancillary PKI-based functions in their enterprise. Noting such a certificate could allow attackers to sign code that validates as having been produced by Microsoft, the company issued an update to address the situation Sunday.

Advertisement. Scroll to continue reading.

The use of forged and stolen certificates is not unique to Flame; in fact, the strategy was used in the case of the Stuxnet and Duqu attacks, adding another item to the list of possible connections between the malware. However, security researchers have revealed a number of differences separating them as well.

Researchers also found more differences between Flame and another notorious espionage Trojan – Duqu. 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,” blogged Alexander Gostev, head of Kaspersky’s Global Research and Analysis team. “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.”

“We definitely can’t be sure without having complete proof, or potentially someone standing up and saying that they’re behind this…the one thing we can say is that this is very sophisticated, it’s been very well, and it’s been very well executed,” said Dan Hubbard, chief technology officer at OpenDNS.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version