Senha em Texto Claro e Criptografia Reversível no Active Directory: A Armadilha do userPassword

Senha em Texto Claro e Criptografia Reversível no Active Directory

Senha em Texto Claro e Criptografia Reversível no Active Directory é uma das poucas configurações incorretas que pulam completamente o fluxo de trabalho usual do atacante — nenhum hash para quebrar, nenhum ticket para repassar, apenas uma senha em texto claro dentro do diretório, diferente de um NT hash roubado e reutilizado via Pass-the-Hash. O Active Directory foi projetado para nunca armazenar uma cópia utilizável de uma senha: todo valor de unicodePwd é hasheado de forma unidirecional (NT hash e chaves de longo prazo do Kerberos) antes de chegar ao banco de dados, e o próprio atributo não pode ser lido de volta via LDAP. A documentação do protocolo MS-SAMR da Microsoft é explícita sobre o único caso que quebra essa garantia: o armazenamento da senha em texto claro para um objeto só é configurado quando o valor Effective-PasswordReversibleEncryptionEnabled da conta está definido, ou quando seu atributo userAccountControl contém o bit ENCRYPTED_TEXT_PWD_ALLOWED (0x0080) — depois disso, a próxima definição ou alteração de senha grava uma cópia decifrável em supplementalCredentials.

Este artigo cobre dois modos de falha distintos, no nível de atributo, que terminam com um atacante obtendo uma credencial utilizável em texto claro diretamente do diretório:

• O atributo LDAP legado userPassword, que alguns ambientes preenchem diretamente com uma string literal.
• A flag de criptografia reversível em userAccountControl, que instrui todo controlador de domínio a manter uma cópia decifrável da senha junto com os hashes normais.

Ambos são classificados como Críticos no catálogo de auditoria da etc-collector (PASSWORD_CLEARTEXT_STORAGE, REVERSIBLE_ENCRYPTION), porque comprometer qualquer um dos dois dá ao atacante a senha literal, não apenas um hash para quebrar ou repassar. Essa distinção importa operacionalmente: um hash quebrado ou uma sessão repassada pode ser contido girando uma credencial e revisando o que ela alcançava, mas uma senha em texto claro recuperada costuma ser reutilizada em outros lugares — contas pessoais, outros sistemas, outros domínios —, então o raio de impacto de qualquer uma das duas exposições vai muito além do objeto AD onde foi encontrada.

Como funciona

O atributo userPassword

userPassword é um atributo LDAP padrão (definido fora do schema da Microsoft, em padrões de diretório derivados da RFC 4519) que o Active Directory também reconhece sob condições específicas. Conforme MS-ADTS §3.1.1.3.1.5.2, o AD permite que clientes escrevam e usem userPassword para definir a senha de uma conta apenas quando:

• o DC está rodando como AD LDS, ou
• o DC é AD DS, o nível funcional do domínio é Windows Server 2003 ou superior, e
• a heurística fUserPwdSupport no atributo dSHeuristics está habilitada.

Quando essa heurística está desativada (padrão no AD DS), userPassword é apenas um atributo comum, não indexado, sem semântica especial — e é exatamente essa a armadilha: muitos administradores e scripts de provisionamento (ferramentas de migração LDAP, jobs de sincronização de RH, integrações Unix/LDAP legadas) ainda escrevem uma senha em texto claro em userPassword por hábito ou necessidade de interoperabilidade. Diferente de unicodePwd, esse atributo é legível por qualquer pessoa com direitos genéricos de leitura sobre o objeto — uma simples busca LDAP (userPassword=*) pode extrair todo valor em texto claro já escrito ali, sem necessidade de escalada de privilégio, sem quebra de hash, sem repasse.

ldapsearch -x -H ldap://dc01.corp.local -D "[email protected]" -W \
  -b "DC=corp,DC=local" "(userPassword=*)" sAMAccountName userPassword

A flag UAC de criptografia reversível

O segundo mecanismo é o bit ENCRYPTED_TEXT_PWD_ALLOWED (decimal 128 / hex 0x0080) dentro de userAccountControl, exposto no objeto de usuário como o atributo ms-DS-User-Encrypted-Text-Password-Allowed e, no módulo AD PowerShell, como a propriedade de conta AllowReversiblePasswordEncryption. Definir essa flag não grava, por si só, uma senha em texto claro — ela muda o que acontece na próxima definição ou alteração de senha: o AD armazena a nova senha em supplementalCredentials em um formato que pode ser decifrado com a própria chave de criptografia do domínio, além dos hashes normais.

Essa flag existe para suportar protocolos de autenticação legados que precisam da senha real para calcular um challenge-response, mais comumente CHAP para RADIUS/IAS de discagem e VPN, e implementações mais antigas de IIS Digest Authentication. A própria documentação de política de segurança da Microsoft é direta sobre o trade-off: habilitá-la "é essencialmente o mesmo que armazenar versões em texto claro das senhas", e nunca deveria ser ativada em todo o domínio, a menos que uma aplicação realmente precise disso.

Se um domínio precisa disso para um pequeno grupo de contas de serviço legadas, delimitar bem o escopo importa: um objeto de Fine-Grained Password Policy (Password Settings Object) pode definir msDS-PasswordReversibleEncryptionEnabled apenas na OU ou grupo que precisa disso, em vez de ativar a configuração "Armazenar senhas usando criptografia reversível" na Default Domain Policy para todas as contas do domínio.

