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

Last week, Adobe released a patch for a vulnerability in Flash Player that was being exploited in targeted attacks.

Before reading any further, we recommend you to take a moment make sure you apply this patch. Adobe offers this nifty tool to check that you have the latest version of Flash Player.

If you are running Google Chrome, make sure you have version -24.0.1312.57 m- or later.

Now back to CVE-2013-0633, the critical vulnerability that was discovered and reported to Adobe by Kaspersky Lab researchers Sergey Golovanov and Alexander Polyakov. The exploits for CVE-2013-0633 have been observed while monitoring the so-called -legal- surveillance malware created by the Italian company HackingTeam. In this blog, we will describe some of the attacks and the usage of this 0-day to deploy malware from -HackingTeam- marketed as Remote Control System.

Greetings from Dallas, Texas, where the anti-malware industry is meeting for the 22nd edition of Virus Bulletin.

The Java 0day activity that we have been monitoring and preventing for almost the past week has been irresponsibly reported on other blogs, with early posts publicly linking to known sites serving the 0day. In itself, the race to publish on this 0day that will be assigned CVE-2012-4681 (a problem with processing access control within "protection domains"), has been irresponsible. Would you encourage folks to walk down a mugger's dark alley with no protection or would you work to communicate the muggers' whereabouts to the right folks and work on lighting the alley or giving better directions? Would you provide muggers with some new weapons that they haven't considered? The efforts this time around seem misplaced.

Anyway, initial sites hosting the exploit were unique and spreading known APT related toolset components, including a Poison Ivy variant. Here is a somewhat unexpected heat map of early, related PIvy detections.

And here is a heat map of early detections for related web pages and javascript delivering the Java exploit:

All the related malware that I have seen to this point targeted Windows systems. The exploits are effective against Java 7 and since the initial targeted attacks, news and the samples spread throughout the broader security community and the exploits made their way to metasploit developers, who added PoC to the open source framework. In turn, the Blackhole authors added the exploit to their COTS. So the attacks are widespread at this point. The first victim regions to be hit with the Blackhole stuff were the US, the Russian Federation, Belarus, Germany, the Ukraine and Moldova. But, in relation to the other exploits included in the pack, victims are getting hit only a fair number of times with the 0day. Internet Explorer users are being hit the most, followed by Firefox, Chrome, and Opera, and then a variety of other applications that handle URLs within their documents and eventually pass the malicious .jar on to a Java client, like Adobe Reader.

We are using a variety of detections and techniques to identify the malicious sites, the web pages involved, the exploit code, and the backdoor payloads delivered by these sites. Even though this particular Java 0day is getting hyped, other older exploits in the Blackhole exploit pack continue to get hit on victim systems with higher volume. So our community is protected from the Blackhole sites themselves, the Blackhole webpages serving the Blackhole Java 0day, compromised sites redirecting to the Blackhole sites, the more prevalent older Blackhole exploits and their delivery pages, and the trojans being delivered by these Blackhole sites. In addition to all that, Kaspersky "Advanced Exploit Prevention" adds another runtime/behavioral layer of protection against the 0day itself with with "Exploit.Java.Generic". This addition is the most interesting to myself - exploit pack authors have been focused on improving their Java exploit server-side polymorphism, and this AEP feature defeats those efforts. So, our user community will see access denied altogether for current Blackhole sites, individual Blackhole web pages detected with variations on "Trojan-Downloader.JS.Agent", the backdoors detected with "Trojan.Win32.Generic" and others (i.e., 61A3CE517FD8736AA32CAF9081F808B4, DEC9676E97AE998C75A58A02F33A66EA, 175EFFD7546CBC156E59DC42B7B9F969, 0C72DF76E96FA3C2A227F3FE4A9579F3), and the 0day Java exploit code detected with "HEUR:Exploit.Java.Agent.gen" (i.e. E441CF993D0242187898C192B207DC25, 70C555D2C6A09D208F52ACCC4787A4E2, E646B73C29310C01A097AA0330E24E7B, 353FD052F2211168DDC4586CB3A93D9F, 32A80AAE1E134AFB3D5C651948DCCC7D) among others, along with the runtime AEP prevention. So while you may see a few links to Virustotal with the inevitable complaining that a scanner is missing a specific chunk of altered code along with innaccurate claims that "AV is dead!" or "AV can't detect it", you should take them for the grain of salt that they are. The real story about client side mass exploitation is more complex than those claims. Some researchers call the various points in a delivery vector a kill chain, and Kaspersky products are killing it.

At the same time, Oracle needs to step it up and deliver an OOB patch, which historically they have failed to do. Maybe this event will provide even more pressure to step up their security update delivery process. They have been snapping up some good security research talent and beginning to reach out, which is a start. A very late start.

UPDATE (2012.08.30): Oracle patches CVE-2012-4681 and two other client side RCE vulnerabilities. It is probably a better idea for Windows users to go to their control panel, find the Java applet, and use the Java update software to manually get the latest JRE 7 and 6 releases - the default delay for the Java Update package to check is currently one week for the Java 7 installer.

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:

download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com
v4stats.windowsupdate.microsoft.com
v9stats.windowsupdate.microsoft.com
v5.windowsupdate.com
v7stats.windowsupdate.microsoft.com
v6stats.windowsupdate.microsoft.com
v8stats.windowsupdate.microsoft.com
v5.download.windowsupdate.com

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.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

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

In this webcast, Kurt Baumgartner talks about the rise of exploits against vulnerabilities in Oracle’s Java software. The discussion centers around the exploitation of Java vulnerabilities in exploit kits and the poor state of patching on the Windows platform.

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.

Driver

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.

Payload

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.

This week I attended the Gartner Symposium in Barcelona. The event is for IT leaders and executives, held in a magnificent venue and superbly organized.

Having the chance of giving a talk there, I wondered what kind of message should I give to such attendees. These people lead big companies and get regular reports from the best analyst in the world. During the conference basically they will get tons of information, and I wanted my message to remain in their minds, so I decided to go for a practical approach.