10 Aug Online detection of Gauss GReAT
25 Jun The Day The Stuxnet Died Costin Raiu
11 Jun Back to Stuxnet: the missing link Aleks
28 Dec The Mystery of Duqu: Part Seven (Back to Stuxnet) 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”.
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|
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.
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.
The driver is the first component of Duqu to be loaded in the system. As we discovered, the driver and other components of malware are installed with a dropper exploiting a 0-day vulnerability (CVE-2011-3402). The driver is registered in the HKLM\System\CurrentControlSet\Services\ registry path. The exact name of the registry key varies in different versions of Duqu drivers.
Once the driver is loaded, it decrypts a small block that contains its registry key and the name of the registry value to be read from that key. It also contains the name of the driver object to create.
All versions of the driver available at the moment have the same registry value name, “FILTER”.
The driver then registers the DriverReinitializationRoutine that queues the WorkerRoutine where actual driver initialization is performed. In the WorkerRoutine the driver reads the “FILTER” value from registry and decrypts it with a hard-coded encryption key. There are two known versions of decryption routine and two corresponding decryption keys. The driver also locates the NTOSKRNL.EXE or NTKRNLPA.EXE module and gets the addresses of API functions for further usage.
The decrypted “FILTER” value from registry contains the list of records that contain the name of the process (“services.exe”), the path to corresponding PNF DLL file that will be injected in that process and the decryption key (0xAE240682) that is used to decrypt the PNF DLL file.
After initialization the driver registers LoadImageNotifyRoutine that will be then called by Windows each time a new module is loaded. The routine checks if the name of image matches one of these specified in “FILTER” value and if it does, starts the injection: it decrypts and copies the PNF DLL file into an allocate memory region on that process. It also builds an copies a stub EXE file into that process that is then used as a loader for the PNF DLL.
As soon as “KERNEL32.DLL” is loaded in the same process, it locates addresses of API functions required by the loader EXE and modifies the original entry point of the main process module so that it passes execution to the loader EXE code.
The loader EXE module performs initial initialization of the PNF DLL module and then executes the export as specified in the configuration (“FILTER”). After that it restores the code of the original entry point and returns execution to the original process module. The loader also interacts with the driver module using a custom IOCTL code to change memory protection of the original entry point code.
This module is stored on disk as an encrypted block of data. As soon as it is decrypted, it turns out to be a DLL packed with UPX. Known versions of PNF DLL modules export 8 or 6 different functions by ordinal numbers.
Export 2 runs export 6 in a separate process.
Export 4 runs export 5 in a separate process.
Export 5 starts a thread in “services.exe” process that loaded the 302 resource (see below) and, if provided with correct information by the callee, installs a complete new set of Duqu components.
Export 6 stops the driver and completely uninstalls all components of Duqu. Export 8 and 1 initialize the PNF DLL module and start main threads.
It seems that ordinal 1 is intended to export primary functionality of the DLL. First, it loads the configuration information from another PNF file, the PNF Config file. If the file is not present, it is created from an encrypted hard-coded copy that is stored in the PNF DLL file.
The name of the configuration file is different for every version of Duqu. The PNF Config contains the name and path to the driver component, to the PNF DLL and PNF Config itself.
When the PNF Config is created, the date of creation is written into the file. The file also contains the TTL (“time to live”) value: a separate thread started by PNF DLL monitors if TTL days passed since the creation date, and after that runs the uninstallation routine.
Some versions of the PNF DLL also start an RPC server similar to the one found in Stuxnet.
The PNF DLL also provides API for manipulating the configuration file from external modules using globally available events.
Depending on the flags in the PNF Config, the PNF DLL code looks for specific processes: the list of process names in the PNF Config, “explorer.exe”, “svchost.exe” and then injects code in them. The code to be injected is stored in binary resource 302 found in PNF DLL.
Depending on the flag in the PNF configuration file, it is either a DLL loader module or a block of data (equivalent of decompressed “.zdata”, see below). Both configuration have been found in different Duqu versions. The PNF DLL checks a flag in PNF Config and determines whether to pass execution to the DLL loader or to locate the payload DLL and call it directly.
The loader DLL module is similar to PNF DLL. The main purpose of the loader is to decompress its “.zdata” section and pass execution to the main payload that is contained in decompressed data.
The .zdata block contains the header that starts with the magic number 0x48747193. It contains the offsets and sizes of the DLL loader, the payload configuration block and the payload DLL.
The configuration block contains the name of the temporary file to use %TEMP%\~DR0001.tmp, additional binary data controlling the behavior of the payload and information required to connect to the C&C servers. There are two lists of C&C servers, one can contain domain names, IP addresses or names of network shares, and the other contains IP addresses in binary format and is used to connect using Windows HTTP (winhttp) services. Although the configuration blocks we have found so far are similar and are set up to connect to its C&C using HTTP and HTTPS, the payload DLL is able to connect to a network share and even become a server.
We are still analyzing the payload. It contains 256K of C++ code with extensive use of STL and its own complex class hierarchies, probably own framework.
The payload is able to connect to C&C server using either winhttp library or connection to a network share IPC$ endpoint. It is able to connect using proxy server configuration of Internet Explorer. It also contains code for acting as a HTTP server and processing the same requests as served by the C&C. The payload is able to load an external DLL module provided by the C&C and interact with it using a pre-defined API. The most noticeable module discovered so far is the infostealer module. There are also modules for updating the TTL value in the PNF DLL configuration, for reading the network and disk storage configuration from the infected machine.
It also can form a PNF DLL with a configuration block and the payload DLL ready for distribution to other machines.
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.
As we continue to investigate the Duqu targeted attack, there is new information that suggests the malware was created to spy on Iran's nuclear program.
Some background and facts:
We can now confirm that some of the targets of Duqu were hit on April 21, using the same method involving CVE-2011-3402, a kernel level exploit in win32k.sys via embedded True Type Font (TTF) file.
According to analysis by IrCERT (Iran's Computer Emergency Response Team) Duqu is an upgraded version of "Stars":
If we are to believe these reports, then it means that Duqu was created in order to spy on Iran's nuclear program.
Just yesterday (November 4), the United Nations announced it was in possession of plans from Iran to make computer models of a nuclear warheads.
"The annex will also say that more than 10 nations have supplied intelligence suggesting Iran is secretly developing components of a nuclear arms program - among them an implosion-type."
It would not be surprising that Stars and Duqu were used to collect such information.