Password Spraying em AD e Entra ID: detecção

O que é Password Spraying?

Password spraying é uma técnica de brute force que testa uma senha, ou um conjunto muito pequeno de senhas comuns, contra muitas contas em vez de tentar muitas senhas contra uma única conta. A MITRE classifica a técnica como T1110.003 em Brute Force.

Esse modelo operacional importa porque foi desenhado para evitar os efeitos mais óbvios do brute force clássico. Em vez de bloquear rapidamente uma única conta após várias tentativas falhas, o atacante distribui poucas tentativas por muitas identidades e espera encontrar a mais fraca.

O escopo deste artigo é identidade híbrida: Active Directory, Microsoft Entra ID e os caminhos cloud ou de acesso remoto que ainda aceitam autenticação baseada em senha. Password spraying não é apenas um problema on-prem. Tanto a CISA quanto a Microsoft o descrevem como um padrão frequente de acesso inicial contra serviços de identidade federados, cloud e expostos à Internet.

Como o Password Spraying funciona

A definição da MITRE é o ponto de partida correto: o adversário usa uma senha única, ou uma lista muito pequena de senhas comuns, contra muitas contas diferentes para evitar bloqueios de conta que normalmente aconteceriam se ele bruteforçasse repetidamente uma única conta.

Na prática, os atacantes primeiro montam a lista de contas-alvo e só depois a “borrifam” com poucas senhas candidatas fracas.

Fontes comuns de contas alvo:

nomes de usuário ou endereços de email visíveis publicamente
convenções de nomenclatura derivadas de LinkedIn, sites corporativos ou catálogos de endereços comprometidos
Global Address Lists depois que uma primeira conta cloud já foi comprometida
identidades híbridas sincronizadas, presentes tanto no AD quanto no Microsoft Entra ID

Caminhos típicos de ataque:

endpoints de login do Microsoft 365 / Entra
fluxos de autenticação federada
portais de VPN
Outlook Web ou outras interfaces de email expostas externamente
RDP ou outros workflows de acesso remoto publicados
LDAP, Kerberos, SMB ou outros protocolos internos quando o atacante já está dentro da rede

A MITRE também destaca uma nuance importante de detecção: atacantes podem preferir tentativas LDAP e Kerberos porque elas podem ser menos visíveis do que falhas SMB, que costumam acionar o evento 4625.

Por que o Password Spraying ainda funciona

Password spraying continua eficaz porque explora escala e previsibilidade, não apenas uma fraqueza técnica isolada.

Senhas fracas ainda existem em escala empresarial

A documentação do Microsoft Entra Password Protection é explícita: a Microsoft bloqueia senhas fracas com base em telemetria real de spray porque senhas fracas e suas variações continuam comuns o suficiente para ter relevância operacional.

Caminhos password-only ainda permanecem expostos

O alerta da CISA sobre brute force e os relatórios mais recentes da Microsoft sobre intrusões cloud apontam para a mesma fragilidade: se um alvo ainda expõe autenticação single-factor baseada em senha, um único sucesso pode bastar para iniciar descoberta, persistência ou movimento lateral.

Caminhos legacy e federados ampliam a superfície de ataque

A CISA avisa explicitamente que campanhas de password spraying frequentemente atacam SSO e aplicações cloud com autenticação federada. Os relatórios mais recentes da Microsoft também mostram password spray como passo inicial antes de reconhecimento mais amplo do tenant Entra e tentativas de persistência.

A abordagem low-and-slow evita lockouts ruidosos

O objetivo do spraying não é velocidade contra uma única conta. O objetivo é confiabilidade sobre muitas contas sem cruzar rapidamente os limites de lockout por identidade.

Pré-requisitos para um ataque de Password Spraying ter sucesso

Password spraying normalmente funciona quando vários problemas se sobrepõem.

1. O atacante consegue enumerar nomes de usuário válidos

Uma campanha de spray fica muito mais simples quando os nomes de usuário seguem padrões previsíveis ou podem ser descobertos com facilidade externamente. Formatos públicos de email, aliases administrativos previsíveis e nomes reutilizados entre cloud e on-prem ajudam bastante.

