When the data doctor makes you ill (but we decrypt his ransomware)

What happened?

Recently, we were contacted by Aon Nederland Cyber Solutions, one of the largest Dutch insurance brokers and one of our cyber insurance partners. They had a small-business client (a transportation company) with a ransomware problem. That Friday morning, all the transportation company servers stopped working. The client performed basic troubleshooting and rebooted all systems, when the IT staff discovered a ransom note on the affected systems. The note was signed by “veri.doktoru@mail.ru”, where “Veri Doktoru” is Turkish for “Data Doctor”. We were apparently dealing with a Turkish data doctor that makes clients ill by infecting them with ransomware.

The point of entry seemed pretty straightforward: an outdated server with many services exposed to the internet. By using passwords found on the first system, the attacker was able to access (and encrypt) other systems, including the domain controller.

Most documents and the database hosting a critical application were encrypted and the attacker had overwritten and deleted all the backups. The attacker’s modus operandi however, was different from what we usually see: instead of deploying malware that encrypts files, this attacker used commercial and open source tools to encrypt files manually. Afterwards, he destroyed the legitimate backups and original files.

The company was at a loss. They had lost years of documents and the application they used to manage their core business was offline, with the data inaccessible. They seriously considered paying tens of thousands of Euro’s in ransom.

Threat containment

After deploying our EDR agent software agent remotely, we arrived the same day and started to contain the incident. After confirming the situation, we deployed our agent software to all other endpoints and made sure no servers were accessible from the internet anymore.

Following a couple of hours of triage, we decided it was best to physically acquire the database server hosting the critical application. The databases were fully encrypted and it was most likely the first server to be compromised.

Breaking the crypto

The attackers used software called ‘Steganos Backup 2012’ to encrypt the files on the server. At first it felt like an odd choice, the software was no longer sold or maintained by the manufacturer. It was however pretty lightweight and had built-in encryption functionality. This makes it quite portable and therefore easily deployable on remote systems were the attacker has access.

We started by making digital forensic copies of the server disks to maximise the chances of recovering data. In the meantime, we decided to take a look at ‘Steganos Backup 2012’. It most likely had not received much scrutiny from the security community and if we could crack the encryption, we could get the company up-and-running again.

After experimenting with the software, we quickly noticed something odd: the software required a password to restore the backup, but not to create a new backup of the same files. We suspected the key to encrypt the backup was stored somewhere. After a couple of hours of reverse engineering I discovered that it was even better: the original password was stored in the backup profile. The password was encrypted using AES with a 256-bit key. A perfectly fine encryption algorithm, but the key seemed to be stored in the backup program itself. At 1:30 AM, we finally had the password the attackers used to encrypt the files and application database (and I could get some sleep)!

Decrypting all the data

The next morning we started to recover the database and documents. After confirming everything seemed to worked as expected, we contacted the client. They were extremely happy and were able to decrypt all systems data using the same password. That evening (less than 48 hours after the attack was discovered) their most important application was working and they could conduct business again.

This attack was not very sophisticated but still pretty effective. By using commercial software the attacker did not need to spend time or money developing custom ransomware, evading antivirus etc. Although the attacker will probably change his modus operandi, we hope this post helps victims of this group to recover their data. Were your files encrypted using this method? We have prepared a Python script to recover the password from the 'localParams' file of Steganos Backup 2012.

decryptSteganos.py

#!/usr/bin/python3
# Decrypts localParams file from Steganos Backup 2012 profiles
# This file can be found in:
# %APPDATA%\Local\Steganos Backup\plans\<profile_id>\control

import sys
from Cryptodome.Cipher import AES
from Cryptodome.Util.Padding import unpad

key = b"\xd7\x34\x73\x4e\xd8\x70\x2c\x2b\x34\xfa\x10\xad\x40\x17\x43\x25\x77\xfd\x02\xc8\xec\x6f\x1c\xb0\xae\x95\xed\xb2\xc5\xad\x47\x69"

contents = open(sys.argv[1], "rb").read()
iv = contents[:16]
data = contents[16:]

aes = AES.new(key, AES.MODE_CBC, iv)
print("Password: '%s'" % unpad(aes.decrypt(data), 16).decode("utf-8"))

Have you been a victim of other ransomware? We suggest you check https://www.nomoreransom.org/ to see if a solution is available.

Back to business

The client had a bad experience with ransomware, where their data was encrypted for a brief period of time. Paying the criminals a ransom was an option for the client, but it would never be the preferred option. The client was extremely satisfied with our decryption efforts and most importantly for us: they were able to resume business operations the next Monday, three days after the incident occurred.

The only unhappy participant was the attacker. Instead of getting €50.000, this time he got nothing...