Full Report
Imperva identified an unknown threat actor using an administrative AWS API key in one of their production AWS accounts, which led to the exposure of an RDS database snapshot from September 2017 containing email addresses of Imperva Cloud WAF customers, hashed & salted password...
Analysis Summary
# Incident Report: Imperva Cloud WAF Data Breach (2019)
## Executive Summary
An unknown threat actor utilized an exposed administrative AWS API key to gain access to a production AWS account, subsequently stealing a legacy RDS database snapshot. This breach exposed sensitive customer data including emails, hashed/salted passwords, and API keys for a subset of Cloud WAF customers. Imperva responded by rotating credentials, decommissioning the vulnerable environment, and implementing stricter security controls.
## Incident Details
- **Discovery Date:** August 20, 2019
- **Incident Date:** October 2018 (Unauthorized access/Exfiltration)
- **Affected Organization:** Imperva
- **Sector:** Cybersecurity / SaaS
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** 2017 - 2018
- **Vector:** Credential Leakage / Misconfiguration
- **Details:** An internal development team created an AWS Instance in 2017 which contained a legacy AWS administrative API key. This key was likely exposed or inadvertently shared, providing the attacker with administrative privileges to the production AWS environment.
### Lateral Movement
- **Details:** Using the administrative API key, the threat actor performed reconnaissance within the AWS account to identify valuable storage assets, specifically focusing on Relational Database Service (RDS) snapshots.
### Data Exfiltration/Impact
- **Date/Time:** October 2018
- **Details:** The attacker used the API key to access and exfiltrate a database snapshot dated September 15, 2017. This snapshot contained a copy of the production Cloud WAF database.
### Detection & Response
- **Discovery:** August 20, 2019 — Imperva was notified by a third party regarding the data exposure.
- **Response:** Imperva initiated an internal investigation, engaged outside forensics firms, and forced a global password reset and API key rotation for all affected customers.
## Attack Methodology
- **Initial Access:** Use of a leaked/misconfigured AWS Administrative API key.
- **Persistence:** Not explicitly reported; assumed to be via the ongoing validity of the API key.
- **Privilege Escalation:** Administrative rights were inherent to the leaked API key.
- **Defense Evasion:** Use of legitimate administrative tools (AWS CLI/API) to blend in with authorized activity.
- **Credential Access:** Extraction of hashed passwords and API keys from the RDS snapshot.
- **Discovery:** Enumeration of RDS database snapshots.
- **Lateral Movement:** Cloud-based movement from an EC2 instance environment to RDS management.
- **Collection:** Creation or access of an RDS snapshot.
- **Exfiltration:** Transfer of the database snapshot data to an external, attacker-controlled location.
- **Impact:** Massive data breach affecting Cloud WAF customers.
## Impact Assessment
- **Financial:** Significant costs related to forensics, legal counsel, and customer notification.
- **Data Breach:** Exposure of email addresses, hashed/salted passwords, API keys, and SSL certificates for a subset of customers through Sept 2017.
- **Operational:** Diversion of engineering resources to remediation and infrastructure hardening.
- **Reputational:** High impact; as a cybersecurity firm, the breach of a WAF product (designed to prevent such attacks) caused significant brand damage.
## Indicators of Compromise
- **Behavioral indicators:** Unusual API calls originating from non-standard IP addresses targeting RDS snapshot exports; API calls associated with a specific administrative key used outside of normal maintenance windows.
## Response Actions
- **Containment:** Decommissioned the compromised AWS instance and revoked the administrative API key.
- **Eradication:** Verified no other backdoors existed; rotated all customer SSL certificates and API keys.
- **Recovery:** Forced global user password resets; notified the FBI and relevant regulatory bodies (GDPR).
## Lessons Learned
- **Key takeaways:** Transitioning to cloud infrastructure requires strict management of legacy instances. Administrative keys should never be stored on persistent compute instances.
- **What could have been done better:** Earlier implementation of automated secrets management and more aggressive decommissioning of "shadow IT" or development instances that have access to production data.
## Recommendations
- **Least Privilege:** Implement IAM policies that restrict API keys to specific tasks rather than "Full Admin" access.
- **Secrets Management:** Use tools like AWS Secrets Manager or HashiCorp Vault; rotate keys every 90 days.
- **Monitoring:** Implement Amazon GuardDuty or similar tools to alert on anomalous API activity.
- **Snapshot Security:** Enforce encryption for all RDS snapshots and restrict snapshot sharing and export permissions.