Summary
Tens of thousands of MongoDB instances were left exposed to the internet with no authentication on the admin account, a known insecure default in older versions. Multiple attacker groups scanned the internet via Shodan, connected anonymously, exfiltrated or deleted the database contents, and left a ransom note demanding Bitcoin. By early January 2017 roughly 10,500 servers, about a quarter of all internet-facing MongoDB databases, were hit, and cumulative waves through 2017 ruined over 45,000 databases. Many victims who paid recovered nothing because competing crews overwrote each other's ransom notes and in many cases never copied the data.
How to avoid it in your code
- Bind databases to private interfaces only; never listen on 0.0.0.0 or expose DB ports to the internet.
- Enable authentication and role-based access control by default; never run a datastore with auth disabled.
- Restrict database ports with firewalls/security groups to known application hosts.
- Encrypt data at rest and in transit, and keep regular tested backups against extortion/wipe attacks.
- Continuously scan your external surface (Shodan/Censys) for internet-exposed datastores and alert.
References
Related vulnerabilities
All Infra →- HIGHCLOUD-POWERAPPS-2021
On August 23, 2021, UpGuard disclosed that misconfigured Microsoft Power Apps portals exposed roughly 38 million records across 47 organizations, including American Airlines, Ford, J.B. Hunt, the Maryland Department of Health, the State of Indiana, New York City agencies, and Microsoft itself. Exposed data included names, email addresses, phone numbers, social security numbers, and COVID-19 contact tracing and vaccination appointment information. Power Apps portals surface list data through OData list feeds reachable at predictable URLs, and access to those feeds is gated by Table Permissions, but Table Permissions were disabled by default on every list. Because security was opt-in, any portal where a developer enabled an OData feed without explicitly configuring and enabling Table Permissions returned its records to any unauthenticated visitor querying the OData endpoint. This is an insecure-default access-control misconfiguration where the platform defaulted to anonymous read rather than deny.
- HIGHCLOUD-KUBELET-HILDEGARD-2021
On February 3, 2021, Palo Alto Networks Unit 42 reported Hildegard, the first known TeamTNT campaign targeting Kubernetes, detected in January 2021. The attackers gained initial access through a misconfigured kubelet: the kubelet read-write API on port 10250 was reachable and accepted anonymous, unauthenticated requests because it was configured with --anonymous-auth set to true and --authorization-mode set to AlwaysAllow, the insecure legacy defaults shipped by some self-managed clusters. Anyone who could reach port 10250 could call the kubelet run-command API to execute commands inside running pods with no credentials. The attackers used this to exec into pods, move laterally across containers, scan for more exposed kubelets, and harvest cloud access keys, SSH keys, Docker credentials, and service-account tokens from the environment. They then deployed the XMRig Monero miner for cryptojacking, using a tmate reverse shell and IRC for command and control and LD_PRELOAD injection to hide processes. The misconfiguration class is missing authentication caused by an insecure default on an internet-reachable management port.
- HIGHINFRA-TESLA-K8S-2018
Tesla's Kubernetes administrative console was exposed to the internet without password protection, allowing attackers to access it and discover Tesla's AWS access credentials stored within. The attackers used the environment to run cryptomining software inside Tesla's AWS, employing evasion techniques such as hiding the mining pool behind CloudFlare, using a non-standard mining endpoint, and throttling CPU usage to avoid detection. It was discovered by the RedLock Cloud Security Intelligence team, later part of Palo Alto Networks Prisma Cloud, and Tesla remediated within hours stating no customer or vehicle data was compromised.
- CRITICALCONTAINER-EXPOSED-DOCKER-API
Exposed Docker API is a recurring misconfiguration class in which the Docker remote API (default TCP 2375 plaintext, 2376 TLS) is published to untrusted networks without TLS or authentication, granting anyone who reaches it full control of the daemon. Because dockerd runs as root and the unauthenticated API permits arbitrary container creation, an attacker can launch a privileged container that bind-mounts the host root filesystem and then chroots into it to escape to the host. The Commando Cat campaign, reported in 2024 by Cado Security and analyzed by Trend Micro (advisory dated 13 June 2024), abused exactly this exposure: it deployed a benign image (cmd.cat/chattr) generated by the open-source Commando project, then used chroot and volume binding of the host's root directory into the container to break out and run host-level payloads. The delivered payloads installed cryptocurrency miners, registered persistence and a stealthy backdoor (including DropBear SSH on TCP 3022), and exfiltrated host and cloud-service-provider credentials. Shell-script and command-and-control infrastructure overlapped with the TeamTNT cryptojacking group.
- MEDIUMCLOUD-TOYOTA-2023
On May 12, 2023, Toyota disclosed that a cloud environment managed by its Toyota Connected subsidiary had exposed data on roughly 2.15 million customers, essentially the entire Japanese user base of its T-Connect, G-Link, G-Link Lite, and G-BOOK connected services registered since November 2013. The data was exposed from November 6, 2013 to April 17, 2023, nearly a decade, and included in-vehicle GPS terminal IDs, vehicle chassis numbers, location history with timestamps, and a subset of drive-recorder video footage, but not names, credit cards, or other directly identifying personal data. The root cause was a cloud database misconfigured to be publicly accessible instead of private, attributed to human error during setup and allowing unauthenticated internet access. Toyota cited a lack of active detection mechanisms and insufficient enforcement of data-handling rules, which is why the misconfiguration persisted undetected for years. A follow-up disclosure on May 31, 2023 found additional misconfigured cloud services exposing around 260,000 more customers.
- HIGHCLOUD-BLUEBLEED-2022
On September 24, 2022 SOCRadar discovered a misconfigured Microsoft Azure Blob Storage endpoint that exposed roughly 2.4 TB of business data spanning 65,000+ entities across 111 countries, with files dated from 2017 to August 2022, though Microsoft disputed the entity count as exaggerated. The exposed data included customer names, email addresses, phone numbers, company names, and business transaction documents such as signed invoices, proof-of-execution and statement-of-work files, and product offers. The low-level misconfiguration was that the Blob Storage endpoint's access level was set to allow anonymous public access instead of requiring authentication, so the container and its blobs were readable over the internet without any credential. Microsoft's Security Response Center attributed it to an unintentional misconfiguration on an endpoint not in use and reconfigured it to require authentication, stating it found no indication that accounts or systems were compromised.