I received this malware sample from a system administrator of a small technology firm. He had discovered the sample as an email attachment on his mail server. He was concerned because his malware defenses had not protected his users. Furthermore, his endpoint anti-virus solution did not identify the malware, even after decompressing and executing it on an isolated system. I agreed to take a closer look at the executable and report my findings.
Vector
The malware was received as a compressed email attachment, named “invoice.zip.” The ZIP archive contains a single 25KB executable named “BIR Form.exe.” Notice that the executable has the familiar Adobe Acrobat PDF icon. This is a common trojan ploy to tempt a user to double-click and execute the file.
The sanitized email headers show a few things of interest. The sender and recipient email addresses have the same domain. Since the email appears to have originated outside of the organization (confirmed by the sysadmin) then a proper SPF record would have prevented the malware from being accepted by the recipient mail server.
Received: from ELSSMGPS02.NAMEHUB.COM (64.70.94.242) by exhub09.exchhosting.com (192.168.11.107) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Nov 2013 08:33:45 -0800 Received: from 203-191-196-14.static.tpgi.com.au (203-191-196-14.static.tpgi.com.au [203.191.196.14]) by ELSSMGPS02.NAMEHUB.COM (Symantec Messaging Gateway) with SMTP id 49.5F.16486.FAC52825; Tue, 12 Nov 2013 08:52:00 -0800 (PST) Received: from [255.133.133.204] (port=86789 helo=[192.168.2.75]) by 203.191.196.14 with asmtp id 1rqLaL-000U2-00 for myemailaddress@company.net; Wed, 13 Nov 2013 02:33:47 +1000 Date: Wed, 13 Nov 2013 02:33:47 +1000 From: "accounts@company.net" <accounts@company.net> To: <myemailaddress@company.net> Subject: FW:Duplicate Payment
Dynamic Analysis
Executing the malware in a sandbox environment offers some strange results. The file, “BIR Form.exe” copies itself to the user’s temp folder as “budha.exe”, and executes that copy. Then it deletes “BIR Form.exe” and exits.
The copy executed from the user’s temp folder exhibits different behavior, A few DNS look-ups are made to domains “leechsurgery.com” and “jadhaogin.com.” Then, a constant stream of HTTPS requests are made to their corresponding IPs. The “budha.exe” process memory then continues to increase until its virtual memory is exhausted at which time the process crashes. The program never attempts to persist on the system, so the crash effectively ends the program. The user will need to extract the “BIR Form.exe” file and re-execute it for the trojan to retry. What is this executable trying to do?
Re-executing the trojan and taking a memory dump of “budha.exe” process with Process Explorer offers some clues. Using the strings utility against the dump shows a constant repeating pattern, part of which can be seen below.
https://leechsurgery.com/images/photo.exe
HTTP/1.1 404 Not Found
Date: Fri, 22 Nov 2013 02:36:21 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.0-fips mod_jk/1.2.37 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Content-Length: 526
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /images/photo.exe was not found on this server.</p>
<p>Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.</p>
<hr>
<address>Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.0-fips mod_jk/1.2.37 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at leechsurgery.com Port 443</address>
</body></html>
It’s clear that the process is making HTTPS requests to a URL, and is copying the response to memory. The requested URL is the location of an executable called “photo.exe.” But, the server is sending 404 Not Found responses. It appears that the process cannot handle this in an elegant way, and the process memory balloons until it crashes. So, in order to help this along, we will need to find the payload that it is looking for.
Static Analysis
Using IDA to disassemble the “BIR Form.exe” reveals that the executable is packed or obfuscated in some way. Very little of the file’s content is identified as executable code, and a very large section is identified as data. This can be seen clearly in the IDA navigation band.
The identified imported libraries belie the true nature of the trojan. No networking libraries are included, and several multimedia libraries are imported, which the executable never uses. It should be noted that the PEiD utility didn’t identify the packer. So, we will need to manually unpack or decrypt the executable to find the original entry point, or “OEP” of the executable. The following techniques worked for me.
- Trace through the executable to try to understand the size and structure of the executable, including any obvious unpacking or decrypting techniques.
- Watch for new content, especially new strings, appearing in memory or on the stack.
- Monitor the memory allocated to the application for new segments with obvious executable content.
- Record the locations of interesting instructions to use as breakpoints.
- Take frequent VM snapshots so that to quickly “rewind” the debugger.
While quickly tracing the program using Immunity Debugger, I recognized when the behavior I observed during dynamic analysis began executing. As we had observed, the file makes a copy of itself, finds the user’s temp directory and appends the string “budha.exe” to the end of it. Scrolling through the debugger window also shows calls to HTTP and execution functions. The section of memory being executed starts with the familiar DOS header “MZ” at 0x00A20000. After “rewinding” the debugger by reverting to a VM snapshot, we can see where the executable is decrypting this new PE into memory.
Now, we need to identify the point when the program makes a jump into this section. Shortly after the decryption function completes, we find a jump to address 0x00A21020, which falls within the section of code that we observed being decrypted.
To perform a static analysis on the unpacked executable, we will need to export it at OEP. After making the jump to 0x00A21020, we can use the LordPE utility to take full dump of the running program as a new executable. This alone won’t create a working executable, because the ImageBase will still match the original executable. We will need to use the “PE Editor” tool included with LordPE to modify the ImageBase to match the new PE.
After modifying the ImageBase, we can now open the file in IDA. The navigation band shows a large swath of code (in blue) and all of the sections are clear and readable. The imports section now correctly shows the calls that the executable will need, including HTTP requests and file operations.
Reviewing the newly disassembled PE corroborates what we discovered during dynamic analysis. The program is not complex. The program makes a copy of itself with the name “budha.exe” in the user’s temp directory and executes that copy. The original executable “BIR Form.exe” exits and the file is deleted. The “budha.exe” process recognizes that it is the second copy within the users temp directory and proceeds to attempt to download files from the “leechsurgery.com” and jadhaogin.com” domains over HTTPS using the user-agent “updates downloader”. The program then takes this file, copies it locally for execution before exiting.
Conclusion
The trojan downloader investigated here is not sophisticated. It uses simple obfuscation techniques (compression and encryption) to prevent detection. Aside from encryption, it employs no anti-reversing techniques. Since it is delivered as an email attachment, perhaps file size was the greatest concern for the developer.
Hi. Very interested in your piece on Budha.exe. I recently encountered this in a fake message looking as though it came from Skype and with the title concerning a voice mail. This got opened and the attachment clicked and all office files were encrypted or garbaged. We did not seem to get any ransom message; but this could have got missed.
I still have the attachment and have been looking at it on an isolated computer. It has an exe file in it called voice_mail_message.exe. This copies a sample of Budha.exe to the user\temp folder similar to your experience.
When Bhuda.exe is run with Internet access available it opens for about 5 seconds according to Task Manager, and then closes. If the Internet is not available (unplugged) it continues to run using up memory forever – like 3 hours in which case it is using over 100 000 bytes of memory.
I thought it was looking for an encryption key on the Internet. I had assumed that the encrypting programme was in Bhuda.exe and it needed the key from the Internet; which ties in with other info on the Internet about cryptlocker.
After reading your comments, I now wonder if Bhuda.exe is mere the utility for downloading the whole encrypting programme from the Internet.
My Bhuda.exe is 19026, smaller than yours. MD etc is at the beginning of my files; and does not have code/data before it as yours does.
Your comments make no mention of encrypting of files.
I would be interested in your views as to whether the encrypting programme is within Bhuda.exe, or if it is just a download utility.
If I could get Bhuda.exe to encrypt a huge file full of say 1s – perhaps I could work out a way of decrypting some of my files.
Any other comments would be greatly appreciated.
Hey Paul, thanks for the comment. It sounds like you have a malware sample very similar to the one that I discovered. In this case, the malware isn’t downloading an encryption key. It is downloading the *real* malware payload. The first file that you executed, voice_mail_message.exe is required because it is very small and therefore can be distributed by email, or in your case, Skype. So, after execution, it will go out and grab a much larger and more sophisticated payload to do the real malicious dirty work. In my case, the malicious payload was a Zeus/ZBot variant.
I too noticed that sample would slowly consume a ton of memory to the point of crashing. In my case, this was because of a flaw in the program. It is using an HTTPS request to download the larger payload. The address is hard-coded into the executable. If you monitor network requests on your system, you should see these occasional, constant HTTPS requests. However, if the payload doesn’t exist on the server that it is talking to (404, or other error), then it writes this error to memory and then tries to download it again. These errors are written to memory over and over until the program finally crashes with an out of memory exception.
Let me know if you have any other questions.