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.

Introduction

Gauss is the most recent cyber-surveillance operation in the Stuxnet, Duqu and Flame saga.

It was probably created in mid-2011 and deployed for the first time in August-September 2011.

Gauss was discovered during the course of the ongoing effort initiated by the International Telecommunications Union (ITU), following the discovery of Flame. The effort is aimed at mitigating the risks posed by cyber-weapons, which is a key component in achieving the overall objective of global cyber-peace.

In 140 chars or less, “Gauss is a nation state sponsored banking Trojan which carries a warhead of unknown designation”. Besides stealing various kinds of data from infected Windows machines, it also includes an unknown, encrypted payload which is activated on certain specific system configurations.

Just like Duqu was based on the “Tilded” platform on which Stuxnet was developed, Gauss is based on the “Flame” platform. It shares some functionalities with Flame, such as the USB infection subroutines.

In this FAQ, we answer some of the main questions about this operation. In addition to this, we are also releasing a full technical paper (HTML version and PDF version) about the malware’s functionalities.

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:

• Intercept browser cookies and passwords.
• Harvest and send system configuration data to attackers.
• Infect USB sticks with a data stealing module.
• List the content of the system drives and folders
• Steal credentials for various banking systems in the Middle East.
• Hijack account information for social network, email and IM accounts.

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.

Gauss Architecture

In addition, the authors forgot to remove debugging information from some of the Gauss samples, which contain the paths where the project resides. The paths are:

One immediately notices “projects\gauss”.

In regards to the “white” part - we believe this is a reference to Lebanon, the country with the most Gauss infections. According to Wikipedia, “The name Lebanon comes from the Semitic root LBN, meaning "white", likely a reference to the snow-capped Mount Lebanon.” http://en.wikipedia.org/wiki/Lebanon#Etymology

Deep inside one of Stuxnet’s configuration blocks, a certain 8 bytes variable holds a number which, if read as a date, points to June 24th, 2012. This is actually the date when Stuxnet’s LNK replication sub-routines stop working and the worm stops infecting USB memory sticks.

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.

Duqu is back

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:

• The code was compiled with different optimization settings and/or inline attributes of functions.
• The size of the EXE stub that is injected with the PNF DLL was increased by 32 bytes.
• The LoadImageNotifyRoutine routine now compares the module name with “KERNEL32.DLL” using hash checksums instead of simple string comparison.
• The size of the encrypted configuration block was increased from 428 to 574 bytes. There are no new fields in in the block, but the size of the registry value name (“FILTER”) field was increased. This makes the registry value name easily modifiable - probably for future use.
• The algorithm of the two subroutines that decrypt the encrypted config block, registry value and PNF DLL has been changed. This is the third known algorithm used in the Duqu encryption subroutines.
• The algorithm of the hash function for the APIs has changed. All the hash values were changed correspondingly.

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.

The Quest for Identification

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:

• Variants of LISP
• Forth
• Erlang
• Google Go
• Delphi
• OO C
• Old compilers for C++ and other languages

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.

Code layout

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.

Continue reading

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.