The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1
Latest posting
By rating
By popularity

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


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)

Incidents|Full Analysis of Flame's Command & Control servers

Kaspersky Lab Expert
Posted September 17, 13:00  GMT
Tags: Targeted Attacks, Flame, Cyber espionage

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.

Incidents|What was that Wiper thing?

Kaspersky Lab Expert
Posted August 29, 13:00  GMT
Tags: Targeted Attacks, Duqu, Flame, Cyber weapon, Gauss, Wiper

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.

Incidents|Online detection of Gauss

Kaspersky Lab Expert
Posted August 10, 14:23  GMT
Tags: Stuxnet, Duqu, Flame, Gauss

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.



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:

Variant Path to project files
August 2011 d:\projects\gauss
October 2011 d:\projects\gauss_for_macis_2
Dec 2011-Jan 2012 c:\documents and settings\flamer\desktop\gauss_white_1

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.


Two weeks ago, when we announced the discovery of the Flame malware we said that we saw no strong similarity between its code and programming style with that of the Tilded platform which Stuxnet and Duqu are based on.

Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics. For instance, Flame never uses system drivers, while Stuxnet and Duqu’s main method of loading modules for execution is via a kernel driver.

But it turns out we were wrong. Wrong, in that we believed Flame and Stuxnet were two unrelated projects.

Our research unearthed some previously unknown facts that completely transform the current view of how Stuxnet was created and its link with Flame.

The Flame inside Stuxnet

First 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 2009 variant didn’t use the MS10-046 LNK file vulnerability
  • In 2009, Stuxnet only had one driver file; in 2010 there were two (the second was added specifically to work with the LNK vulnerability)
  • In 2009, Stuxnet used a special trick with the “autorun.inf” file to infect USB drives.
All the other differences involve minor modifications to Stuxnet’s internal structure – some modules were deleted and their functions transferred to other modules.

The most significant of those changes involved “resource 207”.

Resource “207” is 520,192 bytes in size and can be found in the 2009 version of Stuxnet. It was later dropped altogether in the 2010 version, its code merged into other modules.

List of resources in the March 2010 variant of Stuxnet

List of resources in the 2009 variant of Stuxnet

Despite the fact that Stuxnet has been the subject of in-depth analysis by numerous companies and experts and lots has been written about its structure, for some reason, the mysterious “resource 207” from 2009 has gone largely unnoticed. But it turns out that this is the missing link between Flame and Stuxnet, two seemingly completely unrelated projects.

The Tocy story

In 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 spoofing

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

Contents of the “MUNCH.WPAD_DATA” variable

The “MUNCH.WPAD_DATA” buffer is actually a WPAD file that is requested by network clients that implement automatic proxy server detection. The code in the WPAD file matches the MD5 hash of the hostname that the client is connecting to against its own list, and if found, offers itself as a HTTP proxy. We were able to identify the hashes:


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.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*

2) Checks if the requested URI matches any pattern specified in the list of strings called “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. If one of the expressions match, it then gets the buffer specified in the corresponding “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA” value, reads the payload value called “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” and sends it to the client.

All the payloads are listed in the Flame’s registry with names starting with “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”, and are encoded with a fixed 104-byte RC4 key.


In our FAQ on Flame posted on May 28, 2012, we postulated there might be a still undiscovered zero-day vulnerability in Flame:

“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">

In the process of infecting a client, 8 CAB files are used. One of them contains a specifically built program called WuSetupV.exe:

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.

Gadget plugin downloads the main body of the malware

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

comments      Link