Preying on Assumptions: Symmetric Encryption in a CryptoLocker Variant

CryptoLocker WarningThis trojan was found on a compromised web server that was used to send mass emails with a malicious attachment. Upon execution, the malware searches all logical drives for common media and document files, appends .CRYPTOLOCKER to each file’s name and allegedly encrypts each file with 2048-bit RSA key. It places a text file in every subdirectory with ransom instructions. It persists on the system by copying itself to a TEMP folder, and adding that copy to the system autoruns. It also gives this copy a file-association to the “.CRYPTOLOCKER” file extension. When it finishes this dirty work, it displays a warning (seen above) with instructions for downloading the Tor Browser to (presumably) cough up some money for the private RSA key required to decrypt the files. This is a similar pattern that we have seen in recent ransomware variants.

I initially executed this sample in a sandbox that had no network connectivity. Though, the malicious process never attempts to make any network connections at any point. Regardless, it still modifies files and displays the CryptoLocker alert. I immediately found this to be unusual. My understanding is that CryptoLocker initially connects to a C&C server which in turn generates a unique RSA key pair of which one is sent to a client for file encryption. This clearly isn’t the case here. I supposed that it’s possible that a public key was hard-coded into this sample, but that seems unnecessarily complicated and fragile, since we know that this was intended to be sent to many inboxes. It’s time to take a closer look at this executable.


The malicious process was identified as a Win32 PE in Process Explorer. However, the original file would not open in IDA (free) or a debugger, indicating in an error message that the program is a .NET executable. Specifically, the program requires .NET 2.0 for execution. This is unusual since .NET executables are more easily reversed, and malware generally leans more towards complication, than ease. After de-obfuscating the file with de4dot, and investigating the decompiled output in JetBrains dotPeek, it is mostly clear what is happening on execution. The malicious executable is encrypted within this .NET program.

DotPeek Output

DotPeek Output

The .NET executable reads itself into memory as as a string, and then splits these strings into arrays based on pretty specific delimiters like [$FILEBASE$] and [$SETTINGS$]. The method  Class5.smethod() is a Rijndael decryption method with a hard-coded key and Initialization Vector. After the program decodes and decrypts this string, the bytes are written to disk (this is the real Win32 PE) and a new process is started from this data. But where in the executable are these strings located?

Loading the file into a text editor shows that a lot of data has been appended to the end it, including some encoded strings and the delimiters that we were looking for. Clever? Note that this data was stripped from the de-obfuscated copy.

Encoded Strings

[$FILEBASE$] delimeter and encoded data

After cutting and pasting selections from the dotPeek output and encoded strings from the original executable into a new Visual Studio project, it was easy to extract the final Win32 executable. However, this PE was packed. Luckily, PEFrame identified the packer as UPX. The file was easily unpacked with UPX and was then clearly readable in IDA and in the debugger.


Extracted PE

So with that out of the way, we can take a closer look at the de-obfuscated piece of malware.


A thorough once-over offers some clues about the capability of this malware. Notably, the .rsrc section of the PE file contains, some interesting data, including the text from the final pop-up alert. The ID# shown to the victim in the alert pop-up is not dynamically generated, which demonstrates that in the least, no unique RSA keys have been generated for purposes of file encryption, and this ID# is just used to make the program appear as if a unique key has been generated.


Static ID# in pop-up warning text

Also within the .rsrc section of the PE is a list of wildcard file extensions. Stepping through execution demonstrates, as expected, that these strings are copied elsewhere in memory and are used when searching for files to encrypt. This variant will search for and encrypt files with the following extensions:


There is also some indication that this malware is capable of decrypting the files on the filesystem. There are strings that appear to be prompts and responses for decryption password input. Though I suppose that this could be sloppy cruft from co-development of separate but similar encryption and decryption programs.


Strings referencing decryption.

There is also code that could be used to remove the malware from the system altogether:



Viewing the output of the encryption function, again, seems to show that this variant is not as complex as it is advertising. After encryption, a text file filled with 0x41414141’s looks like this:


Ineffective encryption?

As you can see, the program is only modifying parts of the file, and the parts that it does modify shows a clear pattern. Furthermore, after the first quarter of any given file, the data is unchanged. This doesn’t look complex, and it certainly doesn’t look like RSA.

Recreating this input file and stepping through execution helped to identify where files are copied into memory and how they are modified. The function that handles the encryption can be seen in the following image, on the left. There are a few clues in this function that may help to reveal the nature of the encryption it is using. The constant 0x9e3779b9 seems to be important, appearing at several points of the encryption function. An internet search for this constant shows that it is a magic number commonly used in the Tiny Encryption Algorithm (TEA). I am admittedly, currently unskilled and impatient at deciphering encryption algorithms in assembly. But after reviewing the TEA algorithm, and the resulting assembly in some implementations, I think it is likely that this variant of CryptoLocker is using TEA in order to encrypt targeted documents. This is significant because TEA is a symmetric cipher, and therefore it will be possible to decrypt the data using the same encryption key, without paying a ransom. As I viewed this disassembled function, I noticed a very similar, but currently unused function, which is shown on the right. Again, after reviewing the TEA algorithm, noting the similarity, and given that the binary has offered clues that it is capable of decryption, I thought it was possible that this was a TEA decryption function.

Hopper Output

Encryption function on the left, unknown function on the right.

Of course, it is possible (and important) to understand the structure of the program to determine if and under what conditions this second function is used. It is also important to determine what key or keys are being used, and exactly how each file is affected. But at this time, I am interested in determining if I can quickly easily decrypt files with this second function.

