Uma empresa pode ter sistemas protegidos e, ainda assim, sofrer uma violação se alguém confiar numa solicitação fraudulenta. O caso Revolut mostra como a engenharia social pode transformar uma comunicação aparentemente legítima numa fuga de informação.
O incidente não começou com um atacante a invadir uma aplicação ou a implementar ransomware. O ponto crítico foi a confiança depositada numa solicitação que parecia provir de uma autoridade legítima.
O que aconteceu no caso Revolut?
Em setembro de 2026, a Revolut confirmou que um terceiro não autorizado conseguiu que funcionários entregassem informações sensíveis de clientes através de solicitações fraudulentas que aparentavam provir de um domínio governamental legítimo. A empresa indicou que os seus sistemas e os fundos dos clientes não foram afetados.
As informações publicadas posteriormente indicam que os dados potencialmente afetados incluíam documentos de identificação, fotografias de verificação, informações pessoais e registos de transações. O Financial Times informou que cerca de 680 clientes foram afetados, embora a Revolut tenha utilizado a expressão "número limitado" e não tenha confirmado publicamente esse número.
O caso ganhou uma nova dimensão quando o grupo que se identifica como iamnotavillain publicou uma exigência de aproximadamente 3 milhões de dólares em Monero e ameaçou vender os dados. A Revolut, no entanto, declarou que não tinha recebido uma comunicação direta do grupo.
A distinção é importante: o incidente confirmado é uma violação de dados provocada através de usurpação de identidade e engenharia social, não um ransomware tradicional que tenha cifrado os sistemas da Revolut.
O problema: uma identidade legítima não garante uma solicitação legítima
O caso permite extrair uma lição que vai além da Revolut.
Um sistema de correio eletrónico pode verificar se uma mensagem provém realmente de um determinado domínio. Isso não significa que a pessoa que utiliza essa conta tenha autoridade para solicitar determinadas informações.
Por outras palavras:
Autenticação não é o mesmo que autorização.
Um endereço legítimo pode ter sido comprometido. Uma conta real pode estar a ser utilizada por um atacante. E um pedido tecnicamente autêntico pode ser operacionalmente fraudulento.
Por isso, as organizações precisam de procedimentos que permitam verificar não só quem solicita algo, mas também se está autorizado para solicitá-lo e se o pedido faz sentido nesse contexto.
Esta lógica coincide com os princípios de Zero Trust, onde nenhuma solicitação deve ser considerada confiável automaticamente e o acesso deve ser avaliado com base na identidade, contexto e autorização.
Engenharia social: atacar a pessoa em vez do sistema
A engenharia social utiliza manipulação, urgência, autoridade ou confiança para levar uma pessoa a revelar informações, conceder acesso ou realizar uma ação.
Nem sempre precisa de um link malicioso.
Pode adotar diferentes formas:
- Phishing: mensagens concebidas para induzir o utilizador a clicar, introduzir credenciais ou fornecer informações.
- Spear phishing: ataques personalizados dirigidos a uma pessoa específica.
- Vishing: chamadas telefónicas nas quais o atacante se faz passar por suporte, um banco, um fornecedor ou um responsável da empresa.
- Smishing: enganos através de SMS ou mensagens instantâneas.
- Fraude do CEO: usurpação de identidade de um executivo para solicitar uma ação urgente ou confidencial.
- Falso fornecedor: solicitação fraudulenta de alteração de conta bancária.
- Pretexting: criação de uma história ou contexto falso para justificar uma solicitação. O caso Revolut encaixa-se especialmente nesta categoria.
O denominador comum é sempre o mesmo: fazer com que uma pessoa faça algo que não faria se conhecesse a verdadeira identidade ou intenção do interlocutor.
Por que os controles técnicos não são suficientes
Um firewall pode bloquear uma conexão maliciosa. Um sistema de autenticação pode impedir o acesso com credenciais incorretas. Uma solução de proteção de e-mail pode identificar determinados padrões suspeitos.
Mas nenhum desses controles substitui uma decisão humana diante de um pedido que parece legítimo.
Por isso, uma estratégia de cultura de cibersegurança deve preparar os colaboradores para reconhecer situações em que a urgência, a autoridade aparente ou a pressão podem ser utilizadas para contornar os procedimentos.
A formação também não deveria limitar-se a explicar o que é um phishing.
Um programa eficaz deve treinar comportamentos concretos:
- verificar o remetente e o contexto;
- desconfiar de solicitações inusualmente urgentes;
- verificar pedidos sensíveis através de um segundo canal;
- não utilizar os dados de contato fornecidos pelo próprio solicitante para realizar essa verificação;
- escalar solicitações excepcionais ao responsável correspondente;
- evitar entregar informações sensíveis apenas porque o pedido parece proceder de uma organização conhecida.
A engenharia social também pode simular situações reais
Uma apresentação teórica pode explicar que não se devem abrir links suspeitos. O problema é que muitos ataques atuais não têm esse aspecto.
Uma solicitação pode utilizar o nome de uma autoridade, um fornecedor conhecido, um colega ou um diretor. Também pode aproveitar informações públicas da organização para construir um cenário credível.
Por isso, as simulações de phishing permitem transformar a formação numa prova prática.
As simulações permitem observar como a equipa responde realmente a situações controladas e utilizar o resultado para reforçar os comportamentos que necessitam de maior atenção.
A Guardey combina simulações com formação contínua e desafios breves de consciencialização. O objetivo não é penalizar o colaborador que comete um erro, mas transformar esse momento numa oportunidade de aprendizagem e reforçar hábitos seguros.
Do phishing tradicional à engenharia social avançada
O caso Revolut também levanta uma evolução importante.
A pergunta já não deveria ser apenas:
"O colaborador sabe reconhecer um e-mail de phishing?"
Também deveria ser:
"O colaborador sabe questionar um pedido que parece legítimo?"
Uma organização madura precisa de preparar as suas equipas para cenários como:
A chave é transformar a segurança num comportamento repetido, e não numa informação que o colaborador recebe uma vez por ano.
Como reduzir o risco de engenharia social
A prevenção requer várias camadas.
1. Estabelecer procedimentos de verificação
Os pedidos excecionais de dados, pagamentos ou alterações de configuração devem contar com um procedimento independente de validação.
2. Aplicar o princípio do privilégio mínimo
Nem todas as pessoas precisam de permissão para acessar, modificar ou entregar as mesmas informações.
3. Utilizar autenticação resistente a phishing
A autenticação multifator reduz determinados riscos de roubo de credenciais, embora não substitua a verificação de uma solicitação nem proteja, por si só, contra todos os cenários de engenharia social.
4. Treinar de forma contínua
A conscientização deve incluir exercícios práticos e cenários que reproduzam situações reais da organização.
5. Medir o comportamento
Os responsáveis pela segurança precisam saber quais tipos de engano geram mais erros e quais áreas requerem reforço.
A combinação de tecnologia, processos e treinamento permite reduzir a dependência de uma única barreira.
A lição da Revolut para qualquer empresa
O caso Revolut deixa uma conclusão especialmente relevante para os responsáveis de TI e cibersegurança:
Não é preciso invadir um sistema para provocar uma brecha.
Se uma organização possui informações sensíveis, também deve proteger os processos que permitem solicitá-las, acessá-las e compartilhá-las.
Um domínio legítimo não prova que uma solicitação seja legítima. Uma identidade autenticada não prova que exista autorização. E uma pessoa bem-intencionada pode se tornar, sem saber, o mecanismo que permite concretizar um ataque.
A engenharia social exige, portanto, uma defesa que combine cultura de cibersegurança, simulações práticas e controles técnicos baseados em princípios de Zero Trust.
O objetivo não é fazer com que os funcionários desconfiem de tudo. É fazer com que saibam quando devem verificar antes de agir.
{{fs-button}}