Em 12 de setembro de 2026, a fintech Revolut confirmou o que descreveu como um golpe sofisticado de personificação externa: uma parte não autorizada usou um e-mail no domínio legítimo de um órgão governamental para enviar solicitações fraudulentas de informações de clientes. As solicitações foram atendidas antes que o esquema fosse detectado.

O que torna este incidente digno da sua atenção é que ele não contém nenhuma invasão no sentido usual. Nenhuma vulnerabilidade de software, nenhuma senha vazada, nenhum malware. A própria Revolut afirmou que seus sistemas e os fundos dos clientes não foram afetados. Alguém pediu os dados da forma correta, pelo canal correto, e os recebeu. É exatamente por isso que isso importa para toda empresa que guarda registros de clientes, e não apenas para os bancos.

O que está de fato confirmado

Nós nos limitamos ao que a empresa anunciou e ao que veículos especializados relataram, porque a investigação está em andamento e muita coisa ainda não foi divulgada:

  • O método: e-mail enviado de uma conta não autorizada dentro de um domínio pertencente a um órgão governamental real, com a aparência de uma solicitação oficial de informações.
  • Os dados: dados de identidade e de contato, incluindo data de nascimento, endereço postal, endereço de e-mail e número de telefone, além de cópias de documentos de identidade, como passaportes e carteiras de motorista, junto com as imagens de verificação facial coletadas durante as verificações de "conheça seu cliente" (KYC).
  • A escala: a empresa falou em um número limitado de clientes e não divulgou nenhum número.
  • O órgão: a Revolut se recusou a nomear o órgão governamental cujo domínio foi usado, citando a investigação em andamento.
  • A resposta: o endereço foi bloqueado, os clientes afetados foram notificados diretamente e a empresa alertou o órgão governamental pertinente, as autoridades policiais, os reguladores financeiros e as autoridades de proteção de dados.

Um pesquisador de segurança cripto conhecido como ZachXBT avaliou que o alvo pareciam ser clientes de alto patrimônio, o que sugere a montagem de perfis detalhados, e não uma coleta indiscriminada. Trata-se da avaliação de um pesquisador, não de uma declaração da empresa, e a citamos como tal.

Por que a solicitação funcionou: autenticação não é autorização

A maioria dos sistemas de e-mail corporativo depende de verificações técnicas que confirmam que uma mensagem realmente se originou no domínio que alega. Essas verificações funcionam bem contra a falsificação comum: quem se passa por um domínio que não controla é rejeitado. Mas elas foram criadas para responder a exatamente uma pergunta: esta mensagem saiu daquele domínio?

Essa não é a pergunta que você precisa responder. A sua pergunta é se a pessoa que escreveu a mensagem está autorizada a pedir o que está pedindo. Nenhuma verificação de e-mail responde a isso. A distância entre as duas perguntas é a distância entre autenticação e autorização, e é a brecha pela qual toda esta operação passou. Quando a conta remetente está dentro do domínio genuíno, seja comprometida ou provisionada indevidamente, todos os indicadores de confiança que sua equipe consegue ver estarão verdes.

A consequência prática: o trabalho do seu gateway de e-mail termina ao entregar a solicitação intacta. Julgar a solicitação é trabalho humano, e exige um procedimento escrito em vez do instinto individual.

Sua empresa recebe a mesma solicitação de forma mais simples

É fácil arquivar isso como uma história distante de uma fintech europeia. Mas as solicitações que chegam todos os dias às empresas sauditas são a mesma coisa com roupas mais simples: um e-mail pedindo o extrato de um cliente, uma mensagem solicitando dados de funcionários para fins regulatórios, uma ligação pedindo que você confirme detalhes de um contrato, uma correspondência de um endereço com um nome oficial conhecido pedindo documentos para concluir um procedimento.

Na maioria das pequenas e médias empresas, essa solicitação é tratada assim: chega a um funcionário, o remetente parece oficial, recusar um órgão oficial parece mais arriscado do que atender, e o arquivo é enviado. Não há registro de quem pediu, do que foi enviado nem de quando. Não existe nenhuma etapa de verificação independente. Quando o problema aparece mais tarde, a empresa não tem nada com que reconstruir os fatos.

Observe também a pressão aplicada. Urgência e autoridade oficial juntas são o que desativa a verificação. Um funcionário que teme ser culpado por atrapalhar um procedimento do governo vai pular a ligação de confirmação, e esse é o efeito planejado da abordagem, não um efeito colateral.

