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 III

Introduction:

In previous posts (story of Trojan dropper part I, II) we performed both static and dynamic analysis on the threat and also developed a broad idea of what the malware was doing in it’s initial stages. We now set out to investigate the reason behind the crash of the dropped file (“Adobe.exe”) and at the same time we want to retrieve the payload from this particular malware sample.

Analysis:

Let’s go ahead and debug the file. This file (“Adobe.exe”) was found to be packed (custom variant) and the unpacking routine is similar to the approach detailed in part II of this post, so let’s skip all the gory details and dive right into it.

After unpacking the entire binary in memory, control is transferred to a newly unpacked region at the address "0x401634". Now the action begins from here and we get our first decryption routine, which is a simple 1-byte XOR with a static key as seen in the image below which reveals more code

Figure 1: Decrypt code

If we carefully look at the new code below, we can observe that it is riddled with JMP instructions and occasionally we find a few garbage values. The code is crafted in such a way that it resists disassemble attempts which makes reverse engineering the sample more difficult and somewhat painful.

Hidden in between these JMP’s in plain sight is an instruction that is familiar to us by now(i.e the instruction to fetch the address of PEB (Process Environment Block)).

Figure 2: Fetch address of PEB

At this point we can only speculate on why the malware needs the PEB address. Moving further in the code, we encounter another decryption point that is exactly same as the first one, which decrypts more code. Now the control is transferred to the newly decrypted code.

Figure 3: NtGlobalFlag (anti-debug)

In the image above, we have an interesting bit of code. Recall that the malware already collected the address of PEB. At this point, using the instruction CMP DWORD PTR DS:[EDI+68], ECX (here EDI holds the address of PEB which is "0x7FFD4000" and ECX holds a constant 0x70 ) a comparison is performed, after which a JNZ instruction decides the fate of the control flow.

Here we get our first glimpse of the anti-debugging technique employed by this malware. The instruction CMP DWORD PTR DS:[EDI+68], ECX compares the value of the ECX register (i.e. 0x70) to the location in the PEB structure known as “NtGlobalFlag”. The field is set to a value of “0x70”, if the process is spawned under a debugger.

In our case, this is true since we are debugging the file. Finally, the JNZ instruction at "0x401511" is not taken, which lands us in an invalid region in memory, thus triggering the anti-debugging. Let’s jump here and continue with our analysis. We now have another layer of decryption, which reveals more code after which, as usual, control is transferred to this region.

We then reach another piece of code, which is revealed only if we keep up with the control flow.

Figure 4: File-path, name identification (anti-debug)

The above code uses “strstr” to look for a string named “sample” anywhere in file path of our currently debugged file. If found, “strstr” returns a pointer to first occurrence of search string(i.e "sample") in file-path, or else it returns zero. The malware then checks the return value in EAX and takes a conditional jump in the form of JE instruction at "0x401135". If the jump is not taken, the code lands in “ExitProcess”, a call which terminates the process.

This is the second anti-debugging technique the malware employs, although not-an effective one in my opinion considering the odds of a file-path or malware name containing the name “sample”.

Figure 5: GetVolumeinformation, Volumeserial (anti-debug)

Again, here we have another anti-debugging technique where the malware retrieves the Volumeserial number using the API GetVolumeinformation and compares it with  “0CD1A40” and “70144646”. If either comparison matches, the code jumps to the ExitProcess call.

Another anti-debugging technique follows immediately thereafter in the form of “EnumSystemLocalesA”. The first argument that "EnumSystemLocalesA" accepts is a pointer to the callback function. Here the malware does a neat trick. If we look at the code below, at address “0x401179” a constant “0x2” is pushed onto the stack, which is followed immediately by a CALL. 

When this CALL is executed, it pushes the return address onto the top of the stack (which is "0x401180") and the EIP (Instruction pointer) now lands at the "EnumSystemLocalesA" call. Now if we observe the stack, the value on top of the stack is the return address, which naturally becomes the callback function address for "EnumSystemLocalesA" . When the "EnumSystemLocalesA" API is executed, control falls to the callback function, which continues the execution of the code. 

Figure 6: EnumSystemLocalesA (anti-debug)

Let's now continue our debugging from the address “0x401180”. Not far from here, yet another anti- debugging technique is uncovered. This time the malware retrieves the ‘Diskname’ from the registry. 

Figure 7: Diskname (anti-debug)

"RegOpenKeyExA" (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Disk\Enum)  and  "RegQueryValueExA" then uses “strstr” and searches for signs of a virtual environment such as “Xen”, “Vmware”, “Qemu” and also looks for string “virtual”.

Figure 8: Search vm strings(anti-debug)

Once the malware detects a virtual environment, it changes the control flow and land us in an invalid memory region. If we play along, we can observe something interesting here.

Figure 9: Adobe.exe crash

There we go. We can finally reproduce the crash that happened during the first stage of our analysis.
Ok, so a through binary analysis is often not so straight forward after all !!!

Figure 10: sandbox identification(anti-debug)

