Entra ID Risk Protection: Credenciais Vazadas, Usuarios de Risco Nao Corrigidos

Entra ID Risk Protection: Credenciais Vazadas, Usuarios de Risco Nao Corrigidos

O Entra ID Risk Protection nao tem dificuldade em encontrar contas comprometidas. O problema e o que acontece depois. Em um grande numero de tenants, o mesmo padrao se repete — credenciais vazadas e usuarios de risco ficam sem correcao por semanas ou meses — porque a deteccao dispara, cai em um relatorio e fica ali parada. Este artigo trata dessa lacuna: nao da engenharia de deteccao, que a Microsoft ja resolve por voce, mas do fluxo de resposta que quase ninguem operacionaliza.

Todo usuario de risco no Entra ID carrega um estado de risco. O Microsoft Graph documenta os valores possiveis como none, confirmedSafe, remediated, dismissed, atRisk e confirmedCompromised (alem do valor sentinela unknownFutureValue). Apenas tres deles removem uma conta sinalizada da fila — remediated, dismissed e confirmedSafe —, correspondendo as acoes manuais que a Microsoft disponibiliza: descartar, confirmar seguranca, confirmar comprometimento. Tanto atRisk quanto confirmedCompromised deixam o usuario parado no relatorio de usuarios de risco. atRisk significa que a conta continua sinalizada e nada foi feito a respeito. confirmedCompromised e o que costuma surpreender: um administrador analisou a conta, concordou que estava comprometida — e esse estado sozinho ainda nao significa que alguem protegeu a conta.

Confirmar o comprometimento e uma acao de rotulagem, nao de contencao. O mesmo vale para o descarte.

O backlog tambem nao expira sozinho. Deteccoes e usuarios de risco baixo "permanecem no produto por seis meses, apos os quais sao removidos automaticamente" — mas os niveis de risco medio e alto permanecem ate serem corrigidos ou descartados. Uma deteccao de alto risco de credenciais vazadas gerada ha dois anos ainda esta no relatorio de usuarios de risco hoje, a menos que uma pessoa ou uma politica a tenha fechado.

Como Funciona a Deteccao de Credenciais Vazadas

Credenciais vazadas e uma das poucas deteccoes de risco que nao carrega nenhuma ambiguidade.

A Microsoft descreve o pipeline por tras disso: um servico de varredura de credenciais em grande escala que monitora continuamente foruns da dark web, repositorios de vazamentos, sites de paste, dados apreendidos por autoridades policiais e outras fontes, por meio do Microsoft Threat Intelligence Center (MSTIC), da Microsoft Digital Crimes Unit (DCU) e de parceiros do setor. Quando credenciais sao descobertas, o servico valida o material de credencial real contra os hashes de senha atualmente validos do tenant, e uma deteccao e emitida somente quando uma correspondencia confirmada e encontrada. Nas palavras da propria Microsoft, a deteccao "e sempre de alto risco porque representa exposicao verificada de credenciais, nao um sinal heuristico".

Disso decorrem duas consequencias operacionais.

Primeiro, isto nao e uma pontuacao de probabilidade. Viagem atipica pode ser um usuario de ferias. Uma deteccao de credenciais vazadas significa que uma senha que atualmente funciona no seu tenant esta em maos de outra pessoa. Isso merece um incidente, nao uma fila de triagem.

Segundo, voce fica sabendo tarde. Credenciais vazadas e calculada offline, e a Microsoft documenta que "deteccoes disparadas em tempo real levam de 5 a 10 minutos para aparecer nos relatorios. Deteccoes offline levam ate 48 horas para aparecer nos relatorios." A janela entre a exposicao e sua primeira chance de agir e medida em dias — e e exatamente por isso que a resposta precisa ser rapida assim que o sinal chega.

