Spearphishing Connects PCs to Russian Botnet

The talent over at MalwareBytes wrote this week about a Zbot dropper which comes from a PDF exploit through a spear-phishing e-mail.  In their blog, they discuss how a spear-phishing attempts to exploit either CVE-2013-0640 or CVE-2013-2729. User's must be extra cautious dealing with any attachment in an e-mail, but this threat merits extreme concern.  It installs a very persistent rootkit and logs the victim into a botnet which receives new commands/tasks every 10 minutes.  Removal is near impossible and also will use your Windows Mail to spear-phish your contact list.

As noted by MalwareBytes, attackers often use false extensions in order to infect victims (such as totally_legit.doc.exe). In the case of this attack, victim's download and click a malicious PDF.  This PDF, as Malwarebytes mentions, exploits Adobe Reader 11 and downloads an executable file.  At the time of research, 18/51 AV companies saw through this ruse and blocked the content before it had a chance to further exploit the victim.

We obtained a copy of the same malware in the Zscaler cloud and noted the following observations. A dropped file immediately connects to a Russian IP address to set up its beaconing activity as well as download more malicious PE files to the victim's machine.

axisbuild[.]com is showing some suspicious activity besides beaconing.

The translation of the C&C configuration file seen above in English is:

Интервал обращения к серверу в минутах

('Interval back to the server in minutes')

Таймаут цикличного обращения по ссылкам в минутах

('Timeout cyclical treatment referred to in minutes')

Список ссылок c&c

('The list of references c & c')

Страна бота

('Country bot')

Список задач

('task List')

In addition to awaiting for further commands from a remote server, the threat will also make many edits to the vicitm's system in order to remain despite removal processes.

There are several locations where this threat might download additional malicious PE files.  I've added a brief list below to illustrate.  I will provide more upon request to interested security professionals.

There are other locations used to download malicious files.

We took all different versions of these files and combined the phone home traffic to give a full list of IPs contacted.  The dropped files immediately begin to contact various IP addresses using nonstandard ports.  The following is a list of IPs and their hosted country.  

List of nonstandard ports used by all variants.

List of IP addresses which were contacted across all variants.

Administrators should monitor their networks for any activity which might match the outgoing transactions above.  Administrators will have a really tough time removing the threat due to the creation of a rootkit and altering the system's boot sequence.  The Zbot variant maintains a high level of persistence by doing the following:

This allows for untested drivers to be executed as part of the boot process

• Uses bcdedit to modify the Windows boot settings.

Dropped files create a system driver which executes during boot sequence.

• Spawns drivers in the Windows Directory

The Autostarter value is randomly generated

• Creates an autostart registry key

Used to inject malicious process into kernel.

• Registers kernel notifiers (kernel callbacks)

The victim is used as a node in further spear-phishing campaigns.

• Manipulates Windows Mail files

Users and Administrators must take extra caution against suspicious attachments.  Common methods for APT infection include tricking users to go to a compromised website or downloading something malicious through an attachment.  The fact that this threat compromises Windows Mail files means that the victim can be used to attack your contact list.  This allows for the attack to circumvent spam lists and base protections employed by regular users.  The best solution is to employ a sandboxing solution against all files which come through e-mail.

The story of a Trojan Dropper II

Analysis:

Lets analyze the PE file in detail and see what it’s up to. Like most malware, this sample was packed and in order to properly analyze it, we must begin by unpacking the binary. Keeping this in mind, I began by debugging the file, hoping to find the reference to the data section in order to determine precisely where the encrypted portion of data was to be found.

Fortunately, I was not disappointed and was soon able to find the reference point.

Figure 1: Obfuscated data 

After further debugging, we are able to see the code decrypted in memory. The decryption occurs in multiple iterations, until the data is completely decrypted.

Figure 2: Decryption of obfuscated data

Now we have a full view of the decrypted code in memory. The portion that was decrypted contains position independent code (i.e shellcode).

Figure 3: Decrypted data in memory

Since the code is decrypted in memory, we can assume that at some point, control will be transferred to that region, which in this case happens immediately. We also can see that the VirtualProtectEx API is used to change the protection of the memory region and by doing so the malware will be able to execute and manipulate the memory.

Figure 4: Change memory protection

After this occurs, control is transferred to the region by an instruction of JMP EDI. Here, EDI will hold the address to which EIP (instruction pointer) lands and we can see that it is the same portion of the 

code that was decrypted earlier.

Figure 5: Control transferred to new code

There's an interesting bit of code here if we look at first couple of instructions on the landed region. We can see a NOP instruction, followed by SUB EAX,EAX and a CALL and POP EBX. If we carefully observe the address that is called, it is that of the POP EBX. This is a common technique found in shellcode and file infectors where one needs to get the address of the region that is currently being executed.

When this CALL is executed, it pushes the return address onto the stack (in this case it is the address of POP EBX). Now POP EBX is executed, as that instruction pops the value from the top of the stack to EBX. The address is then added to a constant of 0x33, to point to the region that is then decrypted by the decryption loop. This reveals more code, after which a JMP instruction transfers the control to the newly revealed code.

Further, I was able to identify another interesting piece of code here. The code below retrieves the address of the PEB (process environment block) and navigates to PEB_LDR_DATA->InLoadOrderModuleList, where it retrieves the names of the loaded modules (DLL’s) .

Figure 6: Fetch base address of kernel32.dll