Let’s move on and see what surprises the malware has this time. Below, we can see anotherpiece of code that checks for a DLL name called “sbiedll” . Here, the malware checks whether it is run in a popular sandbox called “sandboxie”. If found, as usual, the malware bails out.


Immediately afterward, the malware performs a decryption routine to reveal compressed data, which is again packed with aplib and below we can observe the aplib unpacking routine which decompresses the data to a PE file.

Figure 11: Aplib decompression routine

Soon after, control is passed to the newly decompressed file. Below, we can see the new file being executed.

Figure 12: New PE-file in memory

Debugging further, we can observe the malware revealing the final trick that it has up it’s sleeve ,which I will explain in the next post in this series.

The story of a Trojan Dropper I

Introduction:

Recently, Zscaler ThreatlabZ  received a suspicious file from one of our customers, which 

was named “OrderDetails.zip”. After extracting the executable file from the archive I have 
performed a virustotal scan  to get some information about the file. At that time, very 
few antivirus vendors had definitions in place, which flagged the file as malicious.

As such, I decided to take look at the file in greater detail. After completing the analysis,
I've  decided to blog about the threat. Given the amount of information derived during the analysis, I've decided to divide the blog into multiple parts.

Figure 1:  virus total results

Modern day malware generally implements some kind of packing or obfuscation on the binary, in order to evade antivirus detection. Hence, it’s a good idea to determine which packer may have been used while analyzing the file. In order to do this, I implemented a popular tool called PEiD to check for the existence of a known packer.

Figure 2:  PEiD results

As we can see above, PEiD was not able to pick up anything from this file, but that doesn't mean that the file is not packed. Let’s have a closer look at the file.

While going through the file sections, one of the sections (.data) contained an unusually large amount of data, which at first glance gave the impression that it is obfuscated. This is an important clue and something we have to keep in mind while debugging the file.

Figure 3:  obfuscated data

While looking at the resource section, we can see that the file icon resembles that of a PDF file, which adds to our suspicion. Also, the file is not digitally signed.

Figure 4: File icon at resource section

Lets go further and execute the file. When doing so, I was greeted with a crash report where Windows was telling me that “Adobe.exe” had crashed during execution.

Figure 5:  windows error report 

We knew from the beginning that this was not a proper PDF file and would not therefore work with Adobe Reader. Let’s now look to determine where Adobe.exe exists in the file system. A 
Windows file search reveals Adobe.exe inside the temp folder, which when executed, produces exactly the same result as was shown above 

Figure 6: dropped file named adobe.exe

At the same time, a Wireshark capture was not able to output anything that was of interest.At this point we have adequate evidence to proceed with additional debugging, which i will explain in detail in the 2nd part of this blog post. The story of a Trojan dropper II

Figure 7: wireshark packet capture

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”

Fake AV and PRISM warning on hijacked website

While many individuals are concerned about privacy in light of PRISM, some malicious actors are using the program to scare naive users into installing ransomware. Since August 23rd, we have seen about 20 domains that carry FakeAV and Ransomware. These websites seem to have been hijacked. They are all hosting the malicious content over port 972 and use similar URL patterns. Here are a couple examples:

• kringpad.websiteanddomainauctions.com:972/lesser-assess_away-van.txt?e=20
• miesurheilijaaantidiabetic.conferencesiq.com:972/realism_relinquish-umbrella-gasp.txt?e=21
• squamipi.worldcupbasketball.net:972/duty_therefore.txt?e=21

The malicious files seem to be changing. It started with the classic FakeAV, then switched to a fake PRISM warning. In both cases, the goal is to scare the target into paying the attacker to "fix" their computer.

FakeAV

FakeAV remains a popular technique to lure targets into paying attackers. Most of the instances of FakeAV we have reported earlier were running a fake computer scan in the browser. This time it appeared as a Desktop application.

FakeAV scan of the computer

FakeAV claims to have found threats

The scan claims to have found 18 threats. Two have been cured, but the victim must pay to get the remaining 16 threats taken care of.

Some of the malicious behaviors of this FakeAV variant

PRISM warning

The other malware is interesting. The attacker uses the recent news about PRISM to claim that the victim's computer has been blocked because it accessed illegal pornographic content. The victim has to pay $300 through MoneyPak, a prepaid card service.

No less than 5 federal agencies are "blocking" your computer!

Victim needs to pay up $300 to get his computer back.

Both malware connect to the same couple of IP addresses over ports 80 and 443 that include:

• 37.139.53.199
• 64.120.167.162
• 64.191.122.10

I expect attackers to take advantages of the upcoming UK laws on accessing adult content online to send new types of fake warnings to UK victims.

CookieBomb still dropping malicious content

Cookiebomb is malicious obfuscated javascript injected into legitmate sites.  We've talked on this blog about compromised sites before, but this one appears to still be fully functional and actively spreading malicious content to unsuspecting users.  The talent at MalwareMustDie is onto their shenanigans as well.  As they have mentioned, this is a multi-redirection exploitation that uses two stage obfuscation to hide it's malicious payload.  The curious thing about this situation is that few AV vendors have taken note of the good research.  The final dropped file is being detected by only 7/45 vendors.

