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:
Recently, we’ve found this kind of ransomware attack targeting our PostgreSQL database, and we’ve observed some interesting facts.
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.
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.
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.
The post Analysis: A Ransomware Attack on a PostgreSQL Database appeared first on Blog.