Token Manipulation Attacks (Part 1: Introduction to Tokens and Privileges)

token-manipulation-attacks

Token Manipulation Attacks

INTRODUCTION

In these series of blogpost, we are going to look at the Windows Token-based Attacks along with the full understanding of what are tokens and privileges and how it is implemented in Windows OS Security architecture.

Token Manipulation Attack is a common technique used by several APT’s, malware to gain higher privileges on the victim’s system or to perform some actions on the behalf of any other user(impersonation).

Here are some examples of APT’s and tools which uses this technique taken from MITRE:

Token Manipulation is not exactly an exploit vector, where we exploit some faulty code and craft a payload around that piece of code. In this technique, we are abusing a feature of Windows OS itself, where the OS uses some set of Windows API functions to change the security context of the calling process (in most of the cases) to impersonate a security context of another process (mostly a low privileged process). The impersonation part can be done with the threads of that process, we will look into that in detail later. Windows use this feature for changing the security context of a thread of a calling process which is running under some user to a security context of a different user to execute some operations.

There are many users in windows such as System, Network Service and Local Service along with Administrator account (Group) and normal domain users. All these user accounts run under different security context and have some level of privileges and access. System by default has the highest level of privileges and access on the Local System. In most of the cases, the malicious program steals the token of the process which is running under the security context of System to gain maximum privileges.

TOKEN

Before going ahead and looking into in these techniques, let’s have a basic understanding of Tokens and Privileges.

Token: Token or an access token is a kernel object that describes the security context under which a process or thread executes.

For a simple explanation, let’s take an example of the Access card of an employee. The access card is generated at the time the employee is hired. Every employee has the access to the company premises. Depending on the Designation of the employee or in which department the employee is assigned, the access of the employee is decided. So, a normal entry-level employee will have the office entry access, the department room access or say the pantry access. But this employee won’t be having the access of the Accounts Room, the Finance Room, any other departments room, or the data centre, etc.

Now, the CEO or owner of the company may have all the above access. So, obviously the privileges of the CEO will be far more than a normal entry-level employee.

The same in any OS, the access granted to a high privileged user (root, Administrator) is far more than a standard user whose privileges will be very limited.

This access card in the case of an employee (in our case Access Token) will define the level of tasks they can perform.

The access token contains information such as Security Identifier (SID), Token Type, Users and Groups info, Privileges, Logon Session, etc which are granted to the user at the time of logon.

To perform any action or to use any resource in windows, a process must access a kernel object by opening or creating the objects using windows handles. The kernel grants access to the process based on the access token.

When this access token is created?

  • The access token is created when the user logs on to the computer
  • The authentication process takes place by checking the password is correct or not
  • The user details are checked in the Security Database
  • It is checked whether the user is in the built-in Administrator group if the user belongs to the Administrator group two tokens are generated: Full administrator access token and Standard user access token
  • If the user doesn’t belong to the built-in administrator group, then only a standard user access token is generated

This access token is an important part of the UAC (User Access Control) feature in Windows Operating System.

 When a user, who is a part of the built-in Administrator group logs on, the OS doesn’t provide the user with the full administrator access token. The Windows OS creates split tokens for this user. There are two types of split tokens: Filtered Token and Elevated Token.

When a user is assigned a filtered token it basically means that the user is running with medium integrity, with the privileges of the administrator group and the SID’s stripped down. This means the user cannot perform any administrative tasks directly. To perform administrative tasks, the user must provide the approval (UAC approval prompt) or enter the credentials.

After the user provides the approval or credentials, an elevated token is assigned, and the user can perform the administrative task. An elevated token is token with high integrity, including the SID’s and privileges of the administrator group.

A user providing the approval to perform admin tasks
A user providing credentials to perform admin tasks

The UAC in windows if configured properly, can be very useful.

For the complete understanding of UAC, read this beautiful article on Microsoft Docs .

TOKEN INTERNALS

To further understand the Token object in windows, let’s look at the Token Internals i.e. the Token kernel data structure. We will be using WinDbg for viewing the Kernel Data structures.

First, we view the TOKEN structure.