A sincronizacao de hash de senha importa aqui mais do que a maioria das equipes percebe. Uma redefinicao de senha baseada em nuvem pelo Microsoft Entra corrige o risco do usuario para essa deteccao tanto para senhas em nuvem quanto locais — mas somente "enquanto a sincronizacao de hash de senha (PHS) estiver habilitada para senhas locais".

Por Que o Backlog de Usuarios de Risco Nunca Diminui

Os tenants com os piores backlogs raramente sao os que ignoraram o produto. Sao aqueles em que varias pequenas lacunas se somam.

Os alertas nao chegam a ninguem. O e-mail "Users at risk detected" usa por padrao um limite de risco de usuario Alto. Por padrao, usuarios com atribuicao ativa das funcoes Administrador Global, Administrador de Seguranca ou Leitor de Seguranca sao adicionados a lista de destinatarios, e precisam ter um endereco de E-mail ou E-mail alternativo configurado. Duas ressalvas documentadas quebram isso silenciosamente: um usuario que assume uma dessas funcoes via Privileged Identity Management "so recebe e-mails se estiver elevado no momento em que o e-mail e enviado", e "o envio de e-mails para usuarios em funcoes atribuidas por grupo nao e suportado". Um tenant que concede Leitor de Seguranca por meio de um grupo e eleva administradores sob demanda via PIM pode receber exatamente zero notificacoes enquanto seu painel se enche.

Os limites de politica estao acima da maior parte da fila. A configuracao recomendada pela Microsoft e uma politica de risco de usuario em Alto e uma politica de risco de login em Medio e Alto. E uma orientacao solida, mas significa que toda deteccao de risco medio de usuario e toda deteccao de risco baixo ficam por conta de um humano — e os riscos medios permanecem ate que alguem os feche.

A autocorrecao praticamente nao esta disponivel. A Microsoft alerta que "os usuarios precisam se registrar para a autenticacao multifator do Microsoft Entra antes de enfrentar uma situacao que exija correcao. Para usuarios hibridos sincronizados do ambiente local, o password writeback precisa estar habilitado. Usuarios nao registrados sao bloqueados e exigem intervencao do administrador." Usuarios hibridos tambem precisam de PHS mais a configuracao opcional Permitir que a alteracao de senha local redefina o risco do usuario antes que uma alteracao de senha local limpe o risco. Onde esses pre-requisitos faltam, a politica nao esvazia a fila — ela transforma usuarios de risco em usuarios bloqueados e transfere o trabalho para o help desk.

Algumas deteccoes pararam de se autocorrigir. A Microsoft nao corrige mais automaticamente sessoes com claims de MFA quando uma deteccao relacionada a roubo de token ou a deteccao de IP de Agente de Ameaca Verificado dispara. As deteccoes afetadas sao Microsoft Entra threat intelligence, Token anomalo, Attacker in the Middle, IP de Agente de Ameaca Verificado e Anomalia de emissor de token. Quando uma delas atinge um usuario, limpar o risco exige uma alteracao de senha segura e reautenticacao com MFA. Se o seu modelo mental ainda e "MFA resolve tudo", esses casos se acumulam.

Usuarios excluidos ficam presos para sempre. "Se um usuario que apresentava risco foi excluido do diretorio, esse usuario ainda aparece no relatorio de risco mesmo que a conta tenha sido excluida. Os administradores nao podem descartar o risco de usuarios que foram excluidos do diretorio." Limpar esses casos exige um chamado de suporte da Microsoft. Cada usuario de risco desligado infla permanentemente o numero — e ensina a equipe a nao confiar mais nele.

A automacao legada tem data de validade. A orientacao da Microsoft e explicita: "As politicas de risco legadas configuradas no Microsoft Entra ID Protection serao desativadas em 1 de outubro de 2026." Tenants cuja unica resposta automatizada e uma politica de risco legada no ID Protection — em vez de uma politica de Conditional Access — vao perde-la, e um backlog que estava sendo drenado automaticamente voltara a crescer.

Deteccao: Meca o Seu Proprio Backlog de Correcao

