Entra ID: Replay de Token AiTM, Detecção de Viagem Impossível e MFA Push Fatigue

Entra ID: Replay de Token AiTM e Detecção de Viagem Impossível — Por Que Isso Importa Agora

A autenticação multifator interrompe ataques baseados apenas em senha. Ela não interrompe um invasor que faz proxy de todo o fluxo de login e sai com um cookie de sessão válido depois que o usuário conclui o MFA. É isso que os kits de phishing adversary-in-the-middle (AiTM) fazem, e é exatamente essa lacuna que os sinais de replay de token AiTM do Entra ID, detecção de viagem impossível e MFA push fatigue foram criados para fechar. A Microsoft tem sido explícita quanto ao fato de que essa classe de ataque representa uma parcela crescente das comprometimentos de identidade: o blog de segurança da Microsoft sobre técnicas de ataque a identidades em evolução, além de vários relatos de incidentes, descrevem kits AiTM como o Evilginx implantando um proxy reverso entre a vítima e a página real de login do Microsoft 365, servindo o conteúdo legítimo enquanto captura nome de usuário, senha e — de forma crítica — o token de sessão/atualização emitido após o sucesso do MFA. A Deepwatch documenta o mesmo kit sendo usado por atores de ameaça que vão desde o prolífico operador de phishing Storm-0485 até o ator de espionagem russo Star Blizzard para interceptar silenciosamente sessões do Microsoft 365.

A Microsoft Entra ID Protection transforma esse tipo de atividade em sinais de risco, mas esses sinais estão espalhados por várias detecções distintas, tabelas de log e níveis de licenciamento. Este artigo é um guia de campo para ler cinco deles em conjunto:

• Replay de token AiTM — um token de sessão ou de atualização roubado é reutilizado a partir de uma infraestrutura que o usuário real nunca tocou
• Viagem impossível / atípica — dois logins da mesma identidade, geograficamente distantes demais para que ambos sejam legítimos
• Abuso de aprovação push MFA — um invasor com uma senha válida tenta convencer o usuário a aprovar uma notificação push que ele não solicitou
• Picos de login de service principal — uma identidade de workload de repente se autentica com muito mais frequência, ou de forma muito mais ampla, do que sua linha de base
• Geografia incomum para contas de administrador — uma identidade privilegiada faz login a partir de um local ou dispositivo que nunca usou antes

Como Cada Sinal Aparece na Telemetria do Entra ID

Proxies AiTM e replay de token

A MITRE rastreia o roubo de cookies de sessão como T1539 (Steal Web Session Cookie). Um kit AiTM fica entre o usuário e o endpoint real de login da Microsoft, retransmite cada etapa da autenticação — incluindo o desafio de MFA — e depois captura o artefato de sessão resultante. Como a vítima realmente concluiu o MFA, o token roubado carrega essa reivindicação adiante. O invasor o reproduz a partir de sua própria infraestrutura, não do dispositivo ou da rede da vítima.

A Microsoft Entra ID Protection tem várias detecções que capturam partes disso:

• Anomalous token (riskEventType: anomalousToken) — dispara com características anômalas do token: uma duração incomum, ou um token usado a partir de um local, aplicativo, endereço IP ou user agent que não corresponde ao histórico do usuário. A própria documentação da Microsoft cita isso como um indicador direto de possível replay de token. É em tempo real ou offline e requer Entra ID P2.
• Attacker in the Middle (attackerinTheMiddle, uma detecção de risco de usuário) — uma detecção de alta precisão, disparada quando uma sessão de login é vinculada a um proxy reverso malicioso conhecido, com origem na telemetria do Microsoft Defender for Cloud Apps. Ela eleva o usuário diretamente para risco Alto e requer Microsoft 365 E5 com Enterprise Mobility + Security E5 — diferente da maioria das demais detecções originadas do Defender for Cloud Apps, a Microsoft não lista um caminho de licenciamento independente Entra ID P2 + Defender for Cloud Apps para esta.
• Unfamiliar sign-in properties (unfamiliarFeatures) — compara um login com o histórico aprendido do usuário (IP, ASN, local, dispositivo, navegador, sub-rede do tenant). A orientação da Microsoft sinaliza especificamente: quando dispara em um login não interativo, merece atenção extra, pois esse padrão é consistente com um refresh token repetido silenciosamente em segundo plano, em vez de por meio de um logon interativo.
• Token issuer anomaly (tokenIssuerAnomaly) — para tokens SAML, sinaliza claims de emissor que são incomuns ou correspondem a padrões conhecidos de invasores.

