Seguranca de Senhas no Active Directory: As Ma Configuracoes que os Atacantes Adoram

O Que É a Seguranca de Senhas no Active Directory?

A segurança de senhas no Active Directory abrange as políticas, flags de conta e configurações de autenticação legada que determinam como as credenciais são criadas, armazenadas e reutilizadas em todo o domínio. Quando esses controles são fracos, os atacantes não precisam de uma cadeia de exploração para começar. Uma senha fraca, uma conta administrativa que nunca expira ou uma senha copiada para um atributo já podem ser suficientes.

Esses problemas costumam ser discretos no dia a dia. Contas com PasswordNeverExpires ou PasswordNotRequired podem permanecer em produção por meses, senhas copiadas para campos de descrição são fáceis de passar despercebidas, e configurações legadas como WDigest ou NTLMv1 tornam credenciais recuperadas muito mais fáceis de reutilizar.

Este artigo aborda seis configurações incorretas de senha de alto impacto no Active Directory e como validar que as correções realmente eliminaram a exposição.

Como Funciona

O Active Directory aplica controles de senha por meio de dois mecanismos principais:

• A Política de Senha Padrão do Domínio, aplicada em todo o domínio via Group Policy
• As Fine-Grained Password Policies (FGPP), aplicadas a usuários ou grupos específicos por meio de Password Settings Objects

As Fine-Grained Password Policies são implementadas como Password Settings Objects (PSOs), e sua precedência é definida pelo atributo msDS-PasswordSettingsPrecedence: um valor menor significa uma PSO de prioridade mais alta. Uma PSO vinculada diretamente a um usuário sempre prevalece; quando várias PSOs se aplicam via associação a grupos, a que tem o menor valor de precedência se torna a política resultante, e a Política de Senha Padrão do Domínio só se aplica se nenhuma PSO corresponder. Na prática, contas tier-0 e contas de serviço devem estar sob uma PSO com valor de precedência baixo e uma base de referência materialmente mais forte do que o padrão do domínio.

Se nenhuma das duas for revisada regularmente, o resultado é previsível: senhas fracas ou de vida longa, contas isentas dos controles normais e configurações de autenticação legada que facilitam o abuso de credenciais assim que um atacante ganha um ponto de apoio.

A Cadeia de Ataque

Passo 1 - Enumerar Contas Fracas

Qualquer usuário de domínio autenticado pode consultar o AD em busca de contas com configurações de senha fracas:

# Contas com senhas que nunca expiram
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet

# Contas sem senha obrigatória
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

# Contas com senha no campo de descrição
Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|senha|chave"} |
    Select-Object SamAccountName, Description

Passo 2 - Verificar Exposição a Protocolos Legados

# Verificar se o WDigest está habilitado
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential

# Verificar o nível de compatibilidade NTLM
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# Valores 0-2 permitem NTLMv1; o valor 5 impõe apenas NTLMv2

Passo 3 - Coletar e Crackear

Com o WDigest habilitado, um comprometimento local que alcance o LSASS pode expor credenciais em texto claro diretamente:

# Exemplo Mimikatz com WDigest habilitado
sekurlsa::wdigest

Para senhas fracas ou de vida longa, os atacantes também podem crackear material NTLM offline após um dump de hashes:

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Passo 4 - Persistir por Meio de Higiene de Senha Fraca

Contas com PasswordNeverExpires são alvos de persistência duráveis. Se a conta for sensível e a senha nunca for rotacionada, o atacante mantém um caminho de autenticação válido até que um administrador o redefina explicitamente.

Detecção

Event IDs do Windows

Sinais Comportamentais

• Contas com senhas mais antigas do que a janela de rotação aprovada
• Contas habilitadas com PasswordNeverExpires ou PasswordNotRequired
• Campos de descrição contendo strings semelhantes a credenciais
• WDigest habilitado em endpoints ou servidores onde não é explicitamente necessário
• NTLMv1 ainda sendo negociado em ambientes que deveriam ser exclusivamente NTLMv2

Consulta de Detecção SIEM (Elastic KQL)

event.code: "4624" AND
winlog.event_data.LmPackageName: "NTLM V1"

Remediação

1. Aplicar uma Política de Senha de Domínio Forte

Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
    -MinPasswordLength 14 `
    -ComplexityEnabled $true `
    -MaxPasswordAge (New-TimeSpan -Days 90) `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -PasswordHistoryCount 24

2. Corrigir Senhas que Nunca Expiram

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
    Set-ADUser -PasswordNeverExpires $false

3. Corrigir Contas Sem Senha Obrigatória

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -PasswordNotRequired $false
}

4. Remover Senhas dos Campos de Descrição

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|senha"} | ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
        Write-Host "Descricao limpa para: $($_.SamAccountName)"
    }

5. Desabilitar o WDigest

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" `
    -Name UseLogonCredential -Value 0

Implemente via GPO sempre que possível: Computer Configuration > Administrative Templates > MS Security Guide > WDigest Authentication = Disabled

6. Impor Apenas NTLMv2

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name LmCompatibilityLevel -Value 5