O que a lei saudita exige de você

A Lei de Proteção de Dados Pessoais (PDPL) não deixa isso em aberto. Ela impõe uma dupla obrigação à sua empresa: divulgar apenas quando permitido e comunicar quando errar.

  • O artigo 15 estabelece os casos em que dados pessoais podem ser divulgados, inclusive quando a parte solicitante é uma entidade pública e a solicitação atende a uma finalidade de segurança, aplica outra lei ou cumpre exigências judiciais, conforme especificado no regulamento.
  • O artigo 16 rege os casos em que a divulgação deve ser negada, inclusive quando afetaria a segurança nacional, colocaria em risco a segurança de pessoas ou interferiria em uma investigação em andamento.
  • O artigo 20 obriga o controlador a notificar a autoridade competente e os titulares dos dados sobre uma violação ou divulgação ilícita. O regulamento de aplicação fixa um prazo de 72 horas para notificar a autoridade competente pela Plataforma Nacional de Governança de Dados.

Lendo os três juntos, surge o ponto decisivo: a lei concede o direito à entidade pública, não ao e-mail. Uma solicitação que chega do domínio de uma entidade pública não se torna, por isso, uma solicitação dela. O dever legal de verificar continua sendo seu, como controlador dos dados, e não é transferido a um remetente só porque ele parecia oficial.

A visão da Origami

A Origami é uma empresa de tecnologia que desenvolve sistemas para empresas sauditas, e um padrão que vemos repetidamente é que quase todo o investimento em segurança vai para impedir a entrada não autorizada: senhas, autenticação de dois fatores, firewalls. Isso é necessário, mas protege uma única porta. O incidente de que estamos falando nunca entrou pela porta. Ele bateu, pediu os dados e os recebeu. Nenhuma configuração técnica impede que um funcionário autorizado envie um arquivo a alguém que o pediu de uma forma que parecia correta.

Por isso tratamos a saída de dados da empresa como um procedimento embutido no sistema, e não como uma orientação escrita em um manual: quem tem permissão para exportar dados de clientes, se cada exportação é registrada com quem a fez, quando e por quê, e se as solicitações de terceiros seguem um fluxo de aprovação. Uma empresa que consegue responder em um minuto quais dados saíram daqui no mês passado e por quê tem com o que se defender. Uma empresa que não consegue vai descobrir a brecha no dia em que precisar da resposta.

Um procedimento de uma página para adotar nesta semana

Isso não exige projeto nem orçamento. Exige uma regra escrita e divulgada que proteja seu funcionário de ter que decidir sozinho e sob pressão:

  • Nenhum dado de cliente ou funcionário sai com base apenas em uma mensagem recebida. A mensagem abre a solicitação; ela não a executa, por mais oficial que o remetente pareça e por mais urgente que seja o tom.
  • Verifique por um canal independente. Não responda à mensagem e não ligue para um número escrito dentro dela. Ligue para o número publicado no site oficial da entidade. Esse único passo teria impedido toda esta operação.
  • Um aprovador designado. Uma pessoa autorizada a liberar dados para uma parte externa, com um substituto designado para as ausências. Espalhar a permissão entre todos significa que ninguém responde por ela.
  • Um registro escrito de cada solicitação. Quem pediu, em que qualidade, quais dados, quem aprovou, como foi verificado e a data. Uma linha em uma planilha basta, e o valor dela aparece um ano depois, e não hoje.
  • Envie o mínimo. Se a solicitação for legítima, envie exatamente o que foi pedido, não o arquivo inteiro nem a tabela toda. O volume que você envia é o tamanho do dano se a solicitação se revelar fraudulenta.
  • Conheça o caminho de notificação antes de precisar dele. Quem notifica a Autoridade Saudita de Dados e Inteligência Artificial (SDAIA) em até 72 horas, por qual plataforma e com quais detalhes. O tempo gasto procurando o procedimento sai direto do prazo.

O princípio por trás de tudo isso é que verificar não é obstruir. Um órgão oficial genuíno não vai se opor a uma ligação de confirmação feita para o seu próprio número publicado, e quem se opõe a ser verificado é exatamente quem deve ser verificado. Coloque isso por escrito para sua equipe, para que recusar uma solicitação nunca seja um risco pessoal que um único funcionário tenha que carregar sozinho.

Fontes