Desde meados de agosto de 2026, uma operação de phishing vem capturando sessões ativas de contas corporativas do Google. Todos os sinais que os defensores costumam usar para avaliar um link indicavam que ele era confiável. O operador montou a cadeia dessa forma de propósito.
A equipe de pesquisa de ameaças da Material Security identificou a campanha e derrubou centenas de domínios usados pelos atacantes. A operação foi batizada de Operation CloudFire.
As mensagens chegam como convites do Google Agenda. Às vezes, são enviadas com cópia oculta e, em muitos casos, vêm de uma organização com a qual o destinatário já trocou mensagens. Os pretextos são corriqueiros: avisos de correio de voz, pedidos de proposta e de informações, intimações judiciais e notificações de pagamentos em atraso.
A maioria dos links aponta para o próprio Google. O padrão mais comum usa o redirecionador /url do Google, com o destino real em um parâmetro da consulta. Outras ondas recorreram ao share.google e a links de arquivos do Drive para o mesmo fim. Uma variante usou links de notificações de transações da Intuit.
Em todos os casos, ao avaliar a mensagem, os sistemas exibem um domínio, um certificado e uma reputação legítimos e confiáveis.
O atacante posiciona um proxy reverso ativo diante da página legítima de acesso do Google. A vítima digita a senha, recebe uma solicitação legítima e a aprova, enquanto o operador acompanha a sessão em tempo real.
O servidor encaminha ao Google, assim que chegam, os códigos enviados por SMS, os códigos do aplicativo autenticador, a confirmação numérica do recurso “Toque em Sim” do Google e as etapas de recuperação da conta por telefone. Com isso, nenhum dos controles de segundo fator impede a captura da sessão.
A estrutura usada no ataque, chamada Nyasher, está documentada publicamente desde fevereiro, quando uma chave incorporada diretamente ao código foi encontrada em seu JavaScript.
Os sistemas de reputação respondem a uma pergunta sobre propriedade: quem registrou o domínio, o que ele já hospedou e se alguém apresentou reclamações. A campanha foi montada para que as respostas parecessem sempre benignas. Ela tem três camadas.
A primeira é o redirecionador do Google. A segunda é um desafio do Cloudflare Turnstile, que, em algumas versões, é servido pela própria infraestrutura da Cloudflare. A terceira é a página de captura de senhas, que não existe como site estático para ser analisado.
O JavaScript monta a página no navegador depois que o visitante supera o desafio. Assim, um rastreador não tem o que buscar e um registro do proxy não tem o que registrar. Segundo a Material Security, ninguém havia analisado essas páginas antes de a campanha ser documentada.
A infraestrutura foi projetada para ser descartável. A campanha observada inicialmente usava vários domínios de isca registrados por meio de diferentes empresas, e a maioria havia sido registrada poucos dias antes do uso. Os pontos de recebimento dos dados eram preparados de 1 a 20 dias antes da onda correspondente.
Um certificado curinga foi emitido 46 minutos antes do registro do domínio que cobria. Bloquear qualquer componente isolado custa ao operador alguns dólares e uma tarde de trabalho.
Segundo a Material Security, a empresa acompanha a campanha desde o início, seguindo cada variante à medida que as iscas, as barreiras e os pontos de recebimento mudavam. Desde agosto, após identificar a operação e desenvolver mecanismos de detecção, bloqueou mais de 99% das mensagens maliciosas, com uma taxa de reclassificação de 0,01%.
O trabalho tem sido contínuo, pois o atacante alterou suas táticas, técnicas e procedimentos, além dos temas e textos das iscas, para escapar de mecanismos de detecção estáticos, de aprendizado de máquina e baseados em agentes.
A abordagem funciona porque nenhum sinal isolado determina o resultado. A reputação, sozinha, não teria detectado a campanha. A análise de links também não bastaria: o primeiro salto é uma URL do Google, e a página final só passa a existir quando o navegador a monta.
A Material Security afirma avaliar indicadores técnicos, a intenção aparente da mensagem, o destino real dos links e a relação entre remetente e destinatário. Qualquer um desses elementos pode ser suficiente para identificar uma ameaça.
Um mecanismo de detecção baseado em um único sinal herda os pontos cegos desse sinal, e o operador dedicou bastante esforço a mapeá-los.
O local onde a análise é feita também importa. Um convite de calendário não é um formato fácil de inspecionar para um sistema projetado para analisar mensagens em trânsito. Ainda assim, boa parte da campanha chega por meio de convites.
A Material Security trata convites de calendário como uma superfície de ameaça própria e afirma usar o histórico completo da conta como contexto, junto com os sinais técnicos.
Quando o resultado é o sequestro de uma sessão, e não o roubo de uma senha, as evidências aparecem nos registros de auditoria do Workspace. Uma sessão ativa do Google dá acesso ao e-mail e ao Drive, além de permitir a concessão de acesso OAuth em nome da vítima. O impacto, portanto, vai muito além da caixa de entrada.
Os defensores devem fazer duas perguntas: quem está analisando esses registros e com que rapidez pode agir? Também é fundamental saber se a equipe consegue revogar sessões, conter concessões de acesso OAuth e redefinir a conta afetada em até uma hora.
Muitos programas não conseguem fazer isso. Nesse intervalo, um atacante com uma sessão ativa pode causar bastante dano.
No fim de setembro, a Material Security concluiu que ajustar regras, treinar novamente modelos e atualizar agentes não resolveria o problema por si só. A detecção protege os clientes, mas não afeta o operador que prepara a próxima onda.
Por isso, a equipe de pesquisa de ameaças da Material Security lançou a Operation CloudFire para atingir a infraestrutura da campanha.
A equipe analisou as URLs dos portais e dos sistemas de retaguarda à medida que as mensagens eram enviadas e denunciou os endereços pelo sistema de denúncias de abuso da Cloudflare. A equipe de abuso da Cloudflare confirmou a existência da página intermediária falsa e da página de acesso do Google exibida por meio do proxy. Em seguida, aplicou suas próprias páginas de aviso de phishing a esses destinos.
A ação teve dois efeitos. A infraestrutura do atacante foi exposta: cada portal e ponto de recebimento denunciado precisou ser registrado novamente, redirecionado e receber um certificado antes que o operador pudesse voltar a enviar mensagens. Além disso, qualquer pessoa que clicasse em um link denunciado, fosse ou não cliente da Material Security, via um aviso em vez de um formulário para inserir credenciais.
Os números incluem apenas clientes que concordaram em compartilhar dados com a Material Security. Portanto, os totais reais são maiores. Ao longo de um mês da Operation CloudFire, a empresa registrou:
- 68.676 mensagens da campanha bloqueadas
- 2.112 URLs maliciosas únicas analisadas
- 897 domínios únicos derrubados
- 8.570 endereços de remetentes comprometidos, distribuídos por 6.354 domínios raiz
- Um ritmo de envio alinhado ao horário comercial dos Estados Unidos
A quantidade de remetentes ajuda a explicar como a campanha conquistou credibilidade. Cada endereço comprometido pertencia a uma conta sob controle do atacante antes do envio do primeiro convite. Essas contas enviavam convites aos contatos salvos das vítimas, entre outros endereços.
Os destinatários viam um nome ou domínio conhecido, com histórico limpo e em um horário plausível. Os sistemas de reputação não tinham motivo para sinalizar as mensagens. Por isso, todas as camadas que avaliam propriedade e histórico indicavam que elas eram confiáveis.
Os temas de phishing mudaram: os convites de calendário deram lugar a convites para compartilhar arquivos e documentos do Google Drive. A Material Security não observou um aumento semelhante em outras iscas ou táticas, técnicas e procedimentos, e a atividade desse grupo parece ter se dispersado. A campanha parece encerrada.
Essa é uma atualização de status, não uma conclusão definitiva. Reconstruir a infraestrutura custa pouco, a estrutura está disponível publicamente desde fevereiro e o operador enviou, junto com o código ativo para o Google, uma versão inacabada para o Microsoft 365.
Essa versão inclui o caminho de uma folha de estilos, um segundo ambiente de teste e um texto de título que, decodificado, exibe uma solicitação de acesso da Microsoft. Nenhum desses caminhos funciona hoje, e acrescentar a marca exige apenas inserir um arquivo, sem alterar o código.
O operador já preparou a próxima etapa, mas ainda não a ativou. Para a Material Security, a mudança de tema indica uma evolução, não o abandono da operação. A empresa espera que a próxima mudança seja parecida com esta, mas use outra marca.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...