Ransomware 1: Data Recovery of a Blessing in Disguise

It was the beginning of spring. I was just enjoying a moment of lower workload. The fluctuations in the amount of work are so high, that I sometimes suspect our customers that they plan together.

In the middle of the week (Wednesday), we have a new customer with an indefinite request for help with data recovery. The meeting was arranged at noon the following day (Thursday). At the meeting, I learned that they have encrypted data from shared folders on the Hyper-V server (infrastructure: Hyper-V server with two virtual [DC and Terminal Server with IS]) and are unable to help by themselves.

In such a case, the best way to follow is to recover from backups… but these were several months old, and therefore another way was sought.

Inappropriate or insufficient backups are a much more common offense than you would think. 🙂

How did the attackers attack the server

I took the case myself because I was very professionally interested. First, it was necessary to find the type of ransomware and the method the server was penetrated. Everyone who knows me knows that if I go into something, I will not stop until it is done or I fall down exhausted. About nine o’clock pm, I had most of the information and a prepared report for the customer. Because of the seriousness, I arranged the meeting for the next morning (Friday).

So, what did I found out:

Penetration method

This was a dictionary attack on the port-forwarded RDP Hyper-V server. The attack began at 1:34 am and ended after 38 minutes by guessing the password for the Administrator. From curiosity, I made an NTLM hash dump and tried to break the password myself (thanks to the hash attack I did it in 2.5 minutes). When I then saw the password the user had set up for the administrator, I was surprised that the client’s server was not attacked any time earlier (the password was “Password1“). Subsequently, the attackers had 3x logged on to the server manually (IP from Russia, Ukraine and Luxembourg) via RDP and deployed the Ransomware to the server.

Cryptolocker

Based on the suffix of encrypted files and the form of the ransom note (blackmail), I have mistakenly detected ransomware as a new version of Globe3, for which, at a time, there was no decryption tool. The e-mail address for communicating with the attackers was no longer functional and it was not possible to pay the ransom.

Other observations

• Attackers, in addition to ransomware, have also installed bitcoin mining malware (perhaps a small extra to the ransom).
• I could not find any signs of trying to get to other devices/servers on the network. They only had a local administrator and as such, it didn’t have any further access. They could have been stop the virtual DC and compromise it, but they did not.
• The local user, the administrator, who was abused by the attackers, was not used by anyone. It was just a forgotten account since the initial installation by some original IT contractor. Since then, everyone was probably afraid to touch the account for something could stop working. The screenshot shows when the password was changed. According to the interview with the customer, it is at the time of delivery of the server. The “last logged in” date is the date when the penetration has occurred.

A blessing in disguise

On Friday morning, I have discussed everything I have learned with the customer and what steps we need to take to get rid of the infection and be able to trust the server/network again. We did everything on Friday and part of the weekend. On Monday, the customer could work again. So far, the customer didn’t have any data from shared folders, that were encrypted. We wanted to wait a few weeks before an upgraded version of the Globe3 decryption program would appear.

But the customer was blessed in disguise:

• Due to the “slack” of the attackers, there was no encryption done on the virtual servers that were on the Hyper-V host. That’s because they were running and the ransomware did not get a right to access from the OS.
• With the help of the BLEEPINGCOMPUTER Forum, I have managed to identify the correct version of ransomware and find the decryption program. As a result, we were able to restore all encrypted data.

How could the attack be prevented?

For the occurrence of most incidents, there is a chain of events that must happen to make the incident happen. It would be enough for this customer if at least one of the following measures were respected:

Do not use dictionary passwords

The very basic rule. Do not rely on the fact that Czech words will not be used by the attackers. I often find that administrators turn off enforcement of the complexity and length of passwords in AD (a condition that is necessary, but not enough). This really is a very bad step. Networks that we then service include, for example, passwords that have only 3 characters or are the first name of the user…

Disable default users

All random dictionary attacks (ie the attacker does not know who is being attacked) are trying to penetrate accounts with known usernames like administrator, admin, remote, support. Ideally, do not create or disable these user accounts at all. In our monitoring system, we check every single day that such users do not exist.

Track unused user accounts

If an account is not used, it is not necessary to be active. Employee accounts are often active on the network for employees who do not work for a company for a couple of years but can still access the corporate data. We have preprogrammed this control into the monitoring system, and we monitor all the accounts that has not been logged in within 3 months.

Limit port-forwards

if it is not necessary, do not perform the port-forwards. If you are already doing so, limit them to specific IP addresses, for example. (TIP: FortiGate routers can be restricted based on the country IP, for example, when the company only operates in the Czech Republic, we allow access to the terminal server only from the Czech Republic.).