Written By
Written By
Share
Subscribe
March 22, 2017
This article is part of a Managed Services Security Series. Check out Part I to learn more about Ransomware and how it affects your organization. Part II discusses how unfinished projects create the best holes in security.
—
OST Managed Services comes across a number of interesting security situations while protecting our customers. This story is a slightly obfuscated retelling of a story that occurred at a large customer (Fortune 500 sized). The names and details have been altered from the original to protect our customer.
Why is this spreadsheet just weird symbols?
We received a call from a customer’s IT infrastructure department, indicating they had a ransomware outbreak and needed some help. A rarely used, but important share had just found to be encrypted, and the storage team did not have the tools to figure out the situation, so we came in to help. This is a common problem, it effects almost every organization at some point, but disaster can be avoided by following some simple rules (see our post on ransomware survival). Following standard protocol, we identified the source workstations, and found that there were a contingent of workstations that virus protection had been accidentally turned off, were infected with a root kit and a ransomware package deployed by the rootkit. After finding the systems, and having the deskside team shut them down (and hopefully destroy them), we turned our attention to the data. Then the situation turned ugly. The data had been encrypted for several months. Local storage snapshots were retained for only 2 weeks, and backups were retained for 60 days. This means, in essence, there is no copy of the data prior to encryption located…anywhere.
How to turn a CEO’s face white
After determining that there was no way to get the data back, we learned something new. The reason this share was infrequently accessed was because it was the master storage location for finished customer product. This is the location where finished data that the customer has paid for, is deposited for the customer to retrieve. This is engineering research material, material that cost tens to hundreds of millions to create, and is to be delivered to the customer for manufacture. Without it, the project is a failure, and the money is essentially wasted. Needless to say, the CEO of this company was more than interested in our success in getting the data back. Of course, there was no undoing the lack of precautions, the length of retention chosen, and lack of monitoring tools. There simply was no data to provide back. This is not news that pleases most CEO’s.
We immediately began using every ransomware decryption tool available, even setting up compute farms in Azure to try and decrypt data. We were having some success, about 0.00001% of the files decrypted per hour (meaning it will be ready in 8 years, after spending over $1,000,000 in compute charges).
Buying bitcoins with a purchase order
So what do you do when you have nothing to restore, and decryption isn’t practical? Tell the CEO “why not try paying the ransom?” This is how a CEO’s face goes from white to brick red. However, it was a valid point and the cost of the ransom was worth it if there was any chance the data could be brought back (about $10,000). We received permission to go ahead. However, paying a ransom in the corporate world is not an easy task. The customer was willing to fund it, they had the money, but how do you give a hacker a purchase order? Well, you don’t.
First, we (OST, as a service to our customer) created a bank account and funded it with enough money to pay the ransom. We had five days left before the ransom time ran out, and the hackers would delete the key. Since the ransom had a timer and the cost would increase if not paid in a certain time, we funded it with enough to pay the higher cost. Then, we established accounts using that account with two different bitcoin exchanges (Coinbase and Bitfinex, which ironically was shutdown days after this ordeal was completed), in the event that one could finish their process sooner than the other.
4 days left.
Connecting an exchange account with a bank account is tricky. You can simply point your exchange to your bank just like you’d pay your bills, but you are limited to a low transfer limit, maybe $50 per day. To get higher levels, you need to go through complex verification processes that increase in complexity with the amount. So with each exchange, we went through the process of providing passports, drivers licenses, video testimony that the person submitting the request was the person in the passport, conducting test transactions (the same way paypal verifies your bank account), provided tax return data, and in one case, submitted to a background check.
2 days left.
Then, we transferred the money from the bank account to the exchange. In the end, our authorization level wasn’t high enough in each account, so we had to split our transfers between them, then combine the Bitcoins in one wallet. Once funded, we now have 4 hours left (from 5 days, to 4 hours, down to the wire).
I will leave out the discussion about how bitcoins work, but theoretically, you transfer any fractional quantity of coins from one wallet (a long code that is an encryption key) to another. You have a key that unlocks this wallet, allowing you to make transfers out. Once a bitcoin is transferred, it is gone, there are no takebacks, and a mistake will simply lose your money. Transfers are not instant, you have to initiate your transfer, and wait for the system to update (wait for the blockchain to sync and the version to increase). On top of that, to minimize load, exchanges combine transfers, so your transfer may not be on the next block update.
With 4 hours left, we initiate the bitcoin transfer to the hackers, which I should note, have a very Eastern european accent (I asked if they found Kadyrov’s cat, they were not amused).
Hackers are super nice sometimes
The transfer completed, with 30 minutes to spare. Through the onion-based website (Tor browser) we were talking through, I gave them the transaction reference number. It was confirmed, and they sent me a link to download a key file. Finally. I went to the link… and the website crashed. I tried a number of times, tried some different hacks to get things running, and could not get it to work. So, I contacted the hackers, even gave them my cell phone number and asked if there was anything they could do to help. 6AM, my phone rings. A heavily accented guy asks for me, and says hes going to walk me through getting the file. Him and I chat a little, and we get a way for him to transfer me the file in an anonymous manner. We all get a picture of these hackers as members of the mob that might take you out, but in reality they are just folks in hoodies sitting at home on their laptop trying to make some money to buy groceries.
With key in hand, we got it to the team working the issue. We made a copy of all the data, stood up an isolated server, and decrypted the data on the stand alone server. Everything was decrypted within hours, and we were able to get 100% of the data back and in place.
Disclaimer
The above story is a bit fun to tell, but needs a disclaimer. First, more than half of ransoms paid, do not produce a key. People end up wasting their money. If you decide to pay a ransom, you need to know the likelihood of success is not high. Second, if there ever is a time that you have been affected by ransomware, and decide to pay the ransom, it is important to report the problem to the proper authorities, and ensure you tell them you are planning to pay the ransom. The above was done in coordination with the FBI. The wallets, transaction codes, and all details of the event were recorded and delivered to the FBI for tracking. When we decided to pay the ransom, we asked the assigned agent if it was ok. Technically speaking, transferring money to a foreign entity in exchange for an encryption key may not be legal. That line is obscure at the moment, because bitcoin is not fully considered currency, and the intractability makes it difficult to determine a country of origin for the key. In short, do not misconstrue the above as condoning the purchase of ransomware keys, do so at your own risk, and in general, spend the effort on preventing it in the first place.
