Imperva Hack: Understanding the AWS RDS Data Breach
Although the Imperva breach occurred in 2019, the methodologies and lessons learned remain highly relevant today. In Aug 2019, Imperva disclosed a security incident involving the compromise of a database containing email addresses, hashed and salted passwords, and customers’ API keys. The breaches were limited to customers of a Cloud Web Application Firewall (WAF) product.
The breach involved an AWS RDS (Amazon Relational Database Service), a managed service by AWS that makes it easier to set up, operate, and scale a relational database in the cloud.
It supports various database engines, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server.
The hack has since become a critical learning point in cybersecurity, demonstrating how small vulnerabilities, such as a misconfigured virtual machine (VM), can lead to large-scale data breaches. This article dives deep into the details of the breach, detection strategies, and how organizations can protect themselves from similar threats.
What happened in the Imperva 2019 security breach?
The breach was discovered in August 2019, though it’s unclear how long the threat actors had access prior to this. Investigations suggested that the attack began when a threat actor found an accessible vulnerable VM.
The Attack Process
- Threat actor compromised a VM which was accidentally left accessible by anyone on the internet
- No details given on how the VM was hacked, it could possibly be through a previously stolen credential, unsecure credential or through other installed vulnerable software.
- Threat actor found API key within the configuration or environment variable within the VM
- If AWS CLI is used within the VM, the API Key can typically be found in ~\.aws\credentials
- API code could have been found through code files
- Threat actor reused the API key to access the RDS
- Threat actor accesses customer’s data in RDS
MITRE Framework: Mapping the Tactics and Techniques
We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.
How to detect AWS RDS breaches?
There are multiple opportunities for detection. Let’s walk through the timeline and determine possible detection strategies.
In Stage 3 of the Attack Process, we can detect the threat actor using the following metrics when the threat actor uses the stolen API key to access RDS:
- Detect logins from unusual locations into RDS:
Attackers often operate from geographic locations that differ from normal business activities. Unusual login origins can indicate compromised credentials being used outside of expected regions, time zones, or trusted networks. - Detect spike in data access in RDS:
A sudden surge in data queries, downloads, or exports—beyond normal business use—may signal unauthorized data harvesting. Threat actors often try to exfiltrate as much sensitive data as possible once they are inside. - Detect API usage anomaly:
Abnormal API calls, such as unusual frequencies of requests, calls at odd hours, or invocation of previously unused methods, can reveal the presence of an attacker abusing stolen credentials to access or manipulate cloud resources.
Summary of threats and detection measure
Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies.
Threats | Detection strategies | Stage in illustration |
Threat actor accessing the RDS with the stolen API key | Detect logins from unusual locations into RDS.Detect for spike in data access in RDS.Detect API usage anomaly. | 3 During unauthorized RDS access stage |
Staying ahead of cyber threats with advanced security solutions
Innovative solutions by InsiderSecurity
Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA, and Database Activity Monitor for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.
Database Security Monitor simplifies database monitoring with its AI-powered solution. It identifies suspicious data activity without manual rule-writing, providing early warnings for threats across on-premises and cloud databases. This continuous monitoring detects unusual behavior and potential threats before they escalate. For example, in scenarios similar to the Imperva breach, it would identify sudden spikes in data access in Amazon RDS.
Captions: Database Security Monitor tracks normal activity patterns and flags deviations, helping security teams identify threats early
CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. For example, in scenarios similar to the Imperva breach, it would detect API usage anomaly.
Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.
CSX provides an easy way to perform mitigation and remediation.