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

You can read our Full Technical Paper on SPE / miniFlame here.

In May 2012, a Kaspersky Lab investigation detected a new nation-state cyber-espionage malware, which we named "Flame". Our research also identified some distinguishing features of Flame’s modules. Based on those features, we discovered that in 2009, the first variant of the Stuxnet worm included a module that was created based on the Flame platform. This confirmed there was some form of collaboration between the groups that developed the Flame and Tilded (Stuxnet/Duqu) platforms.

A more in-depth research conducted in June 2012 resulted in the discovery of another nation state-sponsored and previously unknown malware which we named «Gauss». Gauss used a modular structure resembling that of Flame, a similar code base and system for communicating with command-and-control (C&C) servers, as well as numerous other similarities to Flame.

In partnership with Symantec, ITU-IMPACT and CERT-Bund/BSI, we also published our analysis of the Flame Command and Control servers. The analysis showed that the code can understand several communication protocols to talk to different «clients» or malware:

• OldProtocol
• OldProtocolE
• SignupProtocol
• RedProtocol (mentioned but not implemented)

It can happen to anyone…and when it does it usually catches everybody – the victim and his relatives – completely unprepared. I’m talking about kidnapping.

Twice in my life I’ve been involved in helping the police track down and arrest gangs of kidnappers. The first case didn’t directly affect me or my family, but the second time a close friend of mine was kidnapped. And it turns out that our work in tackling cybercrime can also be useful to catch criminals who seem to have little connection with high-tech wrong-doing. The Internet is not just a tool for cybercrime – it is also often used to communicate with the families and friends of kidnap victims, especially to demand a ransom. When this happens, our work can be vital: evidence collected on the Internet as well, as the errors made by criminals, can help to track them down, identifying their location via their IP address.

Our previous analysis of the Flame malware, the advanced cyber-espionage tool that's linked to the Stuxnet operation, was initially published at the end of May 2012 and revealed a large scale campaign targeting several countries in the Middle East.

The Flame malware, including all of its components, was very large and our ongoing investigation revealed more and more details since that time. The news about this threat peaked on 4th June 2012, when Microsoft released an out-of-band patch to block three fraudulent digital certificates used by Flame. On the same day, we confirmed the existence of this in Flame and published our technical analysis of this sophisticated attack. This new side of Flame was so advanced that only the world's top cryptographers could be able to implement it. Since then, skeptical jokes about Flame have disappeared.

Later in June, we definitively confirmed that Flame developers communicated with the Stuxnet development team, which was another convincing fact that Flame was developed with nation-state backing.

We also published our analysis of the Flame command-and-Control (C&C) servers based on external observations and publicly available information. That helped our understanding of where the C&C servers were located and how they were registered.

With this blog post, we are releasing new information that was collected during forensic analysis of the Flame C&C servers. This investigation was done in partnership with Symantec, ITU-IMPACT and CERT-Bund/BSI.

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.

Earlier today, we received an interesting collection of samples from colleagues at another anti-malware company.

The samples are especially interesting because they contain a module with the following string:

C:\Shamoon\ArabianGulf\wiper\release\wiper.pdb

Of course, the ?wiper� reference immediately reminds us of the Iranian computer-wiping incidents from April 2012 that led to the discovery of Flame.

The malware is a 900KB PE file that contains a number of encrypted resources:

There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?

Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.

The containers

Infected USB sticks have two files that contain several encrypted sections. Named “System32.dat” and “System32.bin”, they are 32-bit and 64-bit versions of the same code. These files are loaded from infected drives using the well-known LNK exploit introduced by Stuxnet. Their primary goal is to extract a lot of information about the victim system and write it back to a file on the drive named “.thumbs.db”. Several known versions of the files contain three encrypted sections (one code section, two data sections).

The decryption key for these sections is generated dynamically and depends on the features of the victim system, preventing anyone except the designated target(s) from extracting the contents of the sections.

By the way, the 64-bit version of the module has some debug information left in it. The module contains debug assertion strings and names of the modules:

.\loader.cpp
NULL != encSection
Path
NULL != pathVar && curPos < pathVarSize
NULL != progFilesDirs && curPos < progFilesDirsSize
NULL != isExpected
NULL != key
(NULL != result) && (NULL !=str1) && (NULL != str2)
.\encryption_funcs.cpp

The data

The mysterious encrypted data is stored in three sections:

The files also contain an encrypted resource “100” that seems to be the actual payload, given the relatively small size of the encrypted sections. It is most likely that the section “.exsdat” contains the code for decrypting the resource and executing its contents.

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

In our previous blogpost, we discussed the Madi campaign, uncovered through joint research with our partner Seculert.

In this blogpost, we will continue our analysis with information on the Madi infrastructure, communications, data collection, and victims.

The Madi infrastructure performs its surveillance operations and communications with a simple implementation as well. Five command and control (C2) web servers are currently up and running Microsoft IIS v7.0 web server along with exposed Microsoft Terminal service for RDP access, all maintaining identical copies of the custom, C# server manager software. These servers also act as the stolen data drops. The stolen data seems to be poorly organized on the server side, requiring multiple operators to log in and investigate the data per each of the compromised systems that they are managing over time.

The services at these IP addresses have been cycled through by the operators for unknown reasons. There does not appear to be a pattern to which malware reports to which server just yet. According to sinkhole data and other reliable sources, the approximate locations of Madi victims are distributed mainly within the Middle East, but some are scattered lightly throughout the US and EU. It seems that some of the victims are professionals and academia (both students and staff) running laptops infected with the Madi spyware, travelling throughout the world:

Here is an approximate global map representing the approximate location of Madi victims, dependent on GeoIP data. While the overwhelming percentage of Madi victims in the middle east is not best visualized in this graphic, it helps to understand the Madi reach: