Pesquisadores da empresa de segurança de e-mail ZeroBEC documentaram uma campanha construída sobre a plataforma de phishing como serviço Greatness que se passa pela RingCentral, provedora de comunicações empresariais, usando falsas notificações de correio de voz e de avaliação de desempenho como isca. As mensagens partem de um servidor de e-mail da IONOS sem qualquer relação com a RingCentral, falham em SPF, falham em DMARC e não carregam nenhuma assinatura DKIM. Por qualquer padrão de autenticação, deveriam ser rejeitadas de imediato. Em vez disso, a ZeroBEC descobriu que o e-mail chega rotineiramente à caixa de entrada, porque a RingCentral está em uma lista de remetentes confiáveis da organização receptora, e essa entrada anula tudo o que o DMARC estava configurado para impor.
O Ataque em Termos Simples
A isca se apresenta como [email protected], referindo-se a um correio de voz perdido ou a uma avaliação de desempenho, ambos plausíveis o suficiente dentro de uma organização que realmente usa a RingCentral para conseguir um clique sem muita hesitação. Ao clicar, a vítima é direcionada para a infraestrutura da Greatness, onde a campanha se divide em um de dois caminhos: um fluxo de adversário no meio (AiTM) da Microsoft que intercepta em tempo real um token de sessão aprovado por MFA, ou um fluxo de phishing por código de dispositivo que conduz a vítima a aprovar, em nome do atacante, um login da Microsoft com aparência legítima. Os dois caminhos terminam da mesma forma, com uma sessão do Microsoft 365 ativa e autenticada nas mãos do atacante, sem que nenhuma senha precise ser exposta ou roubada.
Por Que Esse Caso Escapa Especificamente do DMARC
Nada disso é novidade por si só. O relay AiTM e o abuso de código de dispositivo já apareceram este ano em outros kits. O que torna essa campanha digna de um olhar mais atento é o mecanismo de entrega, não o roubo de credenciais. Uma lista de remetentes confiáveis existe para reduzir falsos positivos no e-mail genuíno de um fornecedor confiável. Ela nunca foi projetada para distinguir entre e-mails que realmente se originam na infraestrutura desse fornecedor e e-mails que apenas afirmam vir dele. Assim que uma entrada para ringcentral.com entra em uma lista de permissões, a maioria dos gateways para de aplicar a política DMARC, as verificações de SPF ou a validação de DKIM a qualquer coisa que alegue ser desse remetente, sem exceção. A política que a organização publicou e a política que seu gateway realmente aplica divergem silenciosamente, e ninguém recebe um alerta quando isso acontece.
O Ponto Cego Que Isso Expõe
Um registro DMARC em p=reject deveria significar exatamente o que diz: e-mails que falham no alinhamento não chegam à caixa de entrada. Essa campanha mostra que essa garantia só se sustenta até onde a própria configuração do gateway de e-mail da organização permitir. Cada entrada de remetente confiável, cada domínio na lista de permissões, cada regra de “sempre confiar no e-mail deste fornecedor” é uma exceção mantida manualmente a uma política que, de outra forma, estava fazendo seu trabalho. Quanto mais do ecossistema de fornecedores de uma empresa for liberado dessa forma, a RingCentral hoje, outra ferramenta SaaS amanhã, maior fica a lacuna entre a postura DMARC que uma organização acredita ter e aquela que realmente protege sua caixa de entrada.
Isso não é um argumento contra listas de remetentes confiáveis, que cumprem um propósito real. É um argumento a favor de auditá-las da mesma forma que um proprietário de domínio audita os relatórios agregados do DMARC: como um inventário vivo de exceções, revisado periodicamente, não uma lista construída e esquecida ao longo de anos de tickets de suporte pontuais.
O Que Isso Significa para o Seu Programa
Extraia a configuração de lista de remetentes confiáveis e de permissões da sua organização e revise-a em relação à sua política DMARC. Cada entrada é um ponto onde a aplicação para de funcionar, e a maioria dessas listas se acumula por anos sem que ninguém verifique se a exceção ainda se justifica.
Pergunte ao seu fornecedor de gateway de e-mail exatamente como a lista de permissões interage com a avaliação de DMARC, SPF e DKIM. Algumas plataformas ignoram completamente as verificações de autenticação para remetentes na lista de permissões. Outras ainda registram a falha mesmo entregando o e-mail. Essa diferença determina se você tem alguma visibilidade sobre abusos como esse.
Treine os usuários especificamente sobre RingCentral, Zoom, DocuSign e qualquer outra marca SaaS frequentemente falsificada, não apenas sobre phishing em geral. Os atacantes escolhem essas iscas porque são comuns o suficiente para passar despercebidas e específicas o bastante para driblar a hesitação, e porque é mais provável que o fornecedor real esteja em alguma lista de permissões dentro da organização do destinatário.
Trate o monitoramento de DMARC como uma prática contínua, não como uma configuração única. A visibilidade contínua sobre quem realmente envia e-mails em seu nome, e como sua própria infraestrutura está sendo representada no mundo real, é o que transforma uma política publicada em uma política aplicada.
A Conclusão
O DMARC fez exatamente o que foi criado para fazer nessa campanha: sinalizou corretamente o e-mail como falho no alinhamento. A falha aconteceu um passo depois, em uma lista de remetentes confiáveis que ninguém tinha motivo para revisar até que pesquisadores foram investigar. Essa lacuna entre um veredito correto e um resultado aplicado é onde campanhas como essa vivem, e ela continuará aparecendo em qualquer lugar onde a autenticação seja tratada como uma caixa marcada uma única vez, em vez de um controle monitorado continuamente.
A Excello Mail oferece visibilidade contínua sobre a aplicação do seu DMARC e sobre cada fonte autorizada a enviar e-mails em nome do seu domínio, para que uma política publicada e uma política aplicada nunca se distanciem silenciosamente. Cadastre-se gratuitamente na Excello Mail e veja exatamente quem está enviando e-mails como você, o tempo todo.