Detecção de Rajada de Login Falhado Entra ID

A cobertura para detecção de rajada de login falhado no Entra ID é fina por design: o Microsoft Entra ID Identity Protection não traz nenhuma detecção de risco nativa criada para capturar uma rajada de logins falhados contra uma única conta, mesmo que o sinal bruto — dezenas de tentativas de senha inválida contra uma conta em uma janela curta — esteja direto nos seus logs de login. Este artigo explica por que as próprias detecções do Identity Protection não disparam diante de uma sequência pura de falhas, e como fechar essa lacuna com uma consulta KQL, ajuste do Smart Lockout e um alerta que dispara antes da décima tentativa, não depois da primeira bem-sucedida.

Uma senha errada contra o Entra ID chega em SigninLogs como o código de erro AADSTS50126, e a própria referência da Microsoft para esse código é direta sobre por que uma única ocorrência não significa nada: InvalidUserNameOrPassword — erro ao validar as credenciais devido a nome de usuário ou senha inválidos; o usuário não digitou as credenciais corretas, e é esperado ver algum número desses erros nos seus logs por causa de erros de digitação dos usuários. Esse não é o único código de falha de credencial documentado pela Microsoft — AADSTS50056 significa senha inválida ou nula, que não existe no diretório para esse usuário — e uma detecção que observa apenas um dos dois vê só parte da rajada. Um erro de digitação é ruído. Vinte deles contra a mesma conta em cinco minutos, ou a mesma senha testada contra cinquenta contas em cinco minutos, não são — isso é força bruta direcionada no primeiro caso e password spraying no segundo, e ambos os padrões aparecem como o mesmo sinal bruto: uma rajada de 50126.

Essa distinção importa para o que este artigo linka. Se você quer o playbook do atacante — enumeração de alvos, listas de senhas comuns, por que o spraying evita lockouts por conta —, isso está em Password Spraying: Detecção e Prevenção para Active Directory e Entra ID. Este artigo é a outra metade: a engenharia de detecção sobre telemetria bruta que precisa existir porque o próprio risk engine do Identity Protection deixa esse sinal específico sem marcação.

Por Que o Identity Protection Não Detecta Isso

A Microsoft documenta toda detecção de risco de login e de usuário que o Identity Protection oferece, e nenhuma delas se chama "logins falhados repetidos contra uma conta". Os candidatos mais próximos deixam passar esse sinal, cada um por um motivo específico e documentado:

Detecção	Por que uma rajada pura de falhas não a dispara
Password spray	A detecção de risco só dispara quando um atacante valida com sucesso a senha de um usuário; tentativas de spray malsucedidas contra seus usuários não geram detecção. Uma campanha que nunca acerta — o caso comum contra uma política de senha decente — produz zero eventos de risco.
Malicious IP address	É o que mais se aproxima de um sinal de volume de falhas, mas é um veredito sobre o IP, não sobre a conta sendo atacada. A Microsoft calcula isso offline, com base em altas taxas de falha por credenciais inválidas vindas desse endereço IP ou de outras fontes de reputação de IP, e observa que em alguns casos essa detecção dispara com base em atividade maliciosa anterior. Nenhum limiar é publicado e nenhum é ajustável por você, então nada aqui pode ser usado com confiança para uma conta específica sob ataque.
Atypical travel / Impossible travel / Unfamiliar sign-in properties	As três avaliam as propriedades da atividade de login contra o histórico aprendido. Atypical Travel e Impossible Travel exigem, cada uma, dois logins originados de locais geograficamente distantes; Unfamiliar Sign-in Properties dispara quando um login carrega propriedades desconhecidas para o usuário — IP, ASN, localização, dispositivo, navegador e sub-rede IP do tenant. Nenhuma das três conta falhas, então um atacante testando senhas a partir de um IP e navegador que o tenant já reconhece não deixa nada anômalo para pontuar.
Leaked credentials	Dispara apenas com uma correspondência confirmada contra o pipeline de varredura do corpus de vazamentos da Microsoft. Não diz nada sobre a telemetria de falhas ao vivo nos seus próprios logs.