In the above image, we can see the whole structure of TOKEN data. It consists of several other data structures which defines various attributes and information related to the token which is ultimately related to the logged-on user.

There is TokenId, Privileges array where all the privileges assigned to the user for that token is defined, TokenType defines the type-token it is: Primary or Impersonation, etc.

Let’s look at some of the data structures inside the TOKEN structure.

SEP_TOKEN_PRIVILEGES is a structure which contains all the information about the privileges held by the token.

Present- The present privileges available to the token.

Enabled -The privileges which are enabled (externally or by default).

EnabledByDefault- The privileges which are enabled to the token by default.

TOKEN_TYPE is an enumeration which defines whether the token type is Primary or Impersonation (more on this later in the series).

SECURITY_IMPERSONATION_LEVEL is an enumeration which specifies the different constants that decides at which level the calling process can impersonate the target process.

The definition of the constants from the Microsoft Docs: –

We will be using the TOKEN_TYPE and SECURITY_IMPERSONATION_LEVEL constants for impersonating the token, like whether we want to create a process with a Primary token or want to impersonate a process using the Impersonation token.

SID_AND_ATTRIBUTES structure defines the SID (security identifier) and attributes of the SID.

PRIVILEGES

In general terms, Privilege is a special power or right or benefit provided to a person or a group based on some conditions from a higher authority.

Similarly, in the Windows operating system, a user is assigned some privileges to perform system-related activities by the Administrator. Some privileges are assigned to the user by default by the OS and some privileges can be assigned to the user locally by the Administrator using the Local Security Policy Settings.

WHAT EXACTLY ARE THESE PRIVILEGES?

Privileges decide which user can control access to system resources to perform system-related tasks such as Shutting down the system, Debug the process memory used by another process, Loading a driver into the memory, Backup files and folders, etc.

Here is the list of Privilege Constants available in Windows.

As we saw above in the SEP_TOKEN_PRIVILEGES structure, there is something called Enabled and EnabledByDefault. This means not all the privileges which are assigned to the user are enabled by default. Only some of the privileges are enabled at the time of assignment, the rest of the privileges must be externally enabled if there is a need for using that privilege to perform any system-related tasks.

Below are the privileges enabled for a standard user: –

As we can see here only the SeChangeNotifyPrivilege is enabled and rest of the privileges which are assigned to the user are disabled. To use those privileges, we must enable them first. 

 In the context of this blog series, we will be enabling the SE_DEBUG_NAME privilege which enables the user to debug processes which aren’t accessible or the processes running under the SYSTEM account.

Now let’s look how a token looks like for different users. We will be looking at the token of notepad process running under the security context of both standard user and an Administrator.

We will be using WinDbg to view the token of the attached process in this case Notepad.

Standard User: –

Here, we can see the session ID of the process in which it is logged on, the Impersonation Level, the token type. As we can see the token type of this process is Primary. Also, in the beginning, the message shows the thread is not impersonating and it is using a primary token.

We can see the privileges assigned to this process. It is same as the privileges assigned to a normal user since it is executed under the security context of a standard user.

The Elevation Type here is 3 (Limited) which states that the token is a limited token with administrator privileges stripped down and the administrator groups disabled.

Administrator User: – 

Here, we can see the token is similar to the standard user except the privileges assigned are far more than the standard user, basically, all the privileges are assigned to the administrator user. Also, we can see the Elevation Type here is 2 (Full) which states that it is an elevated token with no privileges and groups stripped down.

Note: Elevation Type is 2 or 3 when only the UAC is enabled, Type 1 is when the UAC is disabled, or the user is the built-in Administrator account or service account.   

CONCLUSION

In this blog post, we discussed Access Tokens, why access tokens are used, when it is generated, the internals of TOKEN structure and many more terms related to Tokens. This all was essential to understanding how tokens come into the picture under the security context of each user and process in the Windows OS and in the next blog post, with this little knowledge we will go further and use the Windows API’s to carry out some operations to perform Token Manipulation Attacks.

Read part 2 here

For more blogs click here

  •  
  •  
  •  
  •  
  •  
  •  
  •