Better know a data source: Process integrity levels

Note: Although the level Medium Plus doesn’t include a description due to a lack of references, you should still look out for these SIDs.

Why focus on process integrity level?

Integrity levels can be applied to securable objects as a way of evaluating the level of access that a source object has to a target object. Monitoring processes spawning from a lower integrity level into a higher integrity level can tip defenders off when a process is about to perform a task that requires higher privileges or when sensitive privileges have been co-opted.

Each integrity level comes with a set of system privileges. By default, the higher integrity level you are, the more system privileges you have on a host and the more access you have to securable objects. This is one of the primary drivers that compels adversaries to find ways to escalate their integrity level. The following example from James Forshaw’s NtObjectManager PowerShell module shows the default privileges given to a process of medium integrity level and then again of high integrity level.

Medium integrity level:

High integrity level:

These token privileges dictate what you can and can’t do on a machine from a system operations perspective, such as loading drivers, changing the host’s time, impersonating a client, creating a primary token, etc.

As we noted earlier, when an admin logs in, a split token is generated. Unless you explicitly set the process token to a high integrity level, the process will default to the lowest group the user/token is associated with, which for most users will be a medium integrity level. Users must specify when they want to use their administrative privileges, and in most circumstances, User Account Control (UAC) kicks in to either allow that elevation or not. If the elevation request is successful, the elevated token is granted to that process and the appropriate privileges are applied.

What users can obtain a high integrity level token?

By default, users who are a part of the Administrators groups can obtain a high integrity level token. However, a high integrity level token can still be applied to a user outside of the Administrators group if a sensitive privilege is explicitly granted to that user.

Adversaries have been known to gain access to SeImpersonatePrivilege. This privilege allows an attacker to impersonate different clients—such as named pipe clients, RPC clients, and COM clients— to act with the security context of a targeted token.

This privilege is given to users within the Administrators group by default. Admins can grant this privilege to a user outside of that group using the User Rights Assignments (URA) within Group Policy Object - Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. To do so, the admins would need to add the user to the “impersonate a client after authentication” assignment and start a new logon session with that user.

If the user starts a normal process, they will not have a token that possesses that sensitive privilege. In the screenshot below, I granted SeImpersonatePrivilege to TargetUser, but when I started a normal PowerShell process, I didn’t have that sensitive privilege. The integrity level of TargetUser is “medium.” The examples below are using whoami /groups.

To apply the sensitive privilege SeImpersonatePrivilege, the user has to run as an elevated prompt. After doing so, the sensitive privilege and corresponding high integrity level are applied.

To my knowledge, there is no easy way to determine what token privileges should be considered sensitive —other than by looking at how the privileges are used for sensitive system operations. Knowing this, adversaries prefer to set their sights on processes with specific sensitive privileges granted to their token, or, alternatively, by simply targeting accounts in the Administrators group.

How do adversaries leverage access token process integrity levels?

T1134.002: Create Process With Token is a MITRE ATT&CK technique that describes when an adversary targets access tokens of higher integrity levels and creates a process with a copy of the targeted token. This allows attackers to operate under the security context of the targeted user and run a program, access resources, or establish persistence where they otherwise wouldn’t have been able to.

Adversaries will also impersonate another user either by obtaining a copy of the target token or by obtaining the handle to the target token and setting it to a thread within their running process, in turn changing the integrity level for that thread  (T1134.001: Token Impersonation/Theft). By default this will only work with a token that has a high integrity level process, because that’s the level required to abuse SeImpersonatePrivilege.

In general, it is unusual to see a newly spawned process go from a lower integrity level to a higher one (outside of normal UAC elevation)—it could mean that an adversary has obtained a token of a higher integrity level process or has logged in as another user who is of higher integrity level and is using that logon session token. It could also mean that an administrator is using Start-Process as a normal everyday activity.

As we explained earlier, it’s impossible for an adversary to directly manipulate integrity level metadata. Therefore, if you’re able to gather integrity level-related telemetry, it can serve as a reliable data source.

What data sources are available to retrieve process integrity level?

There are a couple of data sources that you can use to gain insight into a process’s integrity level.

Win32 API:

Data source: GetTokenInformation
Relevant field(s): IntegrityLevel

One way to view the integrity level of a process/thread is to use the GetTokenInformation Win32 API and pass in the TokenIntegrityLevel value into the TokenInformationClass parameter. This will specify that you want to enumerate the TokenIntegrityLevel attribute within the TOKEN_INFORMATION_CLASS enum. The TokenIntegrityLevel attribute is backed by the TOKEN_MANDATORY_LABEL structure, which has an attribute within it called Label. Label is backed by the SID_AND_ATTRIBUTES structure that identifies the mandatory integrity level of the token. The SID attribute can be translated to one of the values seen in the table above.

Here is an example of what this can look like:

Windows Process Auditing:

Data source: Windows Security Log Event ID 4688
Relevant field(s): Mandatory Label
Example data:

Sysmon:

Data source: Event ID 1: Process creation
Relevant field[s]: IntegrityLevel
Example data:

Microsoft Defender for Endpoint (MDE):

Data source: DeviceProcessEvents
Relevant field[s]: ProcessIntegrityLevel, InitiatingProcessIntegrityLevel
Example data:

How do I generate integrity level metadata for sensor and detection validation?

Within the AtomicTestHarnesses PowerShell module, there is a function called Invoke-ATHCreateProcessWithToken that generates telemetry to test optics, detection gaps, and technique knowledge. This module will simulate the behavior of targeting a token then creating a process with a duplicated copy of that targeted token. It will terminate all processes created and close any handles that were opened as a result of this activity. It will then print out an accessible view of data that relates to the activity so that it can easily be tested against the optics available to the users/analysts.

Detection opportunities

The following Microsoft Defender for Endpoint (MDE) queries identify when lower integrity level processes spawn a higher integrity level process or a potentially impersonated login. These will only work for instances where a new process is spawned. Currently, we aren’t aware of any scalable optics or analytics that would give insight into times when token impersonation happens on a thread level. See Access Token Manipulation: Token Impersonation/Theft for more.

Detecting parent-child process integrity level disparities

This MDE query looks for high integrity level processes spawning a system integrity level process and/or low integrity level process spawning high or system integrity level process.

Detecting login impersonation

As in the previous MDE query, this detection logic looks for integrity level disparities between parent and child processes. However, here we’re also looking for a corresponding command line with the seclogon (secondary logon) string. The seclogon string is a good indication of logging on as another user and abusing their security context. This logic will show when a process was spawned with CreateProcessWithLogon.

Another way to detect login impersonation

You can also use identity events to look for logins where the InitiatingProcessCommandLine tag has seclogon (secondary logon). This telemetry also suggests the use of CreateProcessWithLogon.