Os relatorios do portal dizem quem esta em risco. Eles nao dizem ha quanto tempo alguem permanece em risco, que e o numero que importa. Para isso, voce precisa dos dados de risco no Log Analytics.

Configure as configuracoes de diagnostico em Entra ID > Monitoramento e integridade > Configuracoes de diagnostico e exporte as categorias RiskyUsers e UserRiskEvents (a Microsoft tambem expoe RiskyServicePrincipals, ServicePrincipalRiskEvents, RiskyAgents e AgentRiskEvents). Elas caem nas tabelas AADRiskyUsers e AADUserRiskEvents.

O que observar

Deteccoes abertas de credenciais vazadas

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskEventType == "leakedCredentials"
| where RiskState == "atRisk"
| project DetectedDateTime, UserPrincipalName, RiskLevel, RiskState, RiskDetail, DetectionTimingType
| order by DetectedDateTime asc

Cada linha e uma conta cuja senha e sabidamente exposta e que ninguem tocou. Ordenado do mais antigo para o mais recente, o topo desta lista e a sua pior exposicao.

Ha quanto tempo esta o backlog de risco

AADRiskyUsers
| summarize arg_max(TimeGenerated, RiskState, RiskLevel, RiskDetail, RiskLastUpdatedDateTime)
    by UserPrincipalName
| where RiskState == "atRisk"
| where RiskLevel in ("high", "medium")
| extend DaysAtRisk = datetime_diff('day', now(), RiskLastUpdatedDateTime)
| project UserPrincipalName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime, DaysAtRisk
| order by DaysAtRisk desc

AADRiskyUsers recebe um registro a cada mudanca no estado de risco de um usuario, entao arg_max reduz o stream ao ultimo estado conhecido por usuario antes de calcular a idade.

Auditar o botao de descartar

AADRiskyUsers
| where TimeGenerated > ago(90d)
| where RiskState == "dismissed" and RiskDetail == "adminDismissedAllRiskForUser"
| project TimeGenerated, UserPrincipalName, RiskLevel, RiskDetail
| order by TimeGenerated desc

O descarte e um resultado legitimo apos uma investigacao. Tambem e a forma mais rapida de fazer um painel parecer saudavel. Cruze essa lista com o seu sistema de tickets: um descarte sem um registro de investigacao correspondente e uma decisao que ninguem conseguira defender depois.

Tempo ate o fechamento, por tipo de deteccao

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskLevel == "high"
| where RiskState in ("remediated", "dismissed", "confirmedCompromised")
| extend HoursToClose = datetime_diff('hour', LastUpdatedDateTime, DetectedDateTime)
| summarize Detections = count(),
            MedianHours = percentile(HoursToClose, 50),
            P90Hours = percentile(HoursToClose, 90)
    by RiskEventType
| order by Detections desc

Essa e a metrica para apresentar a lideranca. "Temos 40 usuarios de risco" provoca um dar de ombros; "nossa mediana de tempo para fechar uma deteccao confirmada de credenciais vazadas e de 26 dias" nao.

Consultando os mesmos dados via Microsoft Graph

A API riskyUsers exige uma licenca Microsoft Entra ID P2 (ou Microsoft Entra Suite). Para leitura, e necessaria a permissao IdentityRiskyUser.Read.All, e para acesso delegado o usuario conectado precisa ter a funcao Leitor Global, Operador de Seguranca, Leitor de Seguranca ou Administrador de Seguranca.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskState eq 'atRisk' and riskLevel eq 'high'

O endpoint suporta $filter e $select, com um tamanho maximo de pagina de 500 objetos via $top. A mesma consulta pelo Graph PowerShell SDK:

Import-Module Microsoft.Graph.Identity.SignIns

Get-MgRiskyUser -Filter "riskState eq 'atRisk' and riskLevel eq 'high'" -All |
    Select-Object UserPrincipalName, RiskLevel, RiskState, RiskDetail, RiskLastUpdatedDateTime

