Forum Discussion

Laurent750's avatar
Laurent750
Copper Contributor
Jul 29, 2024

SessionID in IdentityLogonEvents?

Hi,

The SessionId information is not available in IdentityLogonEvents. The SessionID data can only be found in the XDR table AADSignInEventsBeta. According to the documentation of that table "All sign-in schema information will eventually move to the IdentityLogonEvents table".

I cannot find the SessionID in Sentinel anywhere else than in CloudAppEvents. Is this expected? How are we supposed to investigate stolen sessions without the sessionId information in Sentinel?

 

1 Reply

  • DerekMorgan2's avatar
    DerekMorgan2
    Brass Contributor

    Hi Laurent750​ ,

     

    A few things worth knowing on this one, all post-2024.

     

    On IdentityLogonEvents. The "all sign-in schema information will eventually move" line has been removed from Microsoft Learn. IdentityLogonEvents is a Microsoft Defender for Identity table sourced from sensors on DCs, AD CS, and AD FS. Its 26 columns cover on-prem AD authentication and don't include any session identifier, which matches the table's actual scope.

     

    For XDR advanced hunting. Microsoft started rolling out EntraIdSignInEvents (preview) on December 9, 2025 as the successor to AADSignInEventsBeta. Both coexist today. The new table carries SessionId. The cookie-theft alert grading page on Microsoft Learn still shows sample KQL against the Beta name. Works fine; just swap the table when you copy it.

     

    For Sentinel. The table you want is SigninLogs or AADNonInteractiveUserSignInLogs. Both carry SessionId, and AADNonInteractiveUserSignInLogs adds ClientSessionId. They reach Sentinel through the Microsoft Entra ID data connector via Diagnostic Settings, not through the Microsoft Defender XDR connector. The XDR connector's table list explicitly excludes both AADSignInEventsBeta and EntraIdSignInEvents, which is why you can't see SessionId in Sentinel today even though you can in advanced hunting.

     

    For non-interactive token replay, AADNonInteractiveUserSignInLogs is the better table. Most stolen-cookie reuse shows up as non-interactive refreshes against the original session ID.

     

    If you want a packaged starting point, Sami Lamppu and Thomas Naunheim's Adversary-in-the-Middle chapter ships a KQL function set for correlating SessionIds, CorrelationIds, UniqueTokenIdentifiers, and RequestIds across the XDR and Entra tables. They updated it about six months ago to use EntraIdSignInEvents:

    https://github.com/Cloud-Architekt/AzureAD-Attack-Defense/blob/main/Adversary-in-the-Middle.md

     

    One last note: Sentinel data lake went GA in February 2026 and supports landing Defender advanced hunting tables (including the sign-in ones) at a lower cost tier. Worth a look if ingest cost is your constraint.