A new customer has called to say that the server doesn´t start and that an external backup disk is not loaded. The contact has been shared by his acquaintance saying if someone can help him, that will be us – such praise is always very pleasing. 🙂
Situation report
Then I got this photo from the server screen. I said okay, I have not seen this yet and it looks interesting. I have quickly googled and assumed that it is 50/50 fake. So the customer went on an unpredictable 4-hour journey from Pilsen to Brno via D1.
Before the customer has arrived, I have managed to google a little more. I have managed to find out that some attackers had switched from their often-leaked “cryptoviruses” to the legitimate Diskcryptor tool. Their “cryptoviruses”, resp. tools they have used to encrypt data had often been defective. Due to defects, security companies have succeeded in breaking the encryption and the attackers have lost the ransom.
It’s a pretty smart move. I’ve been telling myself why they didnt do it that way. By using proven open source tools, they will bypass antivirus (because it is a legitimate application), they will not have to program anything themselves and will not have bugs in the program that would make them part with their ransom.
When I compared the above photo with the “prompt” that DiskCryptor has, I was pretty sure what we are going to do (FVE – full volume encryption). But I did not want to give up, because the customer had relied on us. I have continued searching some more.
When the customer has arrived
I still hoped that the attackers had made a mistake and the data could have been recovered. For example, some attackers used the same password, and I hoped it could work. Unfortunately, none of the passwords had worked.
I have booted the “Active@ LiveCD!” And started to analyze data on the internal RAID server. On the secondary PC, I have then analyzed the external disk using the “EaseUS Data Recovery Wizard”. Both the server and the external disk were really encrypted using DiskCryptor. I have also discovered some unencrypted data by further analysis. In my opinion, this was a “free space” (deleted files at the time before DiskCryptor had started) that the DiskCryptor skipped to shorten the encryption time. I guess we would have encrypted some MDF files that the customer could get , but it would not be a miracle and it would take couple of hours.
The situation was as follows:
- Customer has no backups. The only one he had was the ones on an external disk, which is also encrypted.
- Disks on both the server and the external disk are encrypted with a legitimate SW DiskCryptor, for which I do not expect any errors that could be easily detected.
- The customer has calculated a loss of 63,000 for each day when the data is not in his possession.
- The attackers did not communicate with the customer.
Communication with attackers
Even before the customer has arrived, I began to negotiate with the attackers. It was as an insurance if it came to the worst and we could not recover the data. I led the negotiation from private email (to not to scare them away and to estimate how much the customer is willing to pay) in English (the attackers do not speak Czech 🙂 ).
I have to say that the attacker´s response speed could be envied by any corporate helpline. The attackers estimated the price at 2.1 BTC, which was about 126 thousand crowns at that time. I have negotiated in the style that we are a small family business and we do not have enough money. So we got them to 0.5 BTC (about 30,000 CZK). I think it could go even further, but the customer was already happy with this price, and due to the loss he had incurred for every day of inaccessibility, he came up with the amount.
So we have transferred the money to the BTC, paid the attackers, and we were waiting for a password to unlock the disk. In a few minutes there was an email with a password that was quite simple (6 digits) and fortunately it has worked.
All’s well that ends well
Normally, I would not consider paying ransom as a successful end of data rescue …
On the other hand:
- • When the customer had called us in the morning, he feared he would never see the data and that it would mean the end of the company.
- • He was lucky, however, that in this case the ransom could be paid and the data was really restored.
- • We have managed to fix it all up in 1 day (the customer has left at 8 pm with the functional server from Brno back to Pilsen). Losses from the attach were thus low.
- • The attackers did not estimate the value of the data they have gotten their hands on. The ransom came relatively “cheaply “.
Lesson of the story?
Once we have unlocked the server with the password, I began to find out how the penetration was done. I have originally suspected breaking a Administrator user through a dictionary attack on port-forwarded RDPs (see Ransomware 1: Data Recovery or Blessing in Disguise). I was not sure, however, that the password was weak, but not entirely dictionary like. But after the server was up and running, it was clear to me that the attack was conducted manually through the VNC, which was left behind with a weak password and access from the Internet.
I see the following critical issues with the server:
- Insufficient backups: the server was backed up only on a connected external disk so that only a stand-alone database was backed up. The dangers are numerous:
- Slow recovery: Because only the DB is backed up and not the whole server. So, in the case of recovery, the whole server would have to be reinstalled (updates, drivers), installing the database, installing the information system, reconfiguring everything, and finally recovering the database. This is more than a day’s worth of work, and there is still a need for IS producer collaboration.
- The attack is not survivable: as backups are available from the server, you will lose your backups if it is broken (see this case). It is necessary to prepare for such things and make the backups durable. At PATRON-IT we have introduced two technologies that are not expensive and protect the backups. An article will soon be published.
- • Unnecessary services: Paradoxically, nobody has been using the VNC for several years but has not been removed. It’s the same situation as I wrote in the case (“Ransomware 1: Data Recovery or Blessing in Disguise“) with another customer. All you need to do is to not to use user accounts with common names, block unused accounts, have strong passwords, deactivate port-forward that you do not use, or restrict them to specific ip.
Unupdated system: I’ve noticed that the operating system has not been updated for 4 years after the server is up and running. Although it did not play a role in this case, it would only be a matter of time for the server to be compromised on the basis of an exploit (eg EternalBlue). All you have to do is connect the infected station to the network.