Desde meados de agosto de 2026, uma operação de phishing vem roubando sessões ativas do Google de usuários corporativos. Todas as verificações que os defensores normalmente usam para avaliar um link deram resultado limpo, e o operador planejou assim de propósito.
A equipe de Threat Research da Material Security identificou a campanha e, desde então, derrubou centenas de domínios usados pelos invasores em uma iniciativa que a equipe chama de Operação CloudFire. Veja o que os pesquisadores descobriram.
A isca: convites do Google Agenda
As mensagens aparecem como convites do Google Agenda. Algumas chegam com cópia oculta (BCC), e muitas partem de uma organização com a qual o destinatário já trocou e-mails. Os pretextos são deliberadamente banais: notificações de caixa postal de voz, pedidos de propostas (RFP) e de informações (RFI), intimações judiciais e avisos de pagamento em atraso. Nada nelas se destaca em uma caixa de entrada movimentada.
A maioria dos links aponta para o próprio Google. O padrão habitual passa pelo redirecionador /url do Google, com o destino real escondido em um parâmetro da consulta. Outras ondas usaram links do share.google e do Drive da mesma forma, e uma variante se apoiou em links de notificação de transações da Intuit. Sempre que uma mensagem é analisada, o domínio, o certificado e a reputação exibidos são todos legítimos.
A captura: um proxy reverso diante da tela de login do Google
Depois que a vítima clica, o invasor mantém um proxy reverso ativo na frente da página real de login do Google. A vítima digita a senha, recebe uma solicitação genuína e a aprova enquanto o operador acompanha em tempo real. O servidor repassa cada segundo fator ao Google conforme ele chega, seja um código por mensagem de texto (SMS), um código de aplicativo autenticador, a correspondência numérica Tap-Yes do Google ou a recuperação de conta por telefone. Nenhum desses controles impede que a sessão seja capturada.
A estrutura por trás do ataque, conhecida como Nyasher, é documentada publicamente desde fevereiro, depois que pesquisadores encontraram uma chave codificada diretamente no código JavaScript dela.
Por que os controles habituais ficam em silêncio
Sistemas de reputação respondem a perguntas sobre propriedade. Eles verificam quem registrou um domínio, o que mais ele já hospedou e se alguém fez alguma denúncia contra ele. Esta campanha foi construída para que todas essas respostas viessem inofensivas.
Ela funciona em três camadas. A primeira é o redirecionador do Google, que dá à etapa inicial uma URL (endereço web) de confiança do Google. A segunda é um desafio Cloudflare Turnstile, que em algumas versões é o widget real servido pela própria infraestrutura da Cloudflare. A terceira é a página de captura de senha, e é aí que as coisas ficam complicadas para os defensores. Não há um site estático para analisar. O JavaScript monta a página no navegador depois que o visitante supera o desafio, então um rastreador não tem nada para buscar e um registro de proxy não tem nada para gravar. Até onde os pesquisadores sabem, ninguém havia analisado essas páginas antes da documentação da campanha.
A infraestrutura também foi feita para ser descartada. As primeiras ondas usaram muitos domínios de isca distribuídos por vários registradores, e a maioria foi registrada poucos dias antes do uso. Os endpoints de recebimento entraram no ar entre um e vinte dias antes da onda que atendiam. Um certificado curinga foi emitido 46 minutos antes de o domínio que ele cobre ser sequer registrado. Bloquear qualquer peça isolada custa ao operador alguns dólares e uma tarde de trabalho.
O que foi necessário para interromper a campanha
Os pesquisadores acompanharam a campanha desde o início, seguindo cada variante conforme iscas, portões e endpoints eram rotacionados. Depois que as detecções foram implantadas, eles identificaram mais de 99% das mensagens maliciosas, com taxa de reclassificação de 0,01%. Foi um trabalho contínuo, já que o invasor não parava de mudar táticas, temas e textos das iscas para escapar de detecções estáticas, de aprendizado de máquina e agênticas.
O que funcionou foi não deixar que um único sinal decidisse. A reputação sozinha não teria detectado isso. Nem a análise de links, já que o primeiro salto é uma URL do Google e a página final só existe quando um navegador a monta. Em vez disso, a abordagem de detecção pondera indicadores técnicos junto com a intenção aparente da mensagem, para onde seus links realmente levam e a relação de envio por trás dela. Qualquer um desses pode ser suficiente para agir. Uma detecção baseada em um único sinal herda os pontos cegos desse sinal, e este operador se empenhou para mapeá-los.
O local da análise também importa. Gateways criados para inspecionar e-mails em trânsito não se adequam bem a convites de agenda, e grande parte desta campanha chega como convites. Convites de agenda precisam ser tratados como uma superfície de ameaça própria, com o histórico completo da conta usado como contexto ao lado dos sinais técnicos.
Onde o dano aparece
Uma sessão sequestrada deixa rastros nos registros de auditoria do Google Workspace. Uma sessão ativa alcança o e-mail, o Drive e a capacidade de conceder acesso OAuth (protocolo de autorização) em nome da vítima, de modo que o alcance do dano vai muito além da caixa de entrada.
Isso levanta algumas questões difíceis para as equipes de segurança. Quem analisa de fato esses registros de auditoria e com que rapidez consegue agir sobre o que encontra? A equipe conseguiria revogar sessões, conter concessões OAuth e redefinir a conta afetada em menos de uma hora? Muitos programas não conseguem, e um invasor com uma sessão ativa pode fazer muita coisa em uma hora.
Operação CloudFire: atacando a infraestrutura
No fim de setembro, os pesquisadores concluíram que ajustar regras, retreinar modelos e atualizar agentes não resolveria o problema sozinho. A detecção protege os clientes, mas não faz nada contra um operador que já está preparando a próxima onda. Por isso, a equipe partiu para a infraestrutura.
Os analistas extraíram as URLs de gateway e de backend enquanto as mensagens eram enviadas e as reportaram pelo sistema de denúncias de abuso da Cloudflare. A equipe de abuso da Cloudflare confirmou a página intermediária falsa e a página de login do Google com proxy por trás dela, e então colocou seu próprio aviso de phishing diante desses destinos.
Isso teve dois efeitos. Primeiro, a infraestrutura do invasor foi queimada. Cada gateway e endpoint denunciado precisou ser registrado novamente, reapontado e recertificado antes que o operador pudesse voltar a enviar. Segundo, protegeu pessoas muito além dos clientes de qualquer empresa. Quem clicou em um link denunciado viu uma página de alerta em vez de um formulário de credenciais.
Um mês em números
Esses números cobrem apenas as organizações que concordaram em compartilhar dados, de modo que os totais reais são maiores. Ao longo de um mês da Operação CloudFire, os pesquisadores registraram:
- 68.676 mensagens da campanha bloqueadas
- 2.112 URLs maliciosas únicas analisadas
- 897 domínios únicos derrubados
- 8.570 endereços de remetentes comprometidos e únicos, distribuídos em 6.354 domínios raiz
As mensagens também seguiram um ritmo claro, com os envios acompanhando o horário comercial dos Estados Unidos.
A quantidade de remetentes explica como a campanha conquistou confiança. O invasor controlava cada conta comprometida antes de sair o primeiro convite, e cada uma enviava convites aos contatos salvos do dono da conta, entre outros. Os destinatários viam um nome ou domínio conhecido, em um domínio com histórico limpo, em um horário razoável do dia. Os feeds de reputação não tinham motivo para sinalizar nada disso.
Onde as coisas estão agora
Os temas de phishing migraram de convites de agenda para convites de compartilhamento de arquivos e documentos do Google Drive. Os pesquisadores não observaram um salto correspondente em outras iscas ou táticas, e a atividade desse grupo parece ter se dispersado. Por enquanto, a campanha parece encerrada.
Trata-se de um retrato do momento, e a situação pode mudar rapidamente. Reconstruir a infraestrutura é barato, e a estrutura está pública desde fevereiro. O operador também publicou, junto ao código ativo do Google, uma versão inacabada para o Microsoft 365. Ela inclui um caminho de folha de estilos, um segundo arcabouço e uma string de título que se decodifica em uma tela de login da Microsoft. Nenhum desses caminhos funciona hoje, e adicionar a nova marca significaria apenas incluir um arquivo, sem alterações no código. A continuação já está pronta e aguardando.
Os pesquisadores veem a rotação de temas como iteração contínua e esperam que o próximo movimento seja muito parecido com este, apenas com outra marca.
A análise técnica completa, incluindo indicadores de comprometimento e uma linha do tempo, está no white paper complementar. Equipes que buscam essa atividade em seus próprios ambientes devem começar por ali.