Execute em uma programacao regular e alerte pela contagem, nao por eventos individuais. Um backlog que cresce semana apos semana e o que importa reportar.

Remediacao: Esvazie a Fila e Mantenha-a Vazia

1. Saiba o que cada acao realmente faz

Antes de automatizar qualquer coisa, garanta que a equipe concorda sobre o que cada botao significa. A Microsoft documenta o estado e o detalhe resultantes para cada caminho:

A nomenclatura e realmente confusa, e a propria Microsoft alerta para isso: o detalhe de risco "User performed secured password reset" e um rotulo relatado pelo sistema que indica que o usuario concluiu uma alteracao de senha segura (MFA seguido de alteracao de senha), e nao um fluxo de redefinicao de senha self-service.

Observe tambem a divisao de funcoes — Operador de Seguranca e a funcao com menos privilegios para descartar risco de usuario, enquanto Administrador de Usuarios e necessario para redefinir senhas. Redefinir uma senha dentro do ID Protection exige ambas.

2. Trabalhe o backlog de credenciais vazadas uma vez, manualmente

As etapas de investigacao da Microsoft para essa deteccao sao especificas, e sao o runbook correto para limpar a fila existente:

1. Avalie o escopo da exposicao — revise o historico de risco do usuario e os logs de login em busca de risco de login correlacionado (locais desconhecidos, enderecos IP anonimos, viagem atipica).
2. Verifique se a senha ja foi alterada apos a deteccao do vazamento; se sim, o risco pode ja estar autocorrigido.
3. Bloqueie o acesso se um atacante estiver ativo — bloqueie o usuario, redefina a senha e revogue todos os refresh tokens onde os logs mostrarem acesso nao autorizado.
4. Revise em busca de movimento lateral — escalonamento de privilegios, novos registros de aplicativo, mudancas em regras de caixa de correio, acesso a recursos sensiveis.
5. Verifique contas conectadas — se o usuario reutiliza senhas, trate a credencial como comprometida alem do seu tenant.

3. Faca "confirmar comprometimento" disparar a contencao

Confirmar o comprometimento define o nivel de risco como alto e alimenta os modelos da Microsoft, mas a Microsoft lista as acoes de contencao separadamente: solicitar uma alteracao de senha, bloquear o usuario se o atacante puder redefinir a senha ou executar MFA, revogar refresh tokens, desabilitar quaisquer dispositivos considerados comprometidos e, se voce usa continuous access evaluation, revogar todos os tokens de acesso.

Automatize a rotulagem para que o tempo humano va para a contencao:

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/confirmCompromised
Content-Type: application/json

{
  "userIds": [
    "29f270bb-4d23-4f68-8a57-dc73dc0d4caf",
    "20f91ec9-d140-4d90-9cd9-f618587a1471"
  ]
}

Essa acao exige IdentityRiskyUser.ReadWrite.All, sendo Administrador de Seguranca a funcao suportada com menos privilegios, e retorna 204 No Content em caso de sucesso.

4. Automatize o estado estavel com Conditional Access

A drenagem manual nao escala. Duas politicas de Conditional Access baseadas em risco mantem a fila proxima de zero, e a Microsoft e explicita que elas precisam ser separadas — "nao combine condicoes de risco de login e risco de usuario na mesma politica de Conditional Access."

• Politica de risco de usuario: selecione Exigir correcao de risco quando o risco de usuario for Alto. Essa escolha aplica automaticamente Exigir forca de autenticacao como controle de concessao e Frequencia de login – Todas as vezes como controle de sessao.
• Politica de risco de login: exija autenticacao multifator quando o risco de login for Medio ou Alto, com a frequencia de login definida para todas as vezes.