O resultado prático: uma campanha de força bruta direcionada ou uma onda de spray malsucedida pode acontecer inteiramente dentro de SigninLogs — visível, com timestamp, atribuível a um IP e a um conjunto de contas — sem nunca tocar RiskState, RiskLevelAggregated ou uma única linha no relatório de usuários de risco. Se o seu monitoramento para no dashboard do Identity Protection, esse padrão fica invisível até dar certo.

Detecção: Construa Você Mesmo a Consulta

Como não existe nenhum riskEventType para esse padrão, a detecção precisa ser construída diretamente contra SigninLogs, a tabela do Log Analytics para onde os eventos de login do Entra ID fluem assim que a exportação de diagnóstico é ativada. As colunas que importam:

Coluna	O que contém
`ResultType`	Fornece o código de erro de 5-6 dígitos gerado durante um evento de login. 0 indica sucesso; outros valores indicam falha.
`ResultDescription`	Fornece a mensagem de erro ou o motivo da falha da atividade de login correspondente.
`UserPrincipalName`	O UPN do usuário.
`IPAddress`	O endereço IP do cliente de onde o login ocorreu.
`TimeGenerated`	Timestamp do evento, em UTC.

Antes de escolher um limiar, estabeleça uma baseline para o seu próprio tenant. As consultas de exemplo publicadas pela Microsoft para SigninLogs incluem um ponto de partida para isso — "Failed Signin reasons" —, adaptado aqui para separar os códigos de falha de credencial que importam:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50126", "50056", "50053")
| summarize Count = count() by ResultType, ResultDescription
| order by Count desc

Rode isso primeiro. Se o ruído comum de 50126 por erro de digitação já está na casa das centenas por dia, um limiar de rajada na casa das unidades vai disparar à toa. Com uma baseline em mãos, duas consultas cobrem as duas variantes da mesma lacuna do catálogo — força bruta direcionada contra uma identidade, e spray lento e distribuído contra muitas:

Rajada contra uma única conta:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            SourceIPs = dcount(IPAddress),
            LastFailure = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 15m)
| where FailureCount >= 10
| order by FailureCount desc

Rajada distribuída entre muitas contas a partir de uma fonte:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            TargetedAccounts = dcount(UserPrincipalName),
            Accounts = make_set(UserPrincipalName, 20)
    by IPAddress, bin(TimeGenerated, 15m)
| where FailureCount >= 10 or TargetedAccounts >= 5
| order by FailureCount desc

Ambas as consultas usam apenas colunas documentadas de SigninLogs; os limiares 10 e 5 são pontos de partida ilustrativos, não padrões da Microsoft — dimensione-os com base na consulta de baseline acima, depois aperte-os conforme os falsos positivos caírem. Conecte uma das duas consultas a uma regra de análise agendada do Microsoft Sentinel (ou a um alerta de log simples do Azure Monitor, se você não usa o Sentinel), para que uma rajada gere um incidente em vez de ser encontrada por acaso numa revisão manual de logs.

Remediation

1. Reforce o Smart Lockout em vez de presumir que o padrão basta

O Smart Lockout está ativo para todo tenant, mas seus valores padrão são ajustados para usabilidade ampla, não para detecção:

O limiar de lockout padrão é de 10 tentativas falhadas (tenants do Azure Public; 3 no Azure US Government), depois das quais a conta é bloqueada por 60 segundos inicialmente, com duração crescente a cada bloqueio repetido.
O Smart Lockout diferencia localização familiar de localização desconhecida para separar um atacante do usuário legítimo, e tanto localizações familiares quanto desconhecidas têm contadores de lockout separados — então um atacante que faz login a partir de uma localização que o usuário real nunca usou consome seu próprio contador, rastreado de forma independente dos erros de digitação do usuário real.
O Smart Lockout também guarda os últimos três hashes de senha incorretos para não incrementar o contador de lockout quando a mesma senha é testada de novo. Um spray que repete uma senha comum contra uma conta, portanto, nunca leva essa conta em direção ao lockout — exatamente o caso que a sua própria consulta precisa capturar. A Microsoft observa que esse rastreamento de hash não está disponível para clientes com pass-through authentication ativado.
Personalizar o limiar e a duração abaixo do padrão exige Microsoft Entra ID P1 ou superior, configurável em Entra ID > Authentication methods > Password protection.

