MyBait: Why We Lured Attackers To Encrypt Our Cloud MySQL
Varonis Threat Labs deployed managed MySQL honeypots across major cloud providers to observe attacker behavior. The publicly exposed GCP instance with weak credentials was compromised within hours by multiple automated ransomware operators who brute-forced access, exfiltrated data, dropped tables, and left ransom notes.
- emailrambler+24hse[@]onionmail[.]orgContact email address provided by the attacker in the database ransom note.
- ip196[.]251[.]100[.]205Primary attacker IP address used during the database compromise.
- ip204[.]76[.]203[.]30Source IP address used for sustained brute-force attacks against the database.
- ip5[.]194[.]178[.]102Primary attacker IP address used during the database compromise.
- ip5[.]255[.]126[.]29Primary attacker IP address used during the database compromise.
- ip85[.]11[.]167[.]218Primary attacker IP address used to connect to the database after successful brute-force.
Detection / HunterGoogle
What Happened
Security researchers set up fake, poorly secured cloud databases to see how quickly hackers would attack them. Within hours, automated attackers broke in by guessing the weak password, stole the fake data, deleted the original tables, and left a ransom note demanding Bitcoin. This highlights the severe risk of leaving cloud databases exposed to the internet without strong passwords or access controls. Organizations should immediately restrict database access to private networks and enforce strong authentication methods.
Key Takeaways
- Exposed cloud MySQL databases with weak credentials are compromised within hours by automated ransomware campaigns.
- Attackers utilize a predictable sequence of brute-force access, reconnaissance, data extraction, and table dropping.
- Over 100,000 managed MySQL instances across GCP, AWS, and Azure are currently exposed to the public internet.
- Multiple distinct threat actors are actively targeting the same exposed databases using similar automated scripts.
Affected Systems
- GCP CloudSQL for MySQL
- Azure MySQL Flexible Server
- Amazon RDS for MySQL
Attack Chain
Attackers initiate the compromise by conducting sustained brute-force attacks against publicly exposed MySQL instances. Upon successful authentication, they reconnect via a VPN to mask their origin and perform database reconnaissance using SHOW commands. The attackers then exfiltrate the data using cache-bypassing SELECT queries before dropping foreign keys and deleting the original tables. Finally, they create a new table containing a ransom note demanding cryptocurrency for data restoration.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article does not provide specific detection rules but outlines behavioral patterns and SQL query sequences to monitor in database audit logs.
Detection Engineering Assessment
EDR Visibility: None — The attack targets managed cloud database services (PaaS) where traditional EDR agents cannot be deployed. Network Visibility: Medium — Network monitoring can detect brute-force traffic patterns and large data transfers, but encrypted database connections may obscure the specific SQL queries. Detection Difficulty: Moderate — Detecting the activity requires explicit configuration of database-level audit logging, which is often disabled by default in managed cloud environments.
Required Log Sources
- Cloud Audit Logs
- Database Query Logs (general_log, cloudsql_mysql_audit)
- Cloud Network Flow Logs
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for excessive failed login attempts originating from a single IP address followed by a successful login from a different IP, indicating a successful brute-force attack. | Database Authentication Logs | Credential Access | Low |
| Consider hunting for rapid sequences of SHOW DATABASES, SHOW TABLES, and SHOW FIELDS queries, which may indicate automated database reconnaissance. | Database Query Logs | Discovery | Medium |
| Consider hunting for mass SELECT queries using SQL_NO_CACHE immediately followed by DROP TABLE operations, a strong indicator of database ransomware. | Database Query Logs | Impact | Low |
Control Gaps
- Lack of database-level audit logging enabled by default
- Publicly exposed database endpoints (0.0.0.0/0)
Key Behavioral Indicators
- High volume of SELECT * SQL_NO_CACHE queries
- Creation of tables with names like RECOVER_YOUR_DATA
- Multiple DROP TABLE operations in a short timeframe
False Positive Assessment
- Low
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting.
- Evaluate whether public IP access to managed database instances can be disabled or restricted to known, trusted IP addresses.
- Consider resetting passwords for any database root or administrative accounts to ensure they meet length and complexity requirements.
Infrastructure Hardening
- Consider implementing organizational policies (e.g., GCP custom constraints, AWS SCPs, Azure Policies) to prevent the deployment of public-facing database instances.
- Evaluate transitioning to IAM or Entra ID-based database authentication instead of native database passwords where supported.
- Consider enabling deletion protection and automated backups with point-in-time recovery for all critical databases.
- Evaluate enabling database-level audit logging (e.g., cloudsql_mysql_audit, general_log, MARIADB_AUDIT_PLUGIN) to ensure query visibility.
User Protection
- If applicable, ensure developers and database administrators connect to cloud databases via secure private networks or VPNs rather than the public internet.
Security Awareness
- Consider training engineering teams on the shared responsibility model, emphasizing that access control and authentication remain the customer's responsibility in managed database services.
MITRE ATT&CK Mapping
- T1110.001 - Brute Force: Password Guessing
- T1078.003 - Valid Accounts: Cloud Accounts
- T1526 - Cloud Service Discovery
- T1485 - Data Destruction
- T1048 - Exfiltration Over Alternative Protocol
Additional IOCs
- Command Lines:
- Purpose: Database enumeration and reconnaissance | Tools:
MySQL| Stage: Discovery |SHOW DATABASES; SHOW TABLES; SHOW FIELDS FROM - Purpose: Data extraction bypassing cache | Tools:
MySQL| Stage: Exfiltration |SELECT /*!40001 SQL_NO_CACHE */ - Purpose: Database destruction and ransom note creation | Tools:
MySQL| Stage: Impact |ALTER TABLE ... DROP FOREIGN KEY; DROP TABLE
- Purpose: Database enumeration and reconnaissance | Tools:
