Active Directory normally stores password hashes, which cannot be turned back into passwords. One account setting changes that. MITRE ATT&CK technique T1556.005, Reversible Encryption, covers abusing it to reach plaintext credentials. The tactics are defense impairment, persistence and credential access, and the platform is Windows.
How attackers use it
The AllowReversiblePasswordEncryption property specifies whether reversible password encryption is enabled for an account. By default it is disabled, and credentials are stored as the output of one way hashing. It should stay off unless a legacy or other application requires it.
If the property is enabled, or a user changes their password after it was enabled, MITRE says an adversary may be able to obtain the plaintext of passwords created or changed after that point. Decryption needs four items: the encrypted password (G$RADIUSCHAP) and a 16 byte random value (G$RADIUSCHAPKEY), both from the userParameters attribute, the global LSA secret (G$MSRADIUSCHAPKEY), and a static key hardcoded in the Remote Access Subauthentication DLL (RASSFM.DLL). With those, an adversary may reproduce the key and decrypt the value.
MITRE also covers how the setting gets turned on: through Local Group Policy Editor, user properties, a Fine-Grained Password Policy applied to users or groups, or the ActiveDirectory PowerShell module, for example Set-ADUser -AllowReversiblePasswordEncryption $true.
How to detect it
MITRE lists no data sources here. Watch for changes to the setting and to the policies that apply it:
- Windows event 4738, a user account was changed, which records changes to account control flags.
- Creation or change of Fine-Grained Password Policy objects.
- Group Policy changes to the password policy that store passwords using reversible encryption.
- PowerShell logging that shows
Set-ADUserwith the reversible encryption parameter.
How to reduce the risk
MITRE lists two mitigations.
- Privileged account management. Audit domain and local accounts and their permission levels regularly, so you notice where an adversary could gain wide access by obtaining a privileged account, and check default accounts and unauthorized new local accounts.
- Password policies. Keep
AllowReversiblePasswordEncryptiondisabled unless an application requires it.
Passwords changed while the setting was on remain at risk until the user changes them again, so after you fix the setting, rotate those passwords.
Check your own environment
# Windows AD: find accounts with reversible encryption enabled
Get-ADUser -Filter 'AllowReversiblePasswordEncryption -eq $true' -Properties AllowReversiblePasswordEncryption |
Select-Object SamAccountName, AllowReversiblePasswordEncryption
# Windows AD: review the default domain password policy
Get-ADDefaultDomainPasswordPolicy | Select-Object ReversibleEncryptionEnabled
# Windows AD: review fine grained password policies
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, ReversibleEncryptionEnabled
The goal is an empty first list and False in the other two outputs. For any exception, record the application that requires it.
Quick check
Why must passwords be rotated after fixing the setting?
Passwords created or changed while reversible encryption was enabled can be recovered in plaintext. Turning the setting off does not change values already stored that way.