To attempt decryption, I patched the binary so that the second (decrypt?) function is executed, instead of the usual encryption function. After tracing the flow of the program, just overwriting some instructions with NOPs would force flow into the second function, rather than the first function. I then took some previously encrypted files, and removed the .CRYPTOLOCKER extension so the patched executable would attempt to encrypt them, but with the alternative function.

This worked. Previously encrypted files were intact after being processed by the patched binary. This variant is not using an asymmetric cipher at all.




This is an opportunistic piece of malware that preys on the limited knowledge that many users and system administrators have about CryptoLocker. It preys on the assumption that encrypted files are irretrievable without paying a ransom for a private key. It benefits from the idea of CryptoLocker as a “brand” of malware that is criminal and dangerous, but paradoxically honest and straightforward. I think it is likely that uninformed users or system administrators would pay the ransom if they had no clear alternatives. The authors of this attack would just need to collect their money, since they do not need to generate, distribute nor keep track of the public and private key pairs of their victims.

To Do

My goal was to understand how this variant encrypted files, and to determine if the affected files could be decrypted without an external key. I was able to accomplish this. However, the static analysis of this file is not complete. Certain sections of code, as well as some string data, indicate that decryption may be more straightforward than manual binary patching. This is something that I would like to revisit when I have more time (and skill). Note that I am clearly a novice, pursuing this as a hobby. Any feedback is welcome.

ColdFusion Trojan Distribution

medium_3733339594I responded to an incident that was initiated by an abuse complaint from a European ISP. Their mail server was receiving a large amount of backscatter due to emails that were initially sent from a server that I came to inspect. The sending server was a Postfix server, and there were many undelivered emails in the queue, coming from an unfamiliar domain. After closer inspection of the queue and the Postfix logs, it was clear that the emails were originating from a web server on the local network.

The compromised web server was a Windows server running IIS and ColdFusion. The HTTP ports were publicly accessible. A brief search of the server revealed a few malicious CF files, including a large web shell, and a small mailing script. In the same directory was a newly uploaded text file, containing thousands of email addresses, and a ZIP archive containing a clearly malicious executable made to look like a text file. This piece of malware will be covered in another post.

The smaller CF mailing script contains the following code:

<cfsetting RequestTimeout ="600000">
<cfloop index="id" file="C:\inetpub\wwwroot\CFIDE\fc.txt" from="1" to="31429">
<cfset sleep(100)>
<cfset msg = RandRange(185,750)>
<cfset subj = RandRange(12,21)>
<cfmail from="Mail Delivery System <>" to="#id#" subject="Delivery Status Notification (Failure)">
<cfmailparam file="C:\inetpub\wwwroot\CFIDE\Incoming">
Incoming email(s) for <#id#> could not be delivered due to a persistent data format error.

The incoming email(s) can be read in the attachment <Incoming>
For security purposes it has been saved in a plain text readable binary document.

Technical overview:
>>> (after RCPT To): Status Code 550.. checking .. subject length #subj# chars, message length #msg# chars..
>>> ! Message cannot be represented in 8-Bit ASCII encoding ! Return error code 521
>>> Mail transaction failed... waiting for reply from server ..
>>> Server reply: email successfully stored in plain text binary document <Incoming>
>>> Return failure notification with original email in attachment to recipient ..

This is an automatically generated delivery status notification, please do not reply.
<cfoutput>Mail sent to #id#<br></cfoutput>

This code references a text file, “fc.txt” full of thousands of email addresses, and a ZIP file, called “Incoming”. This script creates plausible looking phishing email content, attaches the file, and then loops through the email addresses. The script uses the SMTP server associated with the server’s ColdFusion configuration.

I searched through the HTTP logs to identify how and when these malicious pages were created and accessed. Each of the pages had only been accessed a couple of times in the recent past. They were accessed from a single IP address, which, through a PTR record is self-identified as a Tor exit node. A continued search of the HTTP logs showed that the same IP had POSTed to the “/CFIDE/administrator” page before accessing these malicious files. It is possible that the site was compromised by exploiting a recent ColdFusion vulnerability identified by CVE-2013-0632. I don’t have the packet captures to confirm what exactly was POSTed to the server. However, this seems like the most likely explanation.


  • This malware sample was distributed as an attachment to a phishing email.
  • The phishing email is designed to look like a legitimate non-delivery report.
  • The email was distributed through a short ColdFusion script that loops through a text file containing thousands of email addresses.
  • The script, email list and ZIP file were uploaded to the server by exploiting ColdFusion vulnerability CVE-2013-0632.
  • The exploit and execution of the mailing script originated from a Tor exit node, effectively anonymizing the attacker.

In the next part, I will inspect and analyze the malware payload contained within the attachment.

photo credit: Darwin Bell via photopin cc

Anatomy and Behavior of a Trojan Downloader

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.


The malware was received as a compressed email attachment, named “” 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.

Trojan downloader icons

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 ( by ( with Microsoft SMTP Server id; Tue, 12 Nov 2013 08:33:45 -0800
Received: from
 ( []) 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 [] (port=86789 helo=[]) by with asmtp id 1rqLaL-000U2-00 for;
 Wed, 13 Nov 2013 02:33:47 +1000
Date: Wed, 13 Nov 2013 02:33:47 +1000
From: "" <>
To: <>
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 “” and “” 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.
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/
Content-Length: 526
Content-Type: text/html; charset=iso-8859-1
<title>404 Not Found</title>
<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>
<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/ Server at Port 443</address>

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.

IDA nav 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 “” and” domains over HTTPS using the user-agent “updates downloader”. The program then takes this file, copies it locally for execution before exiting.


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.