Logon session and access token: How are a process’s identity and permissions formed?

1. Core mechanism

After successful authentication, the authentication package creates a logon session in LSA and supplies information used to create a token. Every process has a primary token; a thread impersonating a client may also use an impersonation token. This lesson examines how access control selects an existing security context, not how directory membership changes.

Interfaces and specifications

• GetTokenInformation(TokenStatistics): returns the AuthenticationId, TokenId, and TokenType fields from the TOKEN_STATISTICS structure.
• OpenProcessToken: requests access to a process's primary token.
• OpenThreadToken: requests access to an impersonating thread's token.
• 4624 TargetLogonId and 4672 SubjectLogonId can be used for session correlation on the same computer.
• 4672 PrivilegeList reports that sensitive privileges were assigned to the new logon session; it does not prove that they were used.

The token object is separate from the logon session

A logon session is the local session context that LSA identifies with a logon ID/LUID. An access token is the object that carries user and group SIDs, the privilege list, the token type, and other security information used in access control.

TOKEN_STATISTICS.AuthenticationId identifies the logon session represented by the token; TokenId identifies a specific token object. Therefore, two tokens that share the same AuthenticationId may have different TokenId values. Treating the logon ID as the identity of the token object breaks correlation.

Effective identity may vary based on thread context

Each process has a primary token and normally uses that security context for access control. If a server thread impersonates a client, the thread also carries an impersonation token, allowing that thread's access checks to use the client context.

The process owner does not change. What changes is the effective token that a particular thread presents during an access check. This distinction prevents analysts from attributing every access made by every thread in a service process to the service account.

In the scene, ArchiveSvc keeps its svc.archive primary token. Thread A handles a client request as tunahan; Thread B continues its background work in the process context. The fixture grants WRITE to the service SID and READ to the client SID. A WRITE request from Thread A is denied while it impersonates the client; Thread B can receive permission for the same request. Neither the process account nor directory membership changes.

Successful Revert ends the thread’s client impersonation, returning subsequent local work to the process context. A failed Revert leaves the client context in place. The teaching example stops at that boundary instead of treating failure as a successful return or producing a resource decision.

Token formation and access control

After successful authentication, the authentication package creates a logon session; LSA assigns the session a Logon ID and creates a token. A new process can start with a copy of the primary token. If a service thread impersonates a client, a second token is attached to that thread.

Before an object access, the system determines the effective token. It then evaluates the token's SIDs and privilege state against the requested access and the object's security descriptor. A privilege being present in a token is not the same as that privilege being used in a particular operation.

Correlate telemetry on the same host

4624 records a successful logon on the accessed computer. 4672 may be generated on the same host when sensitive privileges are assigned to the new session. Correlating 4624 TargetLogonId with 4672 SubjectLogonId establishes the session context.

This correlation is meaningful only within the same computer; a LUID is not globally unique across the network. According to the 4624 version, TargetLinkedLogonId and ElevatedToken fields may be absent. The presence of 4672 cannot prove that a privilege was used or that intent was malicious.

State and data flow

1. After successful authentication, the authentication package creates a logon session.
2. LSA assigns the session a local Logon ID/LUID and creates an access token.
3. The process starts with its primary-token context.
4. If a service thread impersonates a client, an impersonation token is attached to the thread.
5. For an access request, the primary or impersonation token becomes effective according to the current binding.
6. The system evaluates token SIDs, privilege state, requested rights, and the object's security descriptor.
7. Tokens connected to the same session may share AuthenticationId, but they carry distinct TokenId values.

2. Exploitation

Broken trust assumption

The broken assumption is: if I know a process's account, I also know the identity behind every access made by every thread inside it.

Technical prerequisites

• Ability to execute code in a service process or thread, or to influence its token use.
• Access to a client impersonation token available to the thread.
• An impersonation level sufficient for the target operation.
• Effective SIDs or privileges in the token, together with target-resource access controls, that permit the requested operation.
• For access to a remote resource, the required delegation conditions must also be met; local impersonation alone is insufficient.

Exploitation mechanism

A service thread can impersonate a client while the process retains its primary service-account token. The thread's effective security context changes without changing the process owner. This mechanism neither changes directory group membership nor creates a new privilege; it operates only within the authority already present in the token.

