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:
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 orexfiltration ransomware.
Letâs explore each of these types in detail.
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:
There are two types of attackers that might exploit database ransomware.
Usually, both of those attacker types would contact the victim and ask for a ransom in exchange for the decryption key.
Attackers that use this approach actually steal the data instead of encrypting it.
The attacker could leverage the following exfiltration methods:
Hereâs how the two types of attackers, referenced above, may approach an exfiltration ransomware attack:
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.
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:
Figure 1: Exfiltration ransomware example from our honeypots
Here are some general guidelines for database ransomware detection:
Insertion of ransomware note's keywords. For example:
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.
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 thesecond 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.
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>
Now that you have a better understanding of database ransomware, here are few tips to protect your database from a ransomware attack:
**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.
The post Database Ransomware: From Attack to Recovery appeared first on Blog.