A equipe de pesquisa Harmony Email do Check Point divulgou uma campanha de phishing construída sobre uma premissa que deveria preocupar qualquer um que trate autenticação como prova de segurança: as mensagens não eram falsificadas de forma alguma. Foram enviadas pela própria infraestrutura do Google, a partir de um endereço genuíno do Google, usando um recurso legítimo do Google Cloud exatamente como ele foi projetado para ser usado. Ao longo de cerca de duas semanas, os atacantes dispararam 9.394 emails de phishing contra aproximadamente 3.200 organizações-alvo nos Estados Unidos, Europa, Canadá, Ásia-Pacífico e América Latina, e todos eles passaram nas verificações de SPF, DKIM, DMARC e CompAuth da Microsoft sem qualquer atrito.
Um recurso, não uma falha
O caminho de abuso passava pelo serviço Application Integration do Google Cloud, especificamente sua tarefa “Send Email”, uma ferramenta criada para automação legítima de fluxos de trabalho: notificações de sistema, alertas, mensagens internas de rotina. Os atacantes configuraram essa tarefa para disparar para destinatários externos arbitrários, e cada mensagem enviada trazia o endereço de remetente [email protected]. Esse endereço pertence ao Google. Está hospedado na infraestrutura de email do Google, assinado com a chave DKIM do próprio Google, e enviado a partir de faixas de IP que o registro SPF do Google autoriza explicitamente. Não havia domínio nenhum para falsificar, porque nenhum domínio precisava ser falsificado.
As iscas foram construídas para combinar com o remetente: notificações de uma nova mensagem de voz, um documento compartilhado aguardando aprovação de acesso, uma solicitação de permissão em um arquivo. Mensagens comuns, de baixo atrito, exatamente o tipo que um usuário do Google Workspace recebe várias vezes por semana e clica sem pensar duas vezes. O link levava a uma página de captura de credenciais criada para roubar logins do Microsoft 365, um detalhe que tornou a campanha genuinamente multiplataforma: a infraestrutura de email do Google entregando a isca, o ecossistema da Microsoft como o alvo real.
Por que cada camada de autenticação disse sim
O DMARC verifica se o domínio no cabeçalho From autorizou a infraestrutura de envio que entregou a mensagem. Aqui, o cabeçalho From dizia google.com, e os próprios servidores do google.com fizeram o envio. O SPF passou porque o IP de origem estava na lista autorizada do Google, porque era um IP do Google. O DKIM passou porque a assinatura foi gerada com a chave privada real do Google, dentro da infraestrutura de assinatura real do Google. O alinhamento passou porque não havia nenhuma incompatibilidade em toda a cadeia para detectar. O CompAuth da Microsoft, aplicado por cima para organizações que usam Microsoft 365, chegou à mesma conclusão pelo mesmo motivo: nada na procedência técnica da mensagem era fraudulento.
Esse é um modo de falha diferente de domínios parecidos ou caixas de entrada de terceiros comprometidas, padrões que também apareceram em campanhas recentes. Esses ataques exploram uma lacuna entre o que um domínio afirma e o que realmente enviou o email. Este fecha essa lacuna por completo, usando infraestrutura à qual o atacante nunca deveria ter acesso de escrita, um recurso de automação legítimo reaproveitado como um relé de email para quem conseguisse configurá-lo.
O padrão mais amplo em que isso se encaixa
Pesquisadores de segurança têm apontado uma categoria crescente de campanhas que roteiam phishing pelos sistemas de notificação das grandes plataformas de nuvem, em vez de contorná-los. Um convite de calendário, um alerta de unidade compartilhada, um email de conclusão de tarefa, um aviso de mensagem de voz: todos esses são mensagens automatizadas que as plataformas enviam em nome de um usuário, e todas herdam a confiança de autenticação completa dessa plataforma. Quando um atacante encontra uma forma de disparar um desses envios automatizados para um alvo de sua escolha, ele ganha infraestrutura de entrega que nenhum nível de aplicação de DMARC no próprio domínio da vítima consegue impedir, porque o domínio da vítima nunca esteve envolvido.
O Google já restringiu esse caminho de abuso no Application Integration e declarou que está tomando medidas adicionais para prevenir uso indevido semelhante. Isso fecha essa brecha específica. Não fecha a categoria. Qualquer plataforma de nuvem com um recurso de “enviar uma notificação para um endereço arbitrário” é candidata ao mesmo truque, e existem muitas plataformas de nuvem com exatamente esse recurso.
O que isso significa para o seu programa
Não deixe que “autenticado” substitua “verificado” no seu processo de triagem. Uma mensagem que passa em SPF, DKIM e DMARC a partir do próprio domínio de uma grande plataforma diz que a infraestrutura dessa plataforma a enviou. Não diz nada sobre se uma pessoa naquela plataforma, ou um atacante que encontrou um recurso de automação destravado, decidiu para quem ela iria.
Treine os usuários especificamente sobre iscas em formato de notificação. Alertas de mensagem de voz, solicitações de acesso a documentos e notificações de permissão são eficazes justamente por imitarem o ruído rotineiro da plataforma. Um lembrete interno curto de que esses tipos de mensagem podem carregar links de captura de credenciais, mesmo a partir de domínios reais da plataforma, fecha uma lacuna que a autenticação não consegue fechar.
Direcione as páginas de captura de credenciais para autenticação resistente a phishing. Um tenant do Microsoft 365 protegido por chaves de segurança FIDO2 ou passkeys de plataforma é muito mais difícil de comprometer por meio de uma página de senha capturada do que um que depende de senha mais push de MFA, que continua vulnerável à fadiga de aprovações mesmo quando a isca inicial funciona.
Denuncie o abuso de recursos de automação de plataformas quando você identificar, e espere ver mais casos assim. Essa campanha explorou a infraestrutura do Google desta vez. A técnica subjacente, automação legítima reaproveitada como relé de phishing, é transferível para qualquer fornecedor com um recurso semelhante de envio em nome de outro, e suas próprias regras de detecção devem presumir que ela vai aparecer em outro lugar.
Mantenha o DMARC aplicado de qualquer forma. Essa campanha não enfraquece o argumento a favor da aplicação no seu próprio domínio. Ela demonstra uma categoria de risco totalmente separada, uma que vive dentro das plataformas em que você já confia, não na lacuna que o DMARC foi projetado para fechar.
A conclusão
Nada nessa campanha exigiu quebrar o DMARC, falsificar um domínio ou comprometer uma caixa de entrada. Exigiu encontrar um recurso legítimo que enviasse email em nome do Google para quem o atacante especificasse, e apontá-lo para 3.200 alvos. Cada sinal técnico que um servidor de recebimento pode verificar voltou exatamente como foi projetado, porque nada nesses sinais era falso. A autenticação responde a uma pergunta com precisão: se a infraestrutura do domínio alegado enviou isto. Ela nunca foi projetada para responder se essa infraestrutura estava sendo usada da forma que seu dono pretendia.
A Excello Mail te dá visibilidade contínua sobre o cumprimento do seu DMARC e sobre cada fonte autorizada a enviar em nome do seu domínio, para que você detecte abusos rapidamente e mantenha sua própria postura de autenticação impecável, mesmo quando atacantes encontrarem nova infraestrutura para explorar em outros lugares. Cadastre-se gratuitamente na Excello Mail e veja exatamente quem está enviando emails como você, o tempo todo.