Threat reportData BreachTL-2026-0039
MongoDB Database Extortion Campaign - 1,400+ Instances Ransacked
MongoDB Database Extortion Campaign (TL-2026-0039), also tracked as MongoDB Ransom, is a high-severity data breach scored CVSS 8.6, first published 2026-02-03. It carries a reported Russia nexus and is not formally attributed, affects MongoDB MongoDB Server, maps to 20 MITRE ATT&CK techniques (T1046, T1048, T1059), and is covered by 12 detection rules and 42 indicators of compromise.
- CVSS
- 8.6/10High
- CVEs
- 0None referenced
- Techniques
- 20MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 12SPL · KQL · Sigma
- IOCs
- 42Indicators of compromise
Key facts for TL-2026-0039
- Threat ID
- TL-2026-0039
- Also known as
- MongoDB Ransom, NoSQL Extortion, Database Wiper Campaign
- Severity
- HIGH
- CVSS
- 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
- Status
- ACTIVE
- Category
- DATA_BREACH
- First published
- Last reviewed
- Attribution confidence
- NONE
- Nation-state nexus
- Russia
- Motivation
- FINANCIAL
- Target sectors
- Technology, Startups, Healthcare, Education, E-commerce, Government, Small Business
- Target regions
- Global, China, United States, Germany, India, France, Brazil
- Detection rules
- 12
- Indicators of compromise
- 42
Malware and tooling in MongoDB Database Extortion Campaign
Malware and tooling: mongodump
How MongoDB Database Extortion Campaign works
MongoDB database extortion at industrial scale: automated scanning and ransacking of 1,400+ exposed instances — the defensive response playbook for incident forensics, data recovery, and architectural hardening against the no-authentication-by-default attack surface.
This threat focuses on the DEFENSIVE RESPONSE to MongoDB extortion campaigns — incident forensics, data recovery operations, and architectural hardening — distinct from TL-0023 (parent: attack mechanics, campaign scale, 1,400+ databases ransacked). MongoDB's default configuration ships without authentication enabled, binding to 0.0.0.0 on port 27017. This creates a trivially exploitable attack surface: any internet-connected MongoDB instance is immediately discoverable via Shodan (109,000+ currently exposed) and accessible without credentials. Extortion actors run automated pipelines: (1) Shodan/Masscan scan for port 27017 → (2) connect without authentication → (3) mongodump to exfiltrate all databases → (4) db.dropDatabase() to destroy original data → (5) insert ransom note collection ('README', 'RECOVER_YOUR_DATA', 'WARNING') demanding 0.1-0.5 BTC → (6) move to next target. The entire attack takes <60 seconds per instance. Forensic analysis reveals three critical patterns: (A) MOST RANSOM ACTORS NEVER EXFILTRATE DATA — they claim to have it but often only drop databases, meaning payment achieves nothing; (B) Multiple extortion groups target the same instances (double/triple ransoming), with later groups overwriting earlier ransom notes; (C) Oplog analysis can recover recently dropped data IF the oplog has not been overwritten. Recovery operations depend on: oplog retention (hours to days), binary journal files on disk, filesystem-level snapshots (cloud provider), and backup existence (most victims have no backups — that's why they're exposed without auth in the first place). The defensive hardening playbook includes: enable authentication (--auth flag), bind to localhost/private IP only (--bind_ip), enable TLS, configure network-level firewall rules blocking 27017 from internet, enable auditing and oplog for forensic capability, implement automated backup with verification. The MongoDB exposure problem is architectural: security-off-by-default means every deployment starts vulnerable. MongoDB Inc. changed defaults in v3.6+ (2017) to bind to localhost, but millions of legacy and misconfigured instances remain exposed. Shodan currently shows 109,077 exposed MongoDB instances — each one is a target. The extortion economy is self-sustaining: low effort (fully automated), low risk (cryptocurrency payment, no victim interaction), and continuously profitable (new instances exposed daily as developers deploy without security hardening).
MITRE ATT&CK techniques used in TL-2026-0039
discovery
T1046 Network Service Discovery
exfiltration
T1048 Exfiltration Over Alternative Protocol
execution
T1059 Command and Scripting Interpreter
defense-evasion
T1070 Indicator Removal; T1078 Valid Accounts
collection
T1074 Data Staged; T1119 Automated Collection; T1213 Data from Information Repositories
persistence
T1133 External Remote Services
initial-access
T1190 Exploit Public-Facing Application
impact
T1485 Data Destruction; T1486 Data Encrypted for Impact; T1489 Service Stop; T1490 Inhibit System Recovery; T1491 Defacement; T1657 Financial Theft
resource-development
reconnaissance
T1590 Gather Victim Network Information; T1595 Active Scanning; T1596 Search Open Technical Databases
Affected products and versions in MongoDB Database Extortion Campaign
- MongoDB — MongoDB Server
Vulnerable versions: All versions without authentication enabled
Fixed in: Properly configured instances
Remediation for MongoDB Database Extortion Campaign
Immediate actions
- Scan for exposed MongoDB instances (nmap -p 27017)
- Block port 27017 at perimeter firewall immediately
- Check all MongoDB instances for ransom notes
- Do NOT pay ransom - no guarantee of data recovery
- Restore from backups if available
Workarounds
- Use iptables/firewall rules to restrict MongoDB access
- Deploy MongoDB behind VPN for remote access
- Use MongoDB Atlas or managed service with built-in security
Longer-term hardening
- Enable MongoDB authentication (--auth flag)
- Bind MongoDB to localhost or internal IPs only
- Use TLS/SSL for MongoDB connections
- Implement network segmentation for databases
- Regular backup verification and testing
- Security audit of all database deployments
Weaknesses (CWE) in MongoDB Database Extortion Campaign
Timeline of MongoDB Database Extortion Campaign
- First public reports of exposed MongoDB instances accessible without authentication. Shodan begins indexing MongoDB on port 27017. Source: Security researchers, Shodan.
- Victor Gevers (GDI Foundation) begins responsible disclosure campaign, notifying MongoDB operators of exposed instances. Discovers thousands of databases with PII, medical records, financial data accessible without authentication. Source: @0xDUDE.
- First wave of automated MongoDB extortion begins. Attacker 'harak1r1' ransoms 10,000+ databases in days. Ransom: 0.2 BTC. Many victims had no backups. 'MongoDB Apocalypse' coined. Source: BleepingComputer, Kromtech.
- MongoDB extortion reaches 28,000+ ransomed databases. Multiple groups (harak1r1, kraken0, crazzynoob, 3lix1r) compete for same targets. Double/triple ransoming observed — later groups overwrite earlier ransom notes. Source: GDI Foundation tracking.
- Extortion model spreads from MongoDB to Elasticsearch, CouchDB, Hadoop, Redis, and other exposed databases. Same automated scan→drop→ransom pipeline adapted for each database technology. Source: Multiple.
- MongoDB 3.6 released — default bind changed from 0.0.0.0 to localhost (127.0.0.1). First official mitigation of the default-exposure problem. Authentication still not required by default. Source: MongoDB release notes.
- Unistellar group ransoms 12,564 MongoDB instances. Demands 0.1 BTC. Automated pipeline with Shodan integration. Many victims are repeat targets from 2017 wave who never secured their instances. Source: Multiple.
- Meow attack wipes 4,000+ exposed databases (MongoDB, Elasticsearch) WITHOUT leaving ransom notes — pure destruction. Demonstrates that not all attackers are financially motivated. Some just destroy. Source: BleepingComputer.
- New wave of MongoDB extortion driven by Docker containers deployed with default settings. Docker's official MongoDB image ships without authentication. Developers run 'docker run -p 27017:27017 mongo' → instantly exposed. Source: Multiple.
- MongoDB extortion continues as a sustainable low-effort criminal economy. New instances exposed daily as developers deploy without security hardening. 109,000+ MongoDB instances visible on Shodan. Source: Shodan, Rapid7.
- crazzynoob/Mongo Lock groups ransack 1,400+ MongoDB instances in coordinated campaign. Demand 0.1-0.5 BTC. Most victims have no backups. Multiple groups target same instances. Source: TL-0023 parent research.
- First Exploitation
- Discovered
- Disclosed
- Shodan shows 109,077 MongoDB instances exposed on port 27017. Top countries: China (22,691), US (17,620), Germany (12,366). Each is a potential extortion target. The problem is NOT being solved. Source: Shodan live data.
- As of 2026-05-29, this MongoDB extortion campaign is still active: Flare/BleepingComputer (Feb 2026) confirm automated scanning of ~3,100 no-auth instances (45.6% already wiped) with hundreds of new victims monthly. It is a misconfiguration class (CWE-306, no CVE) so there is no patch — exposure-driven and ongoing, validating the record's ACTIVE status.
Sources cited for MongoDB Database Extortion Campaign
- SecurityWeek: Over 1,400 MongoDB Databases Ransacked by Threat Actor
- Shodan: 109,077 MongoDB Instances Exposed (Live Data)
- MongoDB Security Checklist — Official
- MongoDB Enable Authentication
- MongoDB Network Hardening
- MongoDB Oplog Documentation
- MongoDB 3.6 Release — Default Localhost Binding
- MongoDB Atlas Managed Service
- CIS MongoDB Security Benchmark
- OWASP Database Security Cheat Sheet
- NIST SP 800-190: Container Security Guide
- Shodan Blog: Exposed Database Analysis
- Victor Gevers — MongoDB Responsible Disclosure Campaign
- Bob Diachenko — MongoDB Exposure Research
- BinaryEdge Internet Scan Data
Detection coverage for TL-2026-0039
As of 2026-02-03, Threadlinqs Intelligence publishes 12 detection rule(s) for TL-2026-0039 across Splunk SPL, Microsoft KQL and Sigma, covering 42 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.