Adversaries may duplicate then impersonate another user's token to escalate privileges and bypass access controls. An adversary can create a new access token that duplicates an existing token using
DuplicateToken(Ex). The token can then be used with
ImpersonateLoggedOnUser to allow the calling thread to impersonate a logged on user's security context, or with
SetThreadToken to assign the impersonated token to a thread.
An adversary may do this when they have a specific, existing process they want to assign the new token to. For example, this may be useful for when the target user has a non-network logon session on the system.
|M1026||Privileged Account Management||
Limit permissions so that users and user groups cannot create tokens. This setting should be defined for the local system account only. GPO: Computer Configuration > [Policies] > Windows Settings > Security Settings > Local Policies > User Rights Assignment: Create a token object.  Also define who can create a process level token to only the local and network service through GPO: Computer Configuration > [Policies] > Windows Settings > Security Settings > Local Policies > User Rights Assignment: Replace a process level token.
Administrators should log in as a standard user but run their tools with administrator privileges using the built-in access token manipulation command
|M1018||User Account Management||
An adversary must already have administrator level access on the local system to make full use of this technique; be sure to restrict users and accounts to the least privileges they require.
|ID||Data Source||Data Component||Detects|
Monitor executed commands and arguments to detect token manipulation by auditing command-line activity. Specifically, analysts should look for use of the runas command. Detailed command-line logging is not enabled by default in Windows.
|DS0009||Process||OS API Execution|