Database Ransomware: From Attack to Recovery

Introduction

In recent years, ransomware attacks have risen sharply, due to their profitability, ease of access with ransomware-as-a-service (RaaS) tools, and an increasing attack surface. 

Ransomware is a type of attack in which the attacker locks and encrypts a victim’s data and then demands a payment to unlock and decrypt the data. This kind of attack is often associated with files and file systems, but it can also target database servers. Database ransomware can be a challenging event as the recovery process is usually complex and requires deep knowledge of database technologies.

In this blog post, we will explore in detail the threat of database ransomware, including findings from Imperva Threat Research including:

• The ways to detect such an attack
•  General guideline for a recovery
• A detailed and technical example of recovering a MySQL database from such an attack.

What is a database ransomware attack

Unlike the more common file-based ransomware attacks, a database ransomware attack affects the database objects, not its files. 

A database ransomware attack can be classified in two ways: encryption ransomware or exfiltration ransomware.

Let’s explore each of these types in detail.

Encryption Ransomware

This method is often the first to come to mind when talking about ransomware. It is often associated with files and file systems, but is also used on database servers.

In this sort of attack, an attacker could leverage built-in database encryption features such as:

• Data encryption at rest methods like TDE (Transparent Data Encryption). These methods encrypt data before writing it to the disk, and decrypt it when it is read back. Data in memory is not encrypted.
• Built in encryption functions. Databases have support built in (or through plugins)  for encryption functions using standard algorithms like AES, DES, and RSA. A common use for those functions is to insert data into tables or columns while applying those functions on the data values. From that moment, the data is encrypted until a decryption function is applied. Databases might also contain key management features to support the use of those functions.

There are two types of attackers that might exploit database ransomware. 

1. The “hit and run” attacker that encrypts the data in a fast and “noisy” manner without caring about stealth or endurance on the system, and then removing the encryption key. This could be done using a general database mechanism to encrypt data at rest using a primary encryption key and secondary keys encrypted by the primary key. The primary encryption key would be removed, and the database can’t decrypt the table data without the full pair of keys.
2. The “resident” attacker stays under the radar by reading the data carefully in a “slow & low” attack. This attacker would then encrypt the data and leave the encryption key so applications can still function without interference. Once finished, the attacker would remove the primary encryption key, and data won’t be accessible anymore.

Usually, both of those attacker types would contact the victim and ask for a ransom in exchange for the decryption key.

Exfiltration ransomware

Attackers that use this approach actually steal the data instead of encrypting it.

The attacker could leverage the following exfiltration methods:

• Database dumping tools
• Regular ‘select’ queries (sometimes limited to X records)
• Using evasion techniques to bypass security controls, like DNS exfiltration (using database functions that do DNS resolving).

Here’s how the two types of attackers, referenced above, may approach an exfiltration ransomware attack:

• The “hit and run” attacker would read the data in a fast and “noisy” manner, probably using database dumping tools or general queries without filtering clauses.
• The “resident” attacker would stay under the radar, while reading the data carefully and probably using evasion techniques to exfiltrate it slowly.

Once finished, each attacker would truncate or delete the data from the victim’s database and create a new database or a new table that contains a ransom note.

Honeypots

Imperva Threat Research monitors the database attack landscape by setting up multiple database honeypots. These honeypots are used to learn attackers’ tactics, techniques and procedures (TTPs) and develop new detection methods. In our honeypots, we see database attacks on a daily basis.

Although we haven’t observed an encryption ransomware attack in our honeypots, we’ve managed to conduct an experimental attack. On the other hand, we’ve observed multiple exfiltration ransomware attempts in our honeypot servers.

Here are some interesting facts we’ve gathered from our honeypots during the ransomware attack research:

• In some of the attacks, the attacker left a ransom note saying they got our data, but our logs showed otherwise. Only a small portion of the data was read, probably to serve as a sample if the victim asks for proof. When attackers say they stole your data, make sure you understand which data was actually stolen. Attackers are not a reliable source!
• Attackers usually ask for ransom payment in Bitcoin.
• When looking at those BTC addresses, we can observe that there were active transactions, but we can’t necessarily connect them with the ransom requests.
• Sometimes the ransom note includes a threat of GDPR fines, as illustrated in the image below.

Figure 1: Exfiltration ransomware example from our honeypots

Detection

Here are some general guidelines for database ransomware detection:

• Search the database logs for:
  • Use of encryption/decryption functions. For example: 
    • MSSQL’s ENCRYPTBYPASSPHRASE
    • MySQL’s AES_DECRYPT
  • Database key management operations. For example:
    • MSSQL’s ALTER MASTER KEY
    • Oracle’s ADMINISTER KEY MANAGEMENT

Insertion of ransomware note’s keywords. For example:

