Download MacKeeper Research Policy

Do you want to be our security writer? Send your guest post to

How long does it take for a MongoDB to be compromised

Improperly configured MongoDB servers still being compromised after five years of reporting

Back to blog


MongoDB, a popular NoSQL database, has been making news for years due to older improperly configured servers.  As far back as March of 2013 a researcher named David Kirkpatrick, with Trustwave, pointed out that MongoDB did not have authentication set by default, which meant anyone could connect to it and read and write data.  He also reported that it's default configuration was causing it to bind to every interface (, which includes the public Internet interface. This combination placed tens of thousands of MongoDB servers at risk.

In July of 2015 John Matherly of Shodan announced that his scans had found nearly 30,000 open MongoDB databases available to the public on the Internet.  Many companies were caught by surprise with this and some high profile data compromises, some of which we reported, were the result.  

In December of 2016 security researcher Victor Gevers, working with the just launched Project 366 with the GDI Foundation noticed something new.  While poking around open MongoDB instances he noticed many had simply one table named “WARNING”.

The content of this table was simply the Object ID, an email address (, and a note that said “SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !”.

Ransomware had hit the open databases, or had it?

It certainly looks like ransomware, but it turns out that this was different. In this attack there was no data to be returned to the victim upon payment because the data had not been taken, it had just been deleted by dropping the databases. It was done by automation, what has been referred to as a “spray and pray” approach where any publicly open database detected is automatically compromised if possible.

Soon after the ransom warnings made news, other malicious individuals joined in the feeding frenzy, even replacing each other's warning messages and e-mail addresses for the bitcoin payment. This is still going on today.

How fast will they be compromised today?

We at Kromtech Security wondered how prevalent these attacks still were and how fast one of these improperly configured databases would be compromised today.  To find this out, we decided to employ a honeypot, or fake database setup.  A honeypot looks real to the attackers and but allows us to monitor it and see what they do as well as quickly reset it once it is compromised.

What we did

  • Deployed Splunk on EC2 instance with 30 GB storage
  • Configured location dashboard with locations of hosts that attempted to connect to the Honeypot
  • Configured Top 25 IP dashboard with Top 25 IP addresses by count of connections
  • Configured indexes for storing and accessing all collected data
  • Deployed MongoDB version 2.6.10 on EC2 instance with 30GB storage.  We chose this version over the current 3.6 version and also left the database configuration without authentication or access controls to imitate the many still public access instances of MongoDB.
  • Deployed MongoDB Monitoring Splunk App for log forwarding of MongoDB logs
  • Configured MongoDB for maximal verbosity of authentication logs and interactions logs
  • Deployed Splunk forwarder and 
  • Splunk Linux Auditd for auditd logs
  • Generated and uploaded a fake dataset into 2 databases on MongoDB: ***_prod, ***_dev.
  • Made snapshots of MongoDB Honeypot in working condition for backup in case of ransom attack.
  • Opened MongoDB for all TCP connections on 27017 port (typical misconfigured MongoDB) 

What happened

We placed the server live on March 1, 2018.  What resulted was as expected (spoiler alert, the database was compromised).  Immediately upon placing it on the Internet we noticed the regular flurry of automated port scans from many different parts of the globe.  However, the first real connection to the database was made on March 2, 2018 and from a security research search engine from the Shadowserver Foundation.

What came next was a slight surprise, there were plenty of port scans, but there were no other direct connections to the database for ten days.

The next direct connection came from the security research search engine Shodan.  Shodan indexed it on March 11th, 2018, 13:52:31.782349 UTC and retrieved data about the database and it's collections.

Three hours and twenty-four minutes following Shodan indexing, the database was first compromised by an IP address we traced to China.

The entire compromise only took 13 seconds to complete.  The Chinese machine repeatedly connected from  5:16:35.924 - 5:16:48.894 PM UTC while carrying out it's attack.

The attacker first connects to our database, then drops the databases to delete them, drops the Journals to erase their tracks, creates a database called Warning with Readme collection and the Solution Record, then drops the Journals again to cover their tracks.  This was all completed in just thirteen seconds, leading to the conclusion that this was the work of an automated script.

After the compromise we were left with just the following warning:

Thankfully, nobody has made payment to this Bitcoin address according to

What did we learn?

  • Improperly configured MongoDB instances are still on the radar of attackers and scripts.
  • MongoDB databases that are not properly secured will be automatically attacked and compromised in a very short time.
  • While we did find entries that could be used in rule sets or signatures to block this particular attack, the best way would still be to properly update and secure your server.  Keeping the software up to date, solid security procedures, regular backups, and event monitoring are the best ways to protect your data.
  • As with previous reports, our databases were not retrieved first, but simply deleted.  It's been said by others and we'll say it again too, do not pay the ransom if this happens to you, it will not get you your data back!
  • It appears that people are not paying the ransom anymore because this attacker's bitcoin address received no payments.
  • The security research search engines beat the attackers to finding and accessing our database.
  • There has been speculation that many attackers, rather than direct scanning, are getting their information from Shodan, which did index our database very shortly before the compromise. This test appears, at face value, to add to that speculation.



You are going to lose your data if you don't properly secure your server.  That stands true with all, but here there really is no excuse for this to still be happening with MongoDB.  Issues with MongoDB have been known since at least March of 2013 and have been widely reported since.  The company has updated it's software with secure defaults and has released security guidelines.  It's been five years now and these unsecured databases are still widely available on the Internet, almost 54,000 of them now, according to Shodan.  We find this unacceptable and hope that our honeypot test sheds even more light on this issue.



Logs for 13 seconds of ransom attack

Parts of logs can be used as a ruleset basis for detecting those attacks attempts.

Action                                                   Details                                                                                                                                                                                         Timestamp


2018-03-11T17:16:48.894+0000 [conn289828] end connection (0 connections now open)


Created ransom message

2018-03-11T17:16:48.386+0000 [conn289828] added index to empty collection


2018-03-11T17:16:48.386+0000 [conn289828] build index on: Warning.Readme properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "Warning.Readme" }


