O Grupo de Inteligência de Ameaças do Google (GTIG) publicou nesta semana um relatório rastreando três grupos de invasão com suposto nexo russo em campanhas de espionagem contra acadêmicos, diplomatas, profissionais da indústria de defesa e equipes de centros de estudo na Europa, Ucrânia e Estados Unidos. O relatório vale a leitura completa, mas o detalhe que mais importa para quem administra um programa DMARC não é a atribuição. É o quão pouco a autenticação de e-mail tem a ver com tudo isso.
Três grupos, uma mesma ideia central
O Google identifica esses grupos como UNC6293 (um suposto subgrupo do coletivo conhecido como APT29 ou ICE RELIC), UNC7005 (também rastreado pela Microsoft como Storm-2945) e UNC5976. Cada um mira uma população ligeiramente diferente, de acadêmicos e diplomatas nos Estados Unidos e na Europa a organizações de defesa e aeroespaciais na Ucrânia e na Armênia, mas todos compartilham um mesmo princípio operacional: em vez de lutar contra o DMARC, o SPF e o DKIM para falsificar o próprio domínio do alvo, eles encaminham todo o ataque por fluxos de autenticação que são completamente genuínos do lado de quem recebe.
O UNC6293 pede aos alvos que gerem uma senha de aplicativo, um recurso legado do Google pensado para dispositivos antigos que não suportam o login completo, e que a entreguem. Uma senha de aplicativo evita a autenticação em duas etapas por design, então assim que um atacante tem uma, o MFA deixa de fazer parte da equação. Versões posteriores da campanha passaram a pedir que os alvos digitassem um “código de verificação” OAuth em um site de phishing, pulando a etapa de compartilhar a senha mas chegando ao mesmo resultado: um token roubado por meio de uma troca de autenticação completamente legítima.
O UNC7005 opera a gama mais ampla de técnicas. Registrou domínios que falsificavam o Finnish Operations Center, uma organização de apoio à indústria de defesa ligada a trabalhos próximos à OTAN, e enviou e-mails de phishing a partir desses domínios para contratados de defesa europeus entre 6 e 13 de agosto. As vítimas que clicavam eram direcionadas a um projeto do Google Cloud controlado pelo atacante e em “modo de teste”, suficiente para completar um fluxo de consentimento OAuth e roubar o token resultante sem nunca precisar exibir uma página de login falsa. O mesmo grupo executa phishing de código de dispositivo da Microsoft contra participantes de eventos, usando uma página de destino que analisa o tamanho da tela, o fuso horário, o número de núcleos de CPU e as características do navegador do visitante especificamente para detectar e evitar a análise automatizada de segurança antes de exibir um código de dispositivo real da Microsoft.
O detalhe do WhatsApp
A técnica mais chamativa do relatório mira o WhatsApp. O UNC7005 criou páginas de phishing com tema de chamadas seguras e compartilhamento de documentos, e as usou para iniciar uma solicitação genuína de vinculação de dispositivo do WhatsApp e exibir o código QR ou o código de vinculação real na página. Um alvo que o escaneia acaba de autorizar um dispositivo controlado pelo atacante a acessar sua própria conta do WhatsApp, usando o recurso real de vinculação do WhatsApp exatamente como foi projetado.
A partir daí, as vítimas veem uma tela falsa de chamada recebida. Aceitá-la aciona JavaScript que chama diretamente as APIs de câmera e microfone do navegador, grava o sinal e o envia para a infraestrutura do atacante. Nada disso toca um servidor de e-mail, um registro DNS ou uma tag de autenticação. É uma página de phishing abusando de uma API do navegador e do próprio recurso de vinculação de um aplicativo de mensagens, encadeada depois que um e-mail convenceu alguém a clicar em um link.
Por que isso fica fora do trabalho do DMARC
O DMARC existe para responder a uma única pergunta: essa mensagem realmente veio de um servidor de e-mail autorizado pelo proprietário do domínio? Ele cumpre bem essa função, e aplicá-lo de forma rígida impede uma enorme parcela da falsificação de domínios. Mas nenhum desses três grupos precisa falsificar o próprio domínio do alvo para ter sucesso. Os e-mails do Finnish Operations Center do UNC7005 vêm de domínios parecidos recém-registrados que o atacante controla totalmente, então é claro que passam em suas próprias verificações de SPF, DKIM e DMARC. Um domínio registrado pelo atacante há uma semana passar no DMARC não diz absolutamente nada ao destinatário sobre sua confiabilidade.
Mais importante ainda: assim que o alvo clica, o restante do ataque nunca mais toca no e-mail. Uma tela de consentimento OAuth, uma solicitação de código de dispositivo da Microsoft e um pedido de vinculação do WhatsApp são todas interações autenticadas entre a vítima e a plataforma real, exatamente como essas plataformas foram projetadas para funcionar em uso legítimo. O relatório do Google é direto: essas operações “abusam de fluxos de autenticação legítimos que podem não parecer, de imediato, tentativas de phishing para os usuários”, e as contas atacadas costumam ser pessoais, não contas corporativas vinculadas a um domínio, o que deixa as equipes de segurança sem nenhuma visibilidade organizacional sobre o comprometimento.
O que isso significa para o seu programa
Aplicar o DMARC no seu próprio domínio não faz nada para impedir que sua equipe seja vítima de phishing por meio do domínio parecido de outra pessoa. Essas campanhas falsificam organizações externas, organizadores de eventos e agências de apoio, não o empregador do alvo. Sua política DMARC protege o canal de e-mail da sua marca. Ela não tem nenhuma jurisdição sobre um domínio registrado na semana passada para se passar por um fórum de defesa.
Trate solicitações não solicitadas de senha de aplicativo como um incidente, não como um chamado de suporte. Senhas de aplicativo evitam o MFA por design. A própria orientação do Google diz que a maioria dos usuários nunca precisa criar uma. Se uma mensagem pede que um usuário gere e compartilhe uma senha de aplicativo, bloqueie imediatamente a divulgação dessa instrução e investigue.
Estenda seu hábito de verificação fora de banda para além do e-mail, cobrindo todo fluxo de vinculação ou consentimento. Uma tela OAuth genuína, um código de dispositivo genuíno e um código QR do WhatsApp genuíno parecem genuínos porque são. A única verificação confiável é confirmar, por um canal separado, que a pessoa ou organização que solicita a vinculação realmente enviou aquela solicitação.
Audite os dispositivos vinculados em aplicativos de mensagens da mesma forma que audita as permissões de aplicativos OAuth. A maioria dos usuários nunca abriu a tela de dispositivos vinculados do WhatsApp. Um lembrete periódico para verificá-la, junto com auditorias rotineiras de consentimento OAuth no seu provedor de identidade, fecha uma lacuna que a filtragem de e-mail nunca foi projetada para cobrir.
A conclusão
DMARC, SPF e DKIM continuam essenciais, e nada disso muda aqui. O que muda é o lembrete de que um atacante bem financiado e paciente simplesmente vai contornar as partes da sua defesa que funcionam. Esses três grupos não falham nas verificações de DMARC porque nunca se colocam em uma posição em que o DMARC tenha voto. O e-mail é só a porta. Uma vez aberta, o restante da operação roda inteiramente sobre infraestrutura legítima que os protocolos de autenticação nunca foram projetados para fiscalizar.
A Excello Mail ajuda você a aplicar corretamente o DMARC, o SPF e o DKIM nos domínios que você controla, para que o canal de e-mail que os atacantes realmente conseguem falsificar fique bloqueado enquanto sua equipe aprende a identificar os fluxos de autenticação que ficam fora dele. Cadastre-se gratuitamente na Excello Mail e tenha visibilidade completa sobre quem está enviando e-mails como se fosse o seu domínio.