Just a quick post on the LocalAccountTokenFilterPolicy setting. What it is why we have it. As a pentester and administering windows systems I’m bumping into this all the time. The classic scenario being your trying to access the C$ of machine with a local account, and being blocked. You check all the usuals; firewall, creds etc and are banging your head against a brick wall. Its more than likely to be the Remote User Account Control (UAC) LocalAccountTokenFilterPolicy setting in Windows that is stopping you. Depending on what type of account you are connecting with ie Domain or Local depends on whether the UAC access token filtering will take affect, it will not affect domain accounts in the local Administrators group, only Local accounts. Even if the Local account is in the Administrators group, UAC filtering means that the action being taken will run as a standard user until elevated. Think of when you launch CMD or PowerShell logged in as an Admin account, its run in the context of standard user until you elevate, or re launch as an Admin. So when we try to connect to the C$ with a Local account that is in the Administrator group we are blocked by UAC. Disabling LocalAccountTokenFilterPolicy will allow us to connect.
When the Remote User Account Control (UAC) LocalAccountTokenFilterPolicy value is set to 0, Remote UAC access token filtering is enabled. When it is set to 1, remote UAC is disabled. We can set this with the following one liner:
cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
The same scenario can be said for running a credentialed or authenticated Nessus scan with a local account that is part of the Administrators group. For Nessus to enumerate the system it will connect to the C$. It will fail unless the LocalAccountTokenFilterPolicy is set to 1. There are other pre-requisites, these are out of scope of this post however.
Well hope this helps!