• Use your database’s audit engine to save historical database activity data. 
  • MySQL’s enterprise audit plugin
  • PostgreSQL PGAudit extension
• Look for anomalies that deviate from the standard behavior of the DB or its users, such as:
  • Excessive amount of records read: Normal day-to-day amount of rows consumed vs an anomaly
  • New query patterns: Applications usually use a fixed set of queries. If a new query is observed, it can be a sign of a breach.
  • New error messages popping up: Applications usually shouldn’t produce database errors. There are also human users that might access the database and produce errors on occasion. If monitoring those error types regularly, you’ll have the ability to identify new error types which might be an indicator of a breach. For example, an attacker could use techniques like SQLi which might produce syntax errors.

How to Recover from a Database Ransomware Attack

Now that we are familiar with the types of database ransomware, let’s talk about recovering from an attack. You can’t really assure that your data isn’t stolen, and your systems may suffer from availability issues, but you can return your systems to an operational state by recovering your database from backups.

Pre-configurations

If you didn’t back up your database, your data is probably lost, unless you pay the ransom or the attackers are kind enough to return it. That brings us to the first rule: always keep your database frequently backed up in multiple locations. An attacker may not have access to the primary or secondary backup location. Monitor the access permissions to those backups, and test your backup files from time to time to ensure their integrity.

Database logs will be invaluable if you want to prevent data loss after a ransomware attack. 

That brings us to the second rule: always run your database with transaction logs enabled.

It’s also good to have a backup of those logs, as attackers might try to tamper with them.

How to Restore Data after a Ransomware Attack

• Step 1: Identify the tables that were encrypted or deleted.
• Step 2: Locate the most recent backup for each table from Step 1.
• Step 3: Restore each of the tables using the backups from step 2.
• Step 4: Now, you should have your table restored to a backup point in time, but there may have been legitimate changes since then. Search your logs for the point in time just before the attack started and restore operations from the log to that point.

In a situation where legitimate operations were done in parallel to the malicious ones, custom work is needed to read those logs and transform only the legitimate operations into commands. This will enable commands to be executed against the database to fully recover from the attack.

Notice: Each database vendor has its own terms and options for backup and recovery. There are different types of backups (hot, cold, warm, online, offline etc.) and different types of recovery. In this blog post, we’ve covered the general ideas.

<internal link to a section in this document “Recovery example using MySQL (Linux based)” section> For a more in-depth example of the recover process, check out this example of MySQL database recovery <end of link>

How to Mitigate Database Ransomware Attacks

Now that you have a better understanding of database ransomware, here are few tips to protect your database from a ransomware attack:

• Put your database behind a firewall and allow access only to authorized services and personnel.
• Check your databases regularly for non-secure configurations or highly privileged entities (DISA or CIS regulations might help you identify those configurations).
• Follow the “least privilege” concept – a user should be provided only with the minimum permissions or minimum roles to perform their job.
• Always backup your database in multiple locations. Don’t forget to test your backups regularly.
• Databases are often considered an internal service within a  network.Therefore, they  tend to be neglected and the security defenses are lacking. This is a huge mistake as an attacker is likely to find this weak spot and use it against you.
• Use dedicated database monitoring and risk analysis tools to achieve better visibility and enable more effective protection of your databases.

Example: Recovering a MySQL,Linux-based database

The story. We have a test MySQL instance with a database called ‘lab’. In this database, we have a table called ‘test’, which contains fake credit card numbers and their owners. New records are added to the table every day.

We have a daily backup of this database and binary logs are enabled.

An attacker read the records from the ‘cards’ table and then used a ‘delete’ statement to remove the records. Meanwhile, new records are inserted into the table, which makes the recovery process more complex. When the delete statement is done working, there’s an empty table with a ransom note from the attacker.

Here is how we will recover the table:

First, we need to identify the time when the attacker started to delete records from the table. We can do this by using the mysqlbinlog tool with the suspected timeframe. For example:

Here is a portion of the output:

We can see that the rows were deleted at log position 310761361 (“# at 310761361”). We will take one of the previous log positions (310761173) to be our “–stop-position”.

Now, it is time to recover our database to the last successful full backup. There are many ways to backup the database. We will use a backup prepared by the ‘mysqldump’ tool with the “–master-data=2” option. At this point, it’s better to shut down the application to avoid missing data until the recovery process is done.

After the recovery process is finished, we need to continue and also recover the log records that were written until the deletion process was started (this is the “–stop-position” we found in one of the previous steps).  We also need the start-position which is written in the backup file (“MASTER_LOG_POS=310760919”):

This will be done using the ‘mysqlbinlog’ tool:

If there were new rows or changes to the database after the deletion, you can find the right log ranges and apply the previous step again with updated parameters until all data is recovered.