Intruder's latest research shows that Mongo databases are subject to continual attacks when exposed to the internet. Attacks are carried out automatically and on average an unsecured database is compromised less than 24 hours after going online, with the fastest we measured in just 9 minutes.

A little bit of history repeating...

In 2003 the SANS Institute famously proclaimed that putting an unpatched Windows XP machine on the internet would get it breached within 40 minutes. Fast forward nearly two decades and the technologies may have moved on a bit, but so has the average time to breach.

Thankfully, not many organisations are connecting unpatched Windows XP machines to the internet these days, but it's difficult to escape the number of news stories in the last few years describing how hundreds of millions of records of data have been leaked from organisations that left databases in a similarly insecure state. In large part this is because modern databases such as MongoDB and Elasticsearch forgo security controls requiring authentication, and are unsecured by default.

Unsecured databases (ones with no passwords set) are bountiful targets for malicious actors when they're exposed to the internet. Not only are they very easy to find, by sweeping the net and looking for the usual database ports, they are also very easy to exploit. All it takes is connecting to a database, looting it, and selling the information on some dark corner of the internet; using the contents for further credential stuffing attacks, or blackmailing the owner.

We can see from the headlines how often this happens, but we wanted to know how fast it happens. So Intruder's R&D team set about creating some honeypots to find out how these attacks happen, where the threats come from, and how fast it all takes place.

Honeypots you say?

Honeypots are systems designed to detect and monitor network intrusions by posing as vulnerable machines and recording their own compromise by malicious actors. The logs generated from honeypots then provide intelligence on the tactics and techniques deployed by those attempting to gain unauthorised access.

We set up a number of unsecured MongoDB honeypots across the web. Each was filled with fake data, some of which was designed to be alluring to hackers – a table containing password hashes. The honeypots’ network traffic was monitored for malicious activity and if password hashes were exfiltrated and seen crossing the wire, this would indicate that a database was breached.

What did we find?

Our findings show that on average, a Mongo database is scanned every three hours, and breached within 13 hours of being connected to the internet. The fastest breach we recorded was carried out a mere 9 minutes after the database was set up.

After scanning a honeypot, most attackers had breached it in under two seconds, and most database connections were made using PyMongo (a Python driver for MongoDB). This indicates that breaches are carried out automatically, and likely indiscriminately – being a ‘worthwhile’ target has nothing to do with it.

At least one of the honeypots was held to ransom within a minute of connecting. The attacker erased the database’s tables and replaced them with a ransom note, requesting payment in Bitcoin for recovery of the data:

It's worth reiterating that beyond just putting these systems on the internet, we did nothing to bring attention to them. So for anyone thinking "we're too small/unknown to be targeted" or "I'll start worrying about security when we're bigger", hopefully this will serve as a reminder that you're never too small to start doing something.

Where did it come from?

Our fastest breach in less than ten minutes came from an attacker from Russian ISP ‘Skynet’, while over a dozen IP addresses were seen interacting with more than one of our globally dispersed honeypots. These IPs were all given a ‘medium’ or (mostly) ‘high’ risk rating by Auth0’s reputational blacklist service.

Some of the honeypots were scanned by the Shadowserver Foundation, an all-volunteer non-profit organisation that carries out investigations into malicious internet activity. Here in particular it seems they were conducting research into publicly accessible devices that are “trivial to exploit or abuse”.

A few of the breaches were carried out via the Tor network, a service which provides anonymity to its users, including the likes of activists, journalists and whistleblowers. For hackers, anonymity enables them to carry out malicious campaigns incognito, without fearing attribution by law enforcement.

Over half of the breaches originated from IP addresses owned by a Romanian VPS provider. Without mentioning names, or pointing fingers, the provider appears to offer bulletproof hosting services –

• Port scanning “allowed”
• Machines advertised with the capacity to send tens of thousands of packets per second
• Payments can be made through anonymous cryptocurrency
• Services rendered are “unmanaged”

It's quite possible that some of the activity we recorded was from security researchers looking for their next headline or data for their breach database. However when it comes to protecting your company, data security must be a top priority, but so should your reputation. Whether your data is breached by a malicious attacker or a well meaning researcher, you may end up in the headlines either way.

What lessons should we learn?

Even if security or DevOps teams can detect an unsecured database, among all the noise of security alerting – and recognise its potential severity – responding to and containing such a misconfiguration even in less than 13 hours may be a tall order, let alone in under 9 minutes, so prevention is a much stronger defence than cure.

What can you do to prevent this? For Mongo, access control needs to be setup manually. However, secured or not, databases shouldn’t really be directly exposed to the internet as they don't benefit from the same multi-factor authentication as other web services, exposing them to credential stuffing and brute force attacks. Instead they should be firewalled off, or secured through a VPN.

Ideally you should have some way of making this impossible via policy, rather than simply trying to detect it when it happens. Most modern cloud platforms can help in this task, and so organisations who have fully made the jump may benefit here. Detecting it when it happens is the next best thing, and a solid backup for if (or when) the policy control fails, or for cloud environments where policy enforcement is not an option.

Intruder can help with the latter. We identify and prioritise any exposed databases on your external infrastructure. For Mongo in particular, we’ll also make sure to let you know if any unsecured instances are detected.

Alongside daily checks for the latest emerging threats, we proactively monitor for more elementary problems, such as when insecure ports and services are opened up to the internet. Our reduced-noise reporting identifies and ranks areas of the perimeter to target for optimal attack surface reduction.

Improve visibility and gain oversight of your external infrastructure today by starting a free trial.

‍