Full Report
Security researcher Anurag Sen discovered an unprotected Amazon Prime database containing pseudonymized viewing data, accessible from the internet without a password. Named "Sauron," the Elasticsearch database held approximately 215 million records, including information on st...
Analysis Summary
# Incident Report: Exposed Amazon Prime Video Viewing Data
## Executive Summary
Security researcher Anurag Sen discovered an unprotected, internet-facing Elasticsearch database, dubbed "Sauron," containing pseudonymized Prime Video viewing data for approximately 215 million records. The exposure was due to a cloud native misconfiguration that left the production data accessible without authentication. Amazon secured the data immediately upon notification.
## Incident Details
- Discovery Date: September 30, 2024 (Detection via Shodan)
- Incident Date: Unknown exact start, persisted until remediation, discovered October 27, 2024 (Date of Public Disclosure)
- Affected Organization: Amazon (Prime Video)
- Sector: Media Streaming / Technology
- Geography: Undisclosed (Implied global due to Prime membership)
## Timeline of Events
### Initial Access
- Date/Time: Pre-September 30, 2024 (Persistence unknown, discovered via Shodan)
- Vector: Cloud native misconfiguration
- Details: An Elasticsearch database ("Sauron") was publicly accessible via the internet without requiring any authentication credentials.
### Lateral Movement
- No details provided in the source; the primary issue appears to be direct public access to the data store.
### Data Exfiltration/Impact
- Approximately 215 million records of pseudonymized Prime Video viewing data were potentially exposed. Data included streamed content, device type, network quality, and subscription status.
### Detection & Response
- Date/Time: September 30, 2024 (Discovery) / Prior to October 27, 2024 (Remediation)
- Details: Detected by security researcher Anurag Sen (and potentially via Shodan scans). Amazon secured the data shortly after being alerted. Amazon clarified the incident was due to a deployment error, not a flaw in core AWS security.
## Attack Methodology
- Initial Access: Cloud native misconfiguration (Exposed service)
- Persistence: N/A (Direct exposure)
- Privilege Escalation: N/A (No authentication required)
- Defense Evasion: N/A (Configuration flaw)
- Credential Access: N/A (No credentials necessary)
- Discovery: Scanning tools (e.g., Shodan) identified the open service port and lack of authentication.
- Lateral Movement: N/A
- Collection: Direct query or download from the exposed Elasticsearch cluster.
- Exfiltration: Direct data download (implied).
- Impact: Unauthorized access to sensitive user viewing patterns and metadata.
## Impact Assessment
- Financial: Not specified. Potential regulatory fines or investigation costs.
- Data Breach: Approximately 215 million pseudonymized viewing records (content watched, device, network quality, subscription status).
- Operational: Minimal operational disruption mentioned, focused on data exposure mitigation.
- Reputational: Public disclosure of a major configuration error involving sensitive user data.
## Indicators of Compromise
- Network Indicators: Publicly accessible Elasticsearch port (e.g., 9200) responding to external traffic.
- File Indicators: N/A
- Behavioral Indicators: High volume of read access to the Elasticsearch index from external IPs (post-compromise).
## Response Actions
- Containment measures: Immediately secured the unprotected Elasticsearch database instance, removing public access.
- Eradication steps: Configuration corrected following the identification of the deployment error.
- Recovery actions: Validation that the corrected configuration prevented further unauthorized access.
## Lessons Learned
- Publicly accessible databases, regardless of perceived data anonymization (pseudonymization), represent a severe security risk if proper network controls (e.g., zero-trust, proper firewalling) are not enforced.
- Deployment errors in cloud native environments (e.g., misconfigured security groups or deployment templates) can bypass standard security layering.
## Recommendations
- Conduct an immediate, organization-wide audit of all cloud-hosted databases and production data stores to ensure all are protected by appropriate network access controls (deny-by-default).
- Implement automated configuration drift detection and continuous compliance scanning (CSPM) specifically targeting exposed data services on public subnets.
- Review deployment pipelines to ensure security checks (e.g., public IP assignment flags) are mandatory gates before deploying services connected to sensitive data stores.