Here at Websense® Security Labs™, we often blog about big malicious campaigns and how our products protect our customers from them. But what about smaller campaigns that are no less dangerous? 

Broad campaigns often spoof notifications from well-known businesses, establishments, organizations, and agencies, and are very widespread these days. However, smaller volume campaigns sometimes can be as (or even more) dangerous by bypassing the victim's defenses.

Last week, the Websense ThreatSeeker® Network intercepted one such campaign. This small-volume, malicious campaign targeted businesses with legitimate-looking email that refer to items like purchase orders, quotes, and supply information. All of these email had attachments that install variants of the popular Zeus malware on the victim's computer.

Websense Cloud Email Security quarantined these emails as containing a potential virus before most of the malicious attachments were detected by antivirus (AV) engines. Websense ACE (Advanced Classification Engine) provides the extra layers of protection that help Cloud Email Security protect customers against a wide array of threats. 

In many cases, AV signatures are behind the latest threats. But although ACE uses AV as one of its analytics, we found this example where AV was not detecting the threat. Other techniques such as using network behavior (volume vs. time) and reputation are very effective against big campaigns, but would not work in this case, since the volume was low. The content of these email messages looks benign most of the time, so traditional anti-spam rules would not work well either. This is where additional protection is needed. ACE can provide that protection and quarantine such suspicious messages by looking more deeply at their content and features, like the types of attachments, message attributes, web links in each message, and telltale patterns in the content body. 

The period of time between ACE detection and AV detection can potentially prevent a security breach at the most crucial time, averting having to "play catch-up." 

Let's take a closer look at the email that were intercepted.

The variant that was most common on September 27, 2012, had subject lines such as:

RE: NEW ORDER

RE: ATTACHED PO

Notice the email body looks quite benign:

There were other examples. See later in the text.

The most "popular" attachment was a file named "scan.rar," which carried the executable "scan.exe."

Here's a Websense ThreatScope™ analysis of this file, showing the malicious behavior:

http://aceinsight.websense.com/FileAnalysisReport.aspx?rid=65EA634D5A96460CB3489AAD8A840364

Compare this to the VirusTotal report at the time that Cloud Email Security detected the threat. Only 2 out of 43 vendors detected this file as malicious:

http://www.virustotal.com/file/2373c8cb97ba5bd2a9bd5451de02f872c4444c1689b8d4021a7fd3945835da7b/analysis/1348767164/

Of course, AV signatures eventually catch up, so the situation improved to 15/43 a few days later.

Cloud Email Security customers were protected regardless:

Based on the nature of the attachments and a few other key attributes in the messages, ACE determined that these email carried a potential virus and had them quarantined.

Some of the other variants were:

Subject: RE:quotation

Attachment: po.rar

Subject: Urgent Order.

Attachment: payment.zip

Subject: supply info

Attachment: payment.zip

Subject: New PI

Attachment: quote.exe

Subject: Order

Attachment: product details.zip

Subject: Please attend to my order

Attachment: quotation.zip

All of these were quarantined by Cloud Email Security based on the attributes of the message and the attachment.

Click on the file names below for ThreatScope reports that provide an analysis of some of the files contained in the various attachments:

list.exe

Not in VirusTotal at the moment.

Quote.exe

Was not in VirusTotal. After uploading the file, these were their results.

Notice the fake "quotation" PDF that opens with these files:

payment.exe

Not in VirusTotal at the moment.

PO.exe

Not in VirusTotal at the moment.

Quotation_pdf.exe

Here is the VirusTotal report for the above file.

Samples.scr

Was not in VirusTotal. After uploading the file, these were their results.

Finally, here are some additional screenshots of other email variants (these look a little more suspicious than the first example shown above):

Please let us know your thoughts. Are you more concerned about the low-volume attacks or the broad far-reaching high-volume attacks? Send in your comments using the box below.

Websense Security Labs™ ThreatSeeker® network has noticed a low-volume threat circulating as a Microsoft update with a very low detection.  This attack ties in almost perfectly with the release of patches on the upcoming "Patch Tuesday" from Microsoft.  The attack lures the unsuspecting user into following the link provided within the email message, which evidently infects their system as it downloads a malicious executable to the user's machine. The executable (the fake patch) is being hosted on a compromised domain and at the time of writing holds an 11% detection rate as seen here on VirusTotal.