🚨 Perigo: MITRE ATT&CK T1556.005 documenta isso como uma técnica ativa de atacante, não apenas uma configuração incorreta legada: com direitos suficientes, um atacante pode executar Set-ADUser -AllowReversiblePasswordEncryption $true contra uma conta-alvo, esperar (ou forçar) uma redefinição de senha e depois recuperar a senha em texto claro a partir da próxima credencial armazenada da conta — transformando uma única permissão de escrita em uma backdoor permanente de coleta de credenciais que sobrevive à rotação de senha.

Por que isso ainda aparece em ambientes modernos

Nenhum dos dois mecanismos é uma relíquia que afeta apenas domínios da era Windows 2000. userPassword reaparece sempre que uma organização roda ferramentas de sincronização de identidade originalmente construídas para OpenLDAP ou outro diretório baseado em RFC 4519 e as aponta para o Active Directory sem ajuste — o job de sincronização grava o campo para o qual foi construído, e nada no AD o impede, desde que dSHeuristics permita. A criptografia reversível reaparece da mesma forma: um appliance RADIUS, um concentrador VPN antigo ou uma aplicação de intranet legada usando IIS Digest Authentication é configurado uma vez, a política em todo o domínio é ativada para fazer funcionar, e a configuração sobrevive silenciosamente à aplicação que precisava dela — muitas vezes por anos, em todas as contas do domínio, muito depois de qualquer pessoa lembrar por que ela existe.

Os dois casos compartilham a mesma causa raiz: a configuração é um interruptor de todo o domínio ou de todo o objeto, mas a necessidade real é quase sempre estreita — uma aplicação, uma integração, um protocolo legado. Nada obriga uma revisão quando a dependência desaparece, então a exposição persiste como dívida técnica pura até que uma auditoria — ou um atacante — a encontre. Ela pertence à mesma lista de observação das configurações incorretas de segurança do Active Directory mais comuns, que sobrevivem anos além da justificativa original.

Detecção

# Contas com criptografia reversível atualmente habilitada
Get-ADUser -Filter {AllowReversiblePasswordEncryption -eq $true} `
  -Properties AllowReversiblePasswordEncryption, PasswordLastSet |
  Select-Object SamAccountName, PasswordLastSet

# Filtro LDAP bitwise-AND equivalente (matching-rule OID 1.2.840.113556.1.4.803)
Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=128)" `
  -Properties userAccountControl | Select-Object SamAccountName

Como userPassword é um atributo genérico que o AD não indexa nem protege de forma especial por padrão, uma varredura LDAP agendada por (userPassword=*) em todo o domínio é a única forma confiável de detectá-lo; não existe um evento de segurança dedicado para gravação nesse atributo, então reauditar periodicamente importa tanto quanto a varredura inicial.

Remediation

1. Audite antes de tocar em qualquer coisa. Execute as duas consultas acima em todo o domínio e registre cada ocorrência — desativar a flag ou limpar userPassword força uma troca de senha para essa conta, então planeje a rotação com os donos das contas antes.
2. Desative a criptografia reversível em todo o domínio via Group Policy (Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy > "Armazenar senhas usando criptografia reversível" = Desativado), a menos que exista uma dependência legada específica de CHAP/RADIUS ou IIS Digest Authentication.
3. Se houver uma dependência legítima, delimite-a com uma Fine-Grained Password Policy (msDS-PasswordReversibleEncryptionEnabled) aplicada apenas na OU ou grupo que roda essa aplicação — nunca em todo o domínio.
4. Limpe todos os valores de userPassword encontrados e desative novamente fUserPwdSupport em dSHeuristics, a menos que o DC esteja rodando intencionalmente como AD LDS ou uma integração documentada precise disso.
5. Force uma redefinição de senha para cada conta afetada. Desativar a flag ou limpar o atributo não remove retroativamente material de credencial já gravado em supplementalCredentials — só a próxima troca de senha faz isso.
6. Restrinja o acesso de escrita a userAccountControl e userPassword para usuários padrão; ambos devem ser alteráveis apenas pela administração de identidade Tier 0, e qualquer concessão GenericAll/GenericWrite que alcance esses atributos merece o mesmo escrutínio que um caminho até Domain Admin.
7. Conecte o Event ID 4738 ao seu SIEM com um alerta quando Encrypted Text Password Allowed aparecer na lista de atributos alterados, no mínimo para contas privilegiadas e de serviço, e execute as varreduras LDAP de forma recorrente, não como limpeza única.
8. Documente qualquer exceção remanescente. Se uma aplicação legada realmente ainda precisa de criptografia reversível, registre o dono, a data de revisão e o plano de descomissionamento — uma exceção não documentada é indistinguível de uma esquecida na próxima auditoria.

Como a EtcSec detecta isso

O catálogo de auditoria da EtcSec rastreia os dois mecanismos como verificações separadas, de severidade Crítica: PASSWORD_CLEARTEXT_STORAGE sinaliza qualquer objeto em que userPassword tenha um valor, e REVERSIBLE_ENCRYPTION sinaliza qualquer conta com AllowReversiblePasswordEncryption habilitado (o bit UAC ENCRYPTED_TEXT_PWD_ALLOWED). Ambos ficam na categoria Password junto com verificações relacionadas como conformidade de política de senha e segredos cPassword do GPO SYSVOL — juntas, elas cobrem as poucas formas pelas quais um diretório pode acabar guardando uma senha que um atacante nem precisa quebrar.