Full Report
The Big Four biz’s big fat fail exposed a boatload of secrets online A Dutch cybersecurity outfit says its lead researcher recently stumbled upon a 4TB+ SQL Server backup file belonging to EY exposed to the web, effectively leaking the accounting and consulting megacorp's secrets.…
Analysis Summary
# Incident Report: EY Publicly Exposed 4TB SQL Server Backup
## Executive Summary
The accounting and consulting firm, EY, suffered a significant data exposure when a lead researcher from Dutch cybersecurity firm Neo Security discovered a 4TB+ unencrypted SQL Server backup file publicly accessible on the internet. The backup contained sensitive data, including API keys, authentication tokens, and service account passwords. The incident was discovered externally by a researcher, prompting immediate researcher-to-EY communication, leading to a professional response and remediation within a week.
## Incident Details
- Discovery Date: Wednesday, October 29, 2025 (Approximate based on publication date, discovery likely immediately prior)
- Incident Date: Unknown, assumed to be compromised shortly after exposure.
- Affected Organization: EY (Ernst & Young)
- Sector: Accounting and Consulting (Financial Services)
- Geography: Not specified, but related to cloud storage exposure.
## Timeline of Events
### Initial Access
- Date/Time: Unknown duration prior to October 29, 2025.
- Vector: Misconfigured Cloud Storage/Accidental Public Exposure.
- Details: A SQL Server backup file (.BAK) was inadvertently left accessible on the public internet via a cloud storage mechanism (e.g., an S3-like bucket, inferred from context). The file was unencrypted and approximately 4TB in size.
### Lateral Movement
- The provided text does not detail lateral movement, as the incident appears to be a direct exposure of a data repository rather than an intrusion into the network perimeter. The data was already externalized.
### Data Exfiltration/Impact
- The data, being publicly accessible, was vulnerable to being downloaded by automated scanners or malicious actors. The contents included highly sensitive organizational secrets such as API keys, cached authentication tokens, session tokens, service account passwords, and user credentials.
### Detection & Response
- Detection: A lead researcher from Neo Security stumbled upon the publicly exposed file while conducting unrelated investigations or active scanning.
- Response: The researcher downloaded a small sample (first thousand bytes) to confirm its nature and immediately contacted EY. EY's incident responders engaged and managed the situation professionally. Remediation was completed approximately one week after initial contact.
## Attack Methodology
- Initial Access: Misconfiguration leading to public internet exposure of a critical data asset (SQL Backup file). This is analogous to an external actor using automated discovery tools to find publicly exposed assets.
- Persistence: Not applicable, as the attack vector was passive exposure.
- Privilege Escalation: Not applicable.
- Defense Evasion: Not applicable; default cloud configuration settings were insufficient or bypassed by misconfiguration.
- Credential Access: Direct exposure of credentials, keys, and tokens within the exposed file.
- Discovery: External researcher actively scanned or indexed public space for misconfigured data stores.
- Lateral Movement: Not detailed/applicable.
- Collection: Automated scanning or manual download of the 4TB file by the researcher (and potentially others prior to researcher discovery).
- Exfiltration: Direct download from the publicly accessible storage location.
- Impact: Direct data loss through exposure of internal secrets.
## Impact Assessment
- Financial: Not specified.
- Data Breach: Exposure of a 4TB SQL database backup containing organizational secrets, API keys, authentication tokens, session tokens, service account passwords, and user credentials.
- Operational: No immediate operational disruption mentioned, as the issue was data exposure, not system outage.
- Reputational: Significant reputational damage due to the "Big Four" status of EY and the scale of the data leak.
## Indicators of Compromise
- Network indicators: The method suggests scanning for publicly accessible cloud storage endpoints (e.g., bucket listings). (Defanged example: Suspicious traffic originating from broad internet scans targeting storage service metadata).
- File indicators: 4TB unencrypted SQL Server Backup file (.BAK).
- Behavioral indicators: Lack of monitoring/alerting on public exposure of highly sensitive data repositories.
## Response Actions
- Containment measures: Notification by the third-party researcher to EY, followed by taking the exposed backup file offline or restricting public access.
- Eradication steps: Not explicitly detailed, but likely involved comprehensive rotation of all credentials, keys, and tokens found within the now-secured backup file.
- Recovery actions: Confirmed successful remediation of the exposure and credential rotation within one week.
## Lessons Learned
- The extreme danger of misconfiguring cloud storage permissions, especially during convenient backup/migration processes ("one wrong click, one typo in a bucket name").
- Automated scanning tools are highly effective at discovering incorrectly configured, publicly exposed sensitive datasets, even large ones like 4TB backups.
- Unencrypted sensitive backups compound the risk of exposure significantly.
## Recommendations
- Implement mandatory security reviews and policy checks *before* setting any storage bucket or endpoint to public access, even temporarily.
- Mandate encryption at rest for all database backups, regardless of network location.
- Increase monitoring and alerting specifically for the creation or modification of highly sensitive data stores (DB backups) that suddenly become publicly readable.
- Implement "least privilege" configurations, ensuring that even if a bucket is accidentally left public, the contained data has minimal inherent value or sensitivity (e.g., by removing internal credentials before backup export).