Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
The Flame inside StuxnetFirst of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010. The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies. Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants. The main differences were:
The Tocy storyIn October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s. With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”. When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a. Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection. Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet.
The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options.
SNACK: NBNS spoofingThe SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing. When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses. “Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network. SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”.
MUNCH: Spoofing proxy detection and Windows Update request“MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS” When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests.
So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server.When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server : 1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns: MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
“At the moment, we haven’t seen use of any 0-days; however, the worm is known to have infected fully-patched Windows 7 systems through the network, which might indicate the presence of a high risk 0-day.”
Our suspicion was heightened because fully patched Windows 7 machines were being infected over the network in a very suspicious manner.We can now confirm this is the main purpose of a special module of Flame called “Gadget” together with another module called “Munch”. (NOTE: It’s important to understand that the initial Flame infection could still be happening through zero-day vulnerabilities. The “Gadget” module is simply used to spread within a network from a machine that is already infected with the malware). The “Gadget” and “Munch” modules implement an interesting man-in-the-middle attack against other computers in a network. When a machine tries to connect to Microsoft’s Windows Update, it redirects the connection through an infected machine and it sends a fake, malicious Windows Update to the client. The fake update claims to be the following:
“update description="Allows you to display gadgets on your desktop."
displayName="Desktop Gadget Platform" name="WindowsGadgetPlatform">
This program (also detected as Worm.Win32.Flame.a), which is 28KB in size, has been signed by a fake Microsoft certificate:
This allows it to run in the victim’s machine without any warnings. The Flame “Gadget” downloader was compiled on December 27th, 2010. It was signed on December 28 and it was finally put into the CAB archive on Jan 11, 2011.
The following is exactly how the process occurs: the infected machine sets up a fake server by the name “MSHOME-F3BE293C”, which hosts a script that serves a full body of the Flame malware to victim machines. This is done by the module called “Munch”. When a victim updates itself via Windows Update, the query is intercepted and the fake update is pushed. The fake update proceeds to download the main body and infect the computer.
The interception of the query to the official Windows Update (the man-in-the-middle attack) is done by announcing the infected machine as a proxy for the domain. This is done via WPAD. To get infected, the machines do need however to have their System Proxy settings configured to “Auto”.As we continue our investigation of Flame, more and more details appear which indicate our initial statement: this is one of the most interesting and complex malicious programs we have ever seen. Important information: One June 4th, 2012, Microsoft released a number of blog posts and an Update for Windows which is blocking three fraudulent certificates used by Flame. We recommend that Windows users apply this update immediately. Microsoft SRD blog:http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx Microsoft security advisory 2718704:http://technet.microsoft.com/en-us/security/advisory/2718704 MSRC blog:http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx
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.
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:
|Server OS||CentOS Linux||Ubuntu Linux|
|Control scripts||Running on remote server, shielded through SSH port forwarding||Running on servers|
|Number of victims per server||2-3||50+|
|Encryption of connections to server||SSL + proprietary AES-based encryption||SSL|
|Compression of connections||No||Yes, Zlib and modified PPMD|
|Number of known C&C’s domains||n/a||80+|
|Number of known C&C IPs||5||15+|
|Number of proxies used to hide identity||10+||Unknown|
|Time zone of C&C operator||GMT+2 / GMT+3||Unknown|
|Locations of servers||India, Vietnam, Belgium, UK, Netherlands, Switzerland, Korea, etc...||Germany, Netherlands, UK, Switzerland, Hong Kong, Turkey, etc...|
|Number of built-in C&C IPs/domain in malware||1||5, can update list|
|Servers status||Most likely hacked||Most likely bought|
Duqu and Stuxnet raised the stakes in the cyber battles being fought in the Middle East – but now we’ve found what might be the most sophisticated cyber weapon yet unleashed. The ‘Flame’ cyber espionage worm came to the attention of our experts at Kaspersky Lab after the UN’s International Telecommunication Union came to us for help in finding an unknown piece of malware which was deleting sensitive information across the Middle East. While searching for that code – nicknamed Wiper – we discovered a new malware codenamed Worm.Win32.Flame.
Flame shares many characteristics with notorious cyber weapons Duqu and Stuxnet: while its features are different, the geography and careful targeting of attacks coupled with the usage of specific software vulnerabilities seems to put it alongside those familiar ‘super-weapons’ currently deployed in the Middle East by unknown perpetrators. Flame can easily be described as one of the most complex threats ever discovered. It’s big and incredibly sophisticated. It pretty much redefines the notion of cyberwar and cyberespionage.
For the full low-down on this advanced threat, read on…
What exactly is Flame? A worm? A backdoor? What does it do?
Flame is a sophisticated attack toolkit, which is a lot more complex than Duqu. It is a backdoor, a Trojan, and it has worm-like features, allowing it to replicate in a local network and on removable media if it is commanded so by its master.
The initial point of entry of Flame is unknown - we suspect it is deployed through targeted attacks; however, we haven’t seen the original vector of how it spreads. We have some suspicions about possible use of the MS10-033 vulnerability, but we cannot confirm this now.
Once a system is infected, Flame begins a complex set of operations, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard, and so on. All this data is available to the operators through the link to Flame’s command-and-control servers.
Later, the operators can choose to upload further modules, which expand Flame’s functionality. There are about 20 modules in total and the purpose of most of them is still being investigated.
After intercepting one of the domain names used by the Flashback/Flashfake Mac Trojan and setting up a special sinkhole server last Friday, we managed to gather stats on the scale and geographic distribution of the related botnet. We published information on this in our previous blog entry.
We continued to intercept domain names after setting up the sinkhole server and we are currently still monitoring how big the botnet is. We have now recorded a total of 670,000 unique bots. Over the weekend (7-8 April) we saw a significant fall in the number of connected bots:
This doesn’t mean, however, that the botnet is shrinking rapidly – these are merely the numbers for the weekend.
Over the last few days our server has registered all the data sent by bots from the infected computers and recorded their UUIDs in a dedicated database. Based on this information we have set up an online resource where all users of Mac OS X can check if their computer has been infected by Flashback.
To find out if your computer is infected and what to do if it is, visit: flashbackcheck.com
Also users can check if they’re infected with Flashfake by using Kaspersky Lab’s free removal tool.
At the end of the last year the authors of Duqu and Stuxnet tried to eliminate all traces of their activity. They wiped all servers that they used since 2009 or even earlier. The cleanup happened on October 20.
There were virtually no traces of Duqu since then. But several days ago our colleagues in Symantec announced that they found a new "in-the-wild" driver that is very similar to known Duqu drivers. Previous modifications of Duqu drivers were compiled on Nov 3 2010 and Oct 17 2011, and the new driver was compiled on Feb 23 2012.
So, the authors of Duqu are back after a 4 months break.
The newly discovered driver does not contain any new functionality compared to its previous versions. The code contains only minor modifications, and they were most likely done to evade detection from antivirus programs and detection tools such as the CrySyS Duqu Toolkit. Here’s a list of changes compared to older versions:
Old hash function, used in previous versions of the Duqu driver:
New hash function:
The fact that the new driver was found in Iran confirms that most of Duqu incidents are related to this country.
We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?
In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.
In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.
This platform can be conventionally named as ‘Tilded’ as its authors are, for some reason, inclined to use file names which start with "~d".
We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.
Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.
These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.
As we informed you earlier, we’ve recently been conducting an investigation into a number of incidents in connection with a Duqu trojan infection. Thankfully we’ve been able to make some headway in getting to the bottom of Duqu and putting together several of the previously absent components without which it has been difficult to understand what’s actually been going on.
First things first, we would like to express our sincere thanks to the specialists at CERT Sudan. They’ve been providing us with priceless assistance in our investigation, and showed the utmost professionalism - in full accordance with the values and aims of any CERT around the world. Our cooperation with the Sudanese CERT is ongoing and will cover another three incidents found in the country.
Our main achievement has been in the investigation of the incident deemed No.#1, described in my second post about Duqu. We managed to not only locate all the previously undiscovered files of this variant of Duqu, but also to find both the source of the infection and the file dropper that contains the vulnerability exploit in win32k.sys (CVE-2011-3402).
Comparing the data we uncovered with that obtained by other researchers and antivirus companies, we’ve elicited various common traits that have revealed the approximate timeline and overall methods used by Duqu’s authors.
The dates of the incident correlate with the history of discovery in Iran of a virus called Stars. At that time Iranian specialists didn’t share samples of the discovered virus with any of the anti-virus companies, and this, it has to be said, was a serious mistake, which gave rise to all subsequent events in this saga. Most probably, the Iranians found a keylogger module that had been loaded onto a system and which contained a photo of the NGC 6745 galaxy. This could explain the title Stars given to it.
It’s possible that the Iranian specialists found just the keylogger, while the main Duqu module and the dropper (including the documents that contained the then-unknown vulnerability) may have gone undetected.