Mitigating Cryptolocker with the StealthWatch System by Brandon Tansey

Mitigating Cryptolocker

Malware comes in all sorts of shapes and sizes with new types constantly being discovered. Many times these newly discovered malware families stay out of the public eye, however that’s certainly not the case for Cryptolocker. Lancope is helping to protect our customers by incorporating Cryptolocker’s domain generation algorithm with the SLIC Threat Feed, allowing us to add the domains Cryptolocker will communicate with before they’re even registered.

Cryptolocker, initially discovered late 2013, made a huge splash almost immediately, and for good reason. Unlike many types of modern malware, which aim to remain undetected, Cryptolocker boldly announces its presence right after a successful infection. 

Cryptolocker Example

Cryptolocker does this because its authors want you to know that it’s there. It falls into a category of malware called ransomware, or malware that forces/coaxes its victims in to paying a ransom. Some malware in this category, like “FakeAV” variants, restrict the victim’s ability to use their computer until the ransom is paid. Oftentimes this includes an attempt to scare the victim by posing as a law enforcement agency issuing a fine or even claiming to be an anti-virus product offering to remove “the viruses” for money.

As threatening as they may seem, many common types of ransomware can be fixed by a trip to your helpdesk or neighborhood computer expert, but Cryptolocker differs in that removing the malware doesn’t actually fix the issue. In addition, knowing exactly how Cryptolocker works doesn’t allow you to undo its effects. 

The difference here is that Cryptolocker doesn’t only claim to encrypt (or lock) your files, but it really does it and does it well. In order to encourage and allow  victims to pay the ransom, Cryptolocker only encrypts certain types of files. The files that enable your operating system to run will remain intact, but personal and business files like Office documents and pictures will be encrypted. 

Cryptolocker Encryption Example

Removing the malware will stop Cryptolocker from encrypting files created after the infection, however it does nothing to help you get your already encrypted files back. In fact, Cryptolocker even leaves a notice saying that the only way to have your files decrypted is to reinstall the malware (if you’ve removed it) and pay the ransom fee. Unless the victim has adequate backups, this is unfortunately true.

What makes Cryptolocker-encrypted files just about impossible to retrieve are the facts that:  

  • Cryptolocker uses Windows’ built in, validated encryption library

Often times anti-virus companies and malware analysts will attack error-prone custom cryptography implementations in malware to retrieve encrypted data. Cryptolocker avoids this pitfall by using a validated cryptography library included in Windows.

  • Cryptolocker uses public key encryption[1]

Typically when people think about encryption keys they’re thinking about symmetric encryption, or encryption where the same key is used both to encrypt and decrypt a file. Public key encryption is a bit different in that separate (but related) keys are used for encryption and decryption. This means that Cryptolocker can use one key to encrypt its victims’ files without having any knowledge of the decryption key. Since the decryption key is not actually sent to the infected machine until it’s paid for, there is no way for a victim to retrieve it by analyzing their infected machine or its network traffic. It should also be noted that each infection uses a separate “key pair” (or encryption / decryption key combination), so each victim would need to obtain their own specific key instead of using one that someone else paid for.

The infected host never sees the decryption key and this is part of what makes Cryptolocker a formidable threat, however it can also be part of the key to a solution. The fact that the running malware has the encryption key without ever touching the decryption key indicates that the key pair is generated elsewhere. This means that Cryptolocker needs to reach out somewhere to download that key.

Domain Generation Algorithms

Where there is malware, command and control (sometimes just called C2 or C&C) is often just around the corner. C2 is traffic used by malware to communicate back to an attacker to receive commands and updates. While there are exceptions, this typically uses a traditional Client/Server model. When this is the case, as it is with Cryptolocker, malware needs to know where to contact its command and control server(s). 

A common way of accomplishing this is to hard code one (or multiple) IP addresses or domain names that the malware will reach out to for commands. This is easy to implement but also very easy to defeat. In the event that a few C2 servers are taken offline or domain names are seized, an attacker can lose communication with and control of all of their victims. 

The way Cryptolocker solves this problem is by using a domain generation algorithm (DGA). A DGA is just what it sounds like – an algorithm to generate domain names with a predictable output. 

In the case of Cryptolocker, the DGA will produce 1000 domain names per day if needed. An infected machine will attempt to look up each one of these domains until it finds a valid C2 server. Since all Cryptolocker samples use the same algorithm, the attacker behind the malware knows exactly which domains their malware will request on any given day and can register any one of them. This way, even if a domain is seized or made a sinkhole, they have tons of others to choose from. 

