In an ever-connected world, malware thrives and multiplies at an incredible rate. More than 200,000 samples are built, packed and pushed on the market daily. Few of these threats manage to cause widespread havoc and only a meager handful become so successful that they spawn vast numbers of clones.
Among that handful is CryptoLocker — a piece of malware that emerged in September last year and laid the ground for a new (but predictable) class of malware: commercial ransomware.
CryptoLocker has been around for roughly 9 months and has already been used to extort much more than $27 million. The Trojan often comes bundled with spam messages, but the most effective vector is a secondary delivery mechanism that involves the GameOver Zeus botnet deploying Cryptolocker in a pay-per-install affiliation mechanism.
When CryptoLocker lands on a computer, it contacts its command-and-control center, which then generates a 2048-bit RSA key pair. The public key is sent back to the computer and will be used to encrypt files with specific extensions. The key is exceedingly strong – if a victim would have started cracking the key on a regular computer right after the Big Bang, he would be only 0.02% through decryption by now.
Of course, an incident of this magnitude could not have stayed off our radar. We started investigating the CryptoLocker operation as soon as we got ahold of the first sample in an attempt to find weak spots, get the keys and gain some insight about the people who run the operation. Fasten your seatbelt and join us as we progress into the story of a malware operation that has inflicted millions of dollars in financial losses and locked up data with a real value that is still impossible to evaluate.
Shortly after getting the first CryptoLocker sample, our lab guys dug into the code in search for any hint that could lead us further into the operation. As expected, the first clue was the IP address that the sample connected to for further instructions. This IP was acting as a proxy, forwarding all request from the victims to a server hosted at a datacenter in the UK.
On November 22, we contacted the dataecenter to see if a forensic collaboration on the respective server was possible. We were forwarded to their abuse department. Following the protocol, we mailed the abuse box, but were soon informed that our ticket had been forwarded to the “customer” – that proved to be a Russian reseller and not the actual Cryptolocker owner. He got back to us and let us know that they suspended service for the machine used in the malware campaign. The server shutdown was followed by a couple days of silence.
Two weeks later, during the Botconf conference, the folks at MalwareMustDie announced that they had performed a massive takedown of some domains created by the CryptoLocker Domain Generation Algorithm. This two-step process resulted in 44 domains getting suspended around November 13 and some other 94 domains getting suspended by December 6 (conference day). Some of these domains were registered by security companies (including Bitdefender) for threat intelligence purposes. Luckily, our sinkholes were not taken down.
At the other business end, the CryptoLocker malware showed no slowdown, as the hard-coded domains in the CryptoLocker Trojan were not taken into account. The infrastructure stayed up and thrived in spite of the so-called takedown.
In late January, we heard back from the Russian reseller who owned the server hosted in the UK. The server was leased by a third party whose exact identity could not be verified. We exchanged a number of messages informing them that they may be sitting on an important piece of the CryptoLocker puzzle. The reseller promised us full support for forensic purposes. Meanwhile, the UK-NCCU was independently conducting its own surveillance of the server, as they were trying to get to the Cryptolocker gang as well.
On February 6, the UK-NCCU isolated the server to preserve its state. Unfortunately, following the seizure, the reseller had also lost access to the server, and was unable to create a file-system snapshot to share with us. Because of the legal trivia, the UK-NCCU could not share the leads in an on-going investigation with the private sector. It seemed we hit another dead-end in our investigation. Two weeks later, however, the UK-NCCU got back in touch with us to confirm that the server they had access to was not the final piece of the puzzle, but rather a proxy to conceal the botnet’s infrastructure.
Meanwhile, somewhere in Russia, the CryptoLocker gang started moving their operations from the reseller’s proxy to a different machine. On January 28, computers infected with CryptoLocker started connecting to two IPs hosted with a Russian datacenter — a clear indicator that the botnet hadn’t even been crippled, let alone taken down. We came across these new IP addresses by constantly monitoring what domains from the Domain Generating Algorithm are newly registered, and to what IP address they resolve.
The two machines had been configured to act as a proxy to another server in Russia. This secondary server was left inactive for a couple of days, during which it would only serve the default Nginx index page “It Works!”.
Later, one of the IP addresses that the newly registered DGA domains resolved to was assigned to a server hosted in Ukraine. We started to follow this lead by first mailing the hosting company that provided service for the respective IP address. After a brief e-mail exchange, we were forwarded to the Ukraine cybercrime police, who were more than eager to assist. They performed an official verification with Romanian police to establish that we are who we pretend to be, then got back to us with further information on the case.
This time, we managed to get forensics work done on the Tier 1 proxy server used by the CryptoLocker malware, a crucial milestone following our previous (failed) attempt in the UK. When our researchers started digging into the file system snapshot, we discovered that the CryptoLocker operation was not only highly organized, but also extremely opportunistic.
The Tier 1 proxy server forwards the victim’s traffic to a secondary server to maintain anonymity and hide the location of the key server. This proxy also handles domain name resolution to rapidly allow its operators to perform name changes and avoid suspension.
Both the Tier 1 and Tier 2 proxies can be rapidly customized by deploying specialized tools made available by the owner of the infrastructure. When either of the tools run, a regular server becomes a Tier 1 or Tier 2 proxy in minutes, depending on the DNS propagation time.
Since we had access to the Tier 1 proxy, we also managed to get the configuration files, which allowed us to trace the Tier 2 proxy IP address listed within. We reached out again to our new contacts at the Ukrainian Cybercrime Division for help with the Tier 2 machine we identified. Meanwhile, in Ukraine, internal political strife was exploding into violence, so law-enforcement agencies had been mobilized to more urgent matters.
When spirits settled down, we re-started our collaboration with the Ukrainian Cybercrime Division and finally analyzed the secondary server. Forensic analysis on the machine revealed that it was a Tier 2 proxy, as we initially suspected. This new setup was much more sophisticated and designed with resilience in mind.
The second-level proxy was apparently meant to take the information forwarded by the Tier-1 server, filter it and forward it via GRE tunnels to other servers (most likely Tier-3 proxies). Digging deeper into the configuration files revealed that the server had assigned 10 different IP addresses. When data packets reach the first interface, they are automatically forwarded through a specific GRE tunnel and traffic is prioritized appropriately. When probed from IP addresses belonging to law enforcement, CERTs or security companies, the server implements a mechanism to add them to a black hole, routing all packets from the respective IPs to /dev/null.
Like in the case of the Tier 1 proxies, the Tier 2 servers are easy to configure, using a custom written utility. It can be called with one of four parameters, depending on what type of server needs to be deployed.
The Tier 2 server handles two main functionalities: it secures traffic by screening its origin and blocking law enforcement or security companies and it also sends the data it received from Tier-1 servers through highly encrypted and redundant connections.
On June 2, the Gameover Zeus infrastructure – one infection vector for CryptoLocker – was shut down in a synchronized effort by the security industry and law enforcement. Along with GO Zeus, the fine men at UK-NCCU also blocked DNS resolution for the entire list of domains generated by the CryptoLocker DGA, thus cutting off the botnet from the Tier 1 proxies around the world. At the moment, a number of machines are still infected with CryptoLocker that were not “activated”, as the botnet disruption occurred before the locally-installed bot was able to exchange keys with the C&C and commence encryption. Most likely, these hosts will immediately become infected and lose access to their data. We urge users to perform an in-depth virus scan on their computers to detect and eliminate inactive instances of CryptoLocker before the encryption process starts or they risk losing some data.
The June 2 takedown shook the Cryptolocker operation pretty thoroughly. As of this writing, the Cryptolocker services we are monitoring no longer respond. Nor do they serve the keys for people who still give in and pay the ransom. Theoretically, payment is still possible because each wallet is generated at infection time. The service does not send the decryption key as it used to before the takedown. Subsequently, all users whose data is already been encrypted now have no recovery option, even if they pay the ransom. We cannot test this, since CryptoLocker services are still offline.
The intricate infrastructure described in the previous paragraphs, however, is thriving and serving other “customers” in underground forums. Our forensic investigation revealed that the same communication network is responsible for other threats, such as Citadel, FakeAVs, fraud and scams or Casino schemes.
At the moment, the fate of Cryptolocker is undetermined. Infected computers all over the world are still trying to call home to pre-determine URL addresses created using the DGA algorithm, but they are unable to resolve the corresponding IP addresses. However, the Gameover/Zeus family could be back online and we are prepared for an updated Cryptolocker with a new DGA or TOR connectivity to be delivered to the (still) infected computers and to new victims.
File-encrypting ransomware has proven quite successful, given that Cryptolocker alone surpassed $27 million in revenue in less than a year. Various other cyber-criminal groups are taking the business to a whole new level by anonymizing communication via TOR, for instance.
One example would be TorLocker, a commercial ransomware toolkit sold on underground forums as an affiliate program. Among its most touted features, TorLocker includes built-in encryption keys that are renewed every 10 infections and the ability to call home via Tor. Built-in keys allow TorLocker to encrypt files even if the victim PC is not online, while Tor-based communication makes it nearly impossible to shut down the operation.
The mobile sector doesn’t look any brighter. The number of ransomware-based families targeting Android has increased in the past few months. They are not only becoming more prominent, but more sophisticated as well. As a quick example, the first mobile ransomware threats were just attempting to lock users’ screens (by setting the app as a device administrator or by drawing a Web View that stays on top of everything). New mobile ransomware, such as Simplelocker, takes data hostage by applying strong encryption on it, but these threats are less complex than what Cryptolocker does on PCs.
Cryptolocker may be gone, but there is still the issue of the content delivery network. A botnet’s backbone is the communication infrastructure. It is designed not only to scale up operations and provide redundant access to other nodes in case of failure, but it also anonymizes the data flow and prevents victims, law enforcement or security organizations from tracing the real operations center. In our case, taking down this specific backbone would have not only wiped Cryptolocker, but also the other botnets that use it.
Ever since we started investigating the botnet, we have been looking for a way to recover the keys from the Cryptolocker storage server. Disruptions of communication between victims and Command and Control servers can give the security industry time to react to a new threat, but our main focus in this specific type of threat is finding ways to allow everybody to get their data back safely without paying the ransom. This is a huge undertaking that requires not only technological skills, but also industry partners and cooperative law enforcement agencies to provide us with the legal framework for gaining access to the server, financial investments in domains (for sinkholing purposes) and technical expertise to figure out how pieces fit together in this intricate puzzle.
Meanwhile, we strongly urge users to pay extra attention to the resources they visit as well to what they install on their computers. Software updates for third-party products such as Java, Adobe Reader or Flash should be deployed as soon as they become available. The use of an anti-malware solution would also be highly recommended.
A detailed presentation on Cryptolocker and the infrastructure behind it will be given during this year’s Virus Bulletin conference that will take place in Seattle between 24 and 26 September.
tags
June 08, 2023
May 02, 2023
January 11, 2023
January 05, 2023