Analysis: A Ransomware Attack on a PostgreSQL Database

In 2017, we reported on a database ransomware campaign targeting MySQL and MongoDB. Since then, we’ve observed similar attack tactics on a PostgreSQL database in Imperva Threat Research lab. 

In general, the attack flow contained:

• A brute force attack on the database for known users and weak passwords
• Collecting a list of all of the logical databases and all the tables in each database
• With each table, the attacker does the following
  • Gets a list of all of the columns of each table
  • Queries the table and collects the data
  • Drops the table — a way for the attacker to remove the files after stealing them
• Once finished with all the tables, drop the database
• Once finished with all the databases, create a new database and a new table, inserting a ransom note asking for an amount of bitcoin (BTC) in exchange for the ransomed data.
• Usually, the ransom note will include a threatening message suggesting that the data will be publicly exposed if the ransom isn’t paid.
  

Recently, we’ve found this kind of ransomware attack targeting our PostgreSQL database, and we’ve observed some interesting facts.

How Attackers Fooled the Target of the PostgreSQL Database Ransomware

While analyzing the attack we can see two major indicators:

1. The attacker executed a query to get the logical database size.

2. The attacker executed a query to get only a small portion of the records of each table.

That leads us to assume that the attacker wasn’t going to give the victim’s data back, but only shared the size and sample data as a proof if the victim asked for it. The attacker does not intend to collect the whole database, only to fool the victim into thinking they have done it.

Termination and control

We’ve determined that this database ransomware attack is a “Hit and Run”-style attack because of its general flow. There’s another indicator to add.

One of the commands executed by the attacker was:

A backend, in simple words, is a process that handles a database client connection.

We can see that the attacker tries to terminate all of those backend processes with no attempts to do it in a stealthy manner. Those attempts are probably executed in order to have the database objects unlocked for a later drop.

Ransomware notes

The last phase of the attack is a new database creation along with a new table that contains the ransom notes.

We can see that the attacker is asking for a relatively small amount of Bitcoin.  Demanding a small ransom that might give a ‘quick win’ instead of asking for a large ransom is another trademark of the “Hit and Run” style attack.

While looking at the bitcoin address in the ransom note (using blockchain.com), we can see that there are existing transactions in a relatively similar amount of BTC.

Recommendations for Deterring a PostgreSQL Database Ransomware Attack

• As we’ve seen earlier, attackers are not willing to give the victim’s full data back. Database activity monitoring or native audit can help a database ransomware victim to understand what has been taken and know their true status against the attacker.
• Failed logins can be an indicator of the initial access phase of the attack. Create your own login profiling to alert on these cases or use a risk analytics product.
• Don’t expose your database to the internet. There are known solutions like VPNs to handle safe access to the database. Over 650,000 PostgreSQL databases are internet facing, and 99% of them are using the default port of 5432. If you must open your database to the internet (and even if not), change the database configuration from listening on the default port to a least known port.
• Put your database behind a firewall.
• Create a backup and disaster recovery plan for your database, monitor those processes regularly, and test them at regular intervals.