Protecting Privileged Domain Accounts: Restricted Admin and Protected Users

It's been a while since I've written about this topic, and in that time, there have been some useful security updates provided by Microsoft, as well as some troubling developments with Microsoft's Kerberos implementation. In order to fully cover these topics, I'm going to split the discussion into two articles. This article will cover specific updates Microsoft has provided to help protect user credentials. I'll follow up next week to discuss the Kerberos issues in depth.

As a quick reminder, the major takeaway from my previous articles on this subject are that we can successfully protect our privileged domain accounts by taking these 3 steps:

1. Avoid interactive logons to untrusted hosts
2. Disable delegation for privileged accounts
3. Enforce Kerberos network authentication

Let's take a look at the changes in the newest Microsoft operating systems, as well as recent patches for older operating systems, that have helped with each of these 3 areas.

Avoiding Interactive Logons

Of the 3 steps we should take to protect our privileged domain accounts, avoiding interactive logons is the most important because traditional interactive logons store the keys to a user's kingdom?including password hashes, Kerberos keys and tickets, and even the password itself. I used the word "traditional" because we now have a new type of interactive logon that mitigates this credential exposure, called Restricted Admin Remote Desktop. More on that in a moment.

The previous password hashes article in this series includes a detailed look at what constitutes an interactive logon, but to quickly summarize, it includes the following: local desktop logons at the console, remote desktop logons via RDP/VNC/Citrix and the like, and even RunAs logons. Although less common, an interactive logon can also be generated programmatically with tools such as PsExec when the "-u" option is invoked.

So rather than logging on interactively, exposing all of those credentials, you should instead connect with network logons remotely using tools such as PowerShell Remoting, WMI/WMIC, as well as most SMB/CIFS connections such as mapping drives, using Computer Management, etc.

That said, a feature in Windows 8.1 and Server 2012R2 provides a modified version of an interactive logon which has the same beneficial effect of a network logon?it does not store the user's credentials on the remote system.

Here's a look at the description of this feature from the new Remote Desktop client's help dialog box (run "mstsc /?" from a command prompt):

Normal RDP vs. Restricted Admin RDP

Let's take a look at the differences between a normal Remote Desktop logon and the new Restricted Admin Remote Desktop logon.

First we'll look at a regular RDP logon session for user ?mike' to a Windows 8.1 host. The following screenshot shows event ID 4624 as a result of a normal RDP session. Logon Type 10 indicates a Remote Desktop interactive logon. For a list of logon types, see the Ultimate Windows Security description of Event ID 4624.

Next, let's assess the available credentials for ?mike' with this normal RDP logon. I've used mimikatz to dump the hashes and passwords from memory. At this point it's worth noting that not only does Windows 8.1/2012R2 provide the new Restricted Admin mode for avoiding credential exposure, but it also implements some changes to limit credential exposure even with a normal interactive logon. In this first test, we are examining a normal Remote Desktop session which results in a normal interactive logon. Because it is Windows 8.1, we do not have passwords available in memory any longer. That's good, but we do have the user's NTLM (aka NT) hash available, which can be used in pass-the-hash attacks to impersonate user ?mike' on remote systems. This is still a significant exposure since, for the most part, the user's hash is every bit as useful as the password itself in a Windows domain.

To verify we see the correct NT hash above for ?mike', let's calculate the hash. An NT hash is simply an MD4 hash of the user's Unicode password. So here we echo the password with "-n" to prevent the new-line character being added to the string, then pipe that ASCII string through iconv to convert it to Unicode, and finally pipe it into openssl specifying the MD4 hashing algorithm. The result is the same hash as the NT hash shown by mimikatz (this command was run via Cygwin):

$ echo -n Use4Passphrase,K? | iconv -t UTF-16LE | openssl md4
(stdin)= e456d67ce26e0f174ba2c92f4b677cac

Now let's use mimikatz to list the Kerberos tickets available with this logon session (the built-in Microsoft tool klist can also provide this Kerberos ticket information):

We have several Kerberos tickets available, including the TGT ticket (the first one?krbtgt). This is the ticket needed to request service tickets to remote services. It can be used in a pass-the-ticket attack to impersonate ?mike' for remote authentication.

Ok, so thanks to the default settings in Windows 8.1, the clear-text password for ?mike' is no longer available, but the NT hash and Kerberos tickets are. So even with 8.1/2012R2, an interactive logon creates sensitive account credentials that can be stolen by an attacker and used for lateral movement.

