Em 18 de agosto de 2026, pesquisadores da Huntress investigando um ataque de adversário no meio (AiTM) esbarraram no console do operador por trás dele: um kit de phishing que seu autor chama de Knight Office. Só dentro da base de clientes da Huntress, esse mesmo console foi ligado a pelo menos nove violações confirmadas em contas do Microsoft 365 e Google Workspace ao longo de duas semanas. Ampliando o rastro, os pesquisadores encontraram mais de 700 e-mails com variações da mesma isca, linha de assunto e modelo desde abril. Nada desse volume precisou falsificar o domínio que dizia proteger. Falsificou algo mais simples: o destinatário.
Uma Isca Endereçada de Você, Para Você
O primeiro movimento do Knight Office é um truque de cabeçalhos, não um truque de DNS. O e-mail de phishing falsifica seus campos From, To e Return-Path para que a mensagem pareça ter sido enviada do próprio endereço do destinatário, para o próprio endereço do destinatário, um e-mail autodirigido chegando a uma caixa de entrada que nunca o enviou. Por cima disso há um pedido de assinatura no estilo DocuSign com uma linha de assunto urgente, e os pesquisadores encontraram variantes que trocam um “l” minúsculo por um “i” em palavras como “Important” e “Signature”, uma mudança pequena o suficiente para escapar de filtros de spam baseados em correspondência de palavras-chave, ao mesmo tempo em que ainda se lê corretamente para um olho apressado. Clicar não leva a vítima direto a uma página de login falsa. Primeiro a redireciona por meio do Monday.com, uma plataforma legítima de gestão de trabalho, depois por um site Joomla comprometido, antes de finalmente pousar na página construída para roubar algo real.
O Código de Dispositivo É o Ataque Inteiro
Essa página final imita o fluxo de login por código de dispositivo da Microsoft, o mecanismo legítimo que as pessoas usam para autorizar uma TV, uma ferramenta de linha de comando, ou outro dispositivo que não aceita facilmente uma senha digitada. A vítima insere o código mostrado a ela, completa seu login normal exatamente como faria em qualquer dia sem nada de especial, incluindo sua própria etapa de MFA, e ao fazer isso entrega ao Knight Office um token de sessão ativo e totalmente autenticado. Nenhuma senha foi roubada por phishing. Nenhum aviso de MFA foi vencido. O kit nunca precisou de nenhum dos dois, porque um token de sessão válido já carrega ambos.
Uma Porta dos Fundos Construída a Partir de um Recurso de Segurança
Roubar o token não é onde o Knight Office para. A Huntress descobriu que, uma vez dentro, os atacantes registram um dispositivo não autorizado e controlado pelo atacante contra o locatário do Microsoft Entra ID da vítima, e vinculam uma credencial do Windows Hello for Business sem senha à conta comprometida. Essa única etapa transforma um recurso pensado para tornar o login mais seguro em um caminho de volta: mesmo depois que o token de sessão roubado original é revogado, a credencial WHfB vinculada pelo atacante continua funcionando, porque nunca esteve ligada ao roubo que foi detectado. O sinal de alerta é específico o bastante para ser rastreado: um novo registro de dispositivo e uma credencial de chave WHfB recém-criada aparecendo pouco depois da reutilização de um token de sessão vindo de um IP desconhecido não é como um usuário legítimo se reautentica.
Por Que o DMARC Nunca Foi a Camada Que Vigiava Isso
O DMARC responde a uma pergunta estreita: esta mensagem está autorizada, por alinhamento de SPF ou DKIM, a reivindicar o domínio em seu cabeçalho From? O e-mail inicial do Knight Office reivindica sim um domínio, tecnicamente, já que o endereço From falsificado precisa resolver para algo. Mas o truque que faz o trabalho real aqui não é a falsificação de domínio no sentido que o DMARC foi construído para policiar. É um sinal de confiança dirigido à pessoa que lê a mensagem e, tantas vezes quanto isso, à pilha de segurança de e-mail por trás dela. Muitas configurações antiphishing aplicam seu escrutínio mais afiado a e-mails que dizem vir do domínio de outra pessoa, e afrouxam com mensagens que parecem se originar dentro do próprio locatário do destinatário, sob a suposição de que o e-mail intra-domínio é mais seguro por padrão. Uma mensagem falsificada para parecer autoenviada pode passar direto por essa suposição, diante de um filtro ajustado para vigiar as saídas, não o espelho.
Essa é uma brecha diferente das que este blog já percorreu, o caminho de retransmissão anônima fechado ao rejeitar o Direct Send, ou a tag SCL:-1 em lista de confiança que deixa passar e-mail falsificado sem sequer passar pela aplicação antiphishing. O Knight Office não precisa de nenhuma das duas. Ele precisa que o próprio endereço de um destinatário pareça seguro de ver na própria caixa de entrada, e uma página de código de dispositivo convincente o bastante para fazer entregar uma sessão ativa parecer rotina.
O Que Isso Significa Para Seu Programa
Trate “o remetente corresponde ao meu próprio domínio” como um sinal para verificar, não como um motivo para relaxar. Se sua política antiphishing ou seu gateway de e-mail seguro dá ao e-mail intra-domínio uma revisão mais leve do que ao e-mail externo, essa configuração é exatamente o que uma isca autofalsificada foi construída para explorar. A proteção contra falsificação de domínio precisa cobrir mensagens que dizem vir do seu próprio locatário, não só de domínios parecidos com os de outra pessoa.
Treine as pessoas para desconfiar de avisos de código de dispositivo que elas mesmas não iniciaram. Um login por código de dispositivo só deveria seguir uma ação que o próprio usuário acabou de realizar em um dispositivo novo. Um código que aparece depois de clicar em um link de e-mail não é isso, e vale a pena tornar essa distinção tão explícita e repetida quanto qualquer aviso de phishing de senha.
Procure pelo padrão de persistência, não só pelo clique inicial. Um novo registro de dispositivo e uma credencial do Windows Hello for Business recém-vinculada após a reutilização de um token de sessão vindo de um IP não reconhecido é uma sequência específica e detectável. Revogar um token de sessão roubado sem verificar se há um registro de dispositivo não autorizado por trás disso deixa a porta dos fundos real de pé.
Lembre-se de que o DMARC protege o domínio, não a decisão de entrega. Um domínio pode ter uma política DMARC rigorosa de manual e ainda assim ver phishing chegar, porque o DMARC nunca foi posicionado para avaliar a cadeia de redirecionamentos de uma mensagem, sua página de código de dispositivo, ou as heurísticas de confiança intra-locatário que sua plataforma de e-mail aplica antes mesmo de sua política ser consultada.
A Conclusão
O Knight Office não precisou quebrar SPF, DKIM ou DMARC para alcançar 700 caixas de entrada e pelo menos nove comprometimentos confirmados. Precisou de um truque de cabeçalhos que soa familiar, uma cadeia de redirecionamentos que parece tráfego web comum, e uma página de código de dispositivo construída para capturar um token de sessão em trânsito. O DMARC fez seu trabalho em cada uma dessas mensagens, avaliando exatamente o que foi construído para avaliar. O ataque simplesmente entrou por uma porta que esse trabalho nunca teve a tarefa de vigiar.
O DMARC diz a você se uma mensagem está autorizada a reivindicar seu domínio. Ele não pode dizer se sua própria plataforma de e-mail está confiando silenciosamente em mensagens que só parecem vir de dentro dos seus muros. O Excello Mail oferece visibilidade contínua e em linguagem clara sobre sua postura real de autenticação, para que você saiba exatamente onde termina a cobertura do DMARC e onde o resto da sua defesa precisa começar. Cadastre-se gratuitamente no Excello Mail e veja hoje sua imagem real de autenticação.