Security researchers discovered a publicly accessible 4 terabyte SQL Server backup file hosted on a Microsoft Azure storage blob belonging to EY. The backup, which appeared unencrypted, contained full database schema and potentially user credentials, API keys and session tokens. The exposure originated from mis-configured cloud bucket access control and underscored the high risk of cloud-based data leaks.
Current Status: Issue reported via responsible disclosure; EY responded and remediated.
Impact: possible downstream attacks on EY clients, reputational damage, regulatory consequences, Large-scale data breach potential.
ADVISORY OVERVIEW
▪ During routine external attack-surface discovery, researcher sent a HTTP HEAD request to a publicly accessible Azure blob and received a Content-Length: 4 Terabytes response, indicating a massive SQL Server backup file.
▪ The file extension .BAK, combined with magic-bytes analysis of the first 1,000 bytes, confirmed the file as an unencrypted SQL Server backup containing full database contents (schema, data, objects) including likely credentials, API keys and tokens.
▪ Ownership was traced to EY via DNS SOA record lookups pointing to ey[.]com, linking the blob to a major global audit/consulting firm.
▪ The root cause appears to be a cloud-migration or backup export task where the Azure storage container was accidentally set to public read access (or default ACL allowed public) rather than restricted internal access. Researcher emphasizes that modern cloud storage makes such mis-configurations easy and exposure windows are often seconds before automated scanners find them.
▪ Although EY responded and remediated the issue, the large size (4 TB) and public exposure window imply high probability that the data was accessed by multiple threat actors.
RECOMMENDATIONS
▪ Audit all cloud storage exports/backups: Ensure no public ACLs, restrictive permissions only, especially for large database backups or sensitive datasets.
▪ Enable logging and alert on public-read ACL changes: Configure storage alerts for containers/blobs that switch to public or broad CIDRs.
▪ Encrypt backups at rest and in transit: Even if accessible, encryption reduces immediate risk of data extraction.
▪ Rotate credentials and keys: Assume compromise any credentials, tokens or service accounts stored in the database backup should be rotated immediately.
▪ Engage external ASM / attack-surface scans: Use automated tools to find exposed buckets/blobs in near-real time and treat backup/DB exports as high-risk assets.
▪ Segment and isolate backup infrastructure: Restrict backup export destinations, apply network/identity controls and treat backup buckets as sensitive assets requiring hardened permissions.
▪ Limit retention of publicly accessible files: Apply least-privilege and time-limited ACLs; avoid storing raw database backups in any publicly accessible container even briefly.
REFERENCES
▪ https://www.neosecurity.nl/blog/ey-data-leak-4tb-sql-server-backup
▪ https://cybersecuritynews.com/ey-data-leak