2018-03-11T17:16:48.383+0000 [FileAllocator] done allocating datafile /var/lib/mongodb/Warning.0, size: 64MB, took 0.001 secs


2018-03-11T17:16:48.379+0000 [FileAllocator] creating directory /var/lib/mongodb/_tmp


2018-03-11T17:16:48.379+0000 [FileAllocator] allocating new datafile /var/lib/mongodb/Warning.0, filling with zeroes...


2018-03-11T17:16:48.323+0000 [conn289828] allocating new ns file /var/lib/mongodb/Warning.ns, filling with zeroes...



2018-03-11T17:16:47.303+0000 [initandlisten] connection accepted from #289828 (1 connection now open)



2018-03-11T17:16:46.997+0000 [conn289827] end connection (0 connections now open)



2018-03-11T17:16:46.498+0000 [conn289827] dropDatabase test_database finished



2018-03-11T17:16:46.496+0000 [conn289827] removeJournalFiles



2018-03-11T17:16:46.496+0000 [conn289827] dropDatabase test_database starting



2018-03-11T17:16:45.749+0000 [initandlisten] connection accepted from #289827 (1 connection now open)



2018-03-11T17:16:45.336+0000 [conn289826] end connection (0 connections now open)



2018-03-11T17:16:44.847+0000 [conn289826] command test.$cmd command: dropDatabase { dropDatabase: 1.0 } keyUpdates:0 numYields:0 locks(micros) W:125456 reslen:55 125ms



2018-03-11T17:16:44.847+0000 [conn289826] dropDatabase test finished



2018-03-11T17:16:44.841+0000 [conn289826] removeJournalFiles



2018-03-11T17:16:44.721+0000 [conn289826] dropDatabase test starting



2018-03-11T17:16:43.998+0000 [initandlisten] connection accepted from #289826 (1 connection now open)



2018-03-11T17:16:43.706+0000 [conn289825] end connection (0 connections now open)



2018-03-11T17:16:43.569+0000 [clientcursormon] connections:1



2018-03-11T17:16:43.569+0000 [clientcursormon] mapped (incl journal view):320



2018-03-11T17:16:43.569+0000 [clientcursormon] mem (MB) res:66 virt:564



2018-03-11T17:16:43.209+0000 [conn289825] dropDatabase ***_prod finished



2018-03-11T17:16:43.207+0000 [conn289825] removeJournalFiles



2018-03-11T17:16:43.207+0000 [conn289825] dropDatabase ***_prod starting



2018-03-11T17:16:42.463+0000 [initandlisten] connection accepted from #289825 (1 connection now open)



2018-03-11T17:16:42.165+0000 [conn289824] end connection (0 connections now open)



2018-03-11T17:16:41.653+0000 [conn289824] dropDatabase *** finished



2018-03-11T17:16:41.650+0000 [conn289824] removeJournalFiles



2018-03-11T17:16:41.650+0000 [conn289824] dropDatabase *** starting



2018-03-11T17:16:40.886+0000 [initandlisten] connection accepted from #289824 (1 connection now open)



2018-03-11T17:16:40.474+0000 [conn289823] end connection (0 connections now open)



2018-03-11T17:16:39.982+0000 [conn289823] command ***_prod.$cmd command: dropDatabase { dropDatabase: 1.0 } keyUpdates:0 numYields:0 locks(micros) W:131165 reslen:63 131ms



2018-03-11T17:16:39.982+0000 [conn289823] dropDatabase ***_prod finished


Removing Journal files for hiding attackers activity

2018-03-11T17:16:39.948+0000 [conn289823] removeJournalFiles



2018-03-11T17:16:39.851+0000 [conn289823] dropDatabase ***_prod starting



2018-03-11T17:16:39.117+0000 [initandlisten] connection accepted from #289823 (1 connection now open)


First database drop

2018-03-11T17:16:38.816+0000 [conn289822] end connection (0 connections now open)


2018-03-11T17:16:38.330+0000 [conn289822] command ***_dev.$cmd command: dropDatabase { dropDatabase: 1.0 } keyUpdates:0 numYields:0 locks(micros) W:151969 reslen:62 152ms


2018-03-11T17:16:38.328+0000 [conn289822] dropDatabase ***_dev finished


2018-03-11T17:16:38.280+0000 [conn289822] removeJournalFiles


2018-03-11T17:16:38.179+0000 [conn289822] dropDatabase ***_dev starting


2018-03-11T17:16:37.449+0000 [initandlisten] connection accepted from #289822 (1 connection now open)



2018-03-11T17:16:37.154+0000 [conn289821] end connection (0 connections now open)


Initial connection

2018-03-11T17:16:35.924+0000 [initandlisten] connection accepted from #289821 (1 connection now open)


Connections map, as of March 21st, 2018

Attention - Portions of this article may be used for publication if properly referenced and credit is given to Kromtech Security Center.
Do you have security tips or suggestions? Contact:


You may also like