By Assaf Morag, Cybersecurity Researcher
Between 2017-2021, there was a series of research publications about MongoDB ransomware exploitation campaigns. These blogs described the same pattern. Someone in an organization made a mistake, which left MongoDB exposed to the world. The problem was that this MongoDB didn’t require any special authorization or password. So, anyone over the internet could have accessed and controlled that database.
Here’s the attack vector for attackers who abused these exposures:
- Threat actor finds a MongoDB database.
- They copy everything to their own device.
- They delete everything on the victim’s computer.
- In place of the database they leave a ransom note.
- The ransom note claims: Pay hundreds of dollars in the next 48 hours or the database would permanently get deleted.
This was five years ago… but since then, there have only been a few stories about ransom against MongoDB. However, a couple of months ago, we conducted a pentesting exercise for a small-medium business (SMB). The organization had 12 MongoDB instances, and two of them were exposed to the internet with a ransom note inside. Reminding us of the MongoDB ransom campaigns, we decided to create and run a honeypot exposing MongoDB secrets.
A short Google search indicated that under the surface there are many similar stories. One story reflects the threat from a victim’s perspective talking about a rising star tech startup that heavily relied on MongoDB as a database being hacked and extorted for $25,000. In this blog we analyze the current MongoDB ransomware threat.
Key Takeaways from the MongoDB Ransom Attacks
MongoDB ransom attacks are not driven by advanced exploits or novel malware. They are the predictable outcome of internet-exposed, unauthenticated databases. As long as insecure deployment patterns continue to propagate through tutorials, container images, and copy-paste infrastructure, these attacks will remain cheap, scalable, and profitable for threat actors, and costly for organizations without proper controls.
The MongoDB ransom ecosystem demonstrates that real risk often emerges from the intersection of deployment patterns, configuration shortcuts, and attacker monetization models rather than from advanced exploits alone.
The significance of threat intelligence lies not in its volume, but in how precisely it is tailored to an organization’s technological stack and threat model. Actionable threat intelligence delivers value only when it is translated into insights that resonate across every business unit, not just security teams:
- For the CIO and CISO’s office, correlating technology-layer telemetry with deep and dark web intelligence enables risk to be prioritized based on real attacker behavior, not theoretical exposure.
- For the CTO and engineering leadership, visibility into registry and repository data (such as insecure Docker images, leaked configurations, and copy-paste deployment patterns) directly informs safer architecture, hardened defaults, and more secure CI/CD pipelines. For the DevOps and cloud teams, this intelligence highlights where operational convenience is turning into systemic exposure across databases, containers, and network boundaries.
- For the CFO and executive leadership, these same insights translate into measurable business impact: likelihood of operational disruption, potential extortion costs, regulatory exposure, and downstream financial risk. When intelligence from infrastructure, attacker ecosystems, and software supply chains is correlated, the organization shifts from reactive incident response to proactive risk management; understanding not only what is vulnerable, but why it is exposed, how it is being monetized, and where investment will most effectively prevent the next breach.
About the MongoDB Ransom Attacks
Below is a detailed attack flow on MongoDB instances:
- Target: The attacks exploit MongoDB databases that are exposed to the internet with default, unsecured configurations (e.g., no password, open ports).
- Attack Method: Automated scripts (bots) scan for vulnerable instances. Once an open database is found, the data is typically exported (or simply deleted), the collections are dropped, and a new collection containing a ransom note is inserted.
- Ransom: Threat actors demand payment in Bitcoin (often around 0.005 BTC, equivalent today to $500-600 USD) to a specified wallet address, promising to restore the data. However, there is no guarantee the attackers have the data, or will provide a working decryption key if paid.
- Prevalence: These incidents, sometimes referred to as the MongoDB “Apocalypse,” affected tens of thousands of servers.
- Outcome: Victims who have paid the ransom often reported receiving nothing in return or finding the provided data/keys were useless, leading to permanent data loss. Thus, security experts strongly advise against paying ransoms.
Setting Up a Honeypot
We set up a MongoDB honeypot on a container infrastructure, connected to the world without authentication. We deployed the container in various geolocations. It didn’t take long; a few days after we set up the containers, we saw the ransom note in all the servers.
The ransom note left on our honeypot
Collecting Threat Intelligence
After we observed this attack, we started collecting threat intelligence to better assess this threat and associated risks. We found hundreds of relevant results including this MongoDB ransom tutorial as illustrated below:
A MongoDB ransom tutorial found with Flare (Flare link to post, sign up for free trial to access if you aren’t already a customer)
You can also see the original message in a Tor website, which is often harder to find:
The original MongoDB ransom tutorial found on Tor
Post:
What’s up hustlers,
I’ve been using this secret method since 2019 to pull in steady Cash every day, but it’s starting to get crowded now. Before this method gets completely burned out, I’m sharing it here so you can jump on it and make some serious money for yourself.
This isn’t some complicated tech-heavy process. You don’t need to know coding, hacking, or anything technical. If you can copy, paste, and click, you’re good to go. I’ll guide you through every single step.
What Are We Actually Doing??
Here’s the deal:
There are websites out there where businesses store their important information (think customer records, orders, employee details, etc.) in a digital storage system. This storage system is called a database.
But here’s the crazy part—some businesses leave their databases completely unprotected, wide open on the internet. They don’t set up passwords or any security, which means ANYONE (like you) can access them with just a browser.
Once you’re in, you can:
Delete their data (wipe it all clean).
Leave a ransom note telling them to pay Bitcoin if they want their data back.
Sounds wild, right? Stick with me, and I’ll show you how easy it is to do this.
Why Are These Databases Exposed??
Most businesses use a type of database called MongoDB because it’s fast and easy to set up. They use a tool called Mongo Express to manage it (basically, a control panel for their database).
The problem?
Many businesses are careless and leave their Mongo Express control panels exposed online with no passwords. This makes them perfect targets—you don’t even need hacking tools to get in. [Hidden content]
Need Help??
If you’re stuck or have questions, hit me up:
DM me on the forum.
Message me on Telegram: @[removed].
Final Words:
This method is stupidly easy and works like magic, but it won’t last forever.
Businesses are slowly waking up and fixing their Mongo Express setups, so use this while you still can.
Follow the steps, take action, and start earning $600 a day.
Click to expand… access
Why and How Does the MongoDB Attack Technically Happen?
MongoDB is a widely used NoSQL document database designed for flexibility, scalability, and speed. Instead of rigid tables and schemas, MongoDB stores data as JSON-like documents, making it a natural fit for modern applications that evolve quickly and handle diverse data types.
It is commonly used in web and mobile applications, SaaS platforms, IoT backends, real-time analytics, content management systems, and microservices architectures. Its ability to scale horizontally, replicate data across nodes, and support high-throughput workloads has made MongoDB a popular choice among startups and enterprises alike and particularly in cloud-native environments where agility and rapid development are key.
With this understanding, we leveraged Flare to identify publicly shared code snippets that explicitly configure MongoDB servers to be exposed to the internet without authentication.
This approach is based on the assumption (validated repeatedly in real-world incidents) that individuals and organizations often rely on ready-made Docker images and copy-paste configurations from Docker Hub and GitHub when deploying infrastructure. Using Flare, we searched for code artifacts containing the following pattern, which binds MongoDB to all network interfaces and enables unauthenticated access by default:
CMD ["/bin/sh", "-c", "mongod --bind_ip=0.0.0.0"]This configuration results in a MongoDB instance running inside a container that accepts connections from any IP address. When the container port is bound to the host and exposed externally, any internet-originating traffic can connect directly to the database. In their default configuration, these MongoDB deployments do not enforce authentication or require credentials, allowing unrestricted access to any party that can reach the service. As a result, this code pattern leads to publicly exposed MongoDB instances.
Over a three-month analysis period in our query, we identified 763 container images uploaded to Docker Hub containing this configuration, spanning 30 distinct namespaces. Most of these images appear to be intended for personal or experimental use and have only a few hundred pulls. However, we also identified two widely used projects with more than 15,000 pulls each that included the same insecure setup.
While these numbers alone may not appear significant, this represents only one of many common ways MongoDB is inadvertently exposed. We highlight this pattern to illustrate how easily insecure configurations propagate, and how widespread such exposure can become.
A search for exposed MongoDB configurations with Flare
Below is an example taken from a real container image published on Docker Hub. On its own, this configuration is not inherently dangerous and running the image as-is does not automatically expose the database to the internet.
However, when the container is deployed using host networking or with an explicit port mapping such as -p 27017:27017, while keeping the default configuration, as commonly happens in real-world environments, the result is an unauthenticated MongoDB instance accessible from the network. In internet-reachable deployments, this seemingly minor change is often enough to turn a convenience-driven setup into a fully exposed and high-risk database.
A MongoDB configuration accepts connections from any IPv4 address
Furthermore, we also searched for some exposed credentials. We found 17,909 potential results for a specific user: password exposure (one of many potential search terms). Out of those, we found at least half of them as valid credentials that can be used by attackers.
Interestingly, the diversity of sources illustrated the level of password hygiene in the wild and how easy it is for attackers to obtain credentials in the wild. We found exposed credentials in coding repositories and registries (GitHub, Docker Hub), dark web forums, paste sites, and Shai Hulud victims.
A Flare search for leaked MongoDB credentials
Exposure in the Wild
We used Shodan to identify internet-connected MongoDB services. Our analysis revealed more than 200,000 servers running MongoDB that were publicly discoverable. Of these, slightly over 100,000 instances disclosed operational information, and 3,100 were fully exposed to the internet without access restrictions.
Shodan search for internet connected MongoDB instances
Among the 3,100 fully exposed servers, 1,416 instances (45.6%) had already been compromised, with their databases wiped and replaced with a ransom note. In nearly all cases, the ransom demand was approximately $500 USD in Bitcoin.
Notably, only five distinct Bitcoin wallets were observed across all incidents, with the wallet bc1qe2l4ffmsqfdu43d7n76hp2ksmhclt5g9krx3du appearing in over 98% of cases. This strongly suggests the activity is attributable to a single dominant actor, likely the same attacker documented in our previous dark web research.
The data reveals an interesting discrepancy. While Shodan identified 3,100 servers as fully exposed to the internet, our analysis shows that only slightly less than half of these instances were actually found to be compromised and wiped.
One possible explanation is that a portion of the remaining 1,684 servers (54.4%) may have paid the ransom (or at least some of them did) resulting in no visible wipe or ransom note. This suggests that the threat actor’s earnings from this campaign could range from $0 USD (assuming all remaining servers were test environments that were simply taken offline) to as much as $842,000 USD.
Even at the lower end of this estimate, the potential revenue highlights how exposed databases can be monetized at scale, turning what may appear to be opportunistic attacks into a highly profitable side operation.
Based on the Shodan data we found, a little more of 95,000 servers (46.3%) had at least one vulnerability.
While the volume of CVEs observed in the wild may appear alarming, in practice most of these vulnerabilities are limited to denial-of-service conditions or similarly constrained impacts, rather than enabling remote code execution. As a result, the primary risk in our dataset does not stem from exploitable vulnerabilities, but from misconfiguration. In our case, the only truly problematic assets are the approximately 3,100 MongoDB instances that were exposed without proper access controls.
MITRE ATT&CK Mapping
The observed MongoDB ransom activity aligns closely with established adversary behaviors in the MITRE ATT&CK framework. While the attacks are technically simple, they demonstrate a complete and effective attack lifecycle.
Initial Access
- Exploit Public-Facing Application (T1190)
Attackers identify MongoDB services exposed directly to the internet, often discovered via Shodan or mass scanning, and connect without authentication.
Discovery
- Network Service Discovery (T1046)
Automated scripts scan IP ranges for open MongoDB ports (typically 27017). - Account Discovery (T1087)
In unauthenticated deployments, attackers enumerate databases and collections immediately upon connection.
Collection
- Data from Information Repositories (T1213)
Databases are dumped or inspected to determine value prior to deletion.
Impact
- Data Destruction (T1485)
Collections and databases are dropped or wiped entirely. - Service Disruption (T1489)
Business operations relying on the database are immediately disrupted. - Extortion (T1657)
A ransom note is inserted, demanding Bitcoin payment under the threat of permanent data loss.
Notably, no privilege escalation, lateral movement, or malware deployment is required. The attacker operates entirely within the permissions granted by an insecure deployment, making the detection difficult, and therefore a reactive response over a preventative one.
Prevention & Mitigation
Effective prevention of MongoDB ransom attacks is straightforward and largely configuration-driven:
- Avoid exposing MongoDB directly to the internet: MongoDB can be restricted to private networks, VPNs, or bastion hosts. Direct public exposure is almost never justified.
- Enable authentication and authorization: Enforce SCRAM authentication, role-based access control (RBAC), and least-privilege database users.
- Restrict network access:
- Use firewalls, security groups, or Kubernetes network policies to explicitly allow trusted sources only.
- Block port 27017 from public ingress entirely.
- Harden container and cloud deployments:
- Avoid default Docker images and copy-paste configurations that bind MongoDB to 0.0.0.0.
- Treat example configurations as insecure by default.
- Implement continuous exposure monitoring: Regularly scan your own infrastructure using tools such as Shodan Monitor, cloud security posture management (CSPM), or internal attack-surface management.
- Isolate the database:
- Remove public network access immediately.
- Rotate credentials and secrets.
- Audit access logs: Review MongoDB logs for unauthorized connections, enumeration, or collection drops.
- Assess data integrity: Validate backups and confirm no silent data exfiltration occurred.
- Patch and upgrade: Ensure MongoDB is running a supported version and address known vulnerabilities, even if they are not the primary risk vector.
What the MongoDB Threat Means for Security Teams
MongoDB ransom attacks are not a new phenomenon. Between 2017 and 2021, thousands of organizations fell victim to opportunistic ransomware campaigns that exploited a simple but devastating weakness: internet-exposed MongoDB instances deployed without authentication or access controls. Attackers did not rely on sophisticated exploits or zero-days. Instead, they abused insecure defaults, wiped databases, and left ransom notes demanding modest Bitcoin payments, which often with no intention or ability to restore data.
While public reporting on MongoDB ransomware declined in recent years, our research shows the threat never disappeared. In late 2025, the disclosure of MongoBleed (CVE-2025-14847) reinforced that MongoDB remains a high-value target, especially when deployed insecurely. Through a combination of real-world penetration testing, honeypot deployment, dark-web intelligence, container image analysis, and internet-wide scanning, we observed that exposed MongoDB instances continue to be compromised at scale.
Our findings demonstrate that misconfiguration (not vulnerability exploitation) is the dominant risk factor. Of more than 200,000 internet-discoverable MongoDB servers, approximately 3,100 were fully exposed without authentication, and nearly half of those had already been wiped and extorted. A single dominant threat actor appears responsible for the vast majority of observed attacks, monetizing operational negligence into a scalable and potentially lucrative campaign.
While there are currently no known pre-authentication remote code execution (RCE) vulnerabilities in MongoDB, and our findings indicate that MongoDB is not being widely exploited at the vulnerability level, the risk remains significant. A single pre-auth RCE zero-day in MongoDB could instantly expose hundreds of thousands of servers and effectively hand attackers a well-oiled ransom machine capable of operating at massive scale. For this reason, we strongly recommend applying the prevention and hardening best practices outlined above, as misconfiguration—not exploitation—continues to be the critical enabling factor.
Ransomware Readiness with Flare
The Flare Threat Exposure Management solution empowers organizations to proactively detect, prioritize, and mitigate the types of exposures commonly exploited by threat actors. Our platform automatically scans the clear & dark web and prominent threat actor communities 24/7 to discover unknown events, prioritize risks, and deliver actionable intelligence you can use instantly to improve security.
Flare integrates into your security program in 30 minutes and often replaces several SaaS and open source tools. See what external threats are exposed for your organization by signing up for our free trial.
