How the frenzy unfolded: Analyzing various Mongo extortion campaigns

7 February 2017

The MongoDB “ransom” pandemic, which has been in the spotlight for the best part of a month, still appears to be affecting MongoDB installations and various campaigns still appear to be receiving payments. The latest payment for one of the campaigns has been as recent as the January 20, 2017.

Recent Bitcoin Mongo Figure 1 – Recent bitcoin transactions for the files named PLEASE_README

This post will provide additional insight into our previous research in an attempt to identify a timeline of when the first campaigns started and the subsequent copycat campaigns. While we are aware that there were already attacks on open Mongo databases focusing on deleting data, this new approach appeared to be the first widespread, multi-campaign attack based on extortion. We define these attacks as extortion rather than ransom since most campaigns did not appear to even attempt to view or backup the data before deleting.

As per our previous research into open MongoDB services, we set out to identify publicly available open Mongo Status Interfaces. The MongoDB HTTP Status interface is designed for listing information that may be of interest to the database administrators, including database version information, system information and recent client requests. These status pages listen on TCP port 28017 rather than port 27017 commonly used for MongoDB itself. The Status Interface service has been deprecated since version 3.2.

By scraping the logs of publicly accessible MongoDB Status pages, we reviewed the logs for almost 7,000 MongoDBs. These logs provide information regarding connections to the MongoDB, including the deletion and creation of databases and the times which they occurred. We gathered and collated a list of the times that DB allocations and drops occurred for these 7,000 deployments. Using these results we are able to get a rough estimate of the timelines and volumes of these various MongoDB extortion campaigns. The campaigns shown in Figure 2 can be identified by the naming conventions.

 Rate of Dbs created

Figure 2 – Rate of databases created over time, per campaign.

The dataset also provided us with a good indicator of the largest campaigns and the battle raging between them. The output below showing one campaign dropping the “WARNING” database, and creating “PLEASE_READ”.

01:20:57.810 [conn670] dropDatabase WARNING starting

01:20:57.810 [conn670] removeJournalFiles

01:20:57.816 [conn670] dropDatabase WARNING finished

01:20:57.940 [FileAllocator] allocating new datafile /var/lib/mongodb/PLEASE_READ.ns, filling with zeroes...

01:20:57.944 [FileAllocator] done allocating datafile /var/lib/mongodb/PLEASE_READ.ns, size: 16MB,  took 0.003 secs

01:20:57.944 [FileAllocator] allocating new datafile /var/lib/mongodb/PLEASE_READ.0, filling with zeroes...

01:20:57.946 [FileAllocator] done allocating datafile /var/lib/mongodb/PLEASE_READ.0, size: 64MB,  took 0.001 secs

01:20:57.946 [FileAllocator] allocating new datafile /var/lib/mongodb/PLEASE_READ.1, filling with zeroes...

01:20:57.953 [FileAllocator] done allocating datafile /var/lib/mongodb/PLEASE_READ.1, size: 128MB,  took 0.006 secs

01:20:57.954 [conn670] build index PLEASE_READ.PLEASE_READ { _id: 1 }

Figure 3 - An example of competing efforts by ransomware actors, with files being reallocated over a short period of time

 

The total number of malicious databases created is shown below. The tally can include multiple database creations on a single server, as this can occur when various campaigns have overwriting each other repeatedly. It is also worth noting that some of the status pages reviewed provided data for non-public localhost only databases, so they wouldn’t be affected by the attacks.

7558

README_MISSING_DATABASES

7010

PLEASE_READ

4223

WARNING

543

PWNED

537

PWNED_SECURE_YOUR_STUFF_SILLY

187

ENCRYPTED

156

PLEASE_READ_ME

48

README_YOU_DB_IS_INSECURE

9

WARNING_ALERT

 Figure 4 – Malicious DB names

MongoDB status pages also provided a lot more information that could be used by attackers. This was with the aim of gaining authorized access to databases that have been secure, however it left the status and logging service open.

Mongo publicly visible logs 

Figure 5 - Publicly Visible Logs - User authentication

The MongoDB documentation states that the HTTP status interface should be disabled in production environments in order to prevent this kind of data exposure.

Final thoughts

The various campaigns appear to still be rampaging through the public domain, overwriting each other and newly created databases. This will likely continue while people are still feeding the frenzy with Bitcoin payments and attempting to restore backups while still neglecting to password protect their MongoDB instances or firewall them off from the outside world.