Now let's turn our attention to the new Restricted Admin RDP logon. Here I have the event ID 4624 for the session I started with "mstsc /restrictedAdmin":

This 4624 event looks identical to the previous RDP logon event, except the Logon GUID is all zeroes. Unfortunately that's not a definitive marker for a Restricted Admin logon because a normal RDP logon can create this as well (as does Type 11 Cached Logon and Type 7 Unlock Workstation logon). In fact, I could not find a way to definitively identify a Restricted Admin RDP session in the event logs (and this Technet article on Restricted Admin RDP suggests the same). Let me know if you find a way to distinguish a Restricted Admin session in the event logs and I'll update this section with the details.

Now that we have a Restricted Admin session, let's use mimikatz to identify any associated credentials:

In this case we see ?mike' is the user associated with the remote interactive logon, but the credentials are those of the remote workstation named SEATTLE rather than the user's credentials.

Now take a look at the Kerberos tickets available. Notice they are also associated with the workstation credentials rather than the user's credentials:

As advertised, the "Restricted Admin" remote desktop logon allows the user to have interactive access to the workstation, but without exposing the user's credentials. This is a nice development and will certainly be useful for systems administrators needing the full desktop experience. Well?nearly the full experience. Since the user's credentials are not stored on the remote system, the user cannot access remote services or shares as their account. The only resources they can seamlessly access are those which the computer account is authorized to access (in this case, the SEATTLE computer account). For example, I setup a share and allowed the built-in group "Everyone" read-only access and I could access files on that share just fine, since "Everyone" includes computer accounts. However, other shares that required ?mike' credentials were inaccessible.

Keep in mind that Restricted Admin only works when the remote system is Windows 8.1 or Server 2012R2. The connecting client can be an older OS such as Windows 7 or Server 2008R2 if KB2871997 update has been applied.

One last thought on Restricted Admin. There is a somewhat peculiar side-effect to this new feature. It turns out that Restricted Admin provides attackers the ability to perform pass-the-hash or pass-the-ticket attacks against the remote host. While this may seem counter-intuitive (in other words, why would Microsoft allow this?), it actually makes sense when you think about it. In a nutshell, Restricted Admin Remote Desktop no longer sends your username and password to the remote system to perform the interactive logon. This is to protect your credentials on the remote host, by never having them sent to the remote host in the first place. Instead, your client authenticates to the remote host via a network logon using either Kerberos or NTLM. Therefore, an attacker with your NT hash or Kerberos TGT can authenticate as you to connect to the remote system. Aorato has a very informative article on this trade-off titled "Remote Desktop's Restricted Admin: Is the Cure Worse Than the Disease?"

So, is the cure really worse than the disease? Not in my opinion. I think the positives definitely outweigh the negatives. Giving administrators a way to safely interact at the desktop is still a critical need in many organizations. And after all, attackers can do plenty of damage using pass-the-hash without interactive access?as they've been doing for many years in many organizations. Furthermore, if this feature provides incentive for the attacker to move laterally using remote desktop, then that gets me excited from an investigative standpoint because I'll have many more artifacts to sift through as a result of their interactive activity.

New ?Protected Users' Group

The new Protected Users Active Directory group was introduced last year as a native feature to Windows 2012R2 domains. Most of its protections have recently been added to legacy domains (2008R2/2012) via update KB2871997.

This group automatically provides protection to its members for the other 2 mitigation steps discussed in this blog series-disabling delegation and enforcing Kerberos. It does this and more. Here's a rundown:

• Users in this group will have delegation disabled. The issues around token theft of delegate-level impersonation tokens were discussed in the Safeguarding Access Tokens article. The simple fix is to disable delegation for privileged accounts, which happens automatically for members of this group.
• Users in this group will be forced to use Kerberos authentication, meaning NTLM authentication is disabled, as well as the WDigest and CredSSP security service providers. Refer to the Network Authentication In-Depth article for a close look at the reasons we should enforce Kerberos wherever possible.
• Not only does it enforce Kerberos authentication, it enforces Kerberos with AES encryption (versus DES or RC4). As I'll discuss in a follow-up article next week, enforcing AES encryption is an important step in hardening your Kerberos implementation.
• Kerberos long-term keys are not maintained in memory. The long-term keys are used to generate the ticket-granting ticket (TGT), which in turn is used to request service tickets to logon to network services. Because the long-term keys are not maintained in memory, the user must manually re-authenticate when the TGT expires.
• The Kerberos TGT expires after just 4 hours rather than the normal 10 hour default setting.
• Users in this group will not have their cached domain credentials stored.