O playbook de roubo de token da Microsoft lista os gatilhos concretos para os quais um SOC deve alertar em investigações de roubo de token: anomalous token, unfamiliar sign-in properties, logins não interativos de fontes desconhecidas, tentativas de acesso a um Primary Refresh Token (PRT, via Defender for Endpoint) e URLs suspeitas consistentes com uma página de destino AiTM.

Viagem impossível e viagem atípica

A Entra ID Protection na verdade oferece duas detecções relacionadas, mas distintas, aqui, e confundi-las leva a suposições erradas de licenciamento e ferramentas:

• Impossible travel (mcasImpossibleTravel) — identifica atividade em locais geograficamente distantes dentro de uma janela de tempo mais curta do que uma viagem fisicamente possível entre eles permitiria. Tem origem no Microsoft Defender for Cloud Apps, é calculada offline e requer Entra ID P2 mais uma licença independente do Defender for Cloud Apps (ou Microsoft 365 E5).
• Atypical travel (unlikelyTravel) — uma detecção nativa da Entra ID Protection (sem dependência do Defender for Cloud Apps) que sinaliza dois logins de locais distantes onde pelo menos um também é atípico para o histórico daquele usuário específico. Ela leva em conta o tempo de viagem entre locais e suprime deliberadamente falsos positivos comuns, como pontos de saída de VPN e IPs compartilhados em toda a organização. Novos usuários passam por um período de aprendizado de 14 dias ou 10 logins, o que ocorrer primeiro, antes que a detecção seja ativada.

Ambas requerem Entra ID P2. Se o seu tenant tiver apenas P1 ou Free, elas disparam como a detecção genérica Additional risk detected, sem detalhes.

Abuso de aprovação push MFA, em resumo

Dois sinais nativos do Entra são relevantes aqui: Suspicious MFA authentication approval (authenticatorPhishing) é uma detecção em tempo real, exclusiva do P2, que correlaciona incompatibilidades de ASN, navegador, dispositivo e GPS entre o dispositivo que solicita o login e o dispositivo que o aprova via Microsoft Authenticator, sinalizando o par diretamente como risco Alto. User reported suspicious activity (userReportedSuspiciousActivity) dispara quando um usuário nega um prompt de MFA que não iniciou e o reporta explicitamente — a Microsoft trata isso como evidência de alta confiança, confirmada pelo usuário, e define a conta como risco de usuário Alto imediatamente. Apenas o segundo depende de o recurso Report suspicious activity estar ativado; authenticatorPhishing dispara automaticamente a partir da telemetria de login e não requer opt-in separado. Para a cadeia de ataque completa e a sequência de hardening (number matching, MFA resistente a phishing para administradores, fluxo de resposta), veja o artigo dedicado linkado acima.

Picos de login de service principal

Identidades de workload não aparecem na mesma tabela SigninLogs que os usuários — elas registram em AADServicePrincipalSignInLogs (também chamada de ServicePrincipalSignInLogs, dependendo da nomenclatura do workspace/tabela). A orientação de auditoria de Thomas Naunheim para identidades gerenciadas e service principals recomenda agrupar por ServicePrincipalName e IPAddress, e depois agregar contagens de falhas (ResultType != "0") e a diversidade de recursos acessados (dcount(ResourceDisplayName)) — um pico em qualquer uma das dimensões, especialmente vindo de um IP ou ASN que o service principal nunca usou, é o sinal a investigar. A Microsoft Entra ID Protection também tem uma superfície de detecção dedicada de risco de identidade de workload exatamente para esse cenário, separada do risco de usuário.

Geografia incomum para contas de administrador

O próprio guia de operações de segurança da Microsoft para contas privilegiadas é explícito ao afirmar que logins de administrador merecem um monitoramento mais rigoroso e separado do que usuários padrão — novo dispositivo ou local, logins fora do horário de trabalho esperado, e qualquer detecção de risco da Entra ID Protection (em qualquer nível de risco) em uma identidade privilegiada devem gerar um alerta de alta prioridade. O mesmo guia recomenda tratar qualquer atividade de Unfamiliar sign-in ou originada de TOR contra uma função privilegiada como digna de revisão imediata, em vez de esperar que ela escale para risco alto.

