Passwords no Active Directory: riscos em 2026

Introdução

#

Durante muitos anos, proteger passwords no Active Directory significou configurar uma política de domínio com comprimento mínimo, complexidade, histórico, expiração e bloqueio de conta. Estes controlos continuam a ter valor, mas respondem sobretudo a um problema antigo: impedir escolhas demasiado simples e limitar tentativas repetidas contra uma conta. O atacante moderno tenta frequentemente outra coisa. Em vez de descobrir uma password por força bruta, utiliza uma credencial que já conhece ou testa poucas passwords prováveis contra muitos utilizadores.

É aqui que surgem quatro riscos centrais. No password spraying, o atacante distribui uma password comum por centenas ou milhares de contas para evitar o lockout. No credential stuffing, testa pares de utilizador e password obtidos noutros serviços. O password reuse transforma uma fuga externa num incidente interno. Por fim, os password breaches alimentam bases de dados, combo lists e serviços criminosos que automatizam ataques a organizações sem que o Active Directory tenha qualquer sinal prévio.

Uma password pode ter 18 caracteres, maiúsculas, minúsculas, números e símbolos e, ainda assim, estar comprometida. Se tiver sido reutilizada num serviço externo, capturada por malware ou incluída numa fuga, cumpre a política mas deixou de ser segura. Esta diferença entre conformidade sintática e risco real de exposição é a principal limitação das políticas tradicionais.

A conclusão não é abandonar as passwords nem eliminar os controlos nativos. É reposicioná-los como uma camada de base e acrescentar proteção contra passwords conhecidas, autenticação multifator, monitorização de identidade e resposta orientada ao risco.

Como funcionam as Password Policies tradicionais

#

No Active Directory Domain Services, a política de passwords do domínio é normalmente aplicada através de Group Policy. As Fine-Grained Password Policies permitem valores diferentes para conjuntos de utilizadores, por exemplo contas privilegiadas, contas de serviço e utilizadores comuns. Em ambos os casos, o objetivo é validar propriedades da password e regular o comportamento após falhas de autenticação.

Complexidade

#

A regra nativa de complexidade exige caracteres de categorias diferentes e impede determinadas combinações com o nome da conta ou partes do nome apresentado. Um exemplo como Verão2026!Empresa pode cumprir comprimento e composição. Contudo, os utilizadores tendem a construir padrões previsíveis: nome da organização, estação do ano, ano corrente e um símbolo no fim. A password passa no controlo, mas permanece vulnerável a dicionários adaptados ao contexto da empresa.

Password Expiration

#

A idade máxima força uma alteração após um período, historicamente 30, 60 ou 90 dias. O pressuposto era reduzir a janela útil de uma password roubada. Na prática, alterações frequentes incentivam sequências como Projeto2026!01, Projeto2026!02 e Projeto2026!03. O atacante que conhece uma versão anterior consegue prever a seguinte, enquanto a organização aumenta pedidos ao service desk e o risco de passwords anotadas ou guardadas de forma insegura.

A idade mínima pode impedir que um utilizador percorra rapidamente várias passwords para regressar à anterior. É um controlo complementar ao histórico, mas não determina se a credencial está comprometida.

History

#

O password history guarda hashes das últimas passwords para impedir reutilização imediata no mesmo domínio. Por exemplo, um histórico de 24 valores evita que o utilizador altere RedeSegura!24 para uma password temporária e volte logo ao valor anterior. Este controlo não deteta a reutilização da mesma password no correio pessoal, numa loja online ou num fornecedor SaaS. Também não reconhece variações semanticamente quase idênticas.

Minimum Length

#

O comprimento mínimo aumenta o espaço de pesquisa e favorece passphrases. Uma frase longa e única, como quatro ou cinco palavras não relacionadas, tende a resistir melhor a cracking offline do que uma palavra curta sobrecarregada de substituições previsíveis. O valor deve ser compatível com aplicações legadas, VPNs, appliances e mecanismos de sincronização, porque limites técnicos antigos podem truncar passwords sem evidência clara para o utilizador.

Em 2026, 14 ou 15 caracteres constituem uma referência mais defensável para passwords de utilizador, mas contas privilegiadas e segredos geridos devem utilizar valores maiores e aleatórios. O comprimento, por si só, não elimina exposição nem reuse.

Lockout Policies

#

O lockout combina um limiar de tentativas falhadas, uma duração de bloqueio e o período após o qual o contador é reposto. Um limiar demasiado baixo facilita denial of service: basta um atacante falhar repetidamente a autenticação para bloquear utilizadores. Um limiar demasiado alto permite mais tentativas. Valores como 10 tentativas e janelas de 15 minutos podem servir de ponto de partida, mas têm de ser ajustados ao risco, à telemetria e aos protocolos utilizados.

O password spraying contorna precisamente este mecanismo: uma tentativa por conta, seguida de espera suficiente, pode manter cada utilizador abaixo do limiar. O lockout continua a limitar brute force concentrado, mas não deve ser confundido com deteção de ataques distribuídos.

