Uma investigação técnica sobre como erros de design no fluxo de registro de dispositivos do Entra ID podem anular o segundo fator de autenticação e expor infraestruturas críticas.
O Vetor de Ataque: De Senha Roubada a Passe Livre
Imagine que um atacante obteve a senha de um colaborador via phishing ou vazamento. Em uma organização com MFA obrigatório, o ataque deveria parar ali. No entanto, se o fluxo de registro de dispositivos (Register or join devices) não estiver protegido, o atacante pode usar essa senha para registrar sua própria máquina no tenant da empresa.
Uma vez registrado, esse dispositivo “atacante” pode ser classificado como Azure AD joined ou até compliant (se houver falhas no enrolment do Intune). O perigo real surge quando as políticas de Acesso Condicional isentam esses estados de dispositivo de pedir MFA, assumindo que se o dispositivo é “da empresa”, o usuário é legítimo.
Configurações que Deixam seu Entra ID Inseguro
Existem três pontos principais de falha que, combinados, criam essa brecha:
- Registro de Dispositivos sem MFA: A ausência de uma política de Acesso Condicional focada na ação “Register or join devices” permite que novos equipamentos entrem no inventário apenas com usuário e senha.
- Confiança Implícita no Estado do Dispositivo: Políticas que usam “Require device to be marked as compliant” ou “Require Hybrid Azure AD joined device” como substitutos (OR) para o MFA, em vez de requisitos adicionais (AND).
- Exclusões de Escopo em Apps de Primeiro Partido: Deixar aplicações como “My Profile” (myaccount.microsoft.com) fora das políticas de MFA, permitindo a obtenção de tokens SSO iniciais que facilitam o registro do dispositivo.
Como Saber se Você Está Vulnerável?
Você pode validar sua postura seguindo este checklist:
- Verifique o Registro: No portal Entra, procure por políticas de Acesso Condicional com o alvo User actions > Register or join devices. Se não houver uma exigindo MFA para todos os usuários, você está exposto.
- Analise os Grants: Filtre políticas que dão acesso a apps sensíveis. Se elas permitem acesso apenas com o requisito de Device Compliance (sem MFA), o risco é alto.
- Simulação What If: Use a ferramenta What If do Conditional Access. Simule um login de um usuário padrão a partir de um dispositivo marcado como Azure AD joined. Se o resultado indicar “MFA not required”, a vulnerabilidade conceitual existe.
Monitoramento e Detecção
A exploração desse bypass deixa rastros nos logs do Entra ID que devem ser monitorados pelo SOC:
- Sign-in Logs: Procure por logons bem-sucedidos onde o MFA result seja “not required”, mas o dispositivo apareça como Registered ou Compliant, cruzando com a data de criação do dispositivo.
- Audit Logs: Monitore eventos de “Add device”. Alertas devem ser disparados quando um novo dispositivo é criado e, minutos depois, realiza o primeiro login em um app crítico sem desafio de MFA.
- Identity Protection: Utilize o Sign-in Risk. Mesmo que a política dispense o MFA pelo dispositivo, um comportamento anômalo de IP ou localização deveria forçar o segundo fator.
Conclusão e Endurecimento
Para fechar essa brecha, a recomendação é clara: nunca trate o estado do dispositivo como um substituto para o MFA. Implemente uma política global exigindo MFA para o registro de qualquer dispositivo e garanta que o acesso a recursos sensíveis exija MFA + Device Compliance (requisitos cumulativos).
Pesquisa e análise: N00TROPX1C — NULLTROPIC, 2026.
Deixe um comentário