Preying on Assumptions: Reversing Symmetric Encryption in Opportunistic Ransomware

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.

14 thoughts to “Preying on Assumptions: Reversing Symmetric Encryption in Opportunistic Ransomware”

  1. A great writeup. However, recent variants CryptoWall and CryptoDefense don’t appear to be quite the same malware as CryptoLocker. Would this potentially still be relevant on these latest strains?

    1. Thanks for the feedback. I think it’s important to consider that no one owns a trademark on the names “CryptoLocker,” “CryptoWall,” and “CryptoDefense.” Any new independent variant can call themselves these names, and benefit from the fear and assumptions that come along with the name. So, to answer your question, I think that yes, the findings here could be relevant in any new strain. But, each strain would need to be understood as a discrete piece of malware, regardless of what it calls itself. I think that any serious, widely distributed version of CryptoLocker would need to rely on asymmetric ciphers. There are too many prying eyes that will find the ruse.

  2. I recently lost all my data to Cryptolocker virus. I didn’t get the error which you have displayed above but instead got a big red box with a timer. See below-

    Unfortunately my hard-disk was re-imaged to remove this virus and from my understanding there is usually a decryption key planted in the registry which I have lost now because of the re-imaging. I do have a copy of the data but appears to be all encrypted.

    I have to be honest I don’t think I have completely understood exactly what you have done here but do you think there is a way to decrypt the data without the key?

    1. It sounds like you have been infected with a “real” version of CryptoLocker, in which case it will not be possible to decrypt the files without the private key.

  3. Those have been around for about 3 months now:

    They pop up every now and then, hit a very limited amount of targets, and just completely disappear. The malware itself looks to be the product of some kind of construction kit or is based on some leaked or sold source code. A lot of the texts and dialogs that are never used point towards it. There are actually dialogs included that allow you to type in the password to unlock the files. The password is stored as a hash but is completely unrelated to the encryption key so you could technically just patch the password hash for the check to pass. Reversing the hash to the unlock code isn’t as easy though. If I remember correctly the unlock code is hashed multiple times to make rainbow tables useless. So if the unlock code is of reasonable size and complexity it will likely take an unreasonable amount of time to brute force it.

    One interesting aspect of the password dialog is that is does have some tamper protection. If you type in the wrong password too many times, it will actually try to destroy your data by encrypting your files using a “random” key (it’s not actually random, it just calls RDTSC). Fortunately the normal unlock dialog can’t be reached using conventional means in the variants I looked at, otherwise I am sure some victims would have messed up their data that way.

    By the way: Instead of renaming the files and patching the encryption routine it is a lot easier to just jump straight to the decryption logic contained in the malware that is usually called when you type in the correct unlock code. That way it will rename those files back for you and it is even nice enough to remove the infection ;).

    1. Fabian, thanks for the feedback. I know that some security sites picked up this post and used some, ahem, creative hyperbole. I didn’t want to give the impression that I am authoritatively declaring this as a brand new discovery. I just had not come across it before and felt it was noteworthy from both technological and sociological perspectives.

      My sample sounds similar if not identical to the one that you describe. I did see the strings related to decryption and tamper-proofing as well as some other “vestigial” functions within the binary. Though, after my cursory look through it, I couldn’t quickly see how to initiate the password/decrypt dialogues. I see that it calls some native hashing functions, which are probably used to verify the password, as you described.

      I was drawn into taking a closer look at this malware because of its primitive encryption capabilities, and the fact that it clearly is not capable of pulling down an externally generated key. I wonder how successful these fakes are.

      1. Don’t worry about the press. You mentioned that you intended to look into the malware further as you are still a novice. So I thought I point a few things out that are unusual in the sample that would make excellent research projects for your ongoing learning process :).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.