B (151:31)
So they said 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. Threat actors demand payment in Bitcoin, often around 0.005 BTC, equivalent today to between 500 and $600. Actually, that depends upon when you look. Bitcoin's been having a little rough time of it lately, they said, to a specified wallet address, promising to restore the data. However, there's no guarantee the attackers have the data or will provide a working decryption key if paid. These incidents, sometimes referred to as the MongoDB apocalypse, affected tens of thousands of servers. Victims who have paid the ransom often reported receiving nothing in return or finding the provided datas and data keys were useless, leading to permanent data loss. Thus, security experts strongly advise against paying the ransoms. On the other hand, five or six hundred bucks. Part of the key to this working at all is that the bad guys put no effort into this. A bot found it, a bot dealt with it. And they're not asking for millions of dollars, they're asking for six, you know, five or six hundred bucks. They said we set up a MongoDB honeypot and so has Leo 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. They then show the MongoDB shell range running and the command show DBS, you know, DBS D databases which results in the listing of a file titled read underscore me underscore to recover your data. After using the MongoDB shell to switch to that file, it is dumped to the console and it reads all your data is backed up. You must pay 0.0054 BTC2 and then a Bitcoin address. In 48 hours your data will be publicly disclosed and deleted. For more information go to and then they have a a website address, the numeral2info win forward slash MDB they said after paying, after paying send mail to us and then they have an email address rambler and then a plus sign and then a six character token1y08bunionmail.org they said and we will provide a link for you to download your data. Your DB code is and then the same token 1y08 bullet so they said 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, the one that that I I showed you guys above. That's the note that I, you know that I showed before then under the heading why and how does the MongoDB attack actually happen? They said. 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 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 deployment are key. With this understanding, we leveraged Flare, which is a tool that they use their own in house tool 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 that validated repeatedly in real world incidents that organizations and individuals 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 command pattern that would bind MongoDB to to all network interfaces and enable unauthenticated access by default and they give a sample of such a string in their posting, they said 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. Again, 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 okay, so 90 days three months analysis, they said. We identified 763 container images uploaded to Docker Hub containing exactly this insecure configuration. These 763 container images spanned 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. Okay, so there's so Docker Hub is hosting two specific images for which 30,000 deployments have been made insecurely, they said. While these numbers alone do not appear significant, this represents only one of the 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. Out of curiosity, they said, 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 abused by attackers. The diversity of sources illustrate the low 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 such as GitHub and Docker Hub, dark web forums, paste sites, and shy shy hulude victims. We used Shodan to identify Internet connected MongoDB services. Our analysis revealed more than 200,000 servers running MongoDB that were publicly discoverable. Again, remember, there are very few instances where you actually need public exposure from from MongoDB database. It is meant for internal infrastructure, not remote access. 200,000 servers they found running MongoDB that were publicly discoverable. Of these, they said, slightly over 100,000 instances disclosed operational information, and 3,100 were fully exposed to the Internet without access restrictions. Among the 3,100 fully exposed servers, 1416 that is to say, 1,416 instances had already been compromised with their databases Wiped and replaced with a ransom note. In nearly all cases, the ransom demand was approximately $500 US in Bitcoin. Notably, only five distinct Bitcoin wallets were observed across all incidents, with the wallet associated with the ransom notes left on our servers appearing in over 98% of cases. In other words, one attacker is out there. Basically, their, their business model is just scanning the Internet for morons who put Data on a MongoDB and, you know, they delete it and put a ransom note up and Hope to get paid. 98 of all of the ransom notes they've seen pointed to the same bitcoin wallet, they said. 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. They said. 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, were actually found to be compromised and wiped. Based on the Shodan data, we found a little more than 95,000 of the more than 200,000 exposed servers had at least one vulnerability. So there are, you know, also these servers are, are vulnerable in addition, so under their prevention and mitigation section, they enumerate, you know, all the expected steps and measures. You know, avoid exposing MongoDB directly to the Internet, enable authentication and authorization, restrict network access. You know, I'm a big fan of, of IP address filtering. Why let the world have it? Why expose it to Asia, for example? If you have to have it exposed in the U.S. then, then, you know, do some geolocating. That's no longer difficult to do. They say, harden container and cloud deployments, implement continuous exposure monitoring, isolate the database, audit access logs, assess data integrity and patch and upgrade. Right? So, you know, all of that amounts to standard and expected best practices. Don't expose, don't. Don't expose the darn thing to the Internet, period. Why, you know, exercise any sort of security hygiene. So anyway, my two final points are. The first is one of my primary. We wake up and smell the coffee. It's not that it's impossible for authentication to work. It's that it absolutely must not be relied upon to work. It should never be the only thing standing between attackers and disaster. It should only ever be one of multiple lines of defense. One of my favorite things that I hit upon last year thanks to this podcast, is the observation that the only servers that should ever be exposed to the Internet are those that are meant to, to be accessed anonymously by everyone. In other words, no authentication on purpose, no authentication by design. Things like web servers and email servers and DNS servers that everyone is expected to access. Their job is to provide anyone who comes knocking a connection and access. This means that nothing that requires a logon before its services can be used from the public Internet should ever be widely exposed. I know it sounds nutty and impractical, but almost all systems and services could be set up that way if their IT people cared to do so. Pointing fingers at Microsoft, Cisco or whomever after the fact and blaming them for their authentication failures may shift the blame, but a more robust overall network design could have prevented their failure from also highlighting yours. And I said I had two points to make. The second point flows from this line of flare's systems. Conclusion they write attackers did not rely on on sophisticated exploits or zero days. Instead they abused insecure defaults. This further supports the pessimistic the the pessimistic contention I ended with last week AI may help us find flaws in our software. Now we know that's almost certain to happen. Yay team. That's great. But unfortunately, while AI may be getting smarter, it also shows no signs nor hope of being able to make us humans any less dumb. AI won't fix what amounts to laziness and lack of attention to critically important details, configuration mistakes and default setups. That's on us. There's just no excuse from Mongo DB for example, to still, as we enter 2026, be in the sad state it is. It's truly unconscionable.
