First published on TechNet on Apr 18, 2016
Hello, my name is Paul Bergson and this is my first time writing a blog for PFE Plat. I am a platforms PFE in the Premier division of Microsoft. If my name looks familiar, it could be because I spent about 10 years in TechNet’s Directory Service Forum as an MVP and Moderator (pbbergs).
I wanted to write a follow up regarding a couple of credential protection security updates released in May of 2014. I have visited many customers who have never rolled these out, so I thought it important to call attention to them. The two updates in question are ranked as “Important” and not “Critical,” and as a result, the importance of these may not have been understood. Following are the two updates I will be discussing:
- KB2871997 Provides changes to help mitigate Pass-The-Hash, remove clear text storage of passwords, Creation of two new Local Security groups, RDP /restrictedadmin Mode & Protected Users groups.
This update is available for Win7/Win8/2008 R2/2012
Updated: February 9, 2016
- KB2928120 Provides protection for “Group Policy Preferences” credential theft.
This update is available for Vista/Win7/Win8/Win8.1/2008/2008 R2/2012/2012 R2
KB2871997
Removal of Clear-Text Credentials for LSASS:
“This update prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s clear-text password.” WDigest stores passwords in clear text in LSASS and the only way to prevent this is to disable WDigest.
http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx
https://support.microsoft.com/en-us/kb/2871997
“WDigest.dll was introduced in the Windows XP operating system The Digest Authentication protocol is designed for use with Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges, as documented in RFCs 2617 and 2831.”
https://technet.microsoft.com/en-us/library/cc778868(v=ws.10).aspx
Even though you have installed KB2871997, it doesn’t mitigate WDigest’s storage of clear text passwords in LSASS memory -- it merely gives you the ability to change this behavior.
Before the WDigest authentication protocol is disabled, it is recommended to inspect authentication to ensure that it isn’t in use and, therefore, break an app. You can configure Event Audit logging to inspect for WDigest usage by following these blogs:
http://blogs.technet.com/b/kfalde/archive/2014/11/01/kb2871997-and-wdigest-part-1.aspx
http://blogs.technet.com/b/kfalde/archive/2014/11/02/kb2871997-and-wdigest-part-2.aspx
Since most domains have two or more DC’s, it would be easier to monitor the Event Logs by configuring Windows Event Forwarding. For more information, please refer to the following blog:
If you find there is no usage of WDigest and you want to disable it, then follow the steps from KB2871997:
After you install this security update, you can control how installed WDigest credentials can be saved by using a registry setting. To prevent WDigest credentials from being stored in memory, a Group Policy setting can be applied to the UseLogonCredential registry entry under the following subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
- If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.
- If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.
Creation of Two New Local Security Groups:
When this patch is applied, two new, dynamic security groups are created to provide the ability to prevent a remote logon with a local account. To help mitigate the threat of Lateral Account Movement, it is recommended to deny a local account the ability to log onto a remote host. In particular, many organizations have the same local administrative name and password. Once an attacker learns the administrative credentials on one machine, they are then able to laterally move across the domain.
http://blogs.technet.com/b/secguide/archive/2014/09/02/blocking-remote-use-of-local-accounts.aspx
The two new “Dynamic” membership local groups are:
- Local_Account
- Local_Account_and_Member_of_Administrators_Group
When a user logs onto a host with a local account, the system automatically makes them a member of the group, “Local_Account.” If this same user is also a member of the local administrators group, then they will also be made a member of the group, “Local_Account_and_Member_of_Administrators_Group.”
The Remote Logon is governed by the “Allow Logon through Terminal Services” right through local or group policy. This setting can be found under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. By utilizing these two new groups and applying deny within the policy, it will prevent remote access with a local account.
Since these two groups are dynamically managed by the system, you won’t be able to see them with the account picker, but if the following code is run on a machine, it will show if the groups exist.
Try {
$objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-113")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
Write-Host "$objUser.Value --> found"
}
Catch {
"***2871997*** The group Local_Account --> not found"
}
Try {
$objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-114")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
Write-Host "$objUser.Value --> found"
}
Catch {
"***2871997*** The group LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP --> not found"
}
New Switch Added for RDP Access:
A new RDP switch called “/restrictedadmin” (RDPRA) has been added, which will prevent hosts from caching the credentials of remotely authenticated users in memory. This mitigates one of the Pass-the-Hash risks when a remote user authenticates to a compromised host since the password can’t be harvested from LSA memory. Please note that this switch is only available if the user is a member of the local administrators group.
It would be recommended to use this switch whenever an elevated domain account needs to connect to an “uncontrolled” server or workstation. Support personnel who connect to a remote host without using “/restrictedadmin” run the risk of exposing their credentials. If this remote host is compromised, the elevated credentials could then be harvested.
Keep in mind that, in an enterprise environment it is recommended to limit where RDP connections originate from when connecting to user workstations, even when using RDPRA. This is part of the lateral account movement mitigation and is called out in our recently released white paper on Privileged Access Workstations (PAW).
https://technet.microsoft.com/en-US/library/mt634654.aspx
Using the RA switch modifies the ability to connect to other systems from the remote host. When that occurs, the local computer account is used instead of the logged on user account.
Note: There have been two Security Advisory follow ups related to RDPRA:
2973351 Registry update to improve credentials protection and management for Windows-based systems that have the 2919355 update installed.
2975625 Registry update to improve credentials protection and management for Windows systems that do not have the 2919355 update installed.
This update provides configurable registry settings for managing the Restricted Admin mode for Credential Security Support Provider (CredSSP).
The update changes default RDPRA functionality in Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1.
https://support.microsoft.com/en-us/kb/2973351
Protected Users Security Group:
This update provides support for the newly introduced domain security group in Server 2012 R2 called “Protected Users.” This group doesn’t provide any special protection of the user’s credentials – instead, it limits where and how those credentials can be used.
Restrictions for members of this group are as follows:
- Can only sign on using the Kerberos Protocol (No NTLM, Digest or CredSSP)
- NOTE: With NTLM disabled, drives cannot be mapped via IP address – only resource name.
- Requires the use of AES
- Cannot use DES or RC4 encryption
- Cannot use Kerberos “Constrained or Unconstrained Delegation”
- Any attempt to connect to systems utilizing delegation will fail even if it is configured to allow it on the user object
- Kerberos TGT lifetime of four hours, which is configurable
- Can leverage the use of “Authentication Policies and Silos”
https://technet.microsoft.com/en-us/library/dn408190.aspx
A recent blog on the “Protected Users Security Group”
Pass the Hash White Paper (Version 1 & 2)
- http://www.microsoft.com/en-us/download/details.aspx?id=36036
- http://blogs.technet.com/b/lrobins/archive/2011/06/23/quot-admin-free-quot-active-directory-and-windows-part-1-understanding-privileged-groups-in-ad.aspx
- http://blogs.technet.com/b/lrobins/archive/2011/06/23/quot-admin-free-quot-active-directory-part-2-protected-accounts-and-groups-in-active-directory.aspx
KB2928120
A vulnerability was discovered that could allow an attacker to retrieve and decrypt any passwords that were delivered (Stored) within Active Directory’s “Group Policy Preferences.” The security update modifies the Group Policy Management Editor window of the Group Policy Management Console (GPMC) by removing the ability to configure and distribute passwords using the following Group Policy Preferences extensions:
- Local user and group
- Mapped drives
- Services
- Scheduled tasks
- Data sources
This patch only prevents the creation of new policies, if any of these previous preferences have been used, you need to ensure any passwords stored in the xml file within SysVol have been removed. Deleting the policy or definition within the preference will remove it from SysVol.
Looking at the *.XML file example below is a copy of a Group Policy Preference that modifies the local administrator’s password. In this the password is protected using 256-bit AES encryption but, the “Domain Users” group is granted “Read Only” access to this file.
There has been an assigned Common Vulnerability and Exposure number CVE-2014-1812 and there are known targeted attacks to exploit this vulnerability.
There are prerequisites for this fix. Customers running Windows 8.1 or Windows Server 2012 R2 systems must first install the 2919355 update released in April, 2014 before installing the 2928120 update. Please review the following for complete details.
https://technet.microsoft.com/library/security/ms14-025
Summary
It is apparent from the information provided within this post, there are additional steps that can be taken to secure an environment (doesn’t have to be an enterprise environment necessarily) from exposing clear and hashed credentials. As the security landscape continues to evolve, Microsoft has brought to the table these new credential protection methods. They are but a small part of an ongoing battle with malicious attackers.
Thanks for taking the time to read this post!
Microsoft