Websense customers are protected by our Advanced Classification Engine - ACE.

The email message looks quite legitimate, as the display names within the headers actually say they originate from Microsoft Canada (spoofed).  Other attributes of the message include a sense of urgency with the subject: "URGENT: Critical Security Update". The body of the message is presented in two different languages (English and French): indicative of some effort being put into the creation, making it look more legitimate and targeting a larger audience. Installing the fake patch will result in an infected machine with the Zeus Trojan variant: the Trojan variant calls home to its command & control server at visitortracker.net.in .

Below we have the contents of the message together with the body.

Just as a heads up of what to expect of this "Patch Tuesday"; it's a pretty small update as Microsoft will release only two updates to patch two undisclosed vulnerabilities: a Critical update affecting MS Windows and an Important update affecting MS Office.

Websense® Security Labs™ Threatseeker® network has detected a new malicious email campaign that masquerades as originating from Facebook. The campaign appears to actually be originating from the Cutwail/Pushdo spam bot. This time round, the Cyber criminals employ two attack vectors: social engineering and an exploit kit. Both end up with the Zeus/Zbot Trojan installed on the targeted machines.  

Websense customers are protected from this attack with our Advanced Classification Engine analytics, our suite of technologies within TRITON.

Here is an example of a malicious email in Spanish:

The malicious email is spoofed to appear to be coming from Facebook.com and says: "Hi, someone loves your photo comments, please click on the link to see all comments". It provides a fake URL disguised as a formal Facebook link. Once clicked, the user is redirected to an attack page and is prompted to download and run an "update" from Facebook. The "update" file is a Zeus/Zbot Trojan variant. At the time of writing, the file had only a 7% detection.

The attack isn't over yet. While the fake Facebook page loads, the user's machine is attacked silently with several exploits in the background. The exploits are sent via an iframe contained in the fake Facebook attack page. This process happens silently when the attack page is loaded. The exploits are loaded from one of the most prevalent exploit kits today - the Blackhole exploit kit. Any successful exploitation results in the Zeus/Zbot Trojan installed silently on the user's machine.

Here is an example iframe from the Facebook attack page that points to Blackhole exploit kit:

Websense® Security Labs™ ThreatSeeker™ Network has detected another wave of Zeus malicious email messages. This campaign is related to the familiar "pharma" spam messages that we see everyday, with one exception. This campaign combines an HTML or ZIP attachment with a social engineering technique, similar to what we normally see in malicious email campaigns. For example, the message may state that $375 has been sent to a mail recipient's account, and include a link to view the transaction in the recipient's account. Opening the attachment results in a compromised user machine via an obfuscated JavaScript in the attached HTML file.  So far, we have seen this type of email with subjects like "Labels and such" and "Greetings from Rivermark Bill Payer!".

Websense customers are protected by the real-time protection for customers in our Advanced Classification Engine, ACE.

Here is a screen shot of an email message with an HTML attachment:

In the case of an HTML attachment, criminals use obfuscated JavaScript.  Content is encrypted with a commercially available HTML obfuscation tool.

When viewing the deobfuscated content we see that the script uses a meta refresh tag to redirect a user who views the attachment. The script checks which browser is used and only performs the redirection if one of the following browsers: Firefox (navigator.userAgent.indexof('Gecko')) or Chrome/Safari (navigator.userAgent.indexOf('KHTML')).

A user who is using one of the affected browsers will get redirected to a pharmaceutical site like this one:

For email messages that have ZIP attachments, the ZIP file has coverage in VirusTotal - 5/43. The "label.zip" file contains "label.exe" which is a copy of Zeus. The malware copies itself to "C:\Documents and Settings\user\Application Data\Ewca\refef.exe" and tries to access two sites located in the .ru zone.

Here is a screen shot of the encrypted Zeus configuration file being downloaded after the malware injects itself into a legitimate process:

So far, we have seen more than 100,000 email messages like this.

Websense® Security Labs™ ThreatSeeker™ Network has detected an interesting correlation between recent rounds of malicious emails and the JavaScript files being used in mass injections.  First, let's think about recent malicious email campaigns.  If you review our recent blog posts about fake virus alerts and world cup-related malicious spam, you will see that the common theme in the two campaigns is that they contain heavily obfuscated scripts in the HTML attachments.  In fact, we've seen from our bot lab that Zeus variants seem to be responsible for these messages, as well as a number of other messages with different subjects and themes that have malicious HTML attachments.  The script from one of the email variants seemed oddly familiar.

Screenshot of one of the attached malicious HTML files:

Our ThreatSeeker™ Network puts us in the unique position of being able to scan emails and malicious Web sites to gain insights like these.  Follow up on another reported mass injection campaign revealed a similarity that shouldn't be ignored between the injected .js files on compromised sites and the email attachments.

Screenshot of a malicious JavaScript file used in the injection attacks:

In fact, after deobfuscating these by hand, we found that the two files use the same algorithm to deobfuscate their hidden contents.  These files fragment an obfuscated script amongst a number of variables in the file and concatenate them to get one long, obfuscated string.  This string then goes through a series of .replace functions to turn it into an escaped string.  Once the string is unescaped, the resulting character codes are obtained and used in an XOR operation.  The resulting string of numbers from this XOR are then decoded as character codes to obtain the final, clear HTML attack code.

Step 1:  Concatenate several variables to obtain one long, obfuscated string.

Step 2:  Decipher the above string with a number of .replace actions to get an escaped string.

Step 3:  Escape the above string to get a listing of seemingly random characters.

Step 4:  Obtain the character codes for each character in the above string.

Step5:  XOR the above character codes to get another string of character codes.

The final step is obtaining the characters that the above codes represent.  Below are the screen shots of the final and clear script code generated from deobufuscating the email attachment and the .js files which are inserted into compromised hosts.

Screenshot of the deobfuscated email attachments:

Screenshot of the deobfuscated JavaScript attack file:

Now, if we follow the HTTP transactions from visiting one of the injected sites, we really begin to see that these appear to be structured as the same attack, possibly coming from the same group.  Following one example, we can see that after the browser does a GET for the injected Java Script file, there are two more GETs for redirection proxies, until finally we land on the attack site at /index.php?pid=7.  From there, we have two other GET requests for /Applet7.html and /Notes7.pdf.  If you review the video we posted from the malicious virus alert emails, you will find that the flow for that attack was the same, except for the redirection proxies.

Screenshot of the HTTP flow after visiting an injected site:

Websense Messaging and Websense Web Security customers are protected against these attacks.

In my last article, Analyzing Malwares Using Microsoft Tools, we collected a process dump image with an infected ZeuS variant inside it. In this article, we will go through the procedure for separating the ZeuS part from the other parts. With the extracted binary data, we can apply a disassembling process using IDA. You may wonder if it's possible to disassemble the image taken out from the process dump. In this case, the ZeuS variant was injecting a valid DLL file into the process, and somehow managed to hide the existence of the DLL so that it would not appear in the loaded modules list. We can locate that image and can take it out using some tricks.

In the previous article, we found that the following APIs were hooked:

ws2_32.dll:
send, WSASend, closesocket

wininet.dll:
InternetCloseHandle, HttpSendRequestA, HttpQueryInfoA, InternetReadFile, InternetQueryDataAvailable, HttpSendRequestExW, InternetReadFileExA, HttpSendRequestW, HttpSendRequestExA

crypt32.dll:
PFXImportCertStore

user32.dll:
TranslateMessage, DefWindowProcW, NtUserBeginPaint, NtUserEndPaint, DefWindowProcA, GetClipboardData

ntdll.dll:
ZwCreateThread, NtQueryDirectoryFile

With the list of hooked APIs in mind, open the process dump file using Windbg. Then use the "u"(disassemble) command to check the first instructions they have. Below are some of the examples:

From the installed inline hooks, we can get the memory region where the hooking function is installed. Here is one of the "!address" results from the hooking function's addresses:

0:000> !address 00b7dd44

00b70000 : 00b70000 - 00026000

Type 00020000 MEM_PRIVATE

Protect 00000040 PAGE_EXECUTE_READWRITE

State 00001000 MEM_COMMIT

Usage RegionUsageIsVAD

The memory region starts from 0xb70000 and the size is 0x26000 bytes. Let's just dump the start of the memory region using the "db" command, which dumps memory by bytes.

Yes, we got the start of the PE file. We can see the 'MZ' signature and some part of DOS header of the PE file. What we have to do now is simply dump the memory region to a file. Windbg provides a command called ".writemem" to write memory regions to a file.

The following command dumps the region of memory to the file " C:\Malwares\00b70000.bin".

0:000> .writemem C:\Malwares\00b70000.bin b70000 L26000

Writing 26000 bytes............................................................................

We open the file using IDA. It seems to be successful, until we find that there is something wrong with the disassembly listing.

First we get some error message dialog boxes:

Figure 1: Virtual Address Translation Error

We see that the imports table is empty:

Figure 2: Empty Imports Table

Even call instructions are referencing some invalid addresses:

Figure 3: Call Referencing Invalid Region

We notice broken data referencing:

This is happening because the base address for image loading is different from what is set in the PE header. We can check the value of the image base defined in the PE header by looking at the top of the IDA disassembly listing. In this case, the image base is set as 0x400000 as you can see from the following picture, but the image base when we dumped the image was actually 0xb70000.

Figure 4: Image Base is 0x400000

Will only fixing the image base solve the issues? No. We need to take care of the section relocations. When the PE file is loaded into the process address space, it is not just copied exactly. The sections inside are located according to their virtual address. Each section has their position and size in the physical file, and also has a virtual address region to be mapped. All the information is inside the PE file header.

We used the pefile Python module from Ero Carrera to achieve the PE file manipulation. Here's the source code for the script that we used:

Save the python script as "Rebase.py" file. Here's how you can use the script:

c:\python26\python Rebase.py 00b70000.bin 00b70000_rebased.bin 0xb70000

This command will re-base the image base to 0xb70000 and will also correct section location information by setting PointerToRawData to be same as the VirtualAddress value. PointerToRawData is the offset in the file where the section starts. We dumped it from the memory and it should be same as VirtualAddress.

After running the script, open up the re-based image "00b70000_rebased.bin" using IDA.

Now we have a valid and good imports table:

Figure 5: Valid Imports Table

Call instructions are referencing valid APIs:

Figure 6: Call Instruction Referencing Valid APIs

Also, the string referencing is corrected and shows good values:

Figure 7: Valid String Data

Conclusion

Retrieving injected modules and making it valid for disassembling is possible with a few Windbg tricks and python scripts. Tracing malicious code inside a debugger doesn't compare to having it inside a full-blown disassembler. The script presented in this article can be applied to any injected modules in the Windows environment.

Next time we are going to talk about automated scripts that will do all the jobs that we have done with a single command.

Thanks and have a great reversing!

We have been seeing reverse engineering on malware for a while. Some time ago you needed to have magic tools from some underground hackers, but the situation has changed a lot since then. This is especially true for reverse engineering on the Windows platform, where there are a lot of good Microsoft-made tools. They are not specifically made for reverse engineering purposes, but they can be very helpful for reverse engineering binaries. They are also very stable because they went through a lot of internal quality assurance processes before being released to the public.

It feels like these Microsoft-made tools are underestimated. Many hackers are using ollydbg instead of Windbg. Many people are using some other dumping tools to dump processes instead of userdump. And so on. It's not that ollydbg or other tools aren't good. I just want to show how easily the same thing can be achieved with the tools released by Microsoft. I'll show two things: dumping processes, and finding rootkit components embedded in the process images. Both of these can be achieved with just a few lines of commands.

The situation is as follows. We have a machine infected with a malware, a kind of a Zbot variant. We know the malware is doing code injections to collect and control the data flow on the system. So we decide to dump the process image. How can this be achieved with Microsoft tools? We just need to download and install User Mode Process Dumper Version 8.1 on the target system. Here's an example showing the dump of the infected "svchost.exe" process image from the system.

