EY Data Breach: A Support Ticketing Platform Becomes a Tax Data Goldmine

Executive Summary

Ernst & Young (EY), one of the Big Four professional services firms, has begun notifying clients of a data breach involving a third party IT service management platform used by its internal IT support staff. An unauthorized party accessed the platform between March 28 and April 12, 2026, and downloaded documents that included personal and financial information tied to client tax filings. EY detected the anomalous activity on April 23, 2026, eleven days after the intruder's known access window closed, meaning the attacker likely operated undetected inside the environment for over two weeks. EY filed a breach notification with the California Attorney General on July 15, 2026, and is offering affected individuals two years of identity monitoring through Experian. As of this writing, EY has not named the compromised vendor, has not disclosed the initial access method, and no ransomware or extortion group has publicly claimed responsibility.

Separately, in an unrelated incident, a security research firm identified a 4TB unencrypted SQL Server backup file left publicly exposed on Microsoft Azure storage. EY attributed that exposure to an Italian entity it had acquired and stated the file was disconnected from EY's global systems and contained no client or confidential EY data. This appears to be a distinct exposure event, not connected to the ticketing platform intrusion.

Key Takeaways

• Support and ticketing systems are not neutral infrastructure. Employees routinely attach screenshots, spreadsheets, and case files to resolve issues, and over time these systems accumulate sensitive data well beyond their intended operational scope.
• A sixteen day dwell time followed by an eleven day detection lag shows that monitoring gaps in third party platforms can persist even at organizations with mature internal security programs.
• Attribution and root cause remain undisclosed months after detection, which is common in early stage breach disclosures but limits the ability of other organizations using similar platforms to assess their own exposure.
• The parallel Azure exposure incident, even though unrelated and reportedly contained to an acquired entity, illustrates how mergers and acquisitions can leave orphaned cloud assets that fall outside centralized security governance.

Attacker Profile

ShinyHunters

Attack Method

Publicly available information indicates the attacker gained access to a third party IT service management (ITSM) platform used by EY's internal support staff and retained that access for approximately sixteen days before downloading client related documents attached to support tickets. EY has not disclosed whether the initial entry involved stolen credentials, a software vulnerability in the vendor's platform, a compromised integration, or social engineering. Given a vendor operated support ticketing environment and the extended dwell time, plausible and commonly observed entry vectors for this class of incident include credential theft or reuse, exploitation of a vulnerability in the vendor's web facing application, or abuse of an over privileged integration or API token connecting the platform to EY's environment. None of these have been confirmed by EY.

Targeted Country 

London, United Kingdom

Targeted Industry

• Professional services, specifically tax advisory and preparation services.
• Azure exposure involved an EY entity in Italy operating in the same professional services vertical.

Victims

Clients of EY who had tax related documents, and associated support tickets, processed through the affected third party platform during the exposure window. EY has not disclosed a total victim count. The California filing indicates at least several hundred residents of that state alone were notified, since California law requires an Attorney General filing once notifications exceed five hundred residents. The true global figure is very likely higher given EY's scale.

 

 Impacted Data

• Client tax records
• Social Security numbers
• financial account codes
• names, and addresses

MITRE ATT&CK TTPs

T1199: Trusted Relationship, access gained through a third party vendor platform rather than EY's own perimeter

T1078: Valid Accounts, plausible if the actor used legitimate or stolen credentials to access the ITSM platform

T1190: Exploit Public Facing Application, plausible if a vulnerability in the vendor's web application was the entry point

T1213: Data from Information Repositories, collection of documents and attachments stored within the support ticketing system

T1530: Data from Cloud Storage, applicable if the platform or its attachments were cloud hosted

T1074: Data Staged, likely occurred prior to bulk download of documents

T1567: Exfiltration Over Web Service, consistent with downloading files directly through the platform's web interface

T1592: Gather Victim Org Information, reconnaissance phase commonly preceding access to a specific vendor platform

Indicators of Compromise (IOCs) 

http://shnyhntww34phqoa6dcgnvps2yu7dlwzmy5lkvejwjdo6z7bmgshzayd[.]onion/

Mitigation Recommendations

• Treat all attachments within support, ticketing, and helpdesk platforms as governed sensitive records rather than incidental troubleshooting material, and apply data classification and retention policies accordingly.
• Enforce short retention windows for ticket attachments and automatically purge or archive documents once a case is resolved.
• Apply strong authentication, including multi factor authentication, for all accounts with access to third party support platforms, particularly those with access to attachments containing client data.
• Deploy data loss prevention tooling capable of identifying sensitive data types, such as tax identifiers and financial account numbers, at the point of upload into third party systems.
• Monitor download and access volume per account within vendor platforms, with alerting tuned to flag activity that deviates from a user's historical baseline.
• Maintain a current inventory of third party platforms with access to sensitive data, including clear ownership of who monitors each platform for anomalous activity and how quickly alerts reach the security team.
• Conduct regular audits of legacy or acquired entity cloud assets following mergers and acquisitions to prevent orphaned storage, such as the exposed backup file identified in EY's Italian entity, from persisting outside centralized oversight.
• Require vendors managing sensitive client data to provide contractual commitments on encryption at rest, access logging, and breach notification timelines, and validate these commitments through periodic security assessments.

Conclusion

The EY incident is a reminder that an organization's security posture is only as strong as the weakest system connected to its sensitive data, even when that system sits outside the organization's own infrastructure. A support ticketing platform, designed to track routine IT issues, became a repository of client tax data simply because employees attached documents to resolve tickets over time. The sixteen day access window and eleven day detection delay point to gaps in third party monitoring that are common across the industry, not unique to EY. Until EY or investigators release further detail on the initial access method and the identity of the compromised vendor, other organizations relying on similar third party ITSM platforms should treat this as a prompt to review their own attachment handling policies, retention practices, and monitoring coverage for vendor hosted systems, rather than waiting for a confirmed root cause.