All of your data is a backed up. You must pay 0.015 BTC to [REDACTED] 48 hours for recover it. After 48 hours expiration we will leaked and exposed all your data. In case of refusal to pay, we will contact the General Data Protection Regulation, GDPR and notify them that you store user data in an open form and is not safe. Under the rules of the law, you face a heavy fine or arrest and your base dump will be dropped from our server.If you're unlucky enough to find your MongoDB database wiped by the hacker and replaced by a ransom note, there are an important couple of points to consider: Firstly, will paying the ransom get your data back? Almost certainly not. The hacker may well have accessed 22,900 databases that were not properly secured online, but that's a very different proposition from actually having successfully exfiltrated what must be a huge amount of data from so many servers. There's no reason to believe that even if the data was copied by the hacker before it was wiped that they will feel duty bound to return your data to you safely. Secondly, will you be reported for a GDPR violation? Personally I find it hard to imagine that a criminal hacker would make a GDPR complaint against his victims. That's not to say, of course, that someone else won't. And that's a reason, if further reason was ever needed, that everyone running a MongoDB database needs to ensure that they have set it up securely, and not left it open for any Tom, Dick or Hacker to waltz in and cause havoc. Despite MongoDB coming with security features, and providing a checklist for administrators to properly keep their databases out of the reach of unauthorised parties, breaches continue to happen. The tools are there, the information about how to use the tools is available, all that we need is for system administrators to wake up and realise that they need to fix their database security as a matter of priority.... or run the gauntlet of being the next victim of a damaging hack.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.