It’s 10PM; Do You Know Where Your MongoDB Is?

I’m hijacking today’s Torvalds Tuesday post (sorry Linus) to instead talk about a fairly serious issue that is getting some attention over the past couple of days. Victor, who works at the GDI Foundation, has been tweeting about research into exposed, unsecured MongoDB instances. He’s been sending breach notifications and doing his best to keep up with the scale of compromised instances. He’s been doing this for years. Unfortunately, he’s not doing this out of the kindness of his heart.

No, attackers have now started holding unsecured MongoDB instances ransom.

Here’s a sample tweet:

The attacker, who goes by the email address harak1r1@sigaint[.]org is demanding a payment of 0.2 BTC to get the data back.

EDIT: After looking at some screenshots around the web, I can see evidence of the attacker dating back to 12/20 and as recent as 12/31. While premature, I’ll work to expand these timeframes.

Victor has continued digging into some of the databases out there, and what he’s finding is truly staggering. For example:

Yes, you’re seeing that figure correctly, 853.76 BILLION records (that’s a massive MongoDB, btw). Steve Ragan (SteveD3) also published a great article today at over CSO:

Steve outlines some recent breaches that have resulted from unsecured MongoDB instances, as well as potential security considerations. As of 4:00PM today (I’m assuming this is PST), there were upwards of 2,000 instances of hacked DBs, as reported by John Matherly, the Founder of Shodan.

Lastly, Bleeping Computer also published an article about this today:

Long story short: It’s now bigger news. And now, there’s money involved.

Unfortunately, these types of breaches were a long time coming. Information security researchers have been discussing these problems for years. Years.

  • My friend Ming Chow presented at DEF CON 21 about Abusing NoSQL Databases.
  • Another friend, Russell Butturini, presented at DerbyCon 2014 and at BSides Nashville 2014 about his tool NoSQLMap. As part of his NoSQLMap research, Russell utilized and identified 33,575 instances of MongoDB with management ports open; 18,979 of them did not require authentication.
  • John Matherly wrote about unsecured MongoDB instances in 2015, and found 595.2 TB of exposed data.
  • I’ve also presented and blogged extensively about the dangers of default Mongo logging, which records little to no activity.

There are, without a doubt, dozens of articles I missed. Apologies, it was not intentional. But instead of sitting here and talking about how many times we’ve known this was coming, I want to look at the technicalities of what’s going on here.

Holding MongoDB Hostage

Let’s take a look at just how easy it is for this attack to occur.

Based on what I can tell from the ransom notes, the attacker most likely creates a local copy of the data within MongoDB, deletes the original data, and then creates a database and a collection within, both named WARNING. (This is all assuming that those who pay actually get their data back)

Inside this collection is the ransom note. Thus far, the attacker has raked in about $2,700. This may seem a paltry sum to some, but trust me, it was most likely done doing minimal work.

Cloning a MongoDB

Downloading or cloning a MongoDB instance is not difficult. In fact, there are functions built-in to make this easy. Here’s the tools that a default MongoDB install includes:

Screenshot of mongo tools in an Ubuntu default install

Mongoexport or mongodump are likely tools being abused in these ransom cases, as they allow for really quick and easy database exporting. Let’s look at each.


Mongoexport is built to export data from a MongoDB in CSV or JSON format. Here’s the top of the help menu:

Screenshot of mongoexport help menu

With only a few switches, you can very easily connect to a remote MongoDB instance and download it’s data. Example:

I downloaded a sample JSON file containing 29,353 documents. Importing took 0.586 seconds:

Screenshot of importing the file zips.json into a test MongoDB

Now, let’s get the data out:

mongoexport -d test -c zips -o /tmp/stolen_zips.json

It took less than a second:

Screenshot of exporting zips collection from the test db to an output file


Mongodump makes life even easier; it simply dumps out the entire database to BSON files. The goal is to make a database easy to dump, transport, and load into another instance, if need be. Unfortunately, it also makes it really easy to steal data.

Screenshot of mongodump help menu

Running the command dumped my entire test DB in about 0.200 seconds:

Screenshot of dumping a test MongoDB to local files

Before these gets slammed, yes, this example went quickly because it was all done on my local host. The goal was not to set a record for dumping MongoDB data. The goal was to show how simple this is, using built-in tools that can be easily abused without credentials.

But if you want to make an argument that transferring from AWS or Digital Ocean to another cloud-based host will take hours, days, or weeks, then I’m sorry, it doesn’t. There was no need to develop elite 0-day exploits or find some fatal flaw in MongoDB itself. The box itself need not be compromised, as MongoDB was open to the world.

Why Is This Successful?

Many times, I hear a lot of folks say “No one wants to steal my data, it’s not important.” I’ve also heard the phrase “Our data is not sensitive, you can get it out of a phone book.” This thinking is a critical misunderstanding in the goal of ransomware. You’re right, some attack groups are not interested in the content of your data. Ransomware authors, however, are interested in the availability of your data. And if a business function relies on your MongoDB instance, and it’s no longer available, then you’re stuck.

Why is This Dangerous?

This is a very easy attack, and right now, a very inexpensive one to recover from. Just wait until a mission-critical DB is found and held hostage.

How To Protect Against This?

There are MongoDB security recommendations abound, including on MongoDB’s website itself. I’d refer you back to the articles above, that provide additional security recommendations. But in short, here’s a few steps you can take:

  • Disable remote access to the MongoDB, if possible. If you absolutely must enable remote access, allow only the IPs you know of.
  • Lock down user accounts and/or enable access controls. Default MongoDB instances don’t ship with much in the way of user accounts and they are not locked down. See below.
Screenshot from MongoDB’s security recommendations site
  • Speaking of users, enable authentication.
  • UPGRADE. There are multiple MongoDB CVEs:
Screenshot of, showing search results for MongoDB

How to Recover From This?

The figure that nearly 2,000 instances have found to be hacked but only $2,700 has been paid thus far is hopefully a good sign. Often times, MongoDBs exist in clusters that are fault tolerant and have backups. If one node goes down, the others may be able to pick up the slack. I just hope this attacker isn’t deleting entire clusters. Here’s a few other options:

  • Admittedly, default MongoDB logging sucks. Ratchet this up if you are using MongoDB in production AND/OR have sensitive data in there.
  • Check your logs; even with limited logging, you may be able to discover what happened to the MongoDB instance, that can help determine if you recover or not.
  • Ask your MongoDB DBAs to check out their instances. If they’re worth their salt, they should know the databases in and out and have an inkling of when something wrong is happening.
  • UPGRADE. See above.
  • If you’ve lost extremely sensitive data, please notify the proper parties. Ransom or note, there is indication that the attacker is downloading the data and holding it hostage. Whether they looked at it or not, this is a data breach.

If you’ve run into any issues with your instance, please don’t hesitate to reach out. And please, please, secure your DBs going forward.

Until tomorrow, Happy Forensicating!