Um limiar mais baixo troca um pouco de atrito para o usuário pela possibilidade de cortar uma campanha de força bruta bem antes de a sua janela de detecção de 15 minutos sequer fechar. Coordene a mudança com qualquer política de lockout híbrida do AD DS. Para pass-through authentication, a Microsoft é explícita: o limiar de lockout do Entra precisa ser menor que o limiar de bloqueio de conta do AD DS, configurado de forma que o limiar do AD DS seja pelo menos duas a três vezes maior que o limiar do Microsoft Entra — o lockout na nuvem absorve o ataque antes que ele chegue ao on-premises.

2. Transforme a consulta KQL em um alerta permanente

Uma consulta que só roda quando alguém lembra de colá-la no Log Analytics não é uma detecção. Salve-a como uma regra de análise agendada do Microsoft Sentinel (ou um alerta de log do Azure Monitor) numa cadência de 15 minutos, compatível com a janela do bin(), e encaminhe para quem é responsável pelos incidentes de identidade. Esse é o controle que realmente fecha a lacuna do catálogo — o Identity Protection permanece em silêncio diante de uma rajada pura de falhas, então nada mais vai alertar por você.

Nada disso substitui o Conditional Access baseado em risco — isso o complementa. Se uma rajada eventualmente produzir um acerto, uma política de risco de login é o que impede essa sessão de fazer qualquer coisa. O passo a passo completo para construir uma está em Azure Identity Protection: Bloqueando Credenciais Vazadas; se a sua baseline de Conditional Access tem outras lacunas de cobertura além do risco de login, verifique-a contra Falhas de Acesso Condicional Entra ID.

SigninLogs só se preenche depois que a exportação de diagnóstico para o Log Analytics é ativada — como qualquer stream do Azure Monitor, ela captura eventos a partir daí, não retroativamente. Ative a exportação agora em Entra ID > Monitoring & health > Diagnostic settings, para que o histórico já esteja lá na próxima vez que você precisar rodar essas consultas contra um incidente que já tem uma semana.

Como a EtcSec Detecta Isso

Os checks de Risk Protection da EtcSec incluem exatamente essa correlação sobre telemetria bruta — rastreada internamente como RISK_FAILED_SIGNIN_BURST, classificada como crítica e mapeada para o MITRE ATT&CK T1110.003 — porque o próprio risk engine do Identity Protection, como documentado acima, não tem nenhuma detecção baseada em volume de falhas contra uma única conta. O check roda as mesmas duas formas das consultas acima, numa janela fixa de 10 minutos: mais de 50 falhas de credencial contra um usuário, ou mais de 50 vindas de um IP espalhadas por mais de 10 usuários distintos. Esses são limiares de auditoria, definidos alto o suficiente para que um achado seja um incidente e não um ponto de partida — exatamente por isso que o KQL acima começa mais baixo e pede para você estabelecer uma baseline primeiro. Ele fica ao lado dos checks que auditam o que acontece depois que o Identity Protection de fato levanta uma flag: RISK_SIGNINS_NOT_INVESTIGATED (logins de risco sem acompanhamento) e RISK_NO_AUTOMATED_RESPONSE (risco visível, sem contenção automatizada configurada), e alimenta diretamente se CA_NO_RISK_BASED_SIGNIN (nenhuma política de Conditional Access baseada em risco de login) importa ou não no seu ambiente.

Para os detectores irmãos da mesma família de telemetria bruta, veja Detecção de Anomalia de Login de Service Principal no Entra e Entra ID: Replay de Token AiTM, Detecção de Viagem Impossível. Para a lacuna do lado da resposta, quando o Identity Protection de fato dispara, veja Entra ID Risk Protection: Credenciais Vazadas, Usuários de Risco Não Corrigidos.

Detecção de Rajada de Login Falhado Entra ID: Por Que a Identity Protection Não Detecta