Automated Extortion Campaign Wipes 1,400 MongoDB Servers, Demands Bitcoin Ransom

An ongoing automated extortion campaign has compromised approximately 1,400 MongoDB servers, with attackers wiping database contents and leaving ransom notes demanding 0.005 BTC (~$500-600 USD) per instance with a 48-hour payment deadline. Research from cybersecurity firm Flare reveals the campaign is the work of a single threat actor exploiting a vast landscape of misconfigured databases — with over 208,000 MongoDB instances publicly exposed on the internet.

The Scale of Exposure

Flare’s research paints a stark picture of MongoDB’s exposure across the internet:

Metric	Count	Context
Publicly exposed instances	208,500	Discoverable via internet scanning
Exposing operational data	100,000	Contain production databases, not just test data
Accessible without authentication	3,100	No credentials required to connect
Already compromised (of unauthed)	45.6%	Nearly half already wiped or ransomed
Running vulnerable older versions	95,000	Susceptible to known security flaws
Active victims in current campaign	~1,400	Databases wiped with ransom notes

The numbers reveal a systemic issue: approximately 100,000 MongoDB instances are exposing real operational data to the public internet, and 3,100 of those can be accessed with no authentication whatsoever.

Single Actor Attribution

Analysis of the ransom notes points decisively to a single operator. Researchers identified only five distinct Bitcoin wallet addresses across all discovered ransom notes, with one address appearing in approximately 98% of cases.

This concentration indicates the campaign is not the work of multiple independent actors or a ransomware-as-a-service operation — it’s a single individual or small group running an automated pipeline at scale.

Attack Methodology

The campaign follows a straightforward automated process:

Step 1: Discovery

The attacker scans the internet for MongoDB instances listening on the default port (27017) that accept connections without authentication.

Step 2: Access

For instances with authentication disabled — MongoDB’s default configuration — the attacker connects directly with no credentials required.

Step 3: Exfiltration (Claimed)

The attacker claims to export the database contents before wiping them. However, given the automated nature and volume of the campaign, there is no evidence that data is actually retained for restoration after payment.

Step 4: Destruction and Ransom

All database collections are deleted and replaced with a single collection containing the ransom note. The note demands 0.005 BTC (approximately $500-600 USD at current exchange rates) sent to a specified Bitcoin address within 48 hours, threatening permanent data destruction if payment is not received.

The Ransom Payment Trap

Flare’s analysis strongly suggests that paying the ransom will not result in data recovery. The automated nature of the operation, the volume of targets, and the low individual ransom amount make it impractical for the attacker to maintain organized archives of stolen data from 1,400+ individual databases.

This matches the pattern seen in previous MongoDB extortion waves dating back to 2017, where victims who paid rarely — if ever — received their data back.

Why This Keeps Happening

MongoDB extortion campaigns have been documented for nearly a decade, yet the number of exposed instances continues to grow. The root causes are well understood:

Default configuration prioritizes convenience. MongoDB has historically shipped with authentication disabled and binding to all network interfaces. While recent versions have improved defaults, legacy deployments and careless configurations persist.

Cloud deployment sprawl. Developers spin up MongoDB instances on cloud platforms for testing or prototyping and either forget to secure them or fail to restrict network access before deploying production data.

Lack of network segmentation. Databases that should only be accessible from application servers are instead exposed directly to the internet, often through misconfigured security groups or firewall rules.

Vulnerable legacy versions. Nearly 95,000 exposed instances run older MongoDB versions with known security vulnerabilities. While most of these vulnerabilities are limited to denial-of-service rather than remote code execution, they represent an additional layer of risk.

Historical Context

This campaign continues a pattern that began in January 2017, when a wave of automated attacks wiped approximately 28,000 MongoDB instances in a single week. Similar campaigns have occurred regularly since:

• 2017: ~28,000 instances wiped, ransom demands of 0.2 BTC
• 2019: Meow attacks destroyed data without any ransom demand
• 2020-2023: Periodic smaller campaigns targeting exposed instances
• 2026: Current campaign — 1,400+ servers, 0.005 BTC demand

The declining ransom amount (from 0.2 BTC to 0.005 BTC) reflects the commoditization of this attack — it’s become a low-effort, high-volume operation rather than a targeted extortion scheme.

Immediate Mitigation Steps

Organizations running MongoDB should audit their deployments immediately:

1. Enable authentication — create administrative users and enable access control. This single step prevents the vast majority of automated attacks.

2. Bind to localhost or specific IPs — configure bindIp to restrict which network interfaces MongoDB listens on. Production databases should never listen on 0.0.0.0.

3. Implement firewall rules — restrict inbound connections to port 27017 (or your configured port) to only application server IP addresses.

4. Upgrade to supported versions — replace any MongoDB instance running an end-of-life version with a current, supported release.

5. Enable TLS/SSL — encrypt connections between application servers and databases to prevent credential interception.

6. Implement automated backups — store backups offline and test restoration procedures regularly. Backups stored on the same network as the database are vulnerable to the same attacks.

7. Audit cloud security groups — review AWS Security Groups, GCP firewall rules, or Azure NSGs for any rules allowing unrestricted inbound access to database ports.

The Fundamental Problem

MongoDB extortion campaigns are not a sophisticated threat. They exploit the simplest possible misconfiguration — databases accessible without authentication on the public internet. The fact that this attack pattern has persisted for nine years with a growing number of exposed targets reflects a systemic failure in deployment practices, not a failure in the database software itself.

Every organization running MongoDB should be able to answer one question with certainty: can our databases be reached from the internet? If the answer is anything other than a confident “no,” the remediation steps above should be implemented immediately.