There's another catch here. The malware looks for specific DLL’s (in this case kernel32.dll), but instead of using the string kernel32.dll to compare with retrieved module names from the PEB, it carries the hash of the DLL names and then calculates the hash value for the retrieved module names and compares them. This allows the malware to make minimum noise and avoid some antivirus rules.

Figure 7: Dll name hash 

Once the malware gets kernel32.dll, it then retrieves the base address of the kernel32.dll, which in this case is 0x7c800000. Now, using the PE file format, the malware moves to the export table of kernel32.dll, as illustrated in the code below,

Figure 8:  Finding exportaddresstable of kernel32.dll

Looking at code above the instruction MOV EBX, DWORD PTR DS:[EAX+78], lands us at the datadirectory-->exportaddresstable of the kernel32.dll. The malware then retrieves the value and adds it to the imagebase (ie 0x7c800000) in order to reach the export table, where it retrieves the address of the exported function. Here too, the malware never uses the names of the function, but instead it uses a stored hash.

After further analysis, we stumble onto another piece of code, which copies data again from the data section to a newly allocated memory region.

Figure 9: Copy more data 

Investigating further, we see that this data is decrypted to reveal what looks like some sort of an address table.

Figure 10: Address table 

The table has significance as it is used as an address calculator, To calculate the address of

the region from where it copies bulk data, Which is further decrypted to form what looks like

a compressed file.

Figure 11: Compressed data

And there it is. Moving ahead, we land in the decompression routine, which quickly reveals that

the data is compressed using “aplib”.

Figure 12: Aplib decompression routine

Once the decompression is completed it does some familiar actions by flushing out the bytes of the original EXE file starting from the imagebase 0x400000 and copy the decompressed data to its new imagebase (i.e 0x400000)

Figure 13: Copy decompressed PE -file 

Finally using “LoadlibraryEx” and Getprocaddress the IAT is rebuild in the memory after which the control is transferred to the new code at the address 0x401021

Figure14: Rebuild IAT in memory

The job of this code is limited. It writes a PE-file which is embedded within itself into the temporary folder as “Adobe.exe” using the api “GetTempPathA”.

Figure 15: Transfer control to OEP

In the end, the file (Adobe.exe) is dropped in the temp folder and executed using the API “ShellExecuteA”.

Figure 16: Execute dropped "Adobe.exe"

A dummy PDF file is also written to the current directory named “Bestellung.pdf”. In a subsequent blog post, we will see why the malware dropped this PDF file.

That’s all for now. In the next post, we’ll continue the analysis of the dropped file “Adobe.exe”

Expack continues exploiting Java vulnerability

Exploit kits available in the wild tend to follow a trend by exploiting vulnerabilities reported in various browser components which are commonly deployed. Recently, we have seen an increase in exploitation of a year old vulnerability reported in the JRE component of JAVA (CVE-2012-1723). Exploitation of this vulnerability in JRE allows a attacker to download malware onto a victim's machine and execute it. Let's looks at an analysis of such an exploit kit recently found in the wild.

Exploit Kit URL:

hxxp://174.142.240.91/577ac477f62d4873cf41dc834d107b7c/influences-portal.php

When accessed, the above exploit URL executes obfuscated JavaScript and loads an applet into the browser as shown below:

Obfuscated source code:

Let's analyze the above obfuscated JavaScript code by de-obfuscating it. While de-obfuscating the JavaScript code, we noticed that the code has multiple layers of obfuscation. For the scope of this article, lets skip ahead to the end of the de-obfuscation process. 

As usual, the exploit kit request loads content based on the version of the browser and versions of different plugins installed in a browser by running browser/plugin detection logic embedded in obfuscated JavaScript. The exploit kit targets vulnerabilities in JRE (Java) and Adobe components of the browsers.

Let's take a look at following de-obfuscated code which loads malicious applet into browser:

The following code calls the relevant functions above, depending upon the JRE version found on the victim's machine:

The applet is executed by the browser, which then downloads a malicious .jar file from following URL,

hxxp://174.142.240.91/577ac477f62d4873cf41dc834d107b7c/influences-portal.php?gKoRO=UfhqAFb&gCTEVgSTdQbZjI=wUkSXV 

The de-complied code of the downloaded .jar file is also heavily obfuscated. 

VT Result: 13 / 45

MD5:  361b0e1eab5e647315e6873ea16ca720

This .jar files exploits the vulnerability in the JRE, which allows the attacker to download additional malware and execute it the browser context.

 

 VT Result: 13 / 46 

MD5: a151fdce265ba4fcab1b36bd624d330f

A Trojan then connects to the CnC server by sending POST data and in response, the CnC server replies with 'STATUS-IMPORT-OK'.

After receiving command 'STATUS-IMPORT-OK' from the CnC server, The Trojan then downloads another malware file (6.exe) from the same domain which looks to be a variant of ZerooAccess rootkit. The detection rate for the '6.exe' is also fairly low on VT.

VT-Result: 6 / 46  

MD5: b152b3d170dc089b057fbbe3d6393764

Exploitation of browser components such as Java and Adobe plugins by exploit kits are now a very common reason for enterprise PCs to become compromised. My colleague Krishanan Subramanian recently blogged about a rise in Red Kit Exploit Kit Activity, which also addressed the same vulnerability in Java. It is vital that enterprises ensure that browser plugins are always patched and up to date, something enterprises regularly fail to do. In the case Java, given the now regular stream of 0days that it has inspired, you may want to seriously consider disabling Java altogether, at least at the browser level, something that you can read about in a previous blog post entitled: Are you vulnerable to yet another Java 0Day exploit?

Pradeep