cpassword – MS14-025

Microsoft announced MS14-025 on 13 May, 2014. However, it continues to be an issue for many IT organizations, even when patched. I repeat, by simply installing the KB you have not fully remediated the vulnerability (elevate of privileges!) unless you ran the provided PowerShell code to ensure you don't have any existing cpassword Group Policies.

For starters… just how bad is MS14-025? Well, I'm glad you asked. It allows an adversary to jump from regular user and directly become local admin if they can discover a vulnerable policy in SYSVOL. How can this be done? Well, any domain entity has the ability to read from SYSVOL, which is how Group Policies are disseminated across an Enterprise! This means, that even a spearphish email campaign can lead to local admin rights to the adversary, even if you spent tons of time ensuring your users don't run as local admin. I repeat, all that work is for nothing unless you do this and run this script—the KB/patch simply ensures you can no longer create bad policies, it doesn't disable/delete the existing ones! Not only this, but many times this policy manages a local admin account across computers, meaning it can be used to laterally move as well, drastically increasing the likelihood an adversary will find the keys to the kingdom, a domain admin or other highly privileged domain account (or any of these accounts with Tier-0 equivalency).

Our guidance remains here.

Hackers are taking advantage of this for years and unfortunately are very successful via this still. Tools like PowerSploit automatically discover these and reverse the symmetrically encrypted password (that Microsoft was forced to publish, which is/has been on MSDN giving attackers such access), giving the attacker the plaintext password.

However, for Incident Responders and those who want to go further than just checking for these policies but to truly understand what is at stake if/when they are discovered, I've developed one that extends our previous guidance. It can be found here: https://aka.ms/cpasswordscript. As the screenshot shows, policies can be complex, including possibly even having the account disabled! Knowing this information could really help drive the urgency if/when such policies are discovered… you should certainly always delete these and transition to our free Local Account Password Solution (LAPS; https://aka.ms/LAPS, which leverages Group Policy Objects Client Side Extensions (CSE)!), but obviously we know there are many other actions an IT team has, many of which are priority. And of course, IR teams should run this whenever they head to a customer… without running this, you potentially are missing a massive gap.

My script above keeps provides relevant data to make relevant decisions, so you:

• Can quickly tell if the policy has the account disabled
• Can quickly see impacted user
• Can quickly assess the exact Path of the where the policy is
• Can quickly identify the exact GP Global Unique ID (GUID) (this can easily be used to remove such policies if ran with the right privileges)

The script doesn't give you the plaintext password, purely to prevent potential liability if your team is external to the customer whom you are providing a service to. However, just know, its easily decrypted which is why this vulnerability exists in the first place.

Hopefully this helps someone and stop another Fortune 500 or major government entity from being completely compromised because of a single Group Policy they didn't know existed…

And do let us know if you have discovered such policies in your environment or if you have any questions on the above.

Andrew