Ransomware: the anatomy of paying a ransom to decrypt hostage files
Ransomware is on the rise and clients seeking to understand the process can learn from this client’s story about being a victim of ransomware as to what can be expected and how to handle a ransomware attack. Recently a company facing a malware infection approached us to help them deal with the encryption of most of their servers across their domain. This also included systems that held online backups - and there was no offline backup solution (that’s a topic for a whole different blog post). The company had discovered a ransom note on their affected systems, along with data files that had been deleted and new files created in the format of <original_filename>.whereisyourfile that appeared to be encrypted.
The ransom note left on the systems described what happened - specifically that the files had been encrypted with RSA 2048-bit encryption - and asked for a ransom. The note also outlined how to communicate and pay, and even included a "try-before-you-buy" offer to decrypt two files for free to prove that the ransomers could release the hostage data.
The method of communication specified by the ransomers was Tor (The Onion Router), an anonymity network designed to obfuscate communications between people using it. In this case, the ransomers were hosting a website on Tor via Tor’s hidden service functionality. The only way to access the web site was through Tor, limiting the ransomer’s risk of being tracked.
For payment, the ransomers wanted Bitcoin - 1.7 bitcoins per server, 14 bitcoins for half of the servers (selected at the ransomer’s discretion), or 28 bitcoins (roughly $35,000 at that time) for everything. As with most ransomware cases, Bitcoin was used due to its innate anonymity and liquidity (transactions are non-reversible, equivalent to cash).
Upon closer inspection, the new 'whereisyourfile' files were indeed encrypted with RSA 2048, and there was no public disclosure of the key or method to decrypt without the keys. If this company could not recover quickly, the business would have to shut down. Accordingly, the only feasible strategy for the client was to pay the ransom.
As you might imagine, the company had never done this before. They had (basically) no idea how to acquire or pay with Bitcoin, how to use Tor, or what (if anything) they would get once the ‘transaction’ was complete. That’s when they engaged our team. After we provided the obligatory "don’t pay the ransom, it only funds criminal activity", "disaster recovery and business continuity planning are key", and "offsite backup and recovery testing can be fun" advice/lecture, it was quickly found that they were looking for us just to help them get through the ransom payment and recovery activities. With that direction, we were off to plan a strategy.
To reduce the company’s risk, our strategy was to perform the following:
- Execute the "try-before-you-buy" option and decrypt two files to validate that the ransomers were capable of performing the decryption process.
- Buy the single most valuable server for 1.7 bitcoins.
- Buy half the servers for 14 bitcoins.
- Buy the last half of the servers for 14 bitcoins.
The plan was devised to reduce risk on our end-in case the negotiations went sour-or if the ransomers decided to steal the bitcoins without releasing the decryption keys. With this plan in mind, we were off to buy some Bitcoin.
Obtaining $35,000 in Bitcoin turned out to be much more difficult than we’d expected. Legitimate exchanges (such as Coinbase) require a significant amount of personal information to validate an account, the details surrounding the exchange were not written for somebody looking to buy a large amount, and the processing times were far beyond the scope of the immediacy posed by the ransom. Bitcoin ATMs are present around the Boulder/Denver area as well, but we found out the hard way that the limitations on new accounts were extremely minimal (under $20 in Bitcoin purchases allowed per day). The ATMs are also in some pretty sketchy locations, so showing up with a wad of cash was awkwardly dangerous.
In order to gather the required bitcoins, we contacted a colleague who is a long-term Bitcoin investor and he graciously loaned us 90% of the Bitcoin required for the ransom. For the other 10%, we met with a friendly, yet armed, Bitcoin dealer in a coffee shop and exchanged several thousand dollars for the remaining part of the ransom.
The next steps were to set up a virtual server on Azure, install the Tor bundle, connect to the attackers’ site, and begin negotiations. The ransomers offered to decrypt two files for free so we uploaded two files to their site, and a few hours later received a link to a file hosting website that contained the two files. After verifying the decrypted data was valid, we sent 1.7 bitcoins to the ransomers’ address and then requested to release one of the most critical servers compromised, a SQL server. It turned out that the ransomers knew our approach. They refused to decrypt that particular server, or any other SQL or backup server. We surmise this was due to the hostnames of the servers clearly stating their purpose and the inherent knowledge that the ransomers had about the value of their ‘hostage’. Instead they told us to supply a lesser value server, and after some deliberation on our part, we asked for a Domain Controller. Several hours later the attackers gave us a download link on a file sharing site to a ZIP archive that contained the following:
- An RSA key in .NET-XML format.
- A decryption program.
- A cleanup program.
- A help file detailing what each of the files were and their usage.
Upon decompiling and inspecting the decryption program, it appeared to be written in .NET and did not perform any overtly malicious actions. We tested the decryption program and key on a VPS set up specifically for this purpose, with several of the encrypted files found on the server. The decryption worked perfectly, and the files were recovered from their encrypted state. The decryption program and key were then loaded onto the domain controller. The decryption on the domain controller took a substantial amount of time, especially given that the decryption program was poorly written and attempted decryption on every file on the drive three times when once would have been enough.
Interestingly, the decryption program left the encrypted files in place, recreating the original file with the decrypted content which required ample disk space on the servers being decrypted. We presume that was done to prevent something from going awry and making them unrecoverable, like using an incorrect key on the encrypted files, or something failing or hanging up mid-decryption. The ‘cleanup program’ was designed to be run independently, after the decryption operations were complete. Quite considerate.
After proving the decryption worked on the domain controller, we then paid the full ransom and awaited delivery. After several more hours of nervous waiting, the ransomers replied with another link to a file hosting site. This download contained the same decryption / deletion / help files, plus all of the server keys that were encrypted on the domain. At this point, the domain was successfully decrypted server-by-server so full incident recovery could begin.
Ultimately, our client decided to analyze all technology and processes throughout their global operations to identify opportunities to improve their security posture, and implemented a regimen of vulnerability assessment and penetration testing across their SaaS solutions. They also incorporated a response to a ransomware attack as part of their incident response process and business continuity planning.
After going through this ordeal, this story ended as well as it could have for this client, and we both learned a lot from the experience. If you have been the victim of a ransomware attack or want to learn if you have vulnerabilities that could facilitate an attack, we offer ransomware prevention that can help you avoid getting into this situation, and recovery services that can help you get out of it as well.