Below is the analysis of a single sample taken from the final list of infected sites we have seen propagating this threat.

First, there is the obfuscation of a small JS inclusion into a potentially legitimate site.  This is where the CookieBomb sets a name, special variable, expiry date, and access path for the eventual infection.  If the cookie is not readily available, it will create one for you and redirect you to another obfuscated hidden iFrame.  Once the hidden site is visited, it will read the cookie's expiry date and provide redirection and infection at a later point to avoid security vendor detection.

Figure 1: Obfuscated Code

Please note that the comment at the top of the image ("/*0f24908*/") is changed and is not therefore useful for detection.

Figure 2: De-obfuscated code from Fig.1

In the deobfuscated code above, we see another URL delivered in a 1px iFrame.  Going to this site leads to yet another obfuscated page, where the real magic happens.  The very first thing that it does is attempt to confirm the version of browser plug-ins the attackers are up against.

Depending on the version installed, it will send the next portion of the attack.

The final step sends the malicious payload that the attackers went to so much trouble to obfuscate.  
 

Attack URLs

Obfuscated content from the obfuscated content

The final drop for this content is a malicious executable that is delivering a small Trojan.  At the time of research, only 7/45 vendors were detecting this content as malicious.

Fiddler session with malicious content being dropped.  (Readme.exe in this case.  Calc.exe in others.)

For the last several weeks, this attack has impacted the below sites:

•  hxxp://www.citytavern.com/
• hxxp://www.usadu.cz/park-en/
• hxxp://bluen.de/jobborse/
• hxxp://bluen.de/
• hxxp://www.niblackfuneralhome.com/
• hxxp://www.kinwindsor.com/
• hxxp://www.mtldesign.net/
• hxxp://javiervazquez.me/ernesto/fdjw3hv7.php
• hxxp://www.cmfurniturerental.com/
• hxxp://sdrs.splashtop.com/strs01/macupdatenotes/en-us/strs01.html
• hxxp://www.nauticodiver.de/tauchbas.htm
• hxxp://www.tmv-alsace-vtt.com/f/parcours.htm
• hxxp://www.cmstaging.com/
• hxxp://educationdegreeonlines.com/benefit-from-studying-with-the-laptop/
• hxxp://www.gute-reise-berlin.de/aussteller.html
• hxxp://lexespana.com/comunes                                                                                                          
• hxxp://livehappylife.com/
• hxxp://corpdeli.com/
• hxxp://www.sudan-sudan.com/sudan/architecture-sudan-sudan.html
• hxxp://www.cmfurniturerental.com/index.php?main_page=index&cPath=114&zenid=8557f58ea51118a7bd633015e3b954ec
• hxxp://www.cherokeecountysc.com/id26.html
• hxxp://www.gute-reise-berlin.de/startseite.html
• hxxp://www.selbstversuch-spanien.de/
• hxxp://educationdegreeonlines.com/
• hxxp://www.nauticodiver.de/schule.htm
• hxxp://bluen.de/uber-uns/
• hxxp://www.nauticodiver.de/impresssum.htm
• hxxp://www.imschuh.de/
• hxxp://www.nauticodiver.de/preisliste.htm
• hxxp://familyreunion.blackamericaweb.com/
• hxxp://bluen.de/jobborse/spezialist-in-akustikversuch/
• hxxp://www.uppertraining.com/blog/cisco-mobile-apps-cover-a-surprising-range-of-functionality/
• hxxp://www.opheij.nl/contact.html
• hxxp://www.hotelmirallac.com/castellano/tarifas.htm
• hxxp://www.sugargrovechamber.org/member_listing/34/curt+john+karas,+cpa,+mba,+pc/
• hxxp://www.kinwindsor.com/favicon.ico
• hxxp://glassdoctor-denver.calls.net/?gclid=CPLt2r3F-LgCFUFyQgodZxwAjQ
• hxxp://bluen.de/jobborse/spezialist-in-logistikplanung/
• hxxp://dreamliftgifts.com/faq.html
• hxxp://www.gute-reise-berlin.de/kontakt.html
• hxxp://www.plomberiumpierrefonds.ca/robinets-de-cuisine/
• hxxp://www.cerexagri.nl/
• hxxp://www.mrbouncehouse.com/
• hxxp://guia.lexespana.com/familia/servicio-domestico/extincion-del-contrato/
• hxxp://www.nauticodiver.de/start.htm
• hxxp://corpdeli.com/lunch-menu
• hxxp://www.hotelmirallac.com/castellano/habitaciones.htm
• hxxp://www.nauticodiver.de/
• hxxp://www.heapoil.org
• hxxp://www.mtldesign.net/aboutus.htm
• hxxp://www.le-vieux-four.com/
• hxxp://www.cleargridsolutions.com/developer.html
• hxxp://www.horseridingfun.com/
• hxxp://educationdegreeonlines.com/2013/07/

The most notable site here is splashtop.com, however, the malicious content has since been removed.  Since AV seems to be uninterested in protecting against this threat, it is advisable to make sure your browsing is safe through other means.

Technical Research: Krishnan Subramanian