2. A autenticação baseada em senha ainda está exposta

Se o tenant ou o ambiente ainda deixam caminhos valiosos protegidos apenas por senha, o atacante tem superfície para atacar. Isso inclui sign-in cloud, VPN, acesso remoto, federation e certas superfícies internas de autenticação.

3. A base de senhas é fraca o bastante para que poucos candidatos funcionem

Esse é exatamente o problema de controle tratado por Seguranca de Senhas no Active Directory: As Ma Configuracoes que os Atacantes Adoram. Um spray funciona porque alguns usuários ainda escolhem senhas fracas, previsíveis ou ligadas à organização.

4. A cobertura de MFA é incompleta ou contornável no caminho alvo

Mesmo quando o spray obtém apenas uma senha válida, a conta se torna muito menos útil se existir MFA forte ou controles resistentes a phishing no caminho correto. A CISA cita explicitamente a ausência de MFA como característica comum dos ambientes vítimas.

5. O monitoramento é fraco demais para reconstruir o padrão

Algumas poucas falhas em uma única conta são fáceis de ignorar. O sinal real é um grande volume de falhas em muitas contas a partir da mesma fonte, da mesma família de infraestrutura ou do mesmo padrão temporal. Sem essa correlação, password spraying continua fácil de perder.

A cadeia de ataque

Uma cadeia típica de intrusão baseada em password spraying se parece com isto.

Etapa 1 - Construir a lista de contas

O atacante coleta nomes de usuário a partir de fontes públicas, vazamentos anteriores, catálogos de endereços ou caixas de email já comprometidas.

Etapa 2 - Escolher uma pequena lista de senhas

As senhas escolhidas costumam ser sazonais, relacionadas à organização ou suficientemente comuns para cumprir requisitos de complexidade e ainda assim permanecer previsíveis.

Etapa 3 - Pulverizar muitas contas

Em vez de martelar uma única identidade, o atacante testa poucas senhas contra muitos usuários e espaça as tentativas para evitar limiares de lockout muito óbvios.

Etapa 4 - Usar a primeira conta bem-sucedida para reconnaissance

O relatório da Microsoft sobre Peach Sandstorm mostra o risco real: uma única conta bem-sucedida pode ser suficiente para tenant discovery, tentativas de persistência ou reconnaissance cloud adicional.

Etapa 5 - Expandir o acesso

A partir daí, o atacante pode:

coletar mais nomes de usuário e funções
baixar emails ou a Global Address List
mirar depois usuários privilegiados
pivotar para aplicações, subscriptions ou infraestrutura ligadas à identidade comprometida

Por isso, password spraying não é apenas um problema de falhas de login. É um problema de acesso inicial que frequentemente se transforma em um problema de privilégios e persistência.

Password Spraying vs outras técnicas de brute force

Esses termos costumam ser misturados, mas não significam a mesma coisa.

Password spraying = uma ou poucas senhas contra muitas contas
Password guessing = tentativas mais diretas contra uma única conta
Credential stuffing = reutilização de pares usuário/senha já conhecidos a partir de outros vazamentos
Brute force clássico = muitas tentativas contra uma única identidade ou um único segredo até funcionar

Essa distinção importa operacionalmente porque as estratégias de detecção e lockout são diferentes.

Detecção

Não existe um detector universal único para password spraying, porque a técnica atravessa superfícies cloud, federadas e on-prem. O modelo útil volta a ser correlação.

Sinais focados em cloud e Entra

Para o Microsoft Entra ID, os sinais mais úteis incluem:

falhas repetidas de sign-in contra muitos usuários a partir do mesmo IP, do mesmo cluster de infraestrutura ou do mesmo user agent
o mesmo padrão de senha candidata sendo testado contra muitas contas ao longo do tempo
comportamento repetido de Smart Lockout ou bloqueio de sign-in sobre muitas contas a partir da mesma fonte
atividade de risco médio ou alto associada a falhas repetidas de senha ou infraestrutura suspeita
uso de autenticação legacy em caminhos de identidade expostos à Internet

A documentação da Microsoft sobre Smart Lockout acrescenta fatos importantes:

