In brief: Defenders can now easily identify logons involving high-privilege identities or special logon flags to better hunt threats and fine-tune detections.
When a user logs on, Windows’ Local Security Authority (LSA) constructs an access token that represents the user’s security context for that session. This token includes the user’s SID, group memberships, user rights, and logon flags, the information that determines what the session is allowed to access. The challenge was that, although Microsoft Defender has been collecting a token creation event at logon to supplement standard logon telemetry, the most important privilege context inside that token was not directly exposed for hunting. It was possible to see that a logon occurred, but much harder to quickly answer questions like: Did this session include Domain Admin membership? Was the logon tied to a local account?
We’re excited to share that Microsoft Defender is closing this visibility gap by surfacing key privilege context from token creation events that occur during login. It surfaces these new token context fields in Advanced Hunting, making it possible to query the privileged groups and logon attributes that were present in the user’s token at logon time. With this context available directly in hunting data, it is now much easier to isolate privileged sessions, investigate suspicious logons, and build higher-fidelity detections around privilege misuse.
New fields include:
- TokenHasDomainAdminSid - The token contained the Domain Admins group SID.
- TokenHasSchemaAdminSid - The token contained the Schema Admins group SID.
- TokenHasEnterpriseAdminSid - The token contained the Enterprise Admins group SID.
- TokenHasGroupPolicyCreatorSid - The token contained the Group Policy Creator Owners group SID.
- TokenHasDomainControllerSid - The token contained the Domain Controllers group SID (indicates a DC’s computer account logon).
- TokenHasCertificatePublisherSid - The token contained the Certificate Publishers group SID (relevant in AD Certificate Services scenarios).
- TokenHasLocalAccountSid - The token contained a local account SID (not a domain account).
- TokenHasNtlmAuthSid - The token contained the NTLM authentication SID (rather than Kerberos).
- TokenHasThisOrgCertificateSid - The token contained a SID associated with certificate-based authentication issued by the organization (e.g., PKINIT logon).
- NumberOfSidsInDomainAdminToken - If the token contained the Domain Admins group SID, this represents the total number of SIDs in that token (a measure of how many group memberships/privileges/logon flags were in an admin’s token).
These fields are available under AdditionalFields in the DeviceLogonEvents table.
How it works
Defender is deriving these fields from the token’s SID list at the moment of logon. Essentially, when the access token is created, Defender inspects it for any well-known high-privilege SIDs or special logon flags (see [MS-DTYP]: Well-Known SID Structures | Microsoft Learn for reference). By capturing privileges at token creation, the data offers an accurate snapshot of the user’s rights at logon. This is valuable because it can catch ephemeral privilege elevations. For example, whether an account is temporarily added to an admin group and quickly removed, or an attacker manipulates the PAC directly using a Silver or Golden Ticket, any logon during that window will still contain the admin SID in the token, even if the directory no longer reflects that membership later.
Note: This token context telemetry is additive to existing Windows logon events. Standard Security Log events like 4624 (logon success) provide information on network context (source IP, etc.) but don’t tell you about group memberships or special authentication methods. The new token fields fill that gap by focusing on privilege context. To correlate a token event with a traditional logon event and obtain a more complete view of the logon, you can match common attributes such as timestamp, account SID, device, logon type and logon ID (see the example query under “1. Spot suspicious privileged logons” below). Together, the two sources let you understand both how the logon happened and what privileges it carried.
Why this is powerful for defenders
The new token context fields unlock powerful ways to detect misuse of privileged accounts and unusual authentication patterns. For example:
1. Spot suspicious privileged logons
Identify cases where privileged tokens appear in unexpected contexts (e.g., admin accounts logging into low-tier devices, unusual logon types, or rare hosts).
// Token creation events
let TokenCreateEvents =
DeviceLogonEvents
| where InitiatingProcessFileName == "lsass.exe" // Token creation events
| where AdditionalFields has "TokenHasDomainAdminSid"
| project DeviceId, AccountSid, AccountDomain, AccountName, LogonType, LogonId,
AdditionalFields, TokenTime = Timestamp;
// Standard logon events
DeviceLogonEvents
| where ActionType == "LogonSuccess"
| where InitiatingProcessFileName != "lsass.exe" // filter out Token creation events
| project DeviceId, AccountSid, AccountDomain, AccountName, LogonType, LogonId,
RemoteDeviceName, RemoteIP, Timestamp
// Correlate both events (same logon, small time window)
| join kind=inner TokenCreateEvents on DeviceId, AccountSid, AccountDomain, AccountName, LogonType, LogonId
| where Timestamp between (TokenTime - 1s .. TokenTime + 1s)
// Example filter (specific source device)
| where RemoteDeviceName == "kali"2. Detect privilege escalation attempts
As previously detailed, whether an adversary utilizes ephemeral group modifications or direct PAC manipulation, the outcome is the same. These temporary group memberships used during an attack will still be reflected in the token captured at logon, making this activity easier to identify retrospectively. For instance, a standard user who suddenly logs on with TokenHasDomainAdminSid is a red flag for potential token manipulation or group membership abuse.
let lookback = 14d;
let recent = 1d;
let token_priv = "TokenHasDomainAdminSid";
// Baseline: users who historically were DAs
let baseline_users =
DeviceLogonEvents
| where Timestamp between (ago(lookback) .. ago(recent))
| where InitiatingProcessFileName == "lsass.exe" // Token creation events
| summarize DA_sids = make_set_if(AccountSid, AdditionalFields has token_priv),
non_DA_sids = make_set_if(AccountSid, AdditionalFields !has token_priv);
// Recent: new users with DA token
DeviceLogonEvents
| where Timestamp > ago(recent)
| where AdditionalFields has token_priv
| where AccountSid in (baseline_users | project non_DA_sids) and
AccountSid !in (baseline_users | project DA_sids)3. Monitor certificate-based logons
If your environment does not normally use smart cards or certificate-based authentication, or if a user who does not typically authenticate using smart cards suddenly generates events with TokenHasThisOrgCertificateSid, this may warrant investigation, as it could indicate authentication using a fraudulently issued certificate.
let lookback = 14d;
let recent = 1d;
// Baseline: users who historically used certificate-based auth
let baseline_users =
DeviceLogonEvents
| where Timestamp between (ago(lookback) .. ago(recent))
| where AdditionalFields has "TokenHasThisOrgCertificateSid"
| summarize by AccountSid;
// Recent: new certificate-based logons
DeviceLogonEvents
| where Timestamp > ago(recent)
| where AdditionalFields has "TokenHasThisOrgCertificateSid"
| where AccountSid !in (baseline_users)4. Identify local account lateral movement
Pivot on TokenHasLocalAccountSid to identify logons where a local account was used, especially in remote or network logon scenarios. Such activity is uncommon in well-managed environments and may indicate lateral movement using shared credentials or local administrator reuse.
DeviceLogonEvents
| where Timestamp > ago(7d)
| where AdditionalFields has "TokenHasLocalAccountSid"
| where LogonType == "Network" or LogonType == "RemoteInteractive"
These examples illustrate how token privilege context can improve both threat hunting and detection engineering. Analysts can quickly isolate high-interest logons from large volumes of authentication telemetry, while custom detection rules can leverage these fields to focus on sessions with elevated privileges and improve fidelity.
Microsoft