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.


Together with our partner CrySyS Lab, we've discovered two new, previously-unknown infection mechanisms for Miniduke. These new infection vectors rely on Java and IE vulnerabilities to infect the victim's PC.

While inspecting one of the C&C servers of Miniduke, we have found files that were not related to the C&C code, but seemed to be prepared for infecting visitors using web-based vulnerabilities.

The page hxxp://[c2_hostname]/groups/business-principles.html is used as an starting point for the attack. It consists of two frames, one for loading the decoy web page from a legitimate website (copied from http://www.albannagroup.com/business-principles.html), and another for performing malicious activities (hxxp://[c2_hostname]/groups/sidebar.html)

Source code of business-principles.html

Decoy webpage loaded

The second webpage, "sidebar.html" contains 88 lines, mostly JavaScript code, and works as a primitive exploit pack. Its code identifies the victim's browser and then serves one of two exploits. It also sends collected browser data to another script by sending a POST request to "hxxp://[c2_hostname]/groups/count/write.php".

Incidents|Flashfake Mac OS X botnet confirmed

Igor Soumenkov
Kaspersky Lab Expert
Posted April 06, 16:54  GMT
Tags: Apple MacOS, Botnets, Apple, Flashfake

Earlier this week, Dr.Web reported the discovery of a Mac OS X botnet Flashback (Flashfake). According to their information, the estimated size of this botnet is more than 500, 000 infected Mac machines.

We followed up with an analysis of the latest variant of this bot, Trojan-Downloader.OSX.Flashfake.ab.

It is being distributed via infected websites as a Java applet that pretends to be an update for the Adobe Flash Player. The Java applet then executes the first stage downloader that subsequently downloads and installs the main component of the Trojan. The main component is a Trojan-Downloader that continuously connects to one of its command-and-control (C&C) servers and waits for new components to download and execute.

The bot locates its C&C servers by domain names, and these names are generated using two algorithms. The first algorithm depends on the current date, and the second algorithm uses several variables that are stored in the Trojan’s body and encrypted with the computer’s hardware UUID using RC4 cipher.

We reverse engineered the first domain generation algorithm and used the current date, 06.04.2012, to generate and register a domain name, "krymbrjasnof.com". After domain registration, we were able to log requests from the bots. Since every request from the bot contains its unique hardware UUID, we were able to calculate the number of active bots. Our logs indicate that a total of 600 000+ unique bots connected to our server in less than 24 hours. They used a total of 620 000+ external IP addresses. More than 50% of the bots connected from the United States.

Geographical distribution of active Flashfake bots

We cannot confirm nor deny that all of the bots that connected to our server were running Mac OS X. The bots can be only identified by a unique variable in their User-Agent HTTP header named “id”, the rest of the User-Agent is statically controlled by the Trojan. See example below:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1; sv:2; id:9D66B9CD-0000-5BCF-0000-000004BD266A) Gecko/20100101 Firefox/9.0.1"

We have used passive OS fingerprinting techniques to get a rough estimation. More than 98% of incoming network packets were most likely sent from Mac OS X hosts. Although this technique is based on heuristics and can’t be completely trusted, it can be used for making order-of-magnitude estimates. So, it is very likely that most of the machines running the Flashfake bot are Macs.

Approximate distribution of OSes used to connect to our server
comments      Link

Research|The mystery of Duqu Framework solved

Igor Soumenkov
Kaspersky Lab Expert
Posted March 19, 13:42  GMT
Tags: Duqu

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

Research|The Mystery of the Duqu Framework

Igor Soumenkov
Kaspersky Lab Expert
Posted March 07, 15:58  GMT
Tags: Duqu

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.



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.

PNF DLL file

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.

302 resource

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.

Configuration block

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.

comments      Link