Microsoft Defender for Identity Recommended Actions: Reversible passwords found in GPOs

by thalpius

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The seventeenth one in the series is the “Reversible password found in GPOs” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Reversible password found in GPOs.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Reversible Passwords

Upon reflection, the term “Reversible Passwords” seems somewhat amusing. It raises the question: What constitutes an irreversible password? If passwords are encrypted, does that imply that with a reversible password, the key is discarded, making it an irreversible password? With encrypted passwords using a symmetric key, as long as the key exists, passwords remain reversible. The title of this recommended action is also confusing, as there is an option called “Store passwords using reversible encryption” in Active Directory, which has nothing to do with this recommended action.

What I find amusing is that the password is “reversible” for anyone due to Microsoft accidentally publishing the symmetric key on MSDN 🤷🏻‍♂️

Yes, Microsoft accidentally published the symmetric key back in 2012 which malicious actors were very grateful for. Since Microsoft was kind enough to publish the key, malicious actors can decrypt passwords found in Group Policy Objects containing an encrypted password.

Group Policy Objects

Group Policies enable the configuration of user or computer settings within an on-premises environment. They are a crucial component of the Domain Controller, offering extensive possibilities for environment configuration.

One such configuration allows the addition of a user to every computer in the domain with a specified password. Upon restarting the computer or during an automatic policy refresh, the user is added to the local computer where the policy is applied. The policy includes the specification of a username and password.

Image 1: Adding a local user using a GPO

Since each computer needs to know the configuration settings, policies are stored in the SYSVOL folder on every Domain Controller. Any authenticated user can access these policies. Therefore, passwords cannot be stored in plain text for security reasons. Microsoft encrypts the passwords using an AES key, ensuring that without the key, the passwords cannot be read in plain text.

Unfortunately, because Microsoft inadvertently published the key, it is possible to decrypt the passwords. A PowerShell script, such as the one referenced, can utilize the published key to decrypt the passwords specified in the domain policy. This situation poses a significant security risk.

Note: Since 2014, creating a user with a password, configuring a scheduled task, or mounting a network drive with a specified password has been prohibited. Microsoft disabled these options due to associated security risks. Fortunately, Microsoft Defender for Identity can identify encrypted passwords located in the SYSVOL folder.

PowerShell Example

As you read this blog post, you are likely already using Microsoft Defender for Identity, which I highly recommend. If you wish to search for encrypted passwords in a domain policy that can be decrypted using the published key, here is a one-liner PowerShell script.

Get-ChildItem -Path \\domain.local\SYSVOL\ -Recurse -Include *.xml | Select-String -Pattern "cpassword" | Select-Object Path, Line

Here is an example of an XML file containing an encrypted password.

<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}"><User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}" name="User" image="0" changed="2012-05-01 10:25:22" uid="{22446077-737D-4D0B-9CE2-D1F5814B5700}" userContext="0" removePolicy="0"><Properties action="C" fullName="User" description="User" cpassword="OXdz8YJUEFZduEcfyxJfgm3ArpMpXtZeMfs7YzjO7Vk" changeLogon="0" noChange="1" neverExpires="0" acctDisabled="0" userName="User"/></User>
</Groups>

The following script enables the decryption of the password to plain text.

Conclusion

Although it is no longer possible to set a password in a Group Policy, any policies created in the past may still contain encrypted passwords that malicious actors can decrypt to obtain plain-text passwords. Microsoft Defender for Identity can identify these passwords within Group Policies, and it is highly recommended to remove any passwords from such policies. For those still using an on-premises environment, there are more secure methods available for device configuration.