Summary
- Comparitech exposed an unprotected MongoDB database containing 1,007 synthetic records for 48 hours.
- The first wipe-and-ransom incident occurred after two hours and 54 minutes, followed by five additional incidents.
- Researchers recorded 260 incoming TCP SYN events from 88 source IP addresses, illustrating the speed of opportunistic discovery.
An unsecured MongoDB database was wiped and held to ransom less than three hours after being exposed to the public internet during a controlled experiment by Comparitech, demonstrating how quickly opportunistic attacks can reach unprotected data infrastructure.
The researchers deliberately made a database containing 1,007 synthetic customer records accessible without authentication and monitored activity over a 48-hour period.
According to Comparitech’s findings, the first destructive incident occurred two hours and 54 minutes after exposure. The experiment recorded five further instances of wipe-and-ransom behaviour before the observation period ended.
The database contained fabricated records rather than genuine customer information, allowing the researchers to observe unauthorised activity without placing real personal information at risk.
The findings demonstrate the limited response time available when a database is placed online without suitable access restrictions, although the results of a single controlled experiment cannot establish the typical compromise time for every exposed system.
Repeated destructive activity within 48 hours
Comparitech recorded 260 incoming TCP SYN events from 88 source IP addresses during the test.
The average rate was approximately 5.4 recorded connection attempts per hour, with the most active individual address responsible for 28 events.
Of the 88 observed source addresses, 38 were geolocated to the United States, making it the largest national grouping in the recorded traffic.
Those locations describe the apparent source of network connections rather than the identity or physical location of the people responsible. Attackers can route activity through rented infrastructure, proxies, or compromised systems in different countries.
The distinction between connection attempts and confirmed destructive activity is equally important.
A TCP SYN event marks an attempt to begin a network connection. It does not independently demonstrate that an attacker authenticated, inspected data, or successfully modified the database.
Comparitech’s six recorded wipe-and-ransom incidents are separate findings based on the observed state of the exposed database. They do not establish that six different attackers were involved.
Justin Schamotta, researcher at Comparitech, said: “The idea that an attacker chooses a particular company to target is a pervasive one, but a lot of attacks are far less selective. Rather than setting their sights on a particular organisation, they’re often looking for any system that presents an opportunity.”
The experiment reflects a form of attack in which an organisation need not be individually selected in advance. Automated systems can discover exposed services across large address ranges and determine whether their configuration permits unauthorised interaction.
Where a service lacks authentication, the time between discovery and attempted access can be particularly short because attackers do not first need to obtain a valid account.
Database configuration becomes an immediate exposure
MongoDB is a document database used in web applications, enterprise systems, and data-processing environments. Its security depends partly on how network access, authentication, permissions, and supporting infrastructure are configured.
Some deployments require remote database access for legitimate operational reasons. However, allowing connections from the wider internet without effective authentication creates a substantially larger exposure than restricting access to designated applications or administrative systems.
The Comparitech experiment illustrates a destructive outcome in which unauthorised users removed the database’s contents and left ransom demands.
A ransom demand does not establish that the attacker retained a recoverable copy of the deleted information. Such claims require independent verification, and payment does not guarantee restoration of lost records.
That uncertainty makes recovery arrangements a separate consideration from preventing the original intrusion.
Backups protected from the compromised database environment can support restoration after destructive activity, while tested recovery procedures help establish whether critical information can actually be recovered within an acceptable period.
Without those measures, the operational consequences of a short-lived configuration mistake may continue long after the exposed service has been disconnected.
Schamotta said: “Our experiment illustrates just how little time organisations have to get this right. It took just two hours and 54 minutes for someone to find our database, wipe its contents and leave a ransom demand. We also recorded five further instances of the same wipe-and-ransom behaviour during the 48 hours it was online.”
The speed of the first incident is relevant to organisations whose infrastructure is deployed through automated workflows. A database created with an unsafe default or an overly permissive network rule may become accessible before a conventional audit or scheduled security review takes place.
Security checks within infrastructure deployment processes can reduce that interval by identifying inappropriate exposure before a service becomes publicly reachable.
Network restrictions, authentication, appropriately limited database permissions, and activity monitoring provide separate controls. Their combined effectiveness depends on whether they are applied consistently across development, testing, and production environments.
The experiment does not establish how the same database would have performed with any particular combination of those controls, since the purpose was to observe an intentionally unprotected installation.
Nevertheless, the destructive activity recorded during the test illustrates why detection alone may arrive too late when an exposed service offers immediate access.
Comparitech’s monitoring continued for 48 hours, during which researchers recorded six wipe-and-ransom incidents and repeated connection attempts against the deliberately unsecured database.
