O Azure Monitor é um serviço legítimo da Microsoft que observa seus recursos na nuvem e envia um e-mail quando algo precisa de atenção. É exatamente por isso que agentes maliciosos passaram os últimos meses transformando-o em seu próprio sistema de distribuição de phishing, um em que a mensagem realmente vem dos servidores de e-mail da Microsoft, realmente passa por toda verificação de autenticação que um servidor receptor pode executar, e realmente termina com um número de telefone conectado a um golpista em vez de um link que um filtro possa sinalizar.
O que os alertas do Azure Monitor deveriam fazer
O Azure Monitor permite que qualquer proprietário de assinatura crie uma regra de alerta que observa uma condição, uma métrica que ultrapassa um limite, o estado de um recurso que muda, um orçamento que é excedido, e dispara uma notificação quando essa condição é atendida. A notificação é tratada por um grupo de ações, uma lista de destinatários e canais que o alerta deve alcançar, que pode incluir um endereço de e-mail digitado diretamente por quem configurou a regra. Quando o alerta dispara, a própria infraestrutura do Azure Monitor gera e envia o e-mail. O remetente é genuinamente [email protected], porque genuinamente é o Azure Monitor quem o envia.
Transformando um alerta de cobrança em um golpe por telefone
O abuso não exige comprometer a Microsoft, sua organização, ou a conta de ninguém. Um atacante precisa apenas de uma assinatura do Azure, incluindo uma gratuita ou de avaliação criada por ele mesmo, com acesso suficiente para construir uma regra de alerta e seu grupo de ações. Pesquisadores da IRONSCALES documentaram um caso em que o atacante criou um grupo de recursos chamado pay-cbb33c4ab1 e configurou um alerta de métrica cujo campo de descrição, normalmente reservado para texto operacional, foi preenchido com linguagem fraudulenta de cobrança. O atacante então adicionou o endereço de e-mail do alvo como destinatário no grupo de ações e disparou o alerta.
O que chega na caixa de entrada é uma notificação real do Azure Monitor, formatada da forma como o Azure Monitor realmente formata suas notificações, enviada do endereço de onde o Azure Monitor realmente envia. A única coisa controlada pelo atacante é o texto dentro dela.
A fatura de 459,90 dólares que o setor de cobrança nunca enviou
A mensagem capturada pela IRONSCALES trazia um ID de transação PP456-887A-22B, uma cobrança de 459,90 dólares vinculada a um descritor de comerciante “Windows Defender”, e um cabeçalho dizendo “MICROSOFT CORPORATION BILLING AND ACCOUNT SECURITY NOTICE”. Nada disso faz parte do modelo padrão de alerta do Azure, e foi exatamente assim que a mensagem foi sinalizada, não por SPF, DKIM ou DMARC, que passaram sem problemas, mas por detecção comportamental que percebeu que alertas do Azure Monitor normalmente não falam sobre cobrança. A mensagem não trazia nenhum link. Trazia dois números de telefone, +1 (812) 266-1890 e +1 (812) 266-1510, nenhum dos quais aparece em nenhuma página oficial de suporte da Microsoft. Isso é phishing por telefone, às vezes chamado de TOAD, entrega de ataque orientada por telefone, e foi deliberadamente construído para não dar nada a um escâner de links para analisar.
Por que isso continua funcionando meses depois
Pesquisadores da Trustwave SpiderLabs documentaram pela primeira vez uma versão ativa dessa campanha em março de 2026, rastreando regras de alerta do Azure Monitor criadas por atacantes com iscas de faturas falsas e pagamentos não autorizados, com vítimas adicionadas diretamente ao grupo de ações vinculado à regra maliciosa. A Triskele Labs, em pesquisa liderada pelo analista Adam Skupien, chegou à mesma conclusão de forma independente e publicou uma solução concreta: encaminhar o e-mail de alertas do Azure Monitor apenas para caixas de entrada ou grupos operacionais designados, e colocar em quarentena para todos os demais. Meses depois, relatos do mesmo padrão continuam chegando, porque a brecha subjacente que torna isso possível, uma plataforma na nuvem que entregará de bom grado um texto escrito por um atacante a qualquer pessoa que o titular da conta liste como destinatário, não foi fechada no nível da plataforma.
Por que o DMARC não tem nada a dizer aqui
O DMARC, junto com SPF e DKIM, responde a uma única pergunta: se o domínio no cabeçalho From da mensagem está autorizado a enviá-la. Quando o Azure Monitor envia um alerta de [email protected], a resposta é inequivocamente sim, porque é a própria infraestrutura da Microsoft que o envia. O DMARC não tem nenhum mecanismo para perguntar quem configurou a regra de alerta, qual conta a criou, ou se o texto no campo de descrição é uma nota operacional legítima ou uma fatura fabricada. A autenticação verifica o canal. Ela nunca foi projetada para inspecionar o que um remetente legítimo deixa um atacante despejar através dele.
O que isso significa para o seu programa
Encaminhe o e-mail do Azure Monitor por um canal dedicado e monitorado. Se sua organização usa alertas do Azure Monitor, restrinja quais caixas de entrada podem recebê-los e aplique escrutínio adicional, em vez de deixar que qualquer endereço que o titular da conta digite em um grupo de ações chegue diretamente a uma caixa de entrada.
Treine os usuários para desconfiar de números de telefone tanto quanto de links. O phishing por telefone existe justamente porque as organizações passaram anos treinando as pessoas para passar o cursor sobre links e verificar domínios. Uma mensagem sem nenhum link e com um número de telefone no lugar deveria gerar a mesma suspeita, não menos.
Saiba como são realmente os seus alertas legítimos. O modelo padrão de notificação do Azure Monitor não inclui extratos de cobrança, IDs de transação ou linguagem urgente de segurança de conta. Um desvio do modelo normal é um sinal mais forte do que o endereço de envio, já que o endereço de envio será válido todas as vezes.
Não espere que a aplicação do DMARC detecte isso. Uma política estrita com p=reject no seu próprio domínio protege contra alguém que se passe por você. Ela não tem nenhum efeito sobre uma mensagem que é genuinamente da Microsoft, com conteúdo que a Microsoft nunca escreveu.
Incentive a detecção baseada em comportamento e conteúdo, não apenas a filtragem baseada em autenticação. A única razão pela qual essa campanha é detectada é que alguns defensores estão observando o que um alerta diz em relação ao que os alertas normalmente dizem, não apenas de onde ele veio.
A conclusão
Cada camada de autenticação de e-mail fez exatamente o que foi projetada para fazer em cada uma dessas mensagens, confirmou que o Azure Monitor as enviou, porque o Azure Monitor de fato o fez. A fraude vive inteiramente em um campo de texto que um serviço de nuvem legítimo vai formatar, assinar e entregar em nome de um atacante, desde que o atacante consiga criar ao menos uma assinatura gratuita. Isso não é uma falha no SPF, no DKIM ou no DMARC. É um lembrete de que autenticar um remetente e verificar o conteúdo que esse remetente escolhe entregar sempre foram dois problemas separados, e uma plataforma tão grande quanto o Azure vai continuar produzindo novas formas de nos lembrar disso.
A Excello Mail oferece visibilidade contínua sobre seus relatórios DMARC, para que você possa ver exatamente quais fontes estão se autenticando sob o seu domínio, mesmo enquanto os atacantes encontram novas formas de fazer uma plataforma legítima carregar conteúdo fraudulento em seu nome. Cadastre-se gratuitamente na Excello Mail e respalde com monitoramento real a camada de autenticação que você realmente controla.