Illustration 1: Using userdump to dump live process images

You just need to call userdump.exe with the target process name and target dump file name. It will go through every process with that specific name and dump the image to a file with the name you designated plus the process ID. In one shot, you can grab all the dump files for each process with same name. Convenient, right? One more benefit of userdump is that it will not kill the process it dumped. So theoretically, the process will not be affected by dumping the images. We can silently duplicate the process images and let the system carry on without intervention.

So now we have the corpse images of the processes and it's time to do some basic autopsy work to see which organs have been tweaked by this infectious botnet client. First, you need a tool called Debugging Tools for Windows (aka Windbg). There are, however, some issues with the Windbg download. The last release date for the standalone download package is March 2009, which is more than a year ago. You need to download and install WDK to use the latest Windbg. But in my case, I was just fine with the March 2009 release. And the examples here will work without any problems with standalone packages.

Just move all the dmp files acquired from userdump to a safe location. Launch Windbg and select File > Open Crash Dump. Then choose the dump file you want to analyze.

If you come from the ollydbg world, the first thing you'll notice is the UI. It doesn't have a fancy GUI like ollydbg. You need to know the debugging commands to achieve anything, even simple things. This can be a big hurdle for the people who are accustomed to full-blown GUI debuggers. But there are still many advantages to this command line approach. You can copy and paste the commands easily. And you can save all the data in a text file for further review. Everything you do inside the debugger is logged, and you can keep those logs as your record. Also Windbg supports a kind of a semi-scripting like the "Debugger Command Program", which makes your life easier if you are performing simple tedious repeating tasks.

We will use this small portion of the Windbg script feature to find the hooks installed on the target process. The following one-line command will reveal every hook (especially if they are inline hooks):

!for_each_module !chkimg @#ModuleName -d

!for_each_module is a kind of extension command. Every command that starts with "!" is an extension. It executes the following command for every module on the target process.

The command to execute for each module is "!chkimg @#ModuleName -d". !chkimg is a command that compares the image on the memory and symbol file or executable file. @#ModuleName will be replaced with the module name that is being executed. The command "!chkimg" will compare the image with the one in the symbol store. In this case, we should use the symbol store from Microsoft. If you don't have your symbol path configured, execute the following command from inside the Windbg command prompt:

.sympath+ SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols

"C:\localsymbols" can be replaced with any local directory that you want to use for symbol cache files.

Here's the result of that "!for_each_module" command with the  "!chkimg" command. Basically, it will iterate through all the modules loaded in the process and check the executable image against the one stored in the Microsoft symbol store. If anything has been modified, it will report the discrepancies.

Illustration 2: The section inside the red square shows the APIs where the malicious hook is installed

From the above picture, you can see that a lot of APIs from ws2_32.dll (winsock) and wininet.dll have been modified. You can quickly see that this malware is monitoring and modifying the network traffic by hooking network-related APIs.

For example, let's look into WSASend API from the ws2_32.dll file. You can use the "u" command to disassemble any portion of the memory. Here, we disassemble the "WSASend" API. The first instruction of the API is a jmp instruction to the memory location 0x00b7dbbd.

Illustration 3: ws2_32!WSASend inline hook installed

We disassemble that part of the memory using the  "u"(disassemble) command. You can see that it's a kind of hooker function.

Illustration 4: Hooker function

By examining the properties of the memory region containing 0x00b7dbbd using the "!address" extension command, we can see that the protection flag has "Execute" and "ReadWrite" bits set. It's usually "ReadOnly" with the "Execute" bit set for the usual executable modules loaded. This might be a heap region and the hooker module might be injected from another process.

Illustration 5: Memory property of region containing the hooker function.

That's it for today. We have showed how to use one-line commands to dump processes, and how to use Windbg to inspect hooks or rootkits installed on the process. The next step will be analyzing the hooker functions themselves. There will be more on this subject in a future blog posting, and it will involve using IDA and IDAPython and the command line version of Windbg.

Thanks, and have a great reversing!