Hackers Attack MongoDB: Delete Databases, Demand Ransom Note

Threat actors are actively launching widespread, automated ransomware campaigns targeting internet-exposed MongoDB instances.

The attacks follow a consistent pattern: attackers scan for unsecured MongoDB databases accessible on the public internet, delete the stored data, and insert ransom notes demanding payment in Bitcoin.

Recent evidence indicates these campaigns remain highly profitable despite modest ransom demands typically ranging from $500 to $600 USD per victim.

The exploitation pattern is technically straightforward but operationally effective. Threat actors use automated scanning tools to identify MongoDB services exposed on port 27017 without authentication.

Once access is established, attackers export or enumerate the database contents to assess value before executing data destruction operations.

MongoDB Instances Hacked

Collections and databases are systematically dropped or wiped entirely, after which a ransom demand message is inserted into the MongoDB instance.

Victims receive threats that their data will be permanently deleted unless they send a Bitcoin payment to attacker-controlled wallet addresses within a specified timeframe, typically 48 hours.

Analysis of real-world compromises reveals that approximately 45.6% of fully exposed MongoDB instances already bear ransom notes, indicating victims have either paid ransoms or had their data destroyed without recovery.

Notably, over 98% of observed ransom payments were directed to a single Bitcoin wallet, suggesting coordinated activity by a dominant threat actor operating this profitable campaign.

Internet-wide scanning has identified more than 200,000 MongoDB servers publicly accessible online, with approximately 3,100 instances confirmed as fully exposed and lacking access controls.

This represents a critical risk surface, as any internet-connected MongoDB lacking authentication becomes immediately vulnerable to automated exploitation.

The underlying cause of this vulnerability landscape stems from deployment misconfigurations rather than software vulnerabilities.

Docker images and copy-paste infrastructure configurations often bind MongoDB to all network interfaces (0.0.0.0) by default, without enforcing authentication.

Developers frequently deploy these templates in production environments with port 27017 exposed externally, inadvertently creating direct internet access to unprotected databases.

An analysis of Docker Hub container repositories identified 763 images with insecure MongoDB configurations across 30 distinct namespaces.

Two widely distributed projects with over 15,000 pulls each contained identical unauthenticated database bindings, demonstrating how insecure defaults propagate through popular infrastructure templates.

Mitigation Imperative

According to Flare, organizations must immediately audit their MongoDB deployments to identify any public exposure.

Critical preventive measures include restricting MongoDB to private networks only and enforcing SCRAM authentication with role-based access control.

Implementing firewall rules to block public ingress on port 27017 and replacing default Docker images with hardened configurations.

Continuous exposure monitoring with tools like Shodan Monitor and cloud security posture management platforms enables rapid detection of misconfigurations before they are exploited.

While MongoDB lacks known pre-authentication remote code execution vulnerabilities, a single zero-day could instantly expose hundreds of thousands of servers to large-scale automated attacks.

Organizations must prioritize network segmentation and immediate authentication enforcement to eliminate this persistent threat vector.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.