When an intruder wants data, databases are the shortest path. MITRE ATT&CK tracks this as T1213.006, Databases, a sub-technique of Data from Information Repositories in the Collection tactic. It spans IaaS, SaaS, Linux, macOS and Windows, because databases live everywhere: on premises, as platform services and as software services.
MITRE names MySQL, PostgreSQL, MongoDB, Amazon Relational Database Service, Azure SQL Database, Google Firebase and Snowflake as examples.
How attackers use it
Databases may contain usernames, hashed passwords, personally identifiable information and financial data. MITRE notes the collected data can support Lateral Movement, Command and Control or Exfiltration. Exfiltrated database content may also be used to extort victims or be sold for profit.
Notice that two of those uses are about moving deeper. Hashed passwords and connection details in a database can open the next door.
How to detect it
The MITRE page describes several analytics, each tied to a different place the activity shows up.
- Database command line clients such as psql, mysql or mongo run by non-admin users, outside automation windows or without a known service context, followed by dumps to .sql or .csv files or outbound transfers.
- On Windows, database clients such as sqlcmd.exe or isql.exe launched by explorer.exe, PowerShell or odd parent processes, followed by .sql, .bak or .csv file creation or encrypted ZIPs.
- GUI or Java based database tools such as DBeaver or Beekeeper run by users who are not in developer or admin roles, followed by file writes in Downloads or Documents and cloud sync activity.
- Database enumeration and export commands, such as selecting everything from a table or listing databases, issued from ephemeral VMs, admin APIs or cloud shells by accounts that are not monitoring accounts.
The common pattern is a tool or account that does not belong to the usual workflow, followed by a file or a network transfer. Turn on database audit logging and process creation logging, and keep both.
How to reduce the risk
- Publish a policy on what may be stored in databases and how customer data is handled. Store only what the business needs.
- Encrypt data stored at rest in databases.
- Set data retention policies that archive or delete data you no longer need.
- Enforce least privilege, with authentication and authorization controls.
- Review accounts and privileges for critical and sensitive databases periodically.
Check your own environment
Work through this list with your database owners:
- Which accounts can run bulk reads on production data, and are they all still needed?
- Do database audit logs record who connected, from where and what they exported?
- Are interactive database clients allowed on laptops that have no reason to use them?
- Where do database credentials live? Connection strings in code and config files are often the real key.
- Is old data archived or deleted on a schedule?
On a Linux host with auditd, you can list the audit rules currently loaded with this read-only command:
sudo auditctl -l
Try it yourself
Click through it at your own pace, or open it full screen.
Where to start
If you only have an afternoon, do these three things in order. First, list the accounts with direct read access to production databases and remove the ones that exist only out of habit. Second, confirm that audit logging is on for connections and for large reads, and that the logs leave the database server. Third, look for plain text connection strings in repositories and shared drives, because a leaked credential gives an intruder the same access as a legitimate client with none of the process telemetry.
Those steps cost little and they cover most of what the MITRE detection analytics assume you can see.
Quick check
Name two signals from the MITRE page that a database dump may be underway.
For example, a database client launched by a non-admin user or an odd parent process, followed by dump style file writes such as .sql, .csv or .bak, or by outbound transfers.
Which mitigation reduces the damage if data is taken from storage directly?
Encrypting data at rest. Retention policies also help because there is less to take.
Sources
- MITRE ATT&CK, T1213.006: https://attack.mitre.org/techniques/T1213/006
