Disabling UAC Remote Restrictions to Limit Credential Exposure

Did you know UAC settings affect remote login privileges? Over the years I've bumped into this and never took the time to fully understand what was happening. I'm writing this post as a quick reference for myself and also to propose a counterintuitive way to limit credential exposure.  Will Schroeder (@harmj0y) wrote an excellent post in 2017 where he laid out some misconceptions and answered a lot of questions about pass-the-hash and how UAC remote restrictions affects remote logins. Based on Will's post and a few Microsoft articles, I've put together a quick chart showing how UAC affects remote logins when using different accounts.

Note: This chart assumes UAC is enabled via HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Using the Built-in Administrator (RID 500) for Remote Administration

By default the built-in administrator (RID 500) account connects with full administrative privileges, meaning that UAC Remote Restrictions are not applied. However, if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken is enabled (set to 1), the RID 500 account is enrolled in UAC protection. The Group Policy setting for this is "User Account Control: Admin Approval Mode for the built-in Administrator account" and it is disabled by default. Microsoft has a good article that describes UAC Group Policy settings and the corresponding registry keys here.

Using a Domain Account That is a Member of the Administrators Group for Remote Administration

UAC remote restrictions aren't applied to domain users. If the account is in the Administrators group on the target, full administrator rights will be granted and UAC is disabled for that session.

Using a Local Admin (Non RID 500 SAM account) for Remote Administration

By default, a non RID 500 local admin will not connect as a full administrator, has no elevation potential, and cannot perform administrative tasks. In order to administer the workstation the user must interactively login. However, if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy is enabled, all local users connecting remotely are granted full administrative rights.

So why would you possibly set this registry entry?

Will says in his post, "So why would you possibly set this registry entry?" in regard to LocalAccountTokenFilterPolicy, which effectively disables UAC remote restrictions. Well, I think there are a couple scenarios where we can use this setting to actually limit credential exposure. Disabling UAC remote restrictions with LocalAccountTokenFilterPolicy is a bad idea if you have local admin accounts with the same passwords across the enterprise. When an attacker lands a foothold and finds the combination of shared local admin creds and disabled UAC remote restrictions, they'll be able to use the credentials to move laterally and it'll be game over quickly. 

However, by now we should know better than to use the same credentials for local admin accounts. Microsoft LAPs is one solution. If you're setting unique local admin passwords, once exposed they're useless on other systems. Another control that I'm a big fan of, is to isolate user systems from each other via Windows Firewall rules or other means. Ideally, a combination of such controls would be implemented in case one were to fail. If you're implementing controls like these, disabling UAC remote restrictions doesn't have much impact. Local admin accounts will be able to remotely perform administrative tasks. If local admin credentials are compromised, they're only good on the compromised system. An attacker can't use the credentials to login to another system.

Let's flip this concept around in an attempt to use this to our advantage. What are some situations in which using local admin credentials could be beneficial? How about patching, running backups, deploying software, or running vulnerability scans? Many times these tasks are being run via privileged domain accounts. Depending on how each application logs in, these credentials may be left behind on every machine that's accessed. When an attacker lands a foothold, we have the same credential exposure problem we had with local accounts. If we instead ran these tasks with unique local admin credentials and disabled UAC remote restrictions in order to do this, we're limiting our exposure. This may make credential management more difficult, but I find it manageable. Instead of using an all-powerful account and spraying those credentials everywhere, we're use local admin accounts to limit our exposure. This approach may not scale to large environments, but for small/medium networks it has worked for me. Another way to limit exposure would be to use an account that is a member of the Protected Users group. This would force Kerberos and only leave a ticket with a short lifespan on the system; however, this unfortunately seems to break the functionality of some admin tools. 

I see this especially useful not so much for workstations, but for servers. Particularly for scanning and deploying patches and backup job credentials. For workstations, I prefer to isolate user systems. That way deployment credentials are only good from admin subnets and servers used for patch management, vulnerability scans, etc.  You could use this strategy for workstations as well, and some applications like PDQ Deploy integrate with Microsoft LAPs to make credential management easier. 

What are your thoughts on this? As always if I missed anything or you have something to contribute, please comment below.