Token use does not change membership

Using an impersonation token does not add members to a user or group object. Its effect is bounded by the SIDs, privileges, and impersonation level already present in the token.

When access crosses to a remote system, that system applies its own authorization rules and delegation conditions. An impersonation context that works for a local file therefore cannot be generalized to the network.

3. Defense & Detection

Telemetry scope

• 4624 is generated under Audit Logon success on the accessed computer; its Version may be 0, 1, or 2.
• 4672 is generated under Audit Special Logon success when sensitive privileges are assigned to a new logon session; it is Version 0.
• 4624 TargetLogonId and 4672 SubjectLogonId should be matched only in the context of the same Computer value.
• Object SACLs are not required for these events.

Events and relevant fields

• 4624: TargetUserSid, TargetUserName, TargetDomainName, TargetLogonId, LogonType and AuthenticationPackageName.
• 4624 Version 2: TargetLinkedLogonId and ElevatedToken may not exist in old versions.
• 4672: SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId and PrivilegeList.
• 4672 shows privilege assignment; it does not show that a privilege was used.

Do not confuse assignment with use

4672 PrivilegeList reports that sensitive privileges were assigned to a new session. It does not identify which process used a privilege or in which operation.

The 4624/4672 relationship therefore establishes session context; proving behavior also requires relevant process and resource telemetry.

Detection logic · XPath

*[System[(EventID=4624 or EventID=4672)]]

Query assumptions

• This expression only selects events; it is neither a SIEM field mapping nor an alert.
• A subsequent step must match 4624 TargetLogonId with 4672 SubjectLogonId on the same Computer.
• TargetLinkedLogonId and ElevatedToken may be absent depending on the 4624 version.
• The query was not run on a real Windows host; no data set, time window, or threshold was defined.

False positives

• SYSTEM logons can produce many 4672 events and are not suspicious by themselves.
• Sensitive privilege assignments appropriate to the role of administrative and service accounts may be routine.
• Negative boundary: the absence of 4672 does not prove that a token is harmless or that no privilege will be used later.
• A token may be used long after the logon event.

Hardening

• Minimize sensitive privilege assignments according to host role.
• Run services under separate, least-privileged identities.
• Baseline same-host 4624/4672 pairs for SYSTEM and approved service accounts; investigate unknown session matches.
• Pilot user-right changes first; verify service function and event volume, and restore the previous assignment if problems occur.
• Check both the impersonation result and the return to the process context; do not treat failed Revert as a successful return. Event 4672 alone does not identify the effective token of a particular thread.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing"/>
    <EventID>4672</EventID>
    <Version>0</Version>
    <Channel>Security</Channel>
    <Computer>WS01.iyelabs.example</Computer>
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-1000-1000-1000-1104</Data>
    <Data Name="SubjectUserName">tunahan</Data>
    <Data Name="SubjectDomainName">IYELABS</Data>
    <Data Name="SubjectLogonId">0x671101</Data>
    <Data Name="PrivilegeList">SeImpersonatePrivilege SeDebugPrivilege</Data>
  </EventData>
</Event>

Two reality checks

Assumption: A process has one identity; knowing its account tells me the identity behind every access it makes.

In fact: A process has a primary token, while an impersonating thread may also use a client token. The effective access context can change by thread and binding without changing the process owner.

Assumption: 4672 proves that the listed privileges were used.

In fact: 4672 reports that sensitive privileges were assigned to a new logon session. Determining which privilege was used by which process requires additional process and resource evidence.

Sources

• Microsoft · LSA Logon Sessions
  Introduction and reference-count paragraphs; logon-session creation and logon ID context.
• Microsoft · Access Tokens
  Access token contents; primary versus impersonation tokens.
• Microsoft · TOKEN_STATISTICS
  Members: TokenId, AuthenticationId and TokenType.
• Microsoft · Impersonation Tokens
  Introduction and API list; primary and impersonation token context for an impersonating thread.
• Microsoft · 4624(S) An account was successfully logged on
  Event Description, Versions and Field Descriptions.
• Microsoft · 4672(S) Special privileges assigned to new logon
  Event XML, Field Descriptions, and privilege-assignment semantics.
• Microsoft · RevertToSelf
  Return value and Remarks: successful termination versus continued client context on failure.