Exclua contas de acesso de emergencia e service principals, comece em modo somente relatorio e confirme o impacto antes de ativar. O passo a passo completo de configuracao esta em Azure Identity Protection: Bloqueando Credenciais Vazadas — e o modo somente relatorio e uma etapa de implantacao, nao um destino, uma armadilha coberta em Conditional Access Modo Somente Relatorio, Exclusoes Obsoletas. Acerte primeiro a lista de exclusoes, com a orientacao em Contas de Acesso de Emergencia Break Glass do Entra ID, e verifique o conjunto de politicas como um todo contra Lacunas de Conditional Access do Entra ID.

5. Corrija os pre-requisitos que bloqueiam a autocorrecao

• Confirme que os usuarios estao registrados para MFA antes de a politica entrar em vigor; usuarios nao registrados sao bloqueados em vez de corrigidos. A cobertura de registro e apenas metade da historia — veja Seguranca de Identidade Azure: Por Que o MFA Sozinho Nao Basta.
• Para identidades hibridas, habilite a sincronizacao de hash de senha e ative Permitir que a alteracao de senha local redefina o risco do usuario em Protection > Identity Protection > Settings. A Microsoft observa que isso e somente opt-in e recomenda proteger o processo de alteracao de senha local — por exemplo, exigindo MFA antes de uma alteracao local.

6. Direcione as notificacoes para alguem que as leia

Verifique se os destinatarios do alerta Users at risk detected tem um endereco de E-mail ou E-mail alternativo valido, nao dependem de funcoes atribuidas por grupo, e considere o timing da ativacao via PIM. Considere reduzir o limite de alerta abaixo do padrao Alto se sua equipe tiver capacidade, e ative o resumo semanal para visibilidade de tendencias.

7. Migre das politicas de risco legadas

Se a aplicacao de risco ainda esta nas politicas legadas do ID Protection em vez de Conditional Access, migre antes de 1 de outubro de 2026: construa as politicas equivalentes de Conditional Access em modo somente relatorio, valide-as, ative-as e entao desative as politicas antigas em ID Protection > Dashboard.

Como o EtcSec Detecta Isso

O EtcSec audita o caminho de resposta, nao apenas a camada de deteccao.

As verificacoes de Risk Protection sinalizam RISK_LEAKED_CREDENTIALS (Credenciais Vazadas Nao Bloqueadas) quando contas com credenciais confirmadamente comprometidas continuam ativas e desbloqueadas, e RISK_USERS_NOT_REMEDIATED (Usuarios de Risco Nao Corrigidos) quando contas sinalizadas como de risco nunca foram corrigidas ou descartadas. Ambas sao classificadas como Criticas, porque ambas descrevem uma conta que um atacante pode usar agora.

Alem delas, RISK_HIGH_RISK_USERS_ACTIVE mostra usuarios de alto risco cujas contas permanecem habilitadas, RISK_SIGNINS_NOT_INVESTIGATED identifica logins de risco sem acompanhamento, e RISK_NO_AUTOMATED_RESPONSE identifica tenants onde o risco e visivel, mas nenhuma contencao automatizada existe.

Para a revisao mais ampla do tenant onde essas verificacoes se encaixam, veja Como Auditar a Seguranca do Microsoft Entra ID. Para as deteccoes do lado do login que alimentam o risco de usuario, veja Entra ID AiTM Token Replay, Deteccao de Viagem Impossivel e MFA Push Fatigue e Password Spraying: Deteccao e Prevencao.

Referencias Primarias

• What are risk detections? — Microsoft Entra ID Protection
• Risk detection types and levels
• Remediate risks and unblock users
• Investigate risk with Microsoft Entra ID Protection
• Risk policies — Microsoft Entra ID Protection
• Configure Microsoft Entra ID Protection notifications
• Export and use Microsoft Entra ID Protection data
• What is Microsoft Entra ID Protection?
• riskyUser resource type — Microsoft Graph v1.0
• riskyUser: confirmCompromised — Microsoft Graph v1.0
• List riskyUsers — Microsoft Graph v1.0
• Azure Monitor Logs reference — AADRiskyUsers
• Azure Monitor Logs reference — AADUserRiskEvents