While this is a major step up from a few hard coded C2 hosts, it’s not a perfect solution. That’s good news for us. In order for a DGA to be useful in a C2 capacity it needs to be both common and deterministic so that the attacker knows where to wait for their C2 traffic. This means that someone who knows the algorithm can know exactly where Cryptolocker-infected hosts are going before they make a single request. 

At StealthWatch Labs we’re constantly working to enhance the protection offered by StealthWatch. In the course of investigating Cryptolocker we reverse engineered its domain generation algorithm and are now using it to populate the Cryptolocker host group of the SLIC Threat Feed.

How to handle an alert 

We hope that SLIC subscribers don’t end up with many (or any) Cryptolocker alerts, but the name of the game with Cryptolocker is speedy response so knowing how to handle it beforehand is important.  Seeing an alert means that Cryptolocker is either searching for a C2 server or has found one, downloading an encryption key in the process. A successful C2 exchange leads to Cryptolocker starting its encryption process, but more on that in a moment.

Cryptolocker can be quite an event on its own, but it’s important to realize that one infection can be the sign of more that have happened or more to come. Cryptolocker is often delivered to Zeus/ZBot botnets, so a Cryptolocker alert may be a good time to search your network for signs Zeus activity. Also, both Cryptolocker and Zeus are commonly mass-distributed by email, so finding the source of one alert may help you identify IOCs that lead to other malicious emails waiting to be opened. 

As far as fighting the encryption routine, again, speed is everything. Not only will Cryptolocker encrypt files on the host it has compromised, but it will also attempt to encrypt files on any attached network drives if given the opportunity. A quick reaction can save a lot of hassle, but trying to react manually may be impractical when talking about a window of seconds to minutes. StealthWatch users can take advantage of StealthWatch’s mitigation functionality to make the best use of the window of time between the first request and the start of the encryption process.

Mitigating Cryptolocker with the StealthWatch System

Fortunately, Cryptolocker is included as a host group within the SLIC threat feed.  While SLIC host groups are not exactly like traditional user-created host groups (in that they are often more than just buckets of IP addresses and may contain patterns to match communication on), you can still alarm on traffic to and from them like any other host group. The fastest path to generating actionable intelligence on Cryptolocker communication within your organization would be to create a Host Lock rule (via Configuration -> Host Locking Configuration) between Inside Hosts and the Cryptolocker host group provided by the SLIC feed. 

This will provide alarms on any communication between your organization’s assets and any Cryptolocker host. 

To take it one step further, these host locks can be acted on via the Mitigation Configuration rules of a FlowCollector. By creating a mitigation configuration between your FlowCollector and a device you wish to mitigate with (such as a null route on a Cisco router, a shun on an ASA, or a custom action triggered by an expect script) via Configuration -> Mitigation Configuration on each FlowCollector, you can tie this action to a policy defined around Cryptolocker.

Define a Cryptolocker policy under Configuration -> Host Policy Configuration, apply it to the Cryptolocker SLIC host group, and explicitly enable the Host Lock Alarm within the policy. Highlight this alarm, select “Edit Mitigation” at the bottom, and choose to mitigate on the source IP. If desired, specify a time duration for the mitigation action to persist. At this point, you should have effectively prevented the Cryptolocker infected host from communicating with the rest of your network, and (hopefully) limiting the damage of Cryptolocker to the host in question. 

Remember that since Cryptolocker attempts to encrypt both local files AND files contained on writable fileshares, this action could have just saved your company a considerable amount of time and money for a recovery effort.

To Cryptolocker and beyond 

Cryptolocker can cause a lot of chaos on not only the individual machines it infects but also the networks they connect to and the cloud storage services and backups they make use of. Supplementing the breadth of visibility that StealthWatch provides with the threat indicators that the SLIC feed includes enables our customers to make Cryptolocker’s DGA work for them rather than against them. 

StealthWatch Labs and the entire Lancope team are working hard to bring lots of awesome new things to StealthWatch, and you can keep up with it by following us here on the blog or on Twitter at @Lancope and @Stealth_Labs. 

Thanks to Dave Brooks for his contribution to the mitigation portion of the post. 



[1] Cryptolocker uses both symmetric and public key encryption. For performance reasons, a file is encrypted using AES256 and the symmetric key used is encrypted using the private key. This encrypted key is then attached to the encrypted file it belongs to.