Porque estas políticas falham atualmente

#

As políticas nativas avaliam sobretudo a password quando é definida ou alterada. Não sabem onde mais foi utilizada, se apareceu ontem numa fuga ou se um infostealer a recolheu de um browser. O atacante opera fora da fronteira do domínio e apresenta depois uma credencial válida ao serviço de autenticação.

flowchart LR
    A[Fuga num serviço externo] --> B[Combo list ou mercado criminoso]
    C[Infostealer no endpoint] --> B
    B --> D[Automação de ataques]
    D --> E[Password spraying]
    D --> F[Credential stuffing]
    E --> G[Active Directory]
    F --> G
    G --> H{Credencial válida?}
    H -->|Sim| I[Acesso inicial]
    H -->|Não| J[Nova conta ou password]

O password reuse cria uma relação invisível entre o domínio e serviços que a organização não controla. Mesmo que a empresa nunca sofra uma fuga, um portal externo pode expor a mesma combinação. O histórico do AD apenas compara valores anteriores daquele utilizador no domínio; não mede unicidade global.

As leaked credentials são agregadas em bases de dados de credenciais e combo lists. Os atacantes filtram por domínio de correio, região, tecnologia ou organização e lançam testes em grande escala. Uma password complexa conhecida pelo atacante não oferece resistência criptográfica durante a autenticação: basta enviá-la.

O infostealer malware tornou a recolha ainda mais direta. Pode capturar passwords guardadas no browser, cookies de sessão, tokens, dados de carteiras e informação do sistema. Isto reduz a dependência de fugas históricas e permite obter credenciais recentes. MFA continua essencial, mas sessões roubadas, métodos resistentes apenas a password e aprovações indevidas exigem proteção de endpoint, Conditional Access e deteção de anomalias. O incidente com sistemas reais durante avaliações de cibersegurança mostra também como credenciais expostas e fronteiras operacionais frágeis podem transformar rapidamente um erro de configuração em acesso indevido.

Por fim, os ataques automatizados reduzem o custo de testar credenciais. Proxies distribuídos, botnets e infraestrutura cloud permitem variar origem, cadência e protocolo. Autenticações contra VPN, RDP Gateway, ADFS, aplicações legadas, Microsoft 365 e serviços publicados podem parecer eventos isolados se não forem correlacionadas. A política de passwords não tem contexto suficiente para ligar esses sinais.

O que mudou nas recomendações da Microsoft

#

As recomendações modernas da Microsoft separam a baseline de configuração da proteção contra risco de identidade. As Microsoft Security Baselines reúnem definições testadas para Windows e Windows Server e devem ser o ponto de partida, não uma configuração copiada sem validação. Uma baseline só deve impor um valor quando este mitiga uma ameaça contemporânea sem criar um impacto operacional superior ao risco.

A mudança mais visível foi o afastamento da expiração periódica obrigatória. A Microsoft recomenda, para contas cloud-only, passwords sem expiração e privilegia alterações quando existe suspeita ou evidência de compromisso. A razão é operacional e comportamental: a rotação por calendário não prova que uma credencial permaneceu secreta e conduz frequentemente a mudanças mínimas e previsíveis. Isto não elimina resets após incidentes, alterações de função, exposição confirmada ou falhas no processo de gestão de segredos.

O Microsoft Entra Password Protection, anteriormente conhecido como Azure AD Password Protection, bloqueia passwords fracas conhecidas e variantes. A lista global da Microsoft pode ser complementada por uma lista personalizada com termos específicos da organização, como marcas, localidades, produtos ou nomes internos. Em ambientes híbridos, a mesma lógica pode proteger alterações e resets realizados no AD DS local.

A arquitetura on-premises tem dois componentes importantes:

• o Password Protection Proxy é instalado num servidor membro do domínio e obtém do Microsoft Entra ID as políticas de passwords proibidas; os domain controllers não necessitam de acesso direto à Internet;
• o Password Filter DC Agent é instalado nos domain controllers, recebe o pedido de validação do sistema operativo e aplica localmente a política em cache, devolvendo aprovação ou rejeição.

Para enforcement consistente, o DC Agent deve existir em todos os domain controllers. Uma instalação parcial é adequada para testes, não para produção, porque um cliente pode enviar a alteração de password para qualquer DC. A Microsoft indica também que as passwords em texto simples não saem do domain controller e que a solução não exige alteração ao schema do AD DS.

O enquadramento acompanha o NIST SP 800-63B, cuja revisão atual estabelece orientações claras para memorized secrets: passwords de fator único com pelo menos 15 caracteres, suporte de comprimentos máximos de pelo menos 64 caracteres, verificação contra uma blocklist de valores comuns, esperados ou comprometidos, ausência de regras adicionais de composição e nenhuma alteração periódica sem evidência de compromisso. O NIST não torna a password irrelevante; desloca a prioridade de padrões artificiais para comprimento, bloqueio de escolhas conhecidas e autenticação multifator.

