Analyzing CryptoLocker
Last Update:
Word Count:
Read Time:
The first analysis article of this series!
Introduction
This article is part of my series: Inside Different Generations of Ransomware.
If you are interested in the full series, please refer to the page above.
This article presents an analysis of CryptoLocker and focuses on its design philosophy and underlying mechanisms.
CryptoLocker
CryptoLocker is a ransomware that spread between 2013 and 2014. This malware encrypts certain types of files stored on local and mounted network drives using RSA public-key cryptography, with the private key stored only on the attackers’ control servers.
CryptoLocker typically propagates through email attachments disguised as legitimate messages, often appearing to originate from trusted companies. 1
This article focuses on the design philosophy and underlying technical mechanisms.
Experimental Environment
To safely conduct malware analysis, the environment should be isolated using virtual machines. Under no circumstances should malware be executed on a personal or production system.
| Tool | Description |
|---|---|
| ExeInfo PE | Detect packers, compilers, and basic file metadata |
| Detect It Easy (DIE) | Identify packers, protectors, and signatures |
| Wireshark | Network traffic analysis |
| dnSpy | .NET analysis tool |
| de4dot | .NET executable de-obfuscator |
| Ghidra | Software reverse engineering framework |
| Device | IP Address | Description |
|---|---|---|
| Windows 7 x64 (VM) | 192.168.85.5 | Victim machine |
| Windows 10 x64 (VM) | 192.168.85.3 | Analysis machine |
The two virtual machines were configured within an isolated internal network to prevent unintended external communication. If you want to know how to set up your experimental environment, please view:
- How to Setup Your Experimental Environment for Malware Analysis
- Installing VMware Tools on Windows XP and Windows 95 with VMware WorkStation 17
Launch
After launching the payload, it copies itself to %APPDATA%. The payload process creates a subprocess to maintain persistence and avoid termination.
If either the parent or child process is terminated, the other will recreate it. Therefore, to fully terminate the malware, both processes must be terminated simultaneously.
Protocol Analysis
The payload continuously attempts to connect to its C2 server.
Further investigation shows that the domains are generated using a built-in algorithm. This raises an important question: if the domains are dynamically generated, how can the attackers ensure that the ransomware successfully connects to a valid C2 server?
The answer lies in the use of a Domain Generation Algorithm (DGA). Since the attackers possess the same algorithm, they can pre-register a subset of the generated domains, ensuring that infected machines can eventually connect to an active C2 server.
Reverse Engineering
In this section, both CryptoLocker 1.0 and 2.0 are analyzed. Version 1.0 is written in C++, while version 2.0 is implemented in .NET.
CryptoLocker 1.0
Open the payload using ExeInfo PE and DIE (Detect It Easy):
Although both these tools suggest that the payload is packed, it does not significantly affect the analysis.
Open the payload using Resource Hacker:
Then analyze the payload using Ghidra:
The payload generates domains using predefined patterns such as *.co.uk and *.info:
The domain generation algorithm (DGA) is shown below:
The malware connects to the C2 server using WinHTTP APIs:
After receiving the RSA public key, the malware enters the encryption phase.
First, it collects information about all available disks:
Next, it scans for files with specific extensions and generates a symmetric key for each file:
The file data is encrypted and written into new *.tmp files:
Finally, the original files are replaced using MoveFileExW, and their attributes are preserved using SetFileAttributesW:
This design follows a hybrid cryptosystem: AES is used for efficient file encryption, while RSA is used to encrypt the AES keys.
Replacing files instead of deleting them reduces the chances of recovery through digital forensics techniques.
CryptoLocker 2.0
CryptoLocker 2.0 is written in .NET. The payload is analyzed using dnSpy:
The code is heavily obfuscated:
Therefore, I de-obfuscated it using de4dot:
The payload resources are shown below:
The overall mechanism of version 2.0 is largely identical to version 1.0:
Conclusion
This article presents an analysis of CryptoLocker version 1.0 and 2.0.
The entire process can be summarized as the following flow charts:
CryptoLocker is one of the most influential ransomware families in history due to its use of a hybrid cryptographic model (RSA + AES). Unlike earlier ransomware, which often contained flawed encryption implementations, CryptoLocker made file recovery without the private key practically infeasible.
It demonstrates how modern ransomware can effectively resist digital forensics through strong cryptographic design and proper key management.
This is the first analysis article in this series. As I continue this series, I will further explore more advanced ransomware families and techniques.
If you have any comments or suggestions, please feel free to leave them below!
References
1. https://en.wikipedia.org/wiki/CryptoLocker ↩
THANKS FOR READING
