Uma campanha que ficou conhecida como Operation CloudFire usava convites do Google Calendar para capturar sessões ativas de contas corporativas do Google Workspace, com um proxy ao vivo colocado na frente da página real de login do Google. A vítima digitava a senha, aprovava o segundo fator genuíno e, ainda assim, entregava ao operador uma sessão já autenticada. Para equipes que administram Workspace, a ação prioritária é encurtar a janela de validade das sessões web, revisar concessões OAuth recentes e passar a tratar convites de calendário como superfície de ataque própria, e não como e-mail comum.
A Material Security, que detectou e acompanhou a operação desde meados de agosto, desarticulou a infraestrutura em parceria com o sistema de abuso da Cloudflare. A campanha parece ter terminado, mas o método continua disponível: o framework por trás dela é público desde fevereiro, sob o nome Nyasher, e o operador já entregou, junto ao código em produção, um ramo inacabado voltado ao Microsoft 365. A próxima onda tende a mudar de marca, não de método.
Como o golpe funcionava
A isca chegava como convite de calendário, por vezes entregue em cópia oculta, em nome de uma organização com a qual o destinatário já havia trocado mensagens. Os temas eram deliberadamente banais: notificações de caixa postal, pedidos de RFP e RFI, intimações judiciais e avisos de cobrança.
O primeiro salto era quase sempre legítimo: os links passavam pelo redirecionador /url do próprio Google, com o destino real escondido em um parâmetro de consulta. Outras ondas usaram links de share.google e de arquivos do Drive para o mesmo propósito. No momento em que a mensagem era avaliada, o domínio, o certificado e a reputação em exibição eram todos confiáveis.
Depois vinha um desafio Cloudflare Turnstile — em algumas montagens, o widget genuíno servido pela própria Cloudflare — e, por fim, a página que capturava a senha. Essa página não tinha endereço para varrer: era construída em memória por script, depois que o visitante passava pelo desafio, sem deixar nada para um crawler buscar nem para aparecer em log de proxy. Segundo a Material, essas páginas nunca haviam sido escaneadas por ninguém, porque foi para isso que foram projetadas.
O mecanismo central era um proxy reverso ao vivo na frente da página de login verdadeira do Google. A vítima via o prompt real, recebia o pedido real e aprovava; códigos SMS, códigos de autenticador, o Tap-Yes com combinação de números e até a recuperação de conta por telefone eram retransmitidos ao Google conforme chegavam. Nenhum segundo fator falhou — todos foram cumpridos dentro de uma sessão que o operador observava em tempo real. O token resultante era capturado antes de chegar ao navegador da vítima, e o invasor herdava acesso a Gmail, Drive e à capacidade de conceder permissões OAuth em nome do usuário.
O desenho é o padrão dos kits de adversário-no-meio, como o portal já detalhou no caso do Green Proxy contra sessões do 365. A diferença aqui está na escala do empréstimo: a campanha usou a infraestrutura do próprio Google como escada de credibilidade em cada etapa da cadeia.
Por que os filtros falharam
Controles de reputação respondem perguntas sobre propriedade: quem registrou o domínio, o que ele já hospedou, se alguém reclamou. A campanha foi montada para que todas essas perguntas devolvessem respostas tranquilizadoras. O relato da Material descreve nove domínios de isca distribuídos em cinco registradores, a maioria registrada dias antes do uso, com endpoints de recepção preparados com uma a três semanas de antecedência e um certificado curinga emitido 46 minutos antes de o domínio que ele cobre ter sido registrado. Bloquear qualquer peça isolada custava ao operador alguns dólares e uma tarde de trabalho.
Detecção ancorada em um único sinal herda os pontos cegos desse sinal. A Material relata que, depois de desenvolver detecções para cada nova variante, passou a capturar mais de 99% das mensagens maliciosas da campanha, com taxa de reclassificação de 0,01% — mas isso exigiu pontuar indicadores técnicos, a intenção da mensagem, para onde os links resolviam e o relacionamento de envio por trás deles. Nenhuma dessas camadas, isolada, teria segurado a operação.
Um convite de calendário também é um encaixe ruim para gateways construídos para inspecionar e-mail em trânsito: quando o resultado é uma sessão sequestrada, e não uma senha roubada, a evidência aterrissa nos registros do Workspace, não no filtro de correio. Quem lê esses registros, e com que rapidez, passa a fazer parte do controle.
Os números da desarticulação
No fim de setembro, a equipe de pesquisa da Material decidiu atacar o outro lado do problema: analisar as URLs de gateway e de backend usadas durante o envio e reportá-las pelo sistema de abuso da Cloudflare. Quando o time de abuso validava o intersticial falso e a página de login do Google proxied atrás dele, aplicava seu próprio intersticial de alerta. Cada ponto de entrada reportado precisava ser registrado, redirecionado e recertificado antes que o operador pudesse enviar de novo — e qualquer pessoa que clicasse em um link reportado, de qualquer caixa de entrada, encontrava uma página de aviso em vez de um formulário de captura.
Em um mês de operação, o balanço divulgado registra 68,676 mensagens, 897 domínios derrubados e 8,570 remetentes comprometidos em 6,354 domínios raiz, além de 2,112 URLs maliciosas analisadas. Cada remetente era uma conta que o atacante já controlava antes do primeiro convite, escrevendo para contatos salvos da vítima em horário comercial dos EUA. Os números vêm de clientes que concordaram em compartilhar telemetria, portanto subestimam o total real.
A atividade do grupo parece dispersa e a campanha, encerrada: os temas migraram de convites de calendário para compartilhamentos de arquivos e documentos do Google, sem aumento correspondente em outras táticas. A Material avalia que o comportamento observado em setembro é de quem itera, não de quem se aposenta — e publicou a lista de domínios envolvidos para que outras equipes possam buscá-los nos próprios ambientes.
Como reduzir a exposição
Um token capturado sobrevive à troca de senha, porque a sessão já está autenticada — a mesma moeda que transforma logs de infostealer em atalho contra o SSO corporativo, como o portal já mostrou em análise anterior. A resposta começa pela duração da sessão: a sessão web padrão dos serviços Google dura 14 dias, intervalo longo demais quando o alvo do ataque é o token. O administrador pode encurtar essa duração por unidade organizacional e por grupo de configuração, exigindo novo login com frequência maior para quem acessa recursos sensíveis.
Há limites a conhecer antes de confiar no controle, todos documentados pelo Google: a duração não vale para apps móveis nativos, como Gmail e Calendar, cujas sessões de login não expiram por si, nem para apps autenticados por OAuth; com provedor de identidade terceiro, a sessão do provedor precisa expirar antes da sessão Google, ou esta pode ser renovada sem novo login; e, ao mudar a configuração, o usuário precisa sair e entrar de novo para o novo valor valer — resetar os cookies de login usuário a usuário força a reautenticação imediata.
Sinais para revisar no Admin Console e nos registros do Workspace:
| Verificação | O que procurar |
|---|---|
| Sessões ativas | Dispositivos e sessões novos pouco depois de convites externos aceitos |
| Concessões OAuth | Aplicativos autorizados pelo usuário em janela recente |
| Encaminhamento e delegação | Regras novas de encaminhamento ou delegação de caixa criadas sem solicitação |
| Padrão de link | Links do Google com destino embutido em parâmetro de consulta em convites |
| Geografia e horário | Aprovações de login fora do padrão do usuário em sequência curta |
Prioridades P1 e P2
P1: encurtar a duração da sessão web por unidade organizacional ainda esta semana; revisar sessões ativas e concessões OAuth das contas com acesso a dados financeiros; e configurar alerta para convites de calendário externos contendo redirecionadores com destino em parâmetro.
P2: revisar a política de reautenticação para apps nativos e OAuth, rodar a lista de domínios da campanha contra DNS e logs de proxy históricos, e treinar equipes de suporte para tratar denúncias de convites suspeitos como possível sessão comprometida — com revogação de sessão e revisão de concessões, e não apenas troca de senha.