A maioria das campanhas que cobrimos passa no DMARC contornando-o completamente, emprestando uma caixa de entrada comprometida, um token OAuth ou o pool de envio de um ESP respeitado. O fornecedor de segurança de e-mail IRONSCALES documentou algo estruturalmente diferente: um e-mail de phishing contra um distrito escolar dos Estados Unidos que passou SPF, DKIM e DMARC para adobe.com porque a própria infraestrutura da Adobe realmente o enviou. Sem falsificação, sem domínio parecido, sem reputação emprestada. Apenas um recurso legítimo do produto, direcionado a um alvo.
Um Recurso Real da Adobe, Direcionado por um Atacante
O Adobe Acrobat permite que qualquer titular de conta compartilhe um documento e dispare uma notificação automática para o endereço que digitar. Um atacante usou esse recurso exatamente como foi projetado. Ele enviou um arquivo chamado EDITABLERollandReadPhonicsMathFactsTargetedInstruction-1, um nome construído para soar como um recurso curricular legítimo de ensino fundamental, e o compartilhou com funcionários de um distrito escolar inteiro. O sistema da Adobe enviou a notificação resultante a partir de [email protected], roteada pela infraestrutura da Amazon SES que a Adobe está autorizada a usar para envio, e assinada com a própria chave DKIM da Adobe. Toda verificação técnica que um servidor de e-mail receptor executa voltou limpa, porque cada uma dessas verificações respondia exatamente à pergunta para a qual foi criada: a adobe.com autorizou esta mensagem? Sim, havia autorizado.
Cada Link Também Apontava Para a Adobe
O e-mail também não trazia nenhuma URL externa suspeita. O chamado à ação principal e os links de apoio eram todos roteados por postoffice.adobe.com/po-server/link/redirect, com o destino real codificado dentro de um JWT assinado com HS512 no parâmetro target da URL. Um gateway que verificasse a reputação de links via o próprio domínio de redirecionamento da Adobe e não tinha nenhum indicador estático para sinalizar, porque o destino malicioso estava escondido dentro de um token codificado em vez de exposto em texto simples. Entre uma identidade de remetente genuína e um host de redirecionamento com aparência genuína, não sobrava nada na mensagem para um controle baseado em assinatura ou em autenticação detectar.
O Que Realmente Detectou o Ataque
A IRONSCALES sinalizou a mensagem por sinais de comportamento e contexto: era um remetente pela primeira vez para esses destinatários, o nome do documento coincidia com a função profissional do alvo com uma precisão que soava mais planejada do que incidental, e os padrões de linguagem na notificação eram consistentes com engenharia social em vez do texto automático típico da Adobe. Os dados de ameaças da comunidade acrescentaram a peça final, mostrando que a mesma isca já havia sido colocada em quarentena em outras organizações. Combinados, esses sinais produziram uma classificação de phishing com 78 por cento de confiança. Quatro caixas de entrada do distrito receberam a mesma mensagem; todas as quatro foram mitigadas, e nenhuma credencial foi roubada.
O Que Isso Significa Para o Seu Programa
Um SPF, DKIM e DMARC aprovados de forma limpa dizem quem autorizou a mensagem, não se a própria plataforma desse remetente foi usada contra você. A Adobe não falhou aqui. Sua autenticação foi precisa. A lacuna está uma camada acima, no que um titular de conta legítimo tem permissão para fazer com um recurso legítimo.
Qualquer serviço que permita a um titular de conta disparar uma notificação para um endereço arbitrário é um canal de entrega que um atacante pode alugar de graça. Ferramentas de compartilhamento de documentos, plataformas de assinatura eletrônica, convites de calendário e notificações de colaboração se encaixam todas nessa categoria, e todas vão autenticar de forma limpa porque a própria plataforma é o remetente de registro.
A detecção comportamental não é uma camada de luxo sobre a autenticação. Em mensagens como essa, é a única camada que tem alguma chance. Um alerta de remetente pela primeira vez, um nome de documento preciso demais e a comparação de padrões entre organizações fizeram o trabalho que SPF, DKIM e DMARC estruturalmente não conseguiam fazer.
Seus relatórios agregados de DMARC não vão revelar esse padrão, porque não há nada a revelar. A mensagem foi autorizada, corretamente, pelo domínio que ela alega representar. Este é um problema de detecção e conscientização que fica adiante da própria postura de autenticação do seu domínio, não uma falha nela.
A Conclusão
O DMARC responde bem a uma pergunta: esta mensagem está autorizada pelo domínio que ela alega representar? Aqui, a resposta honesta foi sim, e a mensagem ainda era uma tentativa de roubo de credenciais construída para parecer um arquivo curricular que um funcionário da escola abriria sem pensar duas vezes. À medida que mais ferramentas de negócio do dia a dia adicionam recursos de compartilhar e notificar, espere ver mais desse padrão: atacantes que param de tentar vencer a autenticação e passam a alugá-la, um recurso legítimo de cada vez.
O DMARC diz se o e-mail que alega vir do seu domínio foi realmente autorizado a ser enviado. Ele não consegue dizer quando alguém abusa dos próprios recursos legítimos de uma plataforma confiável para chegar até as suas pessoas, e é exatamente por isso que a visibilidade sobre os seus próprios fluxos de e-mail autenticados ainda importa. A Excello Mail te dá uma visão clara e contínua de tudo que envia em nome do seu domínio, para que você saiba que a sua própria postura de autenticação está sólida enquanto ameaças como essa continuam evoluindo em outros lugares. Cadastre-se gratuitamente na Excello Mail e coloque essa visibilidade em prática.