Ou via política: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

7. Implantar o Microsoft Entra Password Protection (Ambientes Híbridos)

Para domínios sincronizados com o Microsoft Entra ID, o Microsoft Entra Password Protection on-premises bloqueia senhas fracas diretamente no controlador de domínio durante alterações e redefinições de senha — fechando uma lacuna que a política de complexidade nativa não cobre: palavras de dicionário, padrões de teclado e termos específicos da organização que tecnicamente satisfazem as regras de complexidade, mas são triviais de adivinhar.

A implantação tem dois componentes: um serviço Password Protection Proxy, que busca as listas de senhas banidas globais e personalizadas no Microsoft Entra ID, e um DC Agent instalado em cada controlador de domínio, que aplica localmente a política em cache contra eventos de alteração e redefinição de senha. O DC Agent continua aplicando a partir de sua cópia em cache mesmo se a conectividade com o proxy for temporariamente perdida.

# Confirmar que o DC Agent está instalado e registrando eventos de aplicação
Get-EventLog -LogName "Microsoft-AADPasswordProtection-DCAgent/Admin" -Newest 20

Comece em modo de auditoria para estabelecer uma linha de base de quantas senhas existentes seriam rejeitadas antes de mudar para o modo de aplicação, e adicione termos específicos da organização — nomes de marcas, nomes de produtos, codinomes de projetos internos — à lista personalizada de senhas banidas; a lista global sozinha não vai capturar isso.

Como o EtcSec Detecta Isso

O EtcSec audita os controles de identidade relacionados a senhas em cada varredura de AD.

PASSWORD_NEVER_EXPIRES sinaliza contas habilitadas com senhas que não expiram e ajuda a priorizar as identidades de maior risco.

PASSWORD_POLICY_WEAK avalia a Política de Senha Padrão do Domínio em relação à linha de base escolhida para comprimento, complexidade, histórico e idade.

PASSWORD_NOT_REQUIRED identifica contas onde a flag PASSWD_NOTREQD ainda está definida.

PASSWORD_IN_DESCRIPTION varre as descrições do diretório em busca de strings semelhantes a credenciais.

WDIGEST_ENABLED verifica o cache de credenciais em texto claro do WDigest.

NTLMV1_ALLOWED destaca ambientes que ainda permitem a negociação de NTLMv1.

Contas que Precisam de Tratamento Especial

Não aplique a mesma remediação cegamente a todas as classes de conta.

• Contas de serviço costumam quebrar quando uma senha é redefinida sem atualizar o serviço, a tarefa agendada ou o application pool que dependem dela.
• Contas tier-0 ou break-glass não devem manter credenciais fracas ou compartilhadas só porque são raramente usadas; elas exigem tratamento mais rigoroso, armazenamento mais forte e monitoramento explícito.
• Identidades administrativas compartilhadas devem ser removidas em vez de apenas rotacionadas. A rotação não resolve o problema de responsabilização (accountability).
• Aplicações legadas que ainda dependem de NTLMv1 ou de tratamento fraco de senhas precisam de uma exceção com prazo definido e um plano de migração, não de uma isenção permanente.

Como São Boas Evidências

Uma revisão de fortalecimento de senhas é muito mais fácil de defender quando a equipe guarda exatamente as evidências que comprovam que a limpeza aconteceu. Artefatos úteis incluem a exportação antes/depois das contas com PasswordNeverExpires, a lista de contas que antes tinham PasswordNotRequired, a confirmação de que o WDigest está desabilitado em sistemas representativos, e a nota de responsável ou de migração para qualquer conta de serviço que ainda precise de uma exceção temporária. Essa evidência importa porque a higiene de senhas tende a regredir por meio de exceções urgentes e atalhos de aplicação.

Validação Após a Remediação

Encerre o achado somente depois de reexecutar as mesmas etapas de descoberta que um atacante usaria:

• reexecutar os relatórios de PasswordNeverExpires e PasswordNotRequired e confirmar que as exceções remanescentes são intencionais
• verificar se as exceções de contas de serviço estão documentadas, possuem um responsável e estão vinculadas a um plano de migração, como a adoção de gMSA
• verificar por amostragem sistemas representativos para confirmar que UseLogonCredential é 0 onde o WDigest deveria estar desabilitado
• validar que LmCompatibilityLevel corresponde ao plano de implantação exclusivo de NTLMv2 e que sistemas legados foram tratados explicitamente
• reexecutar a busca no campo de descrição e confirmar que as credenciais foram removidas, e não apenas ocultadas em outro atributo

Controles Relacionados

A higiene de senhas se torna muito mais perigosa quando combinada com Kerberoasting: Como os Atacantes Crackeiam Senhas de Contas de Serviço, Contas Privilegiadas Obsoletas: Risco Oculto no Active Directory, Monitoramento do Active Directory: Os Event IDs de Segurança que Importam ou Ataques NTLM Relay: Sequestrando a Autenticação no AD. Revise esses controles na mesma janela de remediação para eliminar o caminho de ataque, e não apenas um sintoma.