Smart Lockout está habilitado por padrão para tenants Microsoft Entra
o limite padrão é de 10 tentativas falhas para Azure Public e 3 para Azure US Government
a duração inicial do lockout começa em 60 segundos e aumenta após falhas repetidas
Smart Lockout rastreia os últimos três hashes de senhas incorretas, de modo que repetir a mesma senha errada não continua incrementando o contador
esse rastreamento por hash não está disponível em cenários de pass-through authentication, porque a autenticação acontece on-premises

Esses detalhes importam porque muitas equipes superestimam o que o lockout sozinho consegue fazer em um ambiente híbrido.

Sinais AD e on-prem

No monitoramento Windows on-prem, os sinais úteis incluem:

picos de falhas 4625 a partir da mesma fonte contra muitas contas quando SMB ou caminhos similares estão envolvidos
falhas de pré-autenticação Kerberos 4771 em muitos usuários dentro de uma janela curta
falhas LDAP ou Kerberos alinhadas com um padrão multiaccount, mesmo quando não se parecem com uma sequência SMB clássica
a mesma fonte ou o mesmo caminho de relay tocando muitas identidades com cadência baixa, porém constante

A MITRE avisa explicitamente que tentativas LDAP e Kerberos podem ser menos propensas a gerar os padrões de falha Windows mais visíveis em que os defensores frequentemente se apoiam. É exatamente por isso que Monitoramento de Seguranca AD: Os Eventos que Importam é tão relevante aqui.

Como uma boa correlação se parece

Uma detecção forte de password spraying normalmente é enquadrada assim:

um IP, um ASN, um user agent ou um pequeno conjunto de infraestrutura
muitos nomes de usuário alvo
pouquíssimas tentativas por conta
um padrão repetido de senha candidata ou de timing
uma ou duas contas bem-sucedidas seguidas de discovery ou atividade orientada a privilégios

Por que Smart Lockout e logs não bastam sozinhos

Smart Lockout reduz risco, mas a Microsoft deixa claro que ele não garante que um usuário legítimo nunca será bloqueado e não substitui autenticação mais forte nem uma política de senhas melhor. Boa detecção continua dependendo de revisão de logs, alertas e conhecimento exato dos caminhos expostos.

Remediação

A mitigação do password spraying não é apenas um exercício de política de senhas. É a combinação de senhas mais fortes, menos caminhos password-only expostos, controles pós-senha mais fortes e melhor proteção das bordas de autenticação híbrida.

1. Exigir MFA forte nos caminhos de identidade expostos

CISA e Microsoft recomendam MFA como mitigação central. Para sistemas de identidade expostos publicamente, especialmente Microsoft 365, portais administrativos, VPN e acesso remoto, uma senha obtida por spray não deveria ser suficiente para seguir adiante.

É por isso também que Seguranca de Identidade Azure: Quando o MFA Nao Basta e Acesso Condicional Azure: Riscos de Bypass MFA ficam diretamente ao lado deste tema. A MFA precisa existir nos caminhos certos e estar corretamente aplicada.

2. Usar Smart Lockout corretamente no Entra

A Microsoft documenta Smart Lockout como proteção padrão contra brute force e password spraying, mas equipes híbridas precisam configurá-lo com cuidado:

manter o limite do Microsoft Entra abaixo do limite on-prem do AD DS
manter a duração do lockout do Entra acima da duração do AD DS
entender que a pass-through authentication altera parte do comportamento do Smart Lockout
revisar se a política on-prem de bloqueio de contas está gerando mais indisponibilidade do que redução real do risco de spray

3. Implantar Microsoft Entra Password Protection

Microsoft Entra Password Protection é um dos controles anti-spray mais claros disponíveis porque foi projetado com base em telemetria real de spray e bloqueia senhas fracas conhecidas e suas variantes.

Pontos importantes de implementação segundo a Microsoft:

tenants cloud recebem por padrão a global banned password list
podem ser adicionadas listas personalizadas para termos fracos específicos do tenant
AD DS on-prem pode usar a mesma família de controles por meio dos agentes do Microsoft Entra Password Protection
a Microsoft recomenda iniciar a implantação on-prem em modo Audit antes de mudar para Enforced

