Site icon Martin Haller, A blog about corporate IT protection and management

Ransomware 1: Data Recovery of a Blessing in Disguise

ransomware

ransomware

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

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:

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.).

Do you like topics, I write about?

It is not necessary to periodically visit my blog to check if there is a new article. Subscribe below for notifications. You will be the first one who will know about new article.

Exit mobile version