An Overview of KB2871997
Microsoft recently released KB2871997 for Windows 7, Windows 8, Windows Server 2008R2, and Windows Server 2012. This blog will give an overview of the feature changes, their impact, and some important configuration changes that can be made in conjunction with the update to further improve system security.
Note: Since the release of KB2871997, additional KB’s have been released which contribute to fixing credential protection (including bug fixes). Please ensure all the KB’s listed here are installed: https://support.microsoft.com/en-us/kb/2871997.
1. Support for the Protected Users group
“Protected Users” is a security group added to Windows Server 2012R2 domains. When a user account is added to the “Protected Users” group, several additional security restrictions are placed on the account:
- A member of the Protected Users group can only sign on using the Kerberos protocol. The account cannot authenticate using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.
- The Kerberos protocol will not use the weaker DES or RC4 encryption types in the pre-authentication process. This means that the domain must be configured to support at least the AES cypher suite.
- The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.
In a nutshell, this setting blocks everything besides Kerberos authentication and applies hardening to the Kerberos authentication used (enforces AES encryption). We recommend you place high value accounts, such as accounts used by server administrators, in the “Protected Users” group to harden the accounts.
Since a “Protected User” is restricted to Kerberos authentication they work well with “Authentication Policies and Silos”, a new feature introduced for Windows 2012R2 functional level domains. Authentication Policies and Silos allow you to place users and computers within a silo and apply policy (such as logon restrictions) to them. More information on “Authentication Policies and Silos” can be found here: http://technet.microsoft.com/en-us/library/dn486813.aspx.
2. Remote Desktop Client support for the Restricted Admin RDP mode
Part of Microsoft’s official guidance for reducing the risk of lateral movement (or pass-the-hash) attacks is to authenticate to servers using a “network logon” (a specific Windows logon type). Why? Because when a user authenticates to a remote server using a “network logon”, the users credential is never sent to the remote server. This means that even if the remote server is compromised, the users credential cannot be captured.
Virtually every management tool Microsoft ships authenticates using “network logon”. This includes but is not limited to: PowerShell Remoting, WinRM, PSExec, WMI, etc… Prior to this update, Remote Desktop required the user send their clear-text password to the remote server (encrypted over-the-wire but decrypted on the remote server) so they could log on for an interactive session. With this update, it is now possible to use Remote Desktop without sending credentials to the remote server.
Note that this update back ports changes to the Remote Desktop client, not Remote Desktop server. This means you can make Restricted Admin connects from an updated system, but you can only make Restricted Admin connects to a Windows 8.1/2012R2 system.
Only administrators can use the “Restricted Admin” mode; members of the “Remote Desktop Users” group are not allowed to use the Restricted Admin mode. Because the users credential is not sent to the remote system, it is impossible for the user to make authenticated connections from the remote system to other systems. Since the user connecting to the system is an administrator (and can by-design impersonate other users on the system), we have made Restricted Admin connections automatically impersonate the computer account for remote connections. This allows a Restricted Admin to access network resources such as shares as long as the computer account has access.
Microsoft recommends that Restricted Admin is used whenever possible, as this follows the “least privilege” principal. If you are authenticating to a server (even a highly trusted server) and do not need to “double hop” with your privileged account, it is recommended you use Restricted Admin. One common scenario that will greatly benefit from Restricted Admin is the “helpdesk scenario” where a helpdesk agent uses remote desktop with a privileged account to repair user workstations.
Restricted Admin can be used by starting Remote Desktop as follows:
Mstsc.exe /restrictedadmin
3. LSA Credential Cleanup & Other Changes
a. Removal of credentials after logoff
As outlined in Microsoft’s Pass-the-hash whitepaper, Windows caches the credentials of a user in the LSASS process whenever the user logs in. This includes the user’s clear-text password, the users NT/LM password hash, and the users Kerberos TGT/Session key. When the user logs off, the credentials should be cleared out of memory. Prior to this update, this was not always the case. This issue preventing credentials from being cleared is now fixed, credentials will always be cleared from memory after a user logs off.
b. New well known SID’s
This update adds support for two new well known SID’s:
- LOCAL_ACCOUNT – Any local account will inherit this SID
- LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP – Any local account that is a member of the administrators group will inherit this SID
These SID’s were introduced to make it easier to prevent local accounts from being used over the network (something attackers commonly do when performing pass-the-hash attacks). An administrator can configure the Group Policy settings “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services” using the above SID’s to prevent attacks from using local accounts over the network. More information on these settings (and detailed instructions) can be found in Microsoft’s Pass-The-Hash whitepaper.
c. Removal of clear-text credentials from LSASS
As noted previously, one of the credentials stored by LSASS is the user’s clear-text password. This update prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s clear-text password. WDigest still stores the user’s clear-text password because it cannot function without the user’s password (Microsoft does not want to break existing customer setups by shipping an update to disable this). Microsoft recommends users look through their domain controller logs for Digest authentication logons (instructions provided below); if Digest authentication is not being used, customers can apply the FixIt found on the KB article to disable WDigest. Doing this will eliminate all clear-text credentials from LSASS memory.
It’s important to realize that while clear-text credentials will no longer be stored, the NT hash and Kerberos TGT/Session key will still be stored and are considered credentials (without credential equivalents stored in memory, single sign-on would be impossible). Additionally, even though the clear-text credentials are no longer stored in memory, an attacker can use other techniques such as key loggers to recover clear-text passwords. Eliminating clear-text passwords from memory is useful and reduces risk, but it is not guaranteed to stop attackers.
Identifying WDigest use
WDigest use can be identified in two places: your domain controller logs, or your server logs (every server must be checked).
1. Domain Controller Security Event Logs: Event ID 4776
Authentication Package: WDigest
Logon Account: Administrator
Source Workstation: WIN2K12R2CLIENT
Error Code: 0x0
2. Server Security Event Logs: Event ID 4624 (must be checked on all servers)
An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Impersonation Level: Impersonation
New Logon:
Security ID: TESTLAB\administrator
Account Name: Administrator
Account Domain: TESTLAB
Logon ID: 0x2D8B63
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name: -
Source Network Address: ::1
Source Port: 57514
Detailed Authentication Information:
Logon Process: WDIGEST
Authentication Package: WDigest
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
- Joe Bialek, MSRC Engineering