MITRE ATT&CK® Technique

T1556.005: Reversible Encryption

An adversary may abuse Active Directory authentication encryption properties to gain access to credentials on Windows systems. The AllowReversiblePasswordEncryption property specifies whether reversible password encryption for an account is enabled or disabled. By default this property is disabled (instead storing user credentials as the output of one-way hashing functions) and should not be enabled unless legacy or other software require it.[1]

If the property is enabled and/or a user changes their password after it is enabled, an adversary may be able to obtain the plaintext of passwords created/changed after the property was enabled. To decrypt the passwords, an adversary needs four components:

1. Encrypted password (G$RADIUSCHAP) from the Active Directory user-structure userParameters 2. 16 byte randomly-generated value (G$RADIUSCHAPKEY) also from userParameters 3. Global LSA secret (G$MSRADIUSCHAPKEY) 4. Static key hardcoded in the Remote Access Subauthentication DLL (RASSFM.DLL)

With this information, an adversary may be able to reproduce the encryption key and subsequently decrypt the encrypted password value.[2][3]

An adversary may set this property at various scopes through Local Group Policy Editor, user properties, Fine-Grained Password Policy (FGPP), or via the ActiveDirectory PowerShell module. For example, an adversary may implement and apply a FGPP to users or groups if the Domain Functional Level is set to "Windows Server 2008" or higher.[4] In PowerShell, an adversary may make associated changes to user settings using commands similar to Set-ADUser -AllowReversiblePasswordEncryption $true.

EnterpriseT1556.005Sub-techniqueObject v2.0 Modified May 12, 2026, 15:12 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

Reversible Encryption matters because it can turn an Active Directory password setting into a credential exposure problem. If enabled for users, policy, or fine-grained password policy, passwords changed afterward may be recoverable in plaintext by an adversary with the right directory and LSA-secret material. For leaders, this is a Windows identity-control issue: a legacy compatibility setting can undermine password hashing assumptions and create persistence, credential access, and defense-impairment risk.

Executive priority

Prioritize validation that reversible password encryption is disabled except where a documented legacy requirement exists. This should be treated as an identity governance and audit-evidence item: know who can enable it, where it is enabled, which accounts are affected, and whether privileged accounts are excluded. If found enabled, incident decision-making should consider password exposure for accounts that changed passwords after enablement, especially privileged users.

Technical view

For SOC, detection engineering, and IR teams, focus on Active Directory changes that enable AllowReversiblePasswordEncryption through user properties, Local Group Policy, Fine-Grained Password Policy, or Active Directory PowerShell activity such as Set-ADUser changes. Because the ATT&CK object provides no official detection text, validate against the related detection strategy DET0589, "Detect Modification of Authentication Process via Reversible Encryption," and confirm whether directory auditing captures both direct user-account changes and policy-driven changes. Treat this as part of the parent Modify Authentication Process behavior on Windows Active Directory.

Likely telemetry

Active Directory user attribute change events for AllowReversiblePasswordEncryption or equivalent account-control changes
Group Policy and Local Group Policy change records related to storing passwords using reversible encryption
Fine-Grained Password Policy creation, modification, and application to users or groups
PowerShell activity using the ActiveDirectory module that modifies user or policy settings
Privileged account administration logs showing who changed authentication or password policy settings

Detection direction

Baseline where reversible encryption is enabled and alert on new enablement, especially for privileged or administrative users.
Tune detections to distinguish documented legacy exceptions from unexpected user, group, or policy changes.
Correlate reversible-encryption changes with privileged account activity because related mitigation guidance emphasizes privileged account management.
Include FGPP and policy-scope changes, not only direct per-user changes, to reduce blind spots.
Because official ATT&CK detection text is not provided, test DET0589-style logic in the local AD environment before treating coverage as effective.

Mitigation priorities

Keep reversible password encryption disabled by default and require documented approval for any exception.
Apply privileged account management: restrict who can modify user properties, password policies, Group Policy, and FGPP settings.
Use password policy governance to prevent insecure configurations and maintain reviewable evidence for audits.
If reversible encryption was enabled, assess affected users based on when the setting was enabled and when passwords were changed; prioritize privileged accounts for remediation decisions.
Monitor and periodically review legacy dependencies that claim to require reversible encryption.

