Auditing Windows Reversible Password Encryption: The AD Setting That Stores Decryptable Passwords

Most Windows password storage is genuinely one-way. The NT hash in the SAM or NTDS.dit is an unsalted MD4 digest — bad by modern standards, crackable with enough GPU, but you still have to crack it. Reversible encryption is different: it stores the account's password in a form that can be decrypted straight back to plaintext, no cracking required. An attacker who reaches your domain controller doesn't dump hashes for an offline attack; they walk away with the literal passwords. This is one of the highest-severity misconfigurations in Active Directory, and it hides quietly in a checkbox almost nobody looks at.

What "reversible encryption" actually means

When the ENCRYPTED_TEXT_PASSWORD_ALLOWED flag (bit 0x0080 in userAccountControl) is set on an account, the DC keeps a symmetrically encrypted copy of the password alongside the usual hashes. The key material is derived from the DC's own secrets, so anyone who can read the directory database can recover the cleartext. In practice, tools like secretsdump.py print these out plainly:

administrator:...:aad3b435...:31d6cfe0...:::
[*] ClearText passwords
svc-legacy-app:CLEARTEXT:Summer2026!Fleet

That CLEARTEXT line is the whole ballgame. There's no wordlist, no rig, no waiting. If reversible encryption is on for an account, a DC compromise — or an NTDS.dit backup, or a stray shadow copy — hands over that password directly.

Why it gets turned on

Nobody enables this maliciously; it creeps in through legacy requirements:

• CHAP and MS-CHAP authentication for old RAS/VPN or IEEE 802.1X setups that needed the DC to know the plaintext.
• Digest Authentication in IIS configured for a subset of accounts.
• A blanket Group Policy where someone flipped "Store passwords using reversible encryption" domain-wide years ago and never revisited it.
• Fine-grained password policies (PSOs) that inherited the setting for a specific group.

The dangerous case is the domain-wide GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy → Store passwords using reversible encryption. If that is Enabled, every account's password becomes recoverable on its next change.

How to audit for it

There are two things to check: the policy, and the accounts that already carry the flag. Start with the accounts, because a policy can be off today while accounts set months ago still hold reversible copies until their next password change.

Get-ADUser -Filter 'userAccountControl -band 128' -Properties userAccountControl |
  Select-Object SamAccountName,
    @{n='ReversibleEncryption';e={[bool]($_.userAccountControl -band 128)}}

Or use the purpose-built property, which also surfaces PSO inheritance:

Get-ADUser -Filter { AllowReversiblePasswordEncryption -eq $true } `
  -Properties AllowReversiblePasswordEncryption |
  Select-Object SamAccountName, DistinguishedName

Then confirm the domain policy state and any fine-grained policies:

(Get-ADDefaultDomainPasswordPolicy).ReversibleEncryptionEnabled
Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, ReversibleEncryptionEnabled

Any non-empty result from the account queries, or a True on either policy, is a finding you act on the same day.

Remediation

1. Disable the setting at every level — the default domain policy, any PSO, and the per-account flag (Set-ADAccountControl -Identity svc-legacy-app -AllowReversiblePasswordEncryption $false).
2. Force a password change on every affected account. Clearing the flag stops future reversible storage, but the existing decryptable copy persists until the password is reset. This is the step teams forget.
3. Retire the dependency. If CHAP or Digest forced it, migrate that service to a modern protocol (EAP-TLS, Kerberos, OAuth) so the requirement disappears for good.

Where this sits in a compliance program

This maps cleanly to the CIS Microsoft Windows benchmarks — the "Store passwords using reversible encryption" control is a required Disabled setting — and to NIST 800-53 credential-protection controls. It's the kind of finding an annual audit catches once and then never re-checks, which is exactly how it drifts back on when a new legacy app gets stood up.

How WinSentinel handles it

On a single machine, WinSentinel's account and credential-hygiene checks flag reversible encryption wherever it can observe it — no license tier gates this. The free agent runs the full audit locally and reports the finding with remediation steps inline. For an organization running WinSentinel Pro across a fleet, the central node rolls these findings up: you see every domain and endpoint where reversible encryption is enabled in one compliance view, get a drift alert the moment a new account or PSO turns it back on, and can track remediation to closure across all managed machines. The single-box audit tells you you have a problem; the fleet view tells you which of your fifty domains quietly regressed last week.

The takeaway

Reversible password encryption converts "an attacker cracked some hashes" into "an attacker has your passwords." It's a one-checkbox catastrophe that survives audits because almost nobody queries for the residual accounts after the policy is off. Query for the flag, force the resets, kill the legacy dependency — and then keep watching, because this is a setting that comes back.