Windows logon sessions and tokens

[rw-access]

Relates to #647 to map Endpoint fields
Relates to #809 because our approach for multiple tokens should mirror our approach for multiple users

Bringing in @gabriellandau and @wburgess1 to correct all the places that I'm wrong about tokens and sessions in Windows.

I think there are some fields we have within Endpoint that should be added to ECS.

• authentication_id/logon_id/token_id: Are these all the same thing?
• session_id
• integrity_level: protected, system, high, medium, low, untrusted
• elevated: true/false
• elevation_type: default/full/limited
• token_type: primary/impersonation

There are probably more fields. But the other question is what should this field set be and where should it go? We could do something like this:

• process.token.*: capture all information about the primary process token
• thread.token.*: captures all information about the thread's impersonation token.

One downside for that approach is deciding what happens when you have information about an event, like a 4624 logon, but there aren't any processes yet.

Could it also make sense to have token be top level?

• token.primary.*: a process primary token, as well as information about the token created during a user login event would go here to
• token.impersonation.*: thread impersonation token

Another problem is the issue for multiple tokens. If you have a process that accessed another process's primary token, how do you represent both of those? You have potentially the primary token of the source process, the impersonation token of the source process, and the token that was accessed for another process. We'd also have to figure out how to represent multiple processes in a single event, like #809.

[gabriellandau]

protected

That's actually a property of the process, not the token. Protection is a 2-tuple:

PS_PROTECTED_SIGNER
PsProtectedSignerNone = 0n0
PsProtectedSignerAuthenticode = 0n1
PsProtectedSignerCodeGen = 0n2
PsProtectedSignerAntimalware = 0n3
PsProtectedSignerLsa = 0n4
PsProtectedSignerWindows = 0n5
PsProtectedSignerWinTcb = 0n6
PsProtectedSignerMax = 0n7

PS_PROTECTED_TYPE
PsProtectedTypeNone = 0n0
PsProtectedTypeProtectedLight = 0n1
PsProtectedTypeProtected = 0n2
PsProtectedTypeMax = 0n3

Some reading if you're curious to know more: https://www.crowdstrike.com/blog/evolution-protected-processes-part-2-exploitjailbreak-mitigations-unkillable-processes-and/

[rw-access]

Ah. Yeah, I was just blindly copying values from the existing Endgame schema. Good context!

[gabriellandau]

authentication_id/logon_id/token_id: Are these all the same thing?

Yes Logon ID from a security event is the same as a authentication_id in process events. Where do you see token_id?

Could it also make sense to have token be top level?

I would like to be able to say that every process has a token. It's an interesting case for security events that involve tokens but not processes. I don't have a quick answer as to the best way forward.

Another problem is the issue for multiple tokens. If you have a process that accessed another process's primary token, how do you represent both of those? You have potentially the primary token of the source process, the impersonation token of the source process, and the token that was accessed for another process.

I think that would be process.token, thread.token, and target.process.token: https://github.com/elastic/endpoint-app-team/blob/bf7e5501a5bcf4640bd7fe79d8f3c5a7a2ba939a/scripts/mapping.json#L120
If you had a target thread too, you might also have target.thread.token?

[webmat]

@rw-access Is this still relevant?

[Samirbous]

for process execution data, token_sid which is supposed to have value of process.Ext.token.sid will be useful for a subcategory of rules and also for tuning and hunting.