Analyst notes and limits

This is a Windows-focused Active Directory sub-technique under Modify Authentication Process with tactics of defense impairment, persistence, and credential access. The material risk is not merely weak password policy; it is that an authentication setting can make later password changes recoverable in plaintext if other required secret material is obtained. Relationship context supplies one detection strategy, DET0589, and mitigations M1026 Privileged Account Management and M1027 Password Policies.

The supplied ATT&CK object does not include official detection guidance, procedure examples, active exploitation claims, or affected software beyond Windows. Local evidence is required to determine whether the setting is enabled, which accounts are affected, whether exceptions are legitimate, and whether audit logs capture the relevant changes.

Official MITRE ATT&CK definition

Reversible Encryption

With this information, an adversary may be able to reproduce the encryption key and subsequently decrypt the encrypted password value.[2][3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1556	Modify Authentication Process	This object subtechnique of Modify Authentication Process.

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1026: Privileged Account Management Enterprise mitigates · Mitigation M1027: Password Policies Enterprise detects · Detection Strategy DET0589: Detect Modification of Authentication Process via Reversible Encryption Enterprise subtechnique of · Technique T1556: Modify Authentication Process Enterprise

Mitigations

Mitigation direction

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

M1027: Password Policies

Set and enforce secure password policies for accounts to reduce the likelihood of unauthorized access. Strong password policies include enforcing password complexity, requiring regular password changes, and preventing password reuse. This mitigation can be implemented through the following measures:

Windows Systems:

- Use Group Policy Management Console (GPMC) to configure: - Minimum password length (e.g., 12+ characters). - Password complexity requirements. - Password history (e.g., disallow last 24 passwords). - Account lockout duration and thresholds.

Linux Systems:

- Configure Pluggable Authentication Modules (PAM): - Use `pam_pwquality` to enforce complexity and length requirements. - Implement `pam_tally2` or `pam_faillock` for account lockouts. - Use `pwunconv` to disable password reuse.

Password Managers:

- Enforce usage of enterprise password managers (e.g., Bitwarden, 1Password, LastPass) to generate and store strong passwords.

Password Blacklisting:

- Use tools like Have I Been Pwned password checks or NIST-based blacklist solutions to prevent users from setting compromised passwords.

Regular Auditing:

- Periodically audit password policies and account configurations to ensure compliance using tools like LAPS (Local Admin Password Solution) and vulnerability scanners.

*Tools for Implementation*

Windows:

- Group Policy Management Console (GPMC): Enforce password policies. - Microsoft Local Administrator Password Solution (LAPS): Enforce random, unique admin passwords.

Linux/macOS:

- PAM Modules (pam_pwquality, pam_tally2, pam_faillock): Enforce password rules. - Lynis: Audit password policies and system configurations.

Cross-Platform:

- Password Managers (Bitwarden, 1Password, KeePass): Manage and enforce strong passwords. - Have I Been Pwned API: Prevent the use of breached passwords. - NIST SP 800-63B compliant tools: Enforce password guidelines and blacklisting.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 2.0
Created: Jan 13, 2022, 20:02 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 519eb0cf043814cb...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`519eb0cf0438…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
store_pwd_rev_enc

Microsoft. (2021, October 28). Store passwords using reversible encryption. Retrieved January 3, 2022.
Open source URL
[2]
how_pwd_rev_enc_1

Teusink, N. (2009, August 25). Passwords stored using reversible encryption: how it works (part 1). Retrieved November 17, 2021.
Open source URL
[3]
how_pwd_rev_enc_2

Teusink, N. (2009, August 26). Passwords stored using reversible encryption: how it works (part 2). Retrieved November 17, 2021.
Open source URL
[4]
dump_pwd_dcsync

Metcalf, S. (2015, November 22). Dump Clear-Text Passwords for All Admins in the Domain Using Mimikatz DCSync. Retrieved November 15, 2021.
Open source URL
[5]
mitre-attack T1556.005
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use