Intro

In recent years, attackers have increasingly turned to “malware-less” Living-off-the-Land operations against cloud and SaaS environments. This trend has also extended to extortion and ransomware: Instead of deploying traditional ransomware to encrypt files, threat actors sometimes prefer to exploit weaknesses in exposed services like databases and abuse otherwise legitimate commands to steal, encrypt, or destroy data and demand payment in exchange for returning the files or keeping them private.

One prominent example we’ve observed is attacks targeting Internet-facing database servers configured with weak passwords or no authentication at all. This malicious activity has been reported by several research groups over the years, including campaigns targeting MySQL, PostgreSQL, MongoDB, Hadoop, CouchDB, and Elasticsearch.

Attackers connect remotely to these servers, copy the data to another location, wipe the database, and then leave behind a ransom note stored in the database itself. This approach bypasses many conventional detection methods because no malicious binary is ever dropped; the damage is done entirely with normal database commands.

This ransom tactic has grown from a few isolated cases into full-scale automated campaigns. As far back as February 2017, researchers from Rapid7 observed thousands of open databases being hijacked in bulk. Today, threat actors operate specialized bots that crawl the Internet for misconfigured databases, able to compromise a new target within hours or even minutes of it coming online. The ease of automation and the lure of quick and easy profits have made “malware-less” database ransomware a persistent threat.

The rise of “malware-less” ransomware

While classic ransomware attacks typically involve infecting the target environment with malicious programs that encrypt files on the disk using a key known only to the attacker, database ransomware doesn’t encrypt data at all - instead, attackers use the database’s own built-in functionality (queries and commands) to render the data unavailable.

This method has several advantages for the attackers. First, it leaves a lighter footprint: there is no custom malware binary to detect via endpoint security solutions, since the attack leverages allowed operations on the DB service. Second, it often relies on exploiting security misconfigurations (like default credentials or open network access) rather than software vulnerabilities, meaning it can succeed regardless of the server version, and without requiring complex exploits. Lastly, by operating over normal protocols (e.g., executing SQL queries), the activity is more likely to blend in with legitimate user or admin behavior and thereby evade detection by traditional host-based defenses.

In effect, these attacks achieve the same goal as ransomware - denying the victim access to their data - but without the telltale malware indicators. Instead of encrypted files, the data is simply gone or locked away in the form of a database backup in the attacker’s possession. The ransom note and the absence of data might be the only obvious sign of compromise.

Notably, newer campaigns have adopted double extortion tactics even in these malware-less scenarios. Attackers will claim to have stolen the data (whether or not they actually exfiltrated it) and threaten to leak it publicly if the ransom isn’t paid. For example, as noted in a report from Guardicore Labs (now Akamai), a campaign targeting MySQL servers uploaded the victims’ database dumps to a dark web “auction” site and let victims see their data for sale in order to pressure payment. Likewise, ransom notes often warn that if the victim doesn’t pay, the data will be published or sold to others. This serves to demonstrate that even without using malware, database extortion is mirroring the tactics of broader ransomware operations.

However, the risk goes beyond data loss and extortion: an attacker with database access can often escalate their privileges to achieve Remote Code Execution (RCE). Once this foothold is established they can begin to move laterally in your environment using the compromised server as a jumping-off point to discover and attack other systems. Therefore, even in cases where the stolen data isn’t necessarily valuable, it’s important to treat a ransom note as an early indicator of a potential deeper compromise by the ransomware operator or another adversary.

Anatomy of a database ransomware attack

It’s easy to understand why attackers target exposed database servers for data theft and extortion purposes - they’re likely to contain valuable information (customer data, financial records, intellectual property, etc.), and they’re not meant to be directly exposed to the Internet: unlike web servers and API servers, database servers are designed to operate behind firewalls or private networks.

As a result, many default configurations of these database servers neglect strict authentication and exposure controls, which can lead users to deploy them in a misconfigured state without realizing the risk. This often leaves databases wide open to the Internet, lacking proper safeguards and making them easy prey for ransomware operators.

Attackers typically begin their operation with an Internet-wide scan for exposed database ports such as 3306 (MySQL) and 5432 (PostgreSQL). They then use fingerprinting techniques to confirm that the targets are indeed database services, test for missing authentication, try default username:password combinations, and attempt to bruteforce weak passwords.

If they successfully authenticate to the database server, the attacker extracts a small data sample, issues destructive SQL commands such as `DROP DATABASE` or bulk `DELETE`, and finally creates a new table with a name such as `RECOVER_YOUR_DATA` or `README_TO_RECOVER` that contains a note with a ransom demand and a cryptocurrency wallet address. As shown in the screenshot below, in a relational database like PostgreSQL, attackers will often create a new table and insert the ransom note itself as a row in the table:

Similarly, in a NoSQL database like MongoDB, the attacker will usually create a new collection with an indicative name and insert the ransom note as a document:

Measuring the risk

Our analysis shows the following distribution of cloud environments with successful ransomware attacks across different types of database servers. MongoDB is currently the most dominant target, with PostgreSQL representing the second-largest share of environments with incidents. Traditional relational databases like MySQL and its variants (such as Amazon Aurora MySQL and MariaDB) are also being compromised but less frequently.

To determine the overall risk to cloud environments, we compared the security posture of five popular database servers: PostgreSQL, MySQL, MariaDB, MongoDB, and Redis. As might be expected, our analysis shows a direct correlation between the overall popularity of a given database server and the percentage of environments with at least one instance directly exposed to the Internet. An outlier in the dataset is Redis, which has relatively low exposure (5.3% of environments) despite its widespread popularity (74% of environments).

However, Internet exposure is only half of the story. The effective risk depends on how these exposed databases are configured:

Notably, while Redis has a relatively low rate of exposure, it has a comparatively high rate of misconfiguration, with 72% of environments with exposed Redis instances having at least one instance configured with no authentication or with weak credentials. However, since Redis runs in memory, it isn’t a very good candidate for database ransomware, and instead attackers usually abuse Redis misconfigurations in order to compromise the underlying host for cryptojacking.

How can organizations defend themselves?

Prevention

• Database servers should reside in private network segments, protected by firewalls and security groups that only allow traffic from trusted application servers, as there is rarely a legitimate reason for a production database to accept connections from arbitrary IP addresses on the Internet.

• If remote administrators need access, it should be routed through a secure host (or jump server) protected with multi-factor authentication (MFA), rather than by opening the database port to the world.

• Internal database servers should be protected from post-compromise activity by enforcing strong authentication:

  • Disable passwordless access

  • Use strong, unique credentials

  • Leverage MFA

• To mitigate the effects of data loss, implement a backup strategy:

  • Perform regular automated backups for critical and sensitive data and test your recovery process to ensure the backups are viable.

  • Store backups in a separate, access-controlled location.

Detection

• Proactively and continuously scan your entire environment to map your effective attack surface. This allows you to identify any exposed sensitive resources affected by misconfigurations and vulnerabilities so you can address them before attackers have an opportunity to discover and exploit them.

• Scan for Indicators of Compromise (IOCs). Regularly check your databases for unique artifacts that indicate a successful attack. As mentioned above, newly created databases or tables with names like README_TO_RECOVER are strong indicators of database ransomware. See the appendix for a full list of known IOCs.

How can Wiz Help?

The Wiz Dynamic Scanner detects publicly exposed instances of the database servers mentioned above wherever they may be located in your environment, and continuously checks for misconfigurations and vulnerabilities.

Wiz customers can check the Attack Surface Rules page to review rules and findings related to database servers:

Wiz also performs agentless scans for IOCs related to database ransom‑notes and alerts customers if any such evidence is found.

References

• How to avoid a malicious attack that ransoms your data (MongoDB Blog, via Wayback Machine)

• The Ransomware Chronicles: A DevOps Survival Guide (Rapid7 Blog)

• Don’t be ransacked: securing your Elasticsearch cluster properly (Code972 Blog)

• More than 10,000 online databases taken hostage by ransomware attackers (Ars Technica)

• Open databases a juicy extortion target (Threatpost)

• MongoDB ransacked: Now 27,000 databases hit in mass ransom attacks (ZDNet)

• After MongoDB, ransomware groups hit exposed Elasticsearch clusters (PCWorld)

• MongoDB is subject to continual attacks when exposed to the Internet (Help Net Security)

• Please READ_ME: Opportunistic ransomware devastating MySQL servers (Akamai Blog)

• Extortion bot is auto-pwning PostgreSQL (The Register)

• PostgreSQL and MySQL databases targeted by ransomware bot (Help Net Security)

• Help! My Postgres Database Was Compromised (Border0 Blog)

• Protecting Postgres: Key Security Takeaways from a Postgres Honeypot (Hunters Blog)

Appendix - Indicators of Compromise (IOCs)

• Table and document names:

  • README_TO_RECOVER

  • READ_ME_TO_RECOVER

  • RECOVER_YOUR_DATA

  • PLEASE_READ_ME

  • PLEASE_READ

  • PWNED

• Table and document content:

  • All your data is backed up

  • After paying send mail to us

  • Cryptocurrency wallets (in databases that don’t usually contain such information)