RSMUS.comImpersonating Windows access tokens can still be a fruitful way for an attacker to expand access on a network. Thanks to the Windows delegation feature, if an attacker gains privileged access to a system, they can reuse another user’s access tokens to perform domain privilege escalation, all without credentials.
How it works: when a user logs on to Windows, their credentials are stored in the system as a temporary key. This key, or token, can be helpful for the user as it allows convenient access to other systems and applications without forcing them to reauthenticate. This single sign-on approach facilitates access, but these tokens can be abused if accessed by an attacker. Tools such as Incognito exploit this Windows feature by manipulating these access tokens for interactive logons to other systems – essentially, the attacker impersonates a valid user. While this attack was presented with Incognito at DEFCON 15 in 2007, privileged accounts in a number of environments are still vulnerable due to account delegation settings on systems.
The following configurations address the usage of delegation tokens and can prevent token impersonation:
Policy Security Setting: Enable computer and user accounts to be trusted for delegation (Windows Settings > Security Settings > Local Policies > User Rights Assignment)
This setting, defined in the Domain Controller Group Policy object (GPO) and in the local security policy, determines which users can set the “Trusted for Delegation” setting for accounts. This group of users should be restricted and accounts “Trusted for Delegation” should not include privileged or administrator accounts.
User Account Security Setting: Account is sensitive and cannot be delegated (Account Properties > Account Tab > Account Options)
This setting, defined in the Domain Controller Group Policy object (GPO), limits abuse of tokens from non-interactive logins.