Let's take a look the Protected Users group in action. For this testing, we'll run through some tests with a Windows 7 host with update KB2871997 applied. First let's look at standard user ?mike' logged into this machine. This user is not in the Protected Users group.

It's worth noting here that KB2871997 did more than just implement the Protected Users group. It also partially addressed the issue of passwords in memory. However it's only partial (as we can see in the above screenshot), because it did not remove the password from the WDigest SSP. Microsoft decided there would be too many customers negatively impacted to make the removal of WDigest a default part of the change. At the end of the KB2871997 article there are some useful suggestions for monitoring your event logs to determine if WDigest authentication is being used in your environment and therefore decide whether or not it's safe to disable.

Now let's look at a user named ?responder' who is in the Protected Users group. This user has logged on to the same Windows 7 host after ?mike' logged out. As you can see in the middle of the next screenshot, there are no hashes or passwords available for this Protected User?however, we can also see a flaw:

Regarding the flaw, we see credentials lingering in memory from the previous logon for user ?mike'. Credentials lingering in memory has been a known issue for some time and was supposed to have been resolved in KB2871997 (see 3a in the KB article), but apparently it's not completely effective.

In any case, the ?responder' account in the Protected Users group is looking pretty good. The NT hash is no longer maintained. The password is also not stored for the WDigest provider since Protected Users cannot authenticate with WDigest-only with Kerberos. That's all good-but don't get the wrong idea?this is not a substitute for avoiding interactive logons on untrusted hosts! It simply cleans up unnecessary credential exposure since only Kerberos authentication is allowed with these users. As you can see here, Kerberos tickets are still available, including the TGT for ?responder':

Another interesting feature of Protected Users is that the Kerberos TGT is only valid for 4 hours and the Kerberos keys are not stored for automatic TGT renewal (the mimikatz command "sekurlsa::ekeys" lists the stored encryption keys for Kerberos, and there are none for members of Protected Users). So after 4 hours, the user must re-authenticate. For example, I let the logon above persist for several hours and when I came back to list the Kerberos tickets, it had only these remaining?without the TGT (krbtgt) ticket:

In order to log into a remote resource such as a file share, I had to re-authenticate:

The Protected Users testing above was done on a Windows 7 host with KB2871997 applied. A Windows 8.1 host works the same. It still avoids storing the password (which Windows 8.1 does anyway), the NT hash, and the Kerberos keys. For example, here's a screenshot of ?responder' logged on to a Windows 8.1 host and the output of mimikatz skecurlsa::logonpasswords, which would show the NT (NTLM) hash and password if available?and neither are:

Last but not least, members of Protected Users will not have their domain credentials cached for use when a domain controller is unavailable. This useful protection is not well-advertised by Microsoft. One place I happened to notice it mentioned was in the very useful and thorough Microsoft article How to Configure Protected Accounts. It includes just this one line about it, stating Protected Users can no longer "Sign-on offline — the cached logon verifier is not created". I decided I should double-check that this meant what I expected, and it does, even on a Windows 7 host. Here's the output from Quarks PwDump that lists the cached domain credentials from my Windows 7 test host. This was after several interactive logons with the 'responder' Protected User account, yet no cached credentials were available for this account according to the dump:

I also double-checked by attempting to logon when the domain controller was powered down. I was able to logon with 'mike' and 'johnd' using cached account credentials, but a logon attempt with 'responder' gave me the following error:

Wrapping Up

To summarize the changes built into Windows 8.1/2012R2, as well as the corresponding updates added to Windows 7 and higher via KB2871997, the main takeaways are:

• We have a new form of interactive logon called Restricted Admin RDP which authenticates the user with a network logon and avoids storing the user credentials on the remote host. This is the ONLY safe form of an interactive logon to an untrusted host. This is particularly appropriate for systems administrators who need a desktop environment. Unfortunately the target system must be running Windows 8.1 or Server 2012R2, though the client can be Windows 7 or higher with KB2871997 applied.
• The Protected Users group provides a number of beneficial changes to protect its members, including disabling delegation, enforcing Kerberos with only AES encryption, and preventing the storage of cached domain credentials. It is highly recommended to take advantage of the protections provided by this new group. Keep in mind though that interactive logons with Protected User accounts still result in sensitive credential information being created in memory-in particular the user's Kerberos TGT-so Protected Users must still avoid interactive logons to untrusted hosts.

Mike Pilkington is a Sr. Information Security Consultant and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS instructor teaching FOR408 and FOR508. Find Mike on Twitter @mikepilkington.