Detecção: O Que Extrair dos Logs

O playbook de roubo de token do Microsoft Entra fornece consultas iniciais concretas para SigninLogs, AADUserRiskEvents e AuditLogs. Adaptadas aqui para o conjunto de sinais de AiTM/viagem/geografia de administrador:

Encontrar detecções de risco marcadas como unfamiliar ou anomalous a partir de um IP específico (ponto de partida assim que você tiver um IP suspeito de um relatório de phishing ou alerta de EDR):

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "<suspect-ip>"

Extrair todos os logins do mesmo IP de origem para dimensionar o raio de impacto:

SigninLogs
| where IPAddress == "<suspect-ip>"

Estabelecer a linha de base de geografia de login e dispositivos de uma identidade específica — esta é a consulta que o playbook recomenda antes de decidir se um login sinalizado é genuinamente anômalo para aquele usuário:

SigninLogs
| where UserId == "<user-object-id>"
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| extend city_ = tostring(LocationDetails.city)
| extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
| summarize min(TimeGenerated), max(TimeGenerated)
  by IPAddress, ResultDescription, deviceId_, city_, countryOrRegion_, AppDisplayName

O playbook observa explicitamente que nem todo alerta de risco do Entra tem uma linha correspondente em SigninLogs — as detecções de anomalous token, em particular, às vezes só ficam visíveis via AADUserRiskEvents ou pela API de risk-detections do ID Protection, não pelo stream bruto de logins.

Pico de service principal, adaptado da orientação de auditoria do cloud-architekt.net:

AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(1d)
| where ResultType != "0"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated),
    count(), applicationCount = dcount(ResourceDisplayName),
    applicationSet = make_set(ResourceDisplayName)
  by ServicePrincipalName, IPAddress, ResultType

Para geografia de contas privilegiadas e monitoramento de negação de MFA, a Microsoft disponibiliza conteúdo pronto do Sentinel em vez de uma única consulta para copiar — o guia de operações de segurança para contas privilegiadas aponta para templates nomeados, incluindo SuspiciousSignintoPrivilegedAccount.yaml, MFARejectedbyUser.yaml e AADPrivilegedAccountsFailedMFA.yaml no repositório GitHub Azure-Sentinel, que é uma fonte de verdade melhor do que reconstruir aqui a lógica exata de filtro.

Remediação

Para AiTM / replay de token:

1. Migrar contas privilegiadas e de alto valor para MFA resistente a phishing (chaves de segurança FIDO2 ou autenticação baseada em certificado) — um cookie de sessão via proxy é muito menos útil para um invasor se a cerimônia de autenticação original não puder simplesmente ser retransmitida. Veja Azure Identity Security: Por Que o MFA Sozinho Não É Suficiente para entender por que o push MFA padrão não é suficiente por si só.
2. Ativar a Continuous Access Evaluation e a proteção de token do Conditional Access onde houver suporte, para que um token vinculado a um dispositivo não possa simplesmente ser reproduzido a partir da infraestrutura do invasor. O catálogo da EtcSec rastreia essa lacuna diretamente como CA_TOKEN_PROTECTION_DISABLED — veja Lacunas de Conditional Access no Entra ID para a revisão de políticas mais ampla.
3. Ativar as detecções Attacker in the Middle e Anomalous token (requer P2, e Defender for Cloud Apps para a primeira) e direcioná-las para uma política de Conditional Access de risco de login, em vez de deixá-las apenas como visibilidade no dashboard.
4. Tratar um AiTM confirmado como um incidente de roubo de token, não como uma redefinição de senha: seguir os passos de contenção do playbook de roubo de token da Microsoft — revogar sessões, bloquear o IP do invasor e verificar se há métodos MFA recém-registrados ou regras de caixa de correio deixadas para trás depois que a sessão foi usada.

Para viagem impossível / atípica:

1. Confirmar o licenciamento — a atypical travel é nativa do ID Protection P2, mas a impossible travel também exige o Defender for Cloud Apps conectado. A falta dessa conexão descarta silenciosamente o sinal mcasImpossibleTravel.
2. Deixar a janela de aprendizado de 14 dias/10 logins ser concluída para contas novas ou recém-migradas antes de ajustar limiares com base em dados iniciais ruidosos.
3. Alimentar o risco de login em uma política de Conditional Access que exija MFA ou bloqueie em risco médio/alto, em vez de apenas revisar o relatório de logins de risco de forma reativa.

Para abuso de aprovação push MFA: ative o number matching e o recurso Report suspicious activity, e exija MFA resistente a phishing para administradores — veja a sequência completa no artigo dedicado sobre MFA fatigue.

Para picos de service principal:

1. Revisar AADServicePrincipalSignInLogs em busca de comportamento de linha de base versus picos em uma cadência recorrente, não apenas durante a resposta a incidentes.
2. Evitar funções de alto privilégio permanentes em service principals; rotacionar client secrets/certificados em um cronograma definido e preferir managed identities sempre que possível.
3. Ativar as detecções de risco de identidade de workload da Entra ID Protection, se licenciado para isso — políticas de risco de usuário não cobrem service principals.

Para geografia incomum de administrador:

1. Inscrever todas as funções privilegiadas no Privileged Identity Management (PIM) com ativação limitada no tempo e exigir reautenticação na ativação.
2. Alertar sobre qualquer detecção de risco do ID Protection contra uma identidade privilegiada, independentemente do nível de risco atribuído pela Microsoft — a própria orientação da Microsoft para contas privilegiadas recomenda esse padrão mais rigoroso em relação aos usuários padrão.
3. Restringir a elevação de administrador a dispositivos aprovados (PAW/SAW) sempre que viável, e alertar quando a elevação ocorrer fora desse grupo de dispositivos.

Como a EtcSec Detecta Isso

As categorias Risk Protection e Conditional Access da EtcSec verificam se um tenant tem o arcabouço de política e licenciamento do qual essas detecções dependem, não apenas se a Entra ID Protection está ativada. Verificações relevantes do catálogo incluem MFA_SUSPICIOUS_ACTIVITY (padrão de atividade suspeita de MFA/login) e MFA_UNUSUAL_LOCATION (login MFA a partir de geolocalização incomum) no nível do sinal, além de RISK_NO_SIGNIN_RISK_POLICY (nenhuma política de risco de login impondo uma resposta), RISK_SIGNINS_NOT_INVESTIGATED (logins de risco se acumulando sem revisão) e CA_TOKEN_PROTECTION_DISABLED (nenhuma vinculação de token para dificultar o replay) no nível da resposta.

Um tenant que mostra logins de risco no portal, mas não tem nenhuma política agindo sobre eles, e nenhuma proteção de token à frente dos cookies de sessão, é exatamente a lacuna que essas verificações foram criadas para revelar.

Controles Relacionados

Leia isso junto com Azure Identity Protection: Bloqueando Credenciais Vazadas para a configuração de políticas de risco de login e de usuário, MFA Fatigue: Detecção e Prevenção no Microsoft Entra ID para a cadeia de ataque de aprovação push, Azure Privileged Access: Gerenciamento de Acesso Privilegiado no Azure — Riscos sem PIM e Como Auditar a Segurança do Microsoft Entra ID para o lado de PIM e hardening de administradores, e Phishing de Consentimento OAuth e Apps Maliciosos e Device Code Phishing no Entra ID para técnicas adjacentes de phishing de identidade que alimentam os mesmos sinais de risco.

Referências Primárias

• Microsoft Learn: What are risk detections? (Entra ID Protection)
• Microsoft Learn: Token theft playbook
• Microsoft Learn: Security operations for privileged accounts
• Microsoft Learn: Securing workload identities with Entra ID Protection
• Microsoft Learn: How number matching works in MFA push notifications
• MITRE ATT&CK: Steal Web Session Cookie (T1539)
• nicolonsky/ITDR: AiTM phishing detection in Entra ID
• cloud-architekt.net: Sign-in logs and auditing of managed identities and service principals
• Microsoft Security Blog: Defending against evolving identity attack techniques
• Elastic Security Labs: Microsoft Entra ID OAuth phishing and detections