Enzoic e monitorização contínua de credenciais comprometidas

#

O Enzoic for Active Directory procura resolver uma lacuna que o AD nativo e o Microsoft Entra Password Protection não cobrem totalmente: a monitorização contínua do estado de exposição de credenciais. A proposta técnica combina validação no momento da criação ou alteração com verificações posteriores contra inteligência de credenciais comprometidas.

Segundo a documentação e os materiais técnicos do fabricante, a plataforma compara passwords com uma base de dados atualizada a partir de fugas, fontes associadas a mercados criminosos e logs de malware. Pode bloquear valores comprometidos, palavras comuns, derivações do nome do utilizador e variantes obtidas por substituições previsíveis. A Continuous Password Protection volta a avaliar credenciais em uso quando surgem novos dados, permitindo detetar uma password que era aceitável no dia em que foi definida, mas apareceu mais tarde numa fuga.

Na integração com Active Directory, a validação ocorre durante mudanças e resets e pode fornecer feedback ao utilizador. Quando é detetado compromisso posterior, as respostas possíveis incluem notificação, exigência de alteração no próximo logon, desativação da conta ou integração com processos de remediação. O modo exato deve ser definido por risco: desativar automaticamente todas as contas pode interromper operações críticas; apenas gerar alertas pode prolongar a exposição.

Os benefícios potenciais são mensuráveis: reduzir passwords reutilizadas ou já conhecidas, substituir resets globais por remediação direcionada e fornecer telemetria para auditoria e SOC. Existe, porém, uma avaliação obrigatória antes da adoção. A organização deve analisar a arquitetura de consulta, tratamento de hashes, dependências externas, disponibilidade, latência, proteção de dados, residência da informação, licenciamento, comportamento em fail-open ou fail-closed e integração com SIEM.

Enzoic não substitui MFA, proteção de endpoint, PAM, segmentação administrativa ou deteção de identidade. Também deve ser analisado como fornecedor comercial com afirmações próprias sobre cobertura e atualização das suas bases. O valor está na camada adicional de inteligência de exposição, desde que a implementação seja validada tecnicamente e integrada numa estratégia de defesa em profundidade.

Boas práticas para Active Directory em 2026

#

Estas práticas devem ser acompanhadas por eliminação de protocolos legados, revisão de contas inativas, proteção de service accounts com gMSA quando possível, auditoria de grupos privilegiados e recolha centralizada de eventos. A password é apenas um dos controlos do plano de identidade.

Exemplo de arquitetura moderna

#

flowchart TD
    U[Utilizador] --> AD[Active Directory]
    AD --> PP[Password Protection]
    PP --> EZ[Enzoic
monitorização de credenciais comprometidas]
    EZ --> MDI[Microsoft Defender for Identity]
    MDI --> SOC[SOC]

    ENTRA[Microsoft Entra ID
listas global e personalizada] -. política .-> PP
    MFA[MFA e Conditional Access] -. controlo adicional .-> AD
    SOC -. resposta e remediação .-> AD

O diagrama representa camadas lógicas, não um fluxo obrigatório de autenticação. Microsoft Entra Password Protection valida escolhas contra políticas proibidas; uma plataforma como Enzoic acrescenta inteligência contínua de exposição; Defender for Identity produz deteções sobre atividade no AD; e o SOC correlaciona eventos e coordena resposta. Em produção, as integrações devem evitar dependências síncronas desnecessárias que possam impedir alterações de password durante uma indisponibilidade externa.

Conclusão

#

As políticas tradicionais do Active Directory continuam a fornecer uma baseline necessária. Comprimento, histórico, idade mínima e lockout limitam classes específicas de abuso e suportam requisitos operacionais. O erro é esperar que estes mecanismos detetem reuse externo, combo lists, infostealers ou credenciais que se tornam públicas depois de terem sido aceites.

Uma estratégia moderna combina passwords longas e únicas, passphrases, blocklists, Microsoft Entra Password Protection, MFA resistente a phishing, proteção de endpoints, PAM, tiering e deteção contínua. Soluções de monitorização de credenciais comprometidas podem acrescentar visibilidade, mas devem ser avaliadas como componentes de segurança críticos e não como substitutos dos restantes controlos.

Passwords fortes continuam importantes, mas hoje o fator crítico é impedir a utilização de credenciais comprometidas. Isso exige conhecer o estado de exposição da credencial, correlacionar autenticações e responder rapidamente quando o risco muda — não apenas obrigar todos os utilizadores a alterar a password porque o calendário avançou mais 90 dias.

Referências

#

• Petri — Why Active Directory Password Policy Fails Modern Attacks (and What Admins Need Instead)
• Enzoic — Native Active Directory Password Policies Still Fail Modern Attacks
• Microsoft Learn — Microsoft Entra Password Protection para Active Directory Domain Services
• Microsoft Learn — Recomendações de políticas de passwords para Microsoft 365
• Microsoft Learn — Security Baselines
• NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management
• Wikimedia Commons — Microsoft Entra ID color icon, domínio público