29 Aug What was that Wiper thing? GReAT
10 Aug Online detection of Gauss GReAT
25 Jun The Day The Stuxnet Died Costin Raiu
27 Mar The mystery of Duqu: Part Ten Aleks
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.
Several days ago, our colleagues from Symantec published an analysis of a new destructive malware reported in the Middle East. Dubbed “Narilam”, the malware appears to be designed to corrupt databases. The database structure naming indicates that targets are probably in Iran.
We have identified several samples related to this threat. All of them are ~1.5MB Windows PE executables, compiled with Borland C++ Builder. If we are to trust the compilation headers, they appear to have been created in 2009-2010, which means it might have been in the wild for a while:
The earliest known sample has a timestamp of “Thu Sep 03 19:21:05 2009”.
In April 2012, several stories were published about a mysterious malware attack shutting down computer systems at businesses throughout Iran.
Several articles mentioned that a virus named Wiper was responsible. Yet, no samples were available from these attacks, causing many to doubt the accuracy of these reports.
Following these incidents, the International Telecommunication Union (ITU) asked Kaspersky Lab to investigate the incidents and determine the potentially destructive impact of this new malware.
After several weeks of research, we failed to find any malware that shared any known properties with Wiper. However, we did discover the nation-state cyber-espionage campaign now known as Flame and later Gauss.
It is our firm opinion that Wiper was a separate strain of malware that was not Flame. Although Flame was a highly flexible attack platform, we did not see any evidence of very destructive behavior. Given the complexity of Flame, one would expect it to be used for long-term surveillance of targets instead of direct sabotage attacks on computer systems. Of course, it is possible that one of the last stages of the surveillance was the delivery of a Wiper-related payload, but so far we haven-t seen this anywhere.
After the publication of our whitepaper about the Gauss cyber-attack, we have been asked if there is an easy way for users to check their system for infection. Of course the most reliable way is to download and install our antivirus solution or use the free Kaspersky Virus Removal Tool.
If someone needs to double-check or for some reason cannot download full antivirus package, we offer a quick and easy way to check for the presence of Gauss component.
The idea of checking the system using a webpage comes from the wellknown Hungarian research lab, known as CrySyS. They have also introduced a web-based method to check your system for Palida Narrow. Their test webpage is currently available here: http://gauss.crysys.hu.
We used the same idea and tried to improve the detection method. Now it works without server interaction.
What is Gauss? Where does the name come from? Gauss is a complex cyber-espionage toolkit created by the same actors behind the Flame malware platform. It is highly modular and supports new functions which can be deployed remotely by the operators in the form of plugins. The currently known plugins perform the following functions:
The modules have internal names which appear to pay tribute to famous mathematicians and philosophers, such as Kurt Godel, Johann Carl Friedrich Gauss and Joseph-Louis Lagrange.The module named “Gauss” is the most important in the malware as it implements the data stealing capabilities and we have therefore named the malware toolkit by this most important component.
|Variant||Path to project files|
|Dec 2011-Jan 2012||c:\documents and settings\flamer\desktop\gauss_white_1|
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.
In my previous blogpost about the Duqu Framework, I described one of the biggest remaining mysteries about Duqu – the oddities of the C&C communications module which appears to have been written in a different language than the rest of the Duqu code. As technical experts, we found this question very interesting and puzzling and we wanted to share it with the community.
The feedback we received exceeded our wildest expectations. We got more than 200 comments and 60+ e-mail messages with suggestions about possible languages and frameworks that could have been used for generating the Duqu Framework code. We would like to say a big ‘Thank you!’ to everyone who participated in this quest to help us identify the mysterious code.
Let us review the most popular suggestions we got from you:
While analyzing the components of Duqu, we discovered an interesting anomaly in the main component that is responsible for its business logics, the Payload DLL. We would like to share our findings and ask for help identifying the code.
At first glance, the Payload DLL looks like a regular Windows PE DLL file compiled with Microsoft Visual Studio 2008 (linker version 9.0). The entry point code is absolutely standard, and there is one function exported by ordinal number 1 that also looks like MSVC++. This function is called from the PNF DLL and it is actually the “main” function that implements all the logics of contacting C&C servers, receiving additional payload modules and executing them. The most interesting is how this logic was programmed and what tools were used.
The code section of the Payload DLL is common for a binary that was made from several pieces of code. It consists of “slices” of code that may have been initially compiled in separate object files before they were linked in a single DLL. Most of them can be found in any C++ program, like the Standard Template Library (STL) functions, run-time library functions and user-written code, except the biggest slice that contains most of C&C interaction code.
Layout of the code section of the Payload DLL file
This slice is different from others, because it was not compiled from C++ sources. It contains no references to any standard or user-written C++ functions, but is definitely object-oriented. We call it the Duqu Framework.
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.
Over the past few weeks, we have been busy researching the Command and Control infrastructure used by Duqu.
It is now a well-known fact that the original Duqu samples were using a C&C server in India, located at an ISP called Webwerks. Since then, another Duqu C&C server has been discovered which was hosted on a server at Combell Group Nv, in Belgium.
At Kaspersky Lab we have currently cataloged and identified over 12 different Duqu variants. These connect to the C&C server in India, to the one in Belgium, but also to other C&C servers, notably two servers in Vietnam and one in the Netherlands. Besides these, many other servers were used as part of the infrastructure, some of them used as main C&C proxies while others were used by the attackers to jump around the world and make tracing more difficult. Overall, we estimate there have been more than a dozen Duqu command and control servers active during the past three years.
Before going any further, let us say that we still do not know who is behind Duqu and Stuxnet. Although we have analyzed some of the servers, the attackers have covered their tracks quite effectively. On 20 October 2011 a major cleanup operation of the Duqu network was initiated. The attackers wiped every single server they had used as far back as 2009 – in India, Vietnam, Germany, the UK and so on. Nevertheless, despite the massive cleanup, we can shed some light on how the C&C network worked.