Isso importa muito em ambientes híbridos, onde o atacante está igualmente disposto a pulverizar senhas on-prem e cloud.

4. Reduzir autenticação legacy e superfícies password-only expostas

A autenticação legacy continua atraente porque preserva caminhos antigos baseados em senha e pode contornar parte dos controles mais fortes presentes em fluxos modernos. Se ela continua habilitada, os defensores ainda deixam caminhos mais baratos para o atacante testar.

Isso se conecta diretamente com Fortalecimento do Tenant Azure: Security Defaults e com a revisão mais ampla do Conditional Access.

5. Proteger identidades privilegiadas de forma diferente do restante da população

Um spray bem-sucedido contra um usuário de baixo valor já é ruim. Um spray bem-sucedido contra uma conta privilegiada frequentemente é o incidente real. Isso significa:

requisitos MFA mais fortes para funções privilegiadas
restrições de sign-in mais rígidas para identidades administrativas
revisão ativa de usuários privilegiados obsoletos e contas de emergência
reset rápido e investigação imediata quando uma conta privilegiada é alvo ou vítima de spraying

É aqui que Azure Identity Protection: Politicas de Risco e Contas Obsoletas e Superprivilegiadas no AD entram na mesma história de mitigação.

6. Tratar uma conta bem-sucedida por spray como comprometida, não apenas como senha fraca

O reporting de ameaças da Microsoft é útil aqui: uma vez que o spray tem sucesso, o ator frequentemente pivota rapidamente para reconhecimento, persistência e movimento lateral. É necessário redefinir a senha, mas também revogar sessões, revisar mudanças de MFA, inspecionar atividade subsequente e investigar se a conta comprometida expôs mais dados ou caminhos de acesso.

Validação após o hardening

Não encerre a remediação de password spraying apenas porque o Smart Lockout está habilitado ou porque uma nova política de senhas foi anunciada. É preciso validar diretamente os caminhos expostos.

verificar quais caminhos expostos à Internet ainda aceitam autenticação password-only
confirmar que a MFA é exigida nesses caminhos, especialmente para administradores e contas de alto valor
testar o comportamento do Smart Lockout e compará-lo com as configurações on-prem de lockout do AD em ambientes híbridos
revisar logs de sign-in em busca de padrões amplos de falha sobre muitos usuários, não apenas lockouts isolados
confirmar que o Microsoft Entra Password Protection está ativo na nuvem e, quando previsto, on-prem
verificar se termos fracos específicos do tenant, como nome da empresa, nome do produto ou padrões sazonais, estão cobertos na lista personalizada de senhas proibidas

O critério real de sucesso é simples: uma lista pequena de senhas comuns não deve mais produzir um ponto de apoio útil, nem na nuvem nem on-prem.

Como a EtcSec detecta exposição relacionada

A EtcSec não precisa de uma taxonomia artificial de password spraying para ser útil aqui. O valor está nos controles ao redor que determinam se um spray tem sucesso ou fracassa.

Os findings subjacentes mais próximos são aqueles que tornam uma campanha de spray praticável desde o início: política de senhas fraca do lado do AD e ausência de exigência de MFA em caminhos de sign-in do Entra expostos. Não são exatamente a técnica, mas são as falhas de controle que transformam um spray amplo em um foothold útil.

Os controles relacionados mais relevantes são:

Em conjunto, esses controles mostram se o ambiente ainda apresenta uma superfície fácil para campanhas de spray.

Controles relacionados

Password spraying deve ser analisado junto com higiene de senhas, enforcement de MFA, Smart Lockout, resposta a risco de identidade e monitoramento. Se você quer reduzir o sucesso real de campanhas de spray e não apenas falhas ruidosas, revise este tema junto com Seguranca de Senhas no Active Directory: As Ma Configuracoes que os Atacantes Adoram, Seguranca de Identidade Azure: Quando o MFA Nao Basta, Azure Identity Protection: Politicas de Risco, Acesso Condicional Azure: Riscos de Bypass MFA, Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático e Fortalecimento do Tenant Azure: Security Defaults.