Ransomware Attacks on MySQL and MongoDB

Ransomware is arguably one of the most vicious types of attack cyber security experts are dealing with today. The impact ransomware attacks can have on an organization is huge and costly. A ransomware payment alone does not reflect the total expense of an attack—the  more significant costs come from downtime, data recovery and partial or total business paralysis. Following the recent NotPetya ransomware attacks, Maersk estimated their losses at $200-$300 million, while FedEx estimated theirs at $300 million. Needless to say, ransomware-related losses seem to be growing in size.
It is well known that typical ransomware encrypts files—but what about ransomware targeted at databases? We’ve previously written about it, but database ransomware continues to be less talked about even though it introduces a potentially larger risk since an organization’s data and core applications rely on the data in its databases.
In this post we’ll explain how database ransomware attacks work and provide analysis of two database ransomware attacks recently monitored by our systems: one on MySQL and another on NoSQL (MongoDB).

(If ransomware and other database attacks worry you, please check out our related webinar held with the International Information System Security Certification Consortium (ISC(2)), “Best Practices for Mitigating Data Breach Risks.”)

Methods Used to Attack Databases with Ransomware

There are three primary methods used to attack databases with the goal of corrupting or tampering with data:
1) SQL/NoSQL – inside attack
Considering access to the database is already given (whether through brute force, a DBA account that was compromised or even a malicious insider who already has access), an attacker can drop/insert/update data and hence modify the data. This can be done with a few simple SQL transactions/NoSQL commands.
2) SQL/NoSQL – external attack
A web app vulnerability, like SQL Injection or NoSQL injection, allows attackers to execute any SQL statement they wish to make. Although we’ve already seen ransomware attacking web apps, we haven’t seen such a method targeting databases in the wild yet, but it’s likely to happen.
Another method for external attackers is to target databases with public IP. This can be easily done with online services like Shodan.
3) Encrypting the database file
The database file is where the database schema and data are stored. This type of attack is exactly the same as traditional ransomware attacks that target files. The only caveat (from the ransomware point of view) is that it must terminate the database process before encrypting, as it holds the database file, making it unmodifiable to other processes while in use.

Analysis of Database Ransomware Attacks in the Wild

Let’s take a look at two SQL/NoSQL transaction-based attacks that were recently monitored by our systems.

MySQL

The attacker successfully gained access to the databases through brute force user/password combinations. Afterwards, the next step was “show databases”. Then, each of the enumerated databases was deleted with the “drop database” statement.
It is important to note that database monitoring and enforcement systems cannot rely on cumulative suspicious activities per connection (stream). With this attack, after every SQL statement, the attacker’s client logged out before taking the next SQL statement. So deleting a 10-table database would have ended up with 11 sequenced connections (extra one for listing the tables). Also the “Follow TCP Stream” feature in Wireshark will show one malicious activity at a time and not the entire attack sequence.
Figures 1-3 show how the attacker listed the databases and dropped one of them.

Figure 1: The attack lists the databases

Figure 2: The attacker ends the connection before proceeding to the next phase

Figure 3: The attacker deletes a database
After disposing of the data in this database, the attacker created a table named “Readme” and left the ransom note there (Figures 4 and 5).

Figure 4: Creating a “Readme” table

Figure 5: Inserting the ransomware note that explains to the victim what happened and how to pay
And this is how it looks in Imperva SecureSphere database activity monitoring (Figure 6):

Figure 6: SecureSphere audit screen shows the entire attack stack
The ransom note details (as described in Figure 5):

– eMail: cru3lty@safe-mail.net
– BitCoin: 1By1QF7dy9x1EDBdaqvMVzw47Z4JZhocVh
– Reference: https://localbitcoins.com
– Description: Your DataBase is downloaded and backed up on our secured servers. To recover your lost data: Send 0.2 BTC to our BitCoin Address and Contact us by eMail with your MySQL server IP Address and a Proof of Payment. Any eMail without your MySQL server IP Address and a Proof of Payment together will be ignored. You are welcome.

Note: with this attack the attacker didn’t even bother to read the data before deleting it.
It appears this group is changing its bitcoin address every few weeks. The above bitcoin address was used in an attack that took place three weeks ago, while our systems observed a new bitcoin payment address just a few days ago: 1G5tfypKqHGDs8WsYe1HR5JxiwffRzUUas (see Figure 7).

Figure 7: New bitcoin address for MySQL ransomware monitored by Imperva SecureSphere

MongoDB

MongoDB is a NoSQL database, but the attack’s logic is very much the same. Login was easier for the attacker this time as no authentication was required. Access control is not enabled by default on MongoDB, so the entrance ticket was just knowing the IP and the (well known) port. According to Shodan, there are ~20,000 MongoDBs with public IP with no authentication. This is ~40% of all public-facing MongoDBs.
Figures 8 and 9 show where the attacker listed the databases and deleted one of them.

Figure 8: The attacker lists the databases

Figure 9: The attacker deletes one of the databases
In order to let the victim know about the attack (and how to pay), the attacker created a “Warning” database with a “Readme” inside. This is the JSON generated with MongoDB’s native audit…

Figure 10: Creating the Readme document to store the ransom note
And here’s the message itself…

Figure 11: Writing the ransom note and bitcoin account
The ransom note details (as described in Figure 11):

– eMail: cru3lty@safe-mail.net
– BitCoin: 1Ptza47PgMtFMA6fZpLNzacb1EPkWDAv6n
– Solution: Your DataBase is downloaded and backed up on our secured servers. To recover your lost data: Send 0.2 BTC to our BitCoin Address and Contact us by eMail with your MongoDB server IP Address and a Proof of Payment. Any eMail without your MongoDB server IP Address and a Proof of Payment together will be ignored. You are welcome!

Although this is a different bitcoin (BTC) address than the MySQL attack, note the attacker’s contact info – it’s the same group as the MySQL attack and also the top group mentioned in this article on 26K victims of MongoDB attacks. Our systems also indicated both attacks originated from the same IP (China).

To Pay or Not to Pay?

At the time of writing, there were two payments to the MySQL account (none for the latest attack) and three payments to the MongoDB account. A total of 1 BTC, which is $4,800.
Imperva doesn’t suggest customers pay the ransom (although that is a dilemma when no backup is in place), and with these specific attacks we’d highly recommend not paying it, even without a backup. This is due to the fact that for these two recorded and audited attacks, the attacker did not even read the data before disposing it. The attacker listed the databases and immediately dropped the tables without even backing it up, so restoring the data is impossible (for the attacker).

Takeaways

Enforcing behavioral-based policies are effective at detecting these kind of attacks – you can identify brute force attacks, login attempts with known database user dictionaries, abnormal behavior of an application user or SQL audit profiler, etc. But here are a few items you can implement right away for quick security wins:

• Make sure your database cannot be accessed from the internet. Usually there is no real need to expose a database; only the web app server and a jump server for the DBAs should have access to the database’s isolated network (VPN/VPC).
• Make sure firewall rules are in place, whitelisting approved IPs only
• Have audit enabled (using a database activity monitoring solution or even native audit)
• Alert on failed logins (for brute force attempts), preferably with some minimal threshold
• Take regular backups