Um ataque cibernético nem sempre precisa começar com malware, exploração de uma vulnerabilidade ou invasão direta dos servidores de uma empresa.
Às vezes, o criminoso consegue algo potencialmente tão valioso simplesmente convencendo:
uma pessoa ou organização legítima a entregar os dados.
Foi o que aconteceu com a fintech britânica Revolut.
A empresa confirmou em 12 de setembro que informações sensíveis de clientes foram fornecidas a uma parte não autorizada depois que criminosos enviaram:
pedidos fraudulentos de informações que pareciam partir de uma agência governamental legítima.
O detalhe que torna o incidente especialmente preocupante é que as solicitações não chegaram simplesmente de um endereço parecido com o de uma autoridade.
Segundo a Revolut, elas foram enviadas utilizando:
um domínio de e-mail legítimo pertencente a uma agência governamental.
Não há evidência de invasão dos sistemas centrais da Revolut
Essa distinção é fundamental.
O que foi divulgado até agora não indica que criminosos tenham:
invadido a infraestrutura bancária da Revolut;
obtido acesso ao core financeiro;
movimentado dinheiro de clientes;
comprometido diretamente contas por meio de uma vulnerabilidade da plataforma.
A própria empresa afirma que:
seus sistemas e os fundos dos clientes não foram afetados.
O problema aconteceu em outra camada:
o processo utilizado para responder a solicitações oficiais de informações.
Criminosos se passaram por autoridades
Instituições financeiras recebem solicitações de:
polícia;
Justiça;
órgãos reguladores;
autoridades fiscais;
outras entidades governamentais.
Dependendo da legislação e das circunstâncias, bancos e fintechs podem ser obrigados a fornecer determinados registros.
A própria política de privacidade da Revolut prevê compartilhamento de dados com órgãos governamentais quando houver obrigação legal.
Os criminosos exploraram justamente:
a confiança existente nesse processo.
O domínio de e-mail era verdadeiro
Esse é provavelmente o aspecto mais interessante do ataque.
Não se tratava simplesmente de algo como:
policia-governo-falso.com
tentando imitar:
governo.gov.
A Revolut afirma que os pedidos fraudulentos foram enviados a partir de:
um domínio legítimo de uma agência governamental.
Isso sugere que os atacantes conseguiram abusar de uma infraestrutura ou conta associada à própria autoridade.
A Revolut, entretanto, não identificou publicamente:
qual agência governamental estava envolvida.
Também não está claro como os criminosos conseguiram usar esse domínio
Essa é outra questão ainda sem resposta pública.
Pode ter ocorrido:
comprometimento de uma conta;
roubo de credenciais;
abuso de infraestrutura;
outro mecanismo.
Mas não existe informação pública suficiente para afirmar:
qual dessas possibilidades ocorreu.
Portanto, seria prematuro dizer que:
“hackers invadiram uma agência do governo”.
O que está confirmado é que as solicitações fraudulentas chegaram:
por meio de um domínio legítimo de uma agência governamental.
Revolut acreditou que os pedidos eram legítimos
A partir daí, determinadas informações foram:
entregues.
Esse ponto diferencia o incidente de um vazamento tradicional.
Normalmente pensamos em:
atacante → invade servidor → copia banco de dados.
Aqui, a dinâmica foi mais próxima de:
atacante → apresenta-se como autoridade → solicita informações → recebe os dados.
É uma espécie de:
engenharia social institucional.
E os dados envolvidos são extremamente sensíveis
Informações enviadas aos clientes afetados indicam que os registros potencialmente expostos incluem:
data de nascimento;
endereço residencial;
e-mail;
telefone;
documentos de identidade;
passaportes;
carteiras de motorista;
selfies utilizadas na verificação de identidade;
extratos;
IBANs;
registros de saques;
histórico de transações.
Em alguns casos, o histórico financeiro também pode revelar:
transações envolvendo Bitcoin.
Isso significa que senhas foram vazadas?
Até agora:
não há indicação pública disso.
Também não existe confirmação de exposição de:
PIN;
senha da conta;
código de acesso;
chaves privadas de criptomoedas.
A Revolut afirma que:
os fundos dos clientes permanecem seguros.
Isso não reduz a importância do incidente, mas evita transformar o vazamento em algo que não foi confirmado.
Documentos de identidade são particularmente preocupantes
Passaporte.
Carteira de motorista.
Selfie de verificação.
Esses materiais podem ser utilizados em tentativas de:
roubo de identidade;
abertura fraudulenta de contas;
engenharia social;
fraudes financeiras;
criação de documentos falsificados.
E existe outro problema:
eles são difíceis de substituir.
Uma senha pode ser alterada em minutos.
Um documento de identidade possui:
validade;
número;
dados permanentes;
fotografia.
KYC concentra informações valiosas
Instituições financeiras precisam conhecer seus clientes.
Esse processo é chamado:
Know Your Customer — KYC.
Para abrir uma conta, normalmente são solicitados:
nome;
endereço;
data de nascimento;
documento;
fotografia;
informações financeiras.
Isso cria um paradoxo.
As regras de compliance ajudam a combater:
fraude;
lavagem de dinheiro;
financiamento ilícito.
Mas também obrigam instituições a armazenar:
pacotes extremamente completos de identidade.
Para um criminoso, um arquivo KYC pode valer muito mais do que uma simples senha
Uma combinação contendo:
nome;
data de nascimento;
endereço;
telefone;
passaporte;
selfie
pode permitir golpes muito mais sofisticados do que apenas possuir:
um endereço de e-mail.
O criminoso conhece:
quem a vítima é.
O histórico financeiro adiciona outra camada
Se os dados expostos incluem:
extratos
e:
histórico de transações,
o atacante pode aprender:
onde a pessoa compra;
quanto movimenta;
para quem transfere;
quais serviços utiliza;
eventualmente quanto possui.
Isso pode ajudar a selecionar:
vítimas mais interessantes.
Há especulação sobre clientes de alto patrimônio
O investigador on-chain ZachXBT levantou publicamente a hipótese de que o incidente poderia ter sido direcionado a usuários de maior patrimônio.
Mas isso permanece:
uma hipótese externa.
A Revolut não confirmou publicamente que os criminosos tenham selecionado especificamente:
clientes ricos;
investidores;
detentores de Bitcoin.
Portanto, essa possibilidade não deve ser apresentada como:
fato estabelecido.
Transações com Bitcoin aumentam a sensibilidade do vazamento
Existe uma característica particular das criptomoedas.
Blockchains públicas registram:
transações permanentemente.
O desafio para um observador externo geralmente é descobrir:
quem controla determinado endereço.
Se registros de uma instituição financeira conectam:
identidade real
a:
atividade financeira relacionada a criptoativos,
a privacidade do usuário pode ser reduzida significativamente.
Mas isso não significa que bitcoins foram roubados
Novamente, é importante separar:
dados sobre transações
de:
ativos.
Não há indicação de que os criminosos tenham obtido:
seed phrases;
private keys;
controle de carteiras.
A Revolut afirma que:
os fundos não foram afetados.
O problema divulgado é:
exposição de informações.
Quantos clientes foram atingidos?
Essa é uma das principais perguntas sem resposta.
A Revolut descreveu o número como:
“muito limitado”.
Mas não revelou:
100?
1.000?
10.000?
Mais?
Até agora:
não existe número público confirmado.
Portanto, não é correto estimar vítimas com base no tamanho da Revolut
A empresa possui dezenas de milhões de clientes.
Mas isso não significa que:
todos;
milhões;
uma porcentagem específica
tenham sido atingidos.
O incidente parece envolver:
pedidos direcionados de informações.
Isso é muito diferente de alguém copiar:
todo o banco de dados da empresa.
A própria natureza do ataque sugere acesso seletivo
Se o criminoso enviava solicitações fingindo representar uma autoridade, provavelmente precisava especificar:
pessoas;
contas;
registros
sobre os quais queria informações.
Isso pode ajudar a explicar por que a empresa descreve o universo afetado como:
limitado.
Mas sem a divulgação do número:
não é possível medir a dimensão real.
Revolut bloqueou o endereço utilizado
Depois de detectar a fraude, a empresa informou que:
bloqueou imediatamente o endereço.
Também notificou:
a agência governamental envolvida;
autoridades policiais;
autoridades de proteção de dados;
reguladores financeiros.
A empresa afirma ainda ter implementado:
medidas adicionais de segurança.
Mas o incidente levanta uma pergunta maior
Como uma instituição deveria verificar se:
um pedido governamental é realmente governamental?
Confiar apenas no endereço de e-mail não parece mais suficiente.
Porque se a conta legítima de uma autoridade for comprometida:
SPF;
DKIM;
DMARC;
domínio correto;
certificado
podem não resolver o problema.
O e-mail pode ser:
tecnicamente legítimo.
A pessoa que está utilizando a conta:
não.
É o equivalente digital de um criminoso entrar usando um crachá verdadeiro
Imagine alguém chegando a uma empresa.
O crachá:
é verdadeiro.
A porta reconhece:
o crachá.
O sistema libera:
a entrada.
O problema é que:
quem está segurando o crachá não é a pessoa autorizada.
Essa parece ser a essência do incidente envolvendo a Revolut.
Autenticidade da mensagem não é autenticidade da intenção
Essa distinção está se tornando cada vez mais importante.
Um e-mail pode realmente vir de:
@governo.xxx.
Isso prova que:
a infraestrutura enviou a mensagem.
Não necessariamente prova que:
o pedido é legítimo.
Solicitações sensíveis precisam de validação fora do próprio canal
Uma estratégia defensiva é utilizar:
out-of-band verification.
Em vez de responder apenas ao e-mail:
a instituição consulta diretamente o órgão;
utiliza contato previamente cadastrado;
confirma número do processo;
valida ordem judicial;
verifica protocolo;
confirma autoridade solicitante.
Ou seja:
o pedido precisa ser autenticado por mais de um sinal.
Esse conceito já existe em fraude financeira
Se um diretor envia um e-mail dizendo:
“Transfira R$ 2 milhões agora”,
empresas maduras não deveriam simplesmente:
transferir.
Elas confirmam por:
telefone;
sistema interno;
dupla aprovação.
É o mesmo princípio.
Pedidos governamentais de dados extremamente sensíveis deveriam possuir:
controles igualmente robustos.
O ataque lembra Business Email Compromise, mas com uma diferença
No chamado:
BEC — Business Email Compromise,
criminosos comprometem ou imitam contas corporativas para convencer funcionários a:
transferir dinheiro;
alterar conta bancária;
pagar boleto;
enviar informação.
No caso da Revolut, a lógica é semelhante.
Mas a identidade explorada não era:
CEO;
fornecedor;
diretor financeiro.
Era:
uma autoridade governamental.
Poderíamos chamar isso de Government Email Compromise
O princípio é o mesmo:
comprometer um canal confiável;
explorar autoridade;
obter uma ação legítima da vítima.
O funcionário não precisa clicar em:
malware.
Não precisa executar:
arquivo.
Não precisa entregar:
senha.
Ele simplesmente:
cumpre aquilo que acredita ser uma solicitação oficial.
Isso torna ataques desse tipo difíceis de detectar
Imagine receber dezenas de solicitações legítimas todos os meses.
Então chega outra:
mesmo domínio;
mesma aparência;
mesmo tipo de linguagem;
mesma categoria de pedido.
Para o funcionário:
parece rotina.
É justamente isso que torna engenharia social tão eficiente.
A segurança precisa proteger processos, não apenas computadores
Empresas gastam bilhões com:
firewalls;
EDR;
antivírus;
SIEM;
zero trust.
Tudo isso é importante.
Mas nenhum firewall consegue impedir um funcionário autorizado de:
enviar voluntariamente dados para alguém que acredita ser uma autoridade legítima.
O problema passa a ser:
processual.
É necessário Zero Trust também para solicitações
Zero Trust costuma ser resumido como:
never trust, always verify.
A mesma lógica deveria valer para:
e-mails;
ordens;
pedidos;
autoridades.
O fato de uma mensagem vir de um ambiente aparentemente confiável não deveria automaticamente liberar:
dados extremamente sensíveis.
O incidente também mostra o valor de dados financeiros
Criminosos não precisam necessariamente:
roubar dinheiro imediatamente.
Informação financeira pode ser monetizada posteriormente.
Pode alimentar:
phishing;
extorsão;
roubo de identidade;
SIM swapping;
golpes direcionados;
engenharia social.
Imagine um golpe após esse vazamento
O criminoso conhece:
nome;
telefone;
endereço;
documento;
transações;
instituição financeira.
Então liga:
“Olá, somos da Revolut. Detectamos uma transação suspeita de € 4.200.”
A vítima pensa:
como ele sabe que eu uso Revolut?
Depois o criminoso cita:
endereço;
últimos dígitos;
uma transação real.
De repente:
o golpe parece verdadeiro.
É assim que um vazamento pode virar um segundo ataque
O primeiro ataque rouba:
informação.
O segundo utiliza essa informação para roubar:
dinheiro.
É por isso que clientes afetados precisam prestar atenção especialmente a:
phishing;
ligações;
SMS;
mensagens;
pedidos de autenticação.
Criminosos podem até se passar pela própria Revolut falando sobre o vazamento
Esse é um padrão comum.
Depois de um incidente público, aparecem mensagens como:
“Precisamos confirmar sua conta devido ao vazamento.”
Ou:
“Clique aqui para proteger seus fundos.”
A notícia verdadeira vira:
isca para um novo golpe.
A empresa não precisa pedir senha para proteger a conta
Usuários devem desconfiar de qualquer contato solicitando:
senha;
PIN;
código OTP;
aprovação de login;
transferência;
seed phrase;
instalação de aplicativo.
Especialmente se a mensagem usar:
urgência.
O caso é diferente do ataque sofrido pela Revolut em 2022
A fintech já havia enfrentado outro incidente relevante.
Em setembro de 2022, um ataque altamente direcionado permitiu que criminosos acessassem dados de uma pequena parcela dos clientes.
Na época, a Revolut informou que aproximadamente:
0,16% de seus clientes
haviam sido afetados, o que representava dezenas de milhares de usuários.
O episódio atual é:
um incidente separado.
Desta vez, a engenharia social atingiu o processo de compliance
Essa é a característica mais importante.
A Revolut não está relatando simplesmente:
“nossos servidores foram hackeados”.
Está dizendo essencialmente:
recebemos pedidos fraudulentos que pareciam oficiais e entregamos informações.
Isso transforma o caso em um alerta para:
bancos;
fintechs;
operadoras;
provedores de nuvem;
redes sociais;
empresas de tecnologia.
Todas essas empresas recebem solicitações governamentais
Google.
Meta.
Microsoft.
Apple.
Operadoras.
Bancos.
Fintechs.
Provedores.
Todas podem receber solicitações legais para:
identificar usuários;
preservar dados;
fornecer registros;
entregar informações.
Se criminosos conseguem comprometer:
a identidade digital de uma autoridade,
essa infraestrutura pode virar uma ferramenta para:
roubo de dados.
E isso pode ser mais eficiente do que hackear a empresa diretamente
Imagine tentar invadir uma fintech global.
Existem:
SOC;
MFA;
EDR;
segmentação;
monitoramento;
equipes de segurança.
Agora imagine enviar:
um pedido aparentemente legítimo de uma autoridade.
Se o processo de verificação falhar:
a própria empresa pesquisa os dados;
a própria empresa organiza os arquivos;
a própria empresa entrega.
Do ponto de vista do criminoso:
é muito mais fácil.
O ataque transforma confiança institucional em superfície de ataque
Durante anos, segurança cibernética concentrou-se em:
máquinas;
redes;
software.
Agora existe outro elemento:
confiança.
Confiança em:
fornecedor;
funcionário;
autoridade;
e-mail;
identidade.
Criminosos estão aprendendo a atacar:
essas relações.
O caso Revolut deixa três certezas e várias perguntas
Sabemos que:
solicitações fraudulentas foram enviadas usando domínio legítimo de uma agência governamental;
informações de clientes foram entregues a uma parte não autorizada;
a Revolut afirma que seus sistemas e fundos não foram afetados.
Ainda não sabemos:
qual agência foi utilizada;
como o acesso ao domínio foi obtido;
quantas solicitações foram feitas;
quantos clientes foram atingidos;
qual o volume total de dados entregue;
quem está por trás da operação;
qual será o uso final das informações.
É justamente por isso que o incidente precisa ser acompanhado sem transformar:
lacunas em certezas.
Mas o que já está confirmado é suficiente para revelar uma mudança importante no cenário de ameaças.
O criminoso não precisou necessariamente:
quebrar o cofre digital da Revolut.
Ele convenceu quem estava do lado de dentro:
a abrir a gaveta e entregar os documentos.
