Executive Summary

Cybersecurity firm Flare has uncovered an ongoing, automated extortion campaign targeting publicly exposed MongoDB databases. The attack involves a threat actor scanning the internet for MongoDB instances that lack basic authentication controls. Upon finding an open server, the attacker's script automatically wipes all data and leaves behind a ransom note demanding a payment of approximately $500 in Bitcoin. Flare's research found that of 3,100 completely unsecured MongoDB servers discovered, nearly 46% (around 1,400) had already been compromised by this campaign. These attacks, while less common than several years ago, serve as a critical reminder of the importance of fundamental database security hygiene.

Threat Overview

This is a low-sophistication, high-volume automated attack. The threat actor is not using zero-day exploits or advanced techniques but is simply capitalizing on a common and well-known misconfiguration: running a database in production with no authentication required for access.

Attack Flow:

1. Scanning: The attacker uses automated tools like Shodan or custom scripts to scan the internet for open MongoDB ports (typically port 27017).
2. Connection: The script attempts to connect to discovered servers without any credentials.
3. Data Wipe: If the connection is successful (i.e., no authentication is required), the script programmatically deletes all databases and collections on the server.
4. Ransom Note: The script then creates a new database or collection with a ransom note. The note typically contains instructions for payment, a Bitcoin address, and a threat that the data will be lost forever if the ransom is not paid. In reality, the attacker likely does not back up the data; the 'wipe' is a destructive act.

Critical Insight: Attackers in these campaigns rarely, if ever, return the data. The data is typically destroyed, not exfiltrated and stored. Paying the ransom is highly unlikely to result in data recovery.

Technical Analysis

The attack relies on the default configuration of some older versions of MongoDB or on administrator error. In the past, MongoDB instances would bind to 0.0.0.0 by default and not enforce authentication, making them publicly accessible. While modern versions have improved default security, many legacy systems or misconfigured new deployments remain vulnerable.

MITRE ATT&CK TTPs

• T1595.002 - Vulnerability Scanning: The attacker scans for open MongoDB ports and misconfigurations.
• T1190 - Exploit Public-Facing Application: While not an 'exploit' in the traditional sense, this involves abusing a weakness in a public-facing service.
• T1485 - Data Destruction: The core of the attack, where the database contents are wiped.
• T1490 - Inhibit System Recovery: By destroying the primary data source, the attacker inhibits recovery unless viable backups exist.

Impact Assessment

• Permanent Data Loss: For organizations without proper backups, this attack results in permanent and catastrophic data loss.
• Operational Disruption: The loss of a production database can bring business operations to a complete halt, leading to significant financial and reputational damage.
• Low Cost, High Reward for Attacker: The automated nature of the attack means the threat actor can target thousands of victims with minimal effort. Even if only a small fraction pay the $500 ransom, the campaign can be highly profitable.

Cyber Observables for Detection

Detection & Response

• Detect: Regularly use attack surface management (ASM) tools or services like Shodan to scan your own public IP space for exposed database ports. Configure database auditing to log administrative commands like dropDatabase and alert on them. Monitor firewall logs for inbound connections to port 27017 from untrusted sources.
• Response: If a database is wiped, immediately isolate the server from the network to preserve any forensic evidence. Do NOT pay the ransom. Begin restoration procedures from your most recent known-good backup. Conduct a post-mortem to identify and remediate the configuration error that allowed the breach.

Mitigation

Preventing these attacks involves basic security best practices for database administration.

1. Enforce Authentication: This is the most critical step. Ensure your MongoDB instances have authentication enabled and require all clients to provide valid credentials. (M1032 - Multi-factor Authentication and M1027 - Password Policies)
2. Network Hardening: Configure your MongoDB server to only listen for connections on a trusted interface (e.g., bind to a private IP address, 127.0.0.1 if local access only). Never expose a database directly to the public internet. Use firewall rules to restrict access to the database port to only specific, trusted application servers. (M1035 - Limit Access to Resource Over Network)
3. Principle of Least Privilege: Create specific user roles with the minimum permissions necessary for the application to function. The application's service account should not have permissions to drop databases. (M1026 - Privileged Account Management)
4. Data Backup: Maintain regular, tested backups of your databases. Store backups in a separate, isolated location. (M0930 - Data Backup)