ShinyHunters reivindica EY — incidente real, ator ainda não confirmado
A EY confirmou formalmente — via notificações a procuradores-gerais de ao menos quatro estados norte-americanos — que um terceiro não autorizado acessou e exfiltrou documentos com dados fiscais de clientes entre 28 de março e 12 de abril de 2026, via plataforma de ITSM terceirizada. O ShinyHunters reivindicou a autoria em 27 de julho e ameaça publicar o material até 31 de julho caso a EY não negocie; a firma não confirmou nem negou a atribuição, e nenhum dado vazado apareceu em fóruns até o momento.
Juízos analíticos
Cada avaliação vem com seu nível de confiança declarado, conforme a prática de inteligência (ICD 203 / FIRST). Confiança alta não é certeza; confiança baixa não é chute — é o peso que a evidência disponível sustenta.
O incidente de acesso e exfiltração é real e confirmado pela própria EY em filings regulatórios junto a múltiplos procuradores-gerais estaduais nos EUA — não há dúvida sobre o fato base.
A reivindicação do ShinyHunters é coerente com o playbook documentado do grupo (supply chain → credenciais → plataforma SaaS/ITSM de terceiro → exfiltração silenciosa), tornando a atribuição plausível, mas não confirmada — o grupo não forneceu amostras de dados nem identificou o terceiro comprometido.
As alegações adicionais do ShinyHunters sobre acesso lateral a Jira, GitHub e Azure da EY não têm corroboração independente e a EY não as confirmou; devem ser tratadas como alegação de ator não verificada.
O número total de indivíduos afetados é desconhecido e quase certamente superior ao fragmento visível em filings estaduais (873 no Texas, 480 em Massachusetts, 13 em Vermont): a EY opera em mais de 150 países e realiza trabalho tributário para grandes instituições financeiras, cujos clientes finais podem não ter relação direta com a firma.
A janela de detecção tardia — 11 dias após o encerramento do acesso e cerca de 10 semanas antes da notificação pública — é consistente com intrusão silenciosa de exfiltração, sem ransomware, onde gatilhos de alerta tradicionais são menos eficazes.
O prazo de 31 de julho serve primariamente como mecanismo de pressão negocial; o ShinyHunters tem histórico de publicar dados após deadlines não atendidos, mas também de estender prazos quando há engajamento privado — o resultado concreto é incerto.
Análise
O caso EY tem dois planos que a maioria da cobertura embaralha: o incidente confirmado e a reivindicação do ator. São coisas distintas e exigem tratamento separado.
O que a EY confirmou (fonte A, informação 1): entre 28 de março e 12 de abril de 2026, um terceiro não autorizado acessou uma plataforma de gestão de serviços de TI (ITSM) que a firma usa para dar suporte a equipes de trabalho tributário. Os tickets de suporte podiam conter documentos fiscais de clientes anexados. A EY detectou a atividade anômala em 23 de abril — 11 dias depois do encerramento do acesso —, acionou resposta a incidentes com firma de cibersegurança externa, notificou autoridades federais e protocolou notificações a procuradores-gerais de ao menos quatro estados. Os dados confirmados incluem nomes, endereços, SSNs, números de conta financeira e de cartão de crédito/débito. O total de afetados não foi divulgado publicamente; os filings estaduais revelam fragmentos (873 no Texas, 480 em Massachusetts, 13 em Vermont), que provavelmente subestimam o alcance real.
O que o ShinyHunters alega (fonte F, informação 3): o grupo postou em seu site de vazamento em 27 de julho, assumindo a autoria com a frase 'Yes it was us. Now come talk to us.' e fixando prazo de 31 de julho para negociação. Em contato com o BleepingComputer, o grupo afirmou que credenciais foram obtidas via supply chain attack contra um terceiro não identificado, e que esse acesso permitiu pivotar para Jira, GitHub e Azure da EY. O grupo não forneceu amostras de dados, não identificou o fornecedor terceirizado comprometido e não descreveu o volume ou conteúdo do que alega ter exfiltrado.
A sobreposição entre as duas narrativas é real mas incompleta: o ShinyHunters descreve o vetor de acesso (supply chain → ITSM de terceiro) de forma consistente com o que a EY confirmou sobre a plataforma afetada. O timing e o método são coerentes com o playbook documentado do grupo — Microsoft, Mandiant e Google GTIG mapearam em julho de 2026 uma campanha ativa entre meados de 2025 e meados de 2026 em que atores associados ao ShinyHunters exploram OAuth, vishing e supply chain em plataformas SaaS para comprometer ambientes corporativos. O alvo de uma firma das Big Four com acesso a dados fiscais de clientes de grandes instituições financeiras é consistente com o perfil de vítima do grupo.
O que não fecha: a EY não confirmou que o ShinyHunters foi o responsável, nem confirmou os sistemas adicionais (Jira, GitHub, Azure) alegados. Nenhum dado supostamente roubado apareceu em fóruns ou na dark web até 28 de julho. O grupo não entregou prova de posse (proof of life de dados) — ausência que, no histórico do ShinyHunters, não descarta a posse, mas enfraquece a alegação de acesso ampliado. A distância entre 'EY confirmou o incidente de ITSM' e 'ShinyHunters acessou Jira, GitHub e Azure' é grande e não verificável com as fontes disponíveis.
Um detalhe que a imprensa não explorou adequadamente: os indivíduos afetados, segundo os filings, podem não ter relação direta com a EY — seus dados chegaram à plataforma porque são clientes de instituições financeiras que contrataram a EY para serviços tributários. Isso eleva o raio de impacto potencial para além da base de clientes diretos da firma e complica a cadeia de notificação.
Cronologia
- 28 mar 2026Início do acesso não autorizado à plataforma de ITSM terceirizada usada pela EY para suporte a trabalho tributário de clientes. Data confirmada pela EY em notificação ao California AG.
- 12 abr 2026Encerramento da janela de acesso não autorizado, segundo a investigação da EY com firma externa de cibersegurança. Documentos de múltiplos clientes foram baixados durante os 15 dias de acesso.
- 23 abr 2026EY detecta atividade anômala na plataforma de ITSM e aciona procedimento de resposta a incidentes. O acesso já havia cessado 11 dias antes.
- 13 jul 2026EY emite carta de notificação de violação a clientes afetados, descrevendo o incidente e os tipos de dados comprometidos.
- 15 jul 2026EY protocola notificação de violação junto ao California Attorney General. Filing confirma datas do incidente e categorias de dados.
- 16 jul 2026EY protocola notificação junto ao Vermont Attorney General. Filing lista SSNs, códigos de conta financeira e dados de cartão entre os tipos expostos.
- 17 jul 2026Primeira cobertura pública ampla do incidente pela imprensa especializada, com base nos filings regulatórios.
- 27 jul 2026ShinyHunters adiciona a EY ao seu site de vazamento na dark web com a mensagem 'Yes it was us. Now come talk to us.' e prazo final de 31 de julho para negociação, sob ameaça de publicação dos dados.
- 28 jul 2026BleepingComputer confirma contato direto com o ShinyHunters: grupo alega ter obtido credenciais via supply chain attack e acessado Jira, GitHub e Azure da EY. EY não confirma a atribuição nem os sistemas adicionais alegados.
Dados envolvidos
Impacto
O impacto confirmado recai sobre clientes de serviços tributários da EY e, por extensão, sobre clientes finais de instituições financeiras que terceirizaram trabalho fiscal para a firma — pessoas que podem não saber que seus dados transitaram por sistemas da EY. Os tipos de dado expostos (SSN, números de conta, dados de cartão, informações de declarações fiscais) são suficientes para fraude fiscal, abertura de crédito fraudulento e campanhas de phishing altamente direcionadas usando contexto tributário real. A EY oferece 24 meses de monitoramento de identidade e restauração via Experian, com prazo de adesão até 31 de outubro de
2026. O número total de afetados não foi divulgado; os fragmentos estaduais disponíveis são insuficientes para dimensionar o alcance real. Ao menos um escritório de advocacia (Edelson Lechtzin LLP) está investigando ação coletiva.
Elos técnicos
Recomendações
- Clientes da EY que receberam carta de notificação devem ativar um IRS Identity Protection PIN imediatamente — dados fiscais em posse de criminosos são o insumo direto para declarações fraudulentas em nome da vítima.
- Instituições financeiras que terceirizam trabalho tributário para grandes firmas de serviços profissionais devem auditar quais dados de clientes finais transitam por plataformas de ITSM de terceiros — esse é o vetor confirmado neste incidente.
- Equipes de segurança de fornecedores de plataformas ITSM devem revisar controles de acesso a tickets e anexos: tickets de suporte que acumulam documentos fiscais sensíveis como anexos representam concentração de risco desproporcional ao valor operacional do armazenamento.
- Organizações que usam o mesmo perfil de plataforma (ITSM SaaS de terceiro para suporte a trabalho tributário) devem auditar logs de acesso ao ambiente com foco no período de março a abril de 2026, dado que o fornecedor comprometido não foi identificado publicamente.
- Implementar controles de DLP e classificação de dados em plataformas de ticketing para impedir que documentos com SSN, dados de conta ou informações fiscais sejam anexados sem criptografia ponto a ponto ou restrições de acesso por função.
- Monitorar o site de vazamento do ShinyHunters e fóruns como BreachForums para detectar publicação de amostras atribuídas à EY — a aparição de qualquer dado verificável mudaria o veredito de atribuição de 'claimed' para 'confirmed'.
Lacunas de inteligência
O que ainda não sabemos. Um relatório que não declara seus buracos está vendendo, não analisando.
A EY não divulgou o nome da plataforma de ITSM terceirizada comprometida — identificar o fornecedor permitiria avaliar se outros clientes da mesma plataforma foram afetados e verificar se há CVE ou vetor técnico conhecido associado.
O total de indivíduos afetados permanece desconhecido — filings em todos os estados com requisito de notificação resolveriam parcialmente esta lacuna; uma declaração pública da EY com o número total seria definitiva.
O ShinyHunters não forneceu amostras ou prova de posse dos dados — a publicação ou vazamento de qualquer arquivo em fórum verificável confirmaria ou refutaria a atribuição.
O acesso lateral a Jira, GitHub e Azure alegado pelo grupo não foi confirmado nem negado pela EY — a firma poderia, ao menos, declarar se esses sistemas foram auditados como parte da resposta ao incidente.
O vetor técnico de comprometimento da plataforma de ITSM não foi divulgado — saber se foi credential stuffing, vishing, OAuth abuse ou exploração de vulnerabilidade permite avaliar exposição de outras organizações que usam a mesma plataforma.
A cobertura geográfica do incidente é incerta — os filings disponíveis são de estados norte-americanos, mas a EY opera em mais de 150 países; não se sabe se clientes fora dos EUA foram afetados.
Fontes e avaliação
Notação Admiralty (padrão NATO, usado por CERT-EU e OpenCTI): a letra avalia a confiabilidade da FONTE (A completamente confiável a F não avaliada); o número avalia a credibilidade da INFORMAÇÃO (1 confirmada a 6 não julgável). As duas dimensões são avaliadas de forma independente — fonte boa não torna informação frágil confiável.