Knight Office rouba sessões do Microsoft 365 após MFA — e o risco vai além da senha

O Knight Office reforça uma distinção essencial para equipes de segurança: o MFA valida o login, mas não protege automaticamente toda sessão criada depois dele. No incidente documentado pela Huntress, um ataque de adversary-in-the-middle (AiTM, ou adversário no meio) capturou material de sessão do Microsoft 365 e foi seguido pelo registro não autorizado de um dispositivo no Microsoft Entra ID. Portanto, o enquadramento operacional correto é comprometimento de identidade, não mero roubo de senha. 640

Como funciona a cadeia de ataque

A sequência observada começou com um e-mail de phishing no estilo DocuSign. O link passava por um serviço de rastreamento do Monday.com e, em seguida, por um site Joomla comprometido. A cadeia dificultava que verificações de reputação e análises simples do link no e-mail encontrassem o destino final do phishing. 6

Na etapa seguinte, uma página convincente que imita um fluxo de colaboração ou de login da Microsoft pode induzir a vítima a continuar a autenticação, inclusive em uma interação semelhante à de código de dispositivo. O objetivo é fazer com que a pessoa aprove um processo de autenticação que parece legítimo.

No componente AiTM, os criminosos operam um proxy reverso entre a vítima e o serviço legítimo de login da Microsoft:

1. A vítima informa as credenciais e conclui o desafio normal de MFA.
2. O proxy retransmite essas interações para a Microsoft em tempo real.
3. Após a autenticação, o invasor captura o cookie de sessão autenticada ou outro material de token enviado ao navegador.
4. O invasor reproduz esse estado autenticado em sua própria infraestrutura para acessar a conta.

Isso não significa que o MFA foi quebrado criptograficamente. O que foi roubado é o estado de autorização emitido depois do MFA. A Microsoft define roubo de token como o comprometimento e a reprodução de tokens emitidos para um usuário que pode já ter satisfeito a autenticação multifator. 40

Por que trocar a senha pode não encerrar o incidente

Uma sessão de navegador roubada, ou acesso derivado de um token de atualização (refresh token), pode permitir que o invasor continue operando sem novo pedido de senha ou MFA até que os tokens relevantes sejam revogados. A orientação da Microsoft para roubo de token determina bloquear usuários ou dispositivos afetados e revogar os tokens atuais. 40

No caso Knight Office, a atividade pós-comprometimento relatada incluiu registrar uma máquina não autorizada no Microsoft Entra ID e configurar credenciais do Windows Hello for Business controladas pelo invasor. 6 Isso pode abrir uma via de autenticação separada: mesmo depois de revogar a sessão web original ou redefinir a senha, a equipe precisa confirmar que não permaneceu nenhum dispositivo não autorizado nem método de autenticação recém-criado.

A mesma lógica de persistência já foi documentada em pesquisas sobre phishing com código de dispositivo. A Microsoft relatou que um refresh token obtido por abuso desse fluxo pode ser usado para solicitar acesso ao serviço de registro de dispositivos e cadastrar no Entra ID um dispositivo controlado pelo agente da ameaça. 28

Phishing por código de dispositivo é relacionado, mas não igual a AiTM

O phishing AiTM intermedia um login ao vivo e rouba a sessão resultante. Já o phishing por código de dispositivo explora um fluxo legítimo de autorização de dispositivo do OAuth: o invasor inicia uma solicitação de código, convence a vítima a informar esse código e a se autenticar e, se ela aprovar, recebe tokens para o cliente controlado por ele. 22

As duas técnicas mudam o alvo do criminoso: em vez de coletar só a senha, ele busca artefatos de autorização que possam ser usados de imediato. A detecção precisa abranger os dois caminhos. A orientação da Elastic destaca logins interativos bem-sucedidos no Entra que usam o protocolo de código de dispositivo com o cliente Microsoft Authentication Broker e solicitam recursos próprios, como Exchange Online, Microsoft Graph ou SharePoint. 17

Atividade observada e o contexto do phishing como serviço

A investigação da Huntress estabeleceu uma sequência real de intrusão do Knight Office: isca temática de documento, redirecionamentos em múltiplas etapas, captura de token de sessão e registro não autorizado de dispositivo no Entra ID. A Huntress também associou reproduções repetidas de tokens em sua telemetria a um único endereço IP, mas essa observação não deve ser tratada como total global de vítimas. 6

O Knight Office se encaixa em um mercado mais amplo de kits de phishing como serviço (phishing-as-a-service, ou PhaaS) voltados a sessões de identidade do Microsoft 365:

• Mirage2FA usa infraestrutura AiTM para capturar credenciais e sessões autenticadas. A ANY.RUN relatou 9.332 eventos potenciais de comprometimento entre 2024 e 2026, dos quais 4.561 envolveram roubo de cookies. São eventos potenciais baseados em telemetria, não uma contagem de vítimas confirmadas. 4
• Kali365, identificado pela primeira vez em abril de 2026 e distribuído principalmente pelo Telegram, foi alvo de alerta do FBI por sua capacidade de obter tokens OAuth de acesso e atualização do Microsoft 365. 1

A lição defensiva é direta: sessões e tokens precisam receber o mesmo nível de proteção, detecção e resposta aplicado ao comprometimento de senhas.

Prioridades de detecção no Entra ID e Microsoft 365

O foco deve estar em correlações, não em um alerta isolado.

1. Identifique reprodução suspeita de sessão

Investigue logins em que a mesma conta ou sessão aparece, em curto intervalo, a partir de IPs, redes, localizações geográficas, navegadores ou propriedades de dispositivo materialmente diferentes — sobretudo logo após um MFA bem-sucedido. A Microsoft mantém detecções para uso anômalo de token e propriedades de login desconhecidas associadas a cookies de sessão. 38

2. Procure atividade suspeita de código de dispositivo

Revise autenticações bem-sucedidas por código de dispositivo e avalie se cliente, IP de origem, recurso solicitado e comportamento do usuário fazem sentido. Nos logs de login do Entra, essa atividade pode ser identificada por campos como authenticationProtocol: deviceCode e originalTransferMethod: deviceCodeFlow. 26

3. Monitore alterações que criam persistência

Dê prioridade a eventos de auditoria do Entra que envolvam:

• Registros, ingressos, mudanças de propriedade ou identificadores incomuns de dispositivos;
• Inclusão de novos métodos Windows Hello for Business, FIDO2/chave de acesso, MFA ou recuperação de conta;
• Concessões de consentimento a aplicativos, mudanças em aplicativos empresariais, entidades de serviço ou atribuições de funções privilegiadas;
• Alterações em Acesso Condicional, locais nomeados, federação, encaminhamento de e-mail e regras de caixa de entrada.

Um registro não autorizado de dispositivo logo após uma autenticação suspeita deve ser tratado como forte sinal de persistência na identidade. 2628

4. Correlacione evidências de e-mail e identidade

Uma mensagem com tema DocuSign isolada pode ser apenas spam; um novo dispositivo no Entra, por si só, pode ser legítimo. Já a combinação entre mensagem suspeita, evidências da cadeia de redirecionamento, MFA bem-sucedido, reutilização anômala de sessão e alteração em dispositivo ou método de autenticação é muito mais acionável.

Resposta ao incidente: contenha a identidade, não apenas a senha

Em uma suspeita de roubo de token por AiTM ou código de dispositivo, adote um fluxo de contenção de identidade:

1. Bloqueie ou desabilite a identidade afetada, quando necessário. Desabilite contas de usuário e de dispositivo afetadas enquanto o escopo é apurado. 40
2. Revogue sessões atuais e tokens de atualização. Execute a revogação das sessões de login no Entra e force nova autenticação. Para resposta a phishing por código de dispositivo, a Microsoft recomenda especificamente revogar refresh tokens com revokeSignInSessions. 27
3. Redefina as credenciais, mas não pare nisso. Trocar a senha é uma medida complementar; não prova que o acesso do invasor foi removido. 4042
4. Elimine a persistência. Identifique e remova dispositivos não autorizados do Entra; revise a propriedade dos dispositivos; retire métodos recém-adicionados de Windows Hello for Business, FIDO2, MFA, recuperação e credenciais de aplicativos; e examine consentimentos concedidos. 628
5. Faça busca em todo o tenant. Procure URLs de isca, infraestrutura de redirecionamento, IPs suspeitos, eventos de código de dispositivo, anomalias de login após MFA e novos registros de dispositivos em todos os usuários.
6. Avalie o impacto de negócio. Revise a atividade de Exchange, SharePoint, OneDrive, Teams, Microsoft Graph, OAuth e administração em busca de acesso a dados, regras de caixa de entrada, encaminhamento, compartilhamento externo, abuso de consentimento, mudanças de privilégio e acesso a aplicações conectadas por SSO.
7. Preserve evidências antes da limpeza. Retenha mensagens e cabeçalhos de phishing, rastreamentos de e-mail, cadeias de redirecionamento, logs de login e auditoria do Entra, registros de dispositivos, dados de consentimento OAuth e telemetria de navegador ou endpoint.

Como reduzir a exposição antes da próxima isca

Autenticação resistente a phishing é um controle importante para usuários de maior risco, mas deve fazer parte de uma estratégia em camadas. A Microsoft recomenda métodos como chaves de segurança FIDO2, Windows Hello for Business e autenticação baseada em certificado, além de controles que reduzam a vida útil de sessões em dispositivos não gerenciados. 39

As organizações também devem avaliar se o fluxo de código de dispositivo é realmente necessário, restringir registros não autorizados de dispositivos, aplicar políticas de Acesso Condicional baseadas em dispositivo compatível e risco, e garantir que a equipe operacional consiga revogar sessões e investigar rapidamente mudanças em objetos de identidade.

A principal lição do Knight Office não é que o MFA falhou. É que um MFA bem-sucedido pode ser o começo do comprometimento quando o invasor rouba a sessão criada logo depois. A resposta só estará completa quando sessões, dispositivos, métodos de autenticação e acessos delegados do tenant tiverem sido verificados e contidos.