208500 MongolDB exposed the easy extortion that converts databases to Bitcoin

In the current landscape of cybersecurity there are attacks that prefer subtlety and others that go to the rough: those that take advantage of open configurations and make it fast money for criminals. In this case, the points are instances of MongolDB exposed to the Internet without the minimum protections, and the recurring tactic is simple and cost-effective: an automatic deletion followed by a rescue note with a modest request in Bitcoin.

A study of the Flare security firm detected an alarming number of public servants from MongolDB: more than 208,500 instances visible from the Internet, of which about 100,000 filtered operational information and about 3,100 were available without any authentication. When the investigators inspected this group without access control, they found that about 45.6 per cent had already been intervened. In many cases the database had been emptied and left an instruction to pay 0.005 BTC - which today round the $500-600- if the owner wanted the attackers to "restore" the information. The Flare report can be read in detail in its technical publication: Flare: MongolDB ransom activity.

This type of extortion is not new; there were previous waves in previous years where thousands of databases were deleted or encrypted. Those mass campaigns showed that the heart of the problem is not a complex zero- day vulnerability, but basic errors of exposure and absence of authentication. A history of incidents related to open databases was covered by security media, for example in Brian Krebs' piece on MongolDB databases left unprotected: KrebsOnSecurity.

Beyond the immediate impact, there are signs that help shape the attacker. Flare identified only five addresses of wallets in the rescue notes and one of them appeared in the vast majority of cases, suggesting an automated and repetitive operation by the same actor. The researchers also raise the possibility that many exposed instances that did not show signs of erasing could have previously paid to avoid or reverse the damage, although that is not something that can be confirmed in general.

It is important to stress that paying guarantees nothing: extortors promise to restore data but there is no certification that they have useful copies or that they will comply. This is explicitly noted by Flare's own analysis: payments do not ensure recovery.

Why are these attacks still working? Because they are the definition of "fruit within reach": intrusions are based on unrestricted access, default passwords, or copied configurations of deployment guides without adapting security. In addition to this, a considerable population of servers running old versions of MongolDB is found: Flare found almost 95,000 exposed instances with versions susceptible to n-day failures. In many cases the severity of these failures is limited to denial of service, but the combination of outdated software and poor configuration multiplies the global risk.

If you administer MongolDB or have responsibilities for database infrastructure, it is appropriate to take practical and realistic measures: avoid exposing instances to the public unless strictly necessary, enable robust authentication mechanisms, apply firewall rules and network policies (including in Kubernetes) that limit connections to reliable origins, and do not reuse example configurations without reviewing them. MongolDB maintains a good safety practice guide that is useful as a starting point: MongolDB Security Checklist.

In case of an exposure or commitment, the recommended actions are clear: isolate the instance, rotate credentials, review records to detect unauthorized activity and restore from clean backup. In addition, incorporating continuous monitoring and regular scanning of the attack surface reduces the likelihood that a server will remain open without anyone noticing it. Public tools like Shodan allow to check whether a service is visible from the Internet, although its use must be part of a defensive strategy and with the corresponding authorizations.

There are no magic formulas against extortion, but there are practices with a strong return on security investment. Prevention - updating the software, segmenting networks, using strong authentication and keeping verified backup - is what separates those who suffer a deletion and a rescue note from those who simply detect an attempt and close it before it goes to older people. And in the face of doubt, documenting incidents and communicating them to response teams and, if applicable, to the relevant authorities, helps to identify trends and mitigate automated campaigns like this.

If you want to deepen the situation and review figures and technical recommendations, in addition to the report mentioned by Flare, you can consult resources and specialized security news to understand the evolution of these campaigns and keep your assets protected: Flare the official documentation of MongolDB and public service search platforms such as Shodan.