Uma falha que o registo do DORA não explica

O que a RingCentral confirmou de facto

O próprio boletim de segurança da RingCentral no seu Trust Center, datado de 28 de julho de 2026 e classificado com gravidade ALTA, refere que a empresa "descobriu recentemente que era alvo de uma campanha sofisticada de engenharia social" e que "tomou de imediato medidas para travar a atividade não autorizada" com o apoio de uma empresa forense externa. O boletim acrescenta: "este incidente afetou dados de uma parte limitada dos clientes da RingCentral, e estamos a comunicar diretamente com os clientes afetados. Se não foi contactado pela RingCentral, não está afetado."

O grupo de extorsão ShinyHunters já tinha reivindicado o ataque um dia antes, a 27 de julho de 2026, afirmando ter roubado 623 GB de dados, e publicou depois um arquivo de 280 GB depois de a RingCentral se ter recusado a pagar. O Have I Been Pwned processou esse arquivo e acrescentou-o à sua base de dados a 13 de agosto de 2026: cerca de 1,6 milhões de endereços de email únicos, além de nomes, números de telefone e moradas físicas. A RingCentral foi explícita ao afirmar que a falha não chegou ao RingEX, ao RingCentral Contact Center, ao RingCX nem a qualquer outro serviço principal, que, segundo a empresa, "continuam a funcionar sem interrupções."

Um padrão nos fornecedores, não nas vítimas

Ao longo de 2026, o ShinyHunters repetiu o mesmo guião contra um fornecedor de SaaS atrás do outro: instâncias de clientes da Salesforce, dados de clientes alojados na Snowflake e implementações da Oracle PeopleSoft, com o próprio grupo a estimar o total acumulado das suas campanhas em mais de 1,5 mil milhões de registos. A RingCentral é o nome mais recente dessa lista, e o método que a própria empresa descreve, uma pessoa convencida a ceder acesso, em vez de uma falha que um atacante tivesse de encontrar, encaixa numa tendência mais ampla de 2026: campanhas de vishing e engenharia social bem-sucedidas contra colaboradores com acesso privilegiado junto do fornecedor, não do cliente.

Essa distinção importa para quem avalia a RingCentral como fornecedor. Um cliente pode corrigir o seu próprio software e substituir as suas próprias credenciais, mas não tem forma de testar, nem sequer de ver, quão bem a equipa de apoio e administração de um fornecedor resiste a uma chamada convincente. O alvo aqui foi a equipa da RingCentral, não o seu código.

O vazio no registo de risco de fornecedores

As entidades financeiras abrangidas pelo regulamento europeu de resiliência operacional digital devem, nos termos dos artigos 28 a 30 do DORA, manter um registo de informação sobre cada fornecedor de TIC e avaliar o risco que cada um representa para a sua própria resiliência. As entidades essenciais e importantes ao abrigo da diretiva NIS2 têm uma obrigação paralela, no artigo 21, de gerir o risco de cibersegurança da cadeia de fornecimento, incluindo as práticas de segurança dos seus fornecedores diretos. Ambos os quadros pressupõem que a entidade regulada consiga obter de um fornecedor detalhe suficiente para avaliar de facto o seu risco.

O boletim da RingCentral não indica a função do colaborador envolvido, o sistema interno a que o atacante teve acesso, nem qual controlo, autenticação multifator, verificação por chamada de retorno, verificação de identidade no apoio ao cliente, falhou para que uma chamada telefónica se tornasse numa falha. Um banco alemão, um grupo hospitalar neerlandês ou uma seguradora britânica que liste a RingCentral no seu registo de fornecedores de TIC não tem nada de concreto para acrescentar a essa entrada, além de que ocorreu um incidente. O questionário habitual de segurança de fornecedores, um atestado SOC 2, um certificado de encriptação de dados em repouso, um resumo de teste de intrusão, avalia exatamente os controlos técnicos que nunca estiveram em causa num incidente que começou e terminou numa conversa.

O que um operador deveria mesmo mudar

A solução prática não é mais um documento sobre encriptação. Os operadores que dependem da RingCentral, ou de qualquer outro fornecedor de UCaaS ou CCaaS que sirva clientes regulados, deveriam perguntar diretamente ao fornecedor se este realiza os seus próprios testes simulados de engenharia social contra a equipa de apoio e administração, e tratar a resposta, ou a recusa em responder, como uma entrada de pleno direito no seu próprio registo de risco.

As renovações de contrato após esta divulgação são o momento certo para acrescentar uma cláusula concreta: o direito a uma análise técnica pós-incidente, não a uma declaração de marketing, dentro de um prazo fixo após qualquer incidente confirmado. Sem essa cláusula, o próximo aviso de falha de um fornecedor vai soar exatamente como este, completo e conforme no papel, mas inútil para o único documento, o registo de risco, que a regulação exige de facto que um operador mantenha atualizado.

Leia a seguir: 45.601 falhas e só 171 estão a ser usadas  |  Uma mensagem alcançou as chaves SSH