Uma operação de phishing atribuída pelo Google Threat Intelligence Group ao cluster UNC7005 combina páginas controladas por invasores com fluxos legítimos de autenticação do Google, da Microsoft e do WhatsApp. O alvo inclui pessoas ligadas à indústria de defesa europeia, além de outros indivíduos de interesse. A prioridade para as equipes defensivas é bloquear os domínios usados como isca, revisar sessões e tokens de contas expostas e impedir que usuários aprovem vínculos ou aplicativos que não reconhecem.
O que foi observado
O relatório do Google descreve uma operação adaptável, e não uma única página falsa. O invasor começa com uma mensagem direcionada e conduz a vítima para uma infraestrutura sob seu controle. A página pode imitar um evento, uma organização ou uma tela de acesso conhecida. Depois, em vez de simplesmente coletar uma senha, o fluxo tenta fazer a vítima concluir uma ação legítima que entrega ao operador uma forma de acesso persistente.
Esse detalhe muda a resposta. Uma campanha desse tipo pode não gerar um alerta baseado apenas em credenciais vazadas. O usuário pode ter digitado a senha em uma página real do provedor e, ainda assim, ter autorizado um aplicativo, fornecido um código ou associado outro dispositivo à conta. A investigação precisa correlacionar e-mail, navegador, consentimentos OAuth, sessões ativas, dispositivos associados e alterações recentes de recuperação.
O relatório também separa o UNC7005 de outros clusters que perseguem pessoas ligadas à Rússia. Essa distinção é operacionalmente útil: indicadores podem se sobrepor, mas os fluxos de ataque e as ações de contenção não são necessariamente iguais. A equipe deve registrar cada domínio, remetente, redirecionamento e tela apresentada antes de concluir que todos os eventos pertencem à mesma campanha.
O abuso do OAuth
Em uma variante, a mensagem leva a vítima a um domínio controlado pelo atacante. O botão de acesso redireciona para uma página legítima de login do Google. Depois da autenticação, a vítima é enviada a um projeto em modo de teste e não verificado, controlado pelo invasor. O objetivo descrito pelo GTIG é obter tokens de autenticação capazes de ampliar o acesso à conta.
Para o usuário, a presença do domínio legítimo na barra do navegador pode parecer uma confirmação de segurança. Para o defensor, ela é apenas um elemento do fluxo. A pergunta decisiva é: qual aplicativo recebeu autorização, qual escopo foi solicitado e de onde veio o primeiro redirecionamento? Um login bem-sucedido não prova que a operação foi legítima.
O monitoramento deve priorizar consentimentos recentes, aplicações não verificadas, projetos que solicitam escopos incomuns e acessos originados de infraestrutura que não combina com o perfil da organização. Em contas corporativas, administradores devem restringir o consentimento de aplicativos, exigir revisão para aplicações externas e manter alertas para criação ou alteração de credenciais, tokens e regras de encaminhamento.
Também é necessário preservar evidências antes da limpeza. Exporte cabeçalhos completos das mensagens, URLs de redirecionamento, registros de autenticação, identificadores de aplicativo, escopos solicitados e horários. Remover a mensagem sem guardar esses dados pode impedir a reconstrução do caminho usado pelo atacante.
O vínculo do WhatsApp
Outra técnica descrita envolve páginas que imitam uma chamada, uma conversa criptografada ou o compartilhamento de um documento. A vítima é induzida a vincular sua conta do WhatsApp a um dispositivo controlado pelo atacante. Depois do vínculo, o operador pode receber mensagens, acompanhar conversas e usar a confiança da conta comprometida para abordar novos alvos.
A aparência de criptografia não elimina o risco. A proteção do conteúdo durante o transporte não impede que uma conta seja vinculada voluntariamente a outro dispositivo. A fraude ocorre na etapa de autorização: o usuário acredita que está entrando em uma chamada ou validando uma sessão, mas aprova uma associação que beneficia o invasor.
O procedimento de contenção é direto. No WhatsApp, abra a área de dispositivos conectados, remova qualquer sessão desconhecida e registre uma captura da lista para a investigação. Em seguida, confirme a verificação em duas etapas, revise o endereço de recuperação e avise os contatos que receberam mensagens durante o período suspeito. Se a conta for usada para trabalho, a equipe deve tratar o evento como comprometimento de identidade, não como simples spam.
As organizações também precisam explicar que códigos, QR codes e solicitações de vínculo não devem ser aprovados durante uma chamada ou conversa iniciada por uma mensagem inesperada. A validação deve ocorrer por um canal independente, usando um contato conhecido. A urgência criada pelo remetente não é evidência de autenticidade.
Decisão operacional
| Prioridade | Ação | Evidência a preservar |
|---|---|---|
| P1 | Revogar sessões, tokens e consentimentos suspeitos; remover dispositivos desconhecidos; bloquear domínios e remetentes observados. | Logs de autenticação, cabeçalhos, URLs, IDs de aplicativos e lista de dispositivos. |
| P1 | Identificar mensagens enviadas pela conta comprometida e notificar os destinatários antes que aprovem novos acessos. | Mensagens enviadas, regras de encaminhamento e alterações de recuperação. |
| P2 | Restringir aplicativos não verificados, revisar escopos OAuth e reforçar treinamento sobre códigos, QR codes e vínculos. | Políticas administrativas, eventos de consentimento e resultados de simulações. |
No e-mail, procure mensagens que usam convites de eventos, documentos ou solicitações institucionais para iniciar o fluxo. Não limite a busca ao domínio final: examine redirecionadores, parâmetros de URL e páginas intermediárias. No proxy e no DNS, correlacione consultas aos domínios com sessões de autenticação próximas. No provedor de identidade, busque novos dispositivos, alterações de fatores, aplicações recém-autorizadas e acessos incompatíveis com a localização ou a rotina do usuário.
Uma conta que acessou a página, mas não digitou credenciais, ainda merece triagem. O navegador pode ter enviado identificadores, a vítima pode ter aprovado uma etapa parcial ou o atacante pode tentar reutilizar a interação em uma segunda abordagem. A resposta deve separar exposição potencial de comprometimento confirmado, com critérios documentados para cada decisão.
Como reduzir o risco
A defesa mais eficaz combina controles técnicos e uma mudança de procedimento. O usuário não deve avaliar a mensagem apenas pelo visual da página ou pelo domínio mostrado depois do redirecionamento. O processo deve exigir confirmação do pedido por outro canal e impedir consentimentos externos sem revisão.
Para contas críticas, prefira chaves de segurança e políticas que reduzam autenticações suscetíveis a phishing. Limite o uso de contas pessoais em comunicações de trabalho e mantenha inventário dos dispositivos conectados a serviços de mensagens. Estabeleça uma rotina de revogação após qualquer clique em campanha suspeita, mesmo quando não houver confirmação imediata de perda de senha.
O caso também reforça que inteligência de ameaças precisa chegar ao controle operacional. Indicadores sem busca retroativa, regras de detecção e responsáveis por contenção têm pouco valor. O time deve transformar cada domínio, remetente e artefato em consultas reproduzíveis e medir quantas contas foram expostas, quais tokens foram revogados e quais destinatários receberam mensagens falsas.
Fontes
Google Threat Intelligence Group: análise dos clusters e dos fluxos de phishing
Google: proteção da conta e revisão de atividade suspeita
WhatsApp: gerenciamento de dispositivos conectados
O portal já explicou por que fluxos legítimos de login podem ser abusados e como conter o roubo de sessões após phishing. Neste caso, a decisão prioritária é verificar autorização e vínculo de dispositivo, não apenas trocar a senha.