Most attackers don’t walk into your tenant and announce themselves. They quietly blend into normal logins and API calls, making life annoying for incident responders. Until now, tracing what happened during a single session across Microsoft 365 was slow, messy, and filled with guesswork.
If you have ever worked an AiTM phishing case, you know the pain. The attacker steals a token, skips MFA, and suddenly starts pulling emails and good luck figuring out which login that activity actually came from.
Microsoft just announced a new addition to their logs, where they will add what is called a linkable token identifier that comes from Entra ID.
Link to their announcement Strengthen identity threat detection and response with linkable token identifiers
This is huge for incident responders, as this makes it way easier for us to trace a full session across multiple services like Exchange Online, Graph and other M365 services.
What changed?
Microsoft Entra now includes two new identifiers that make it easier to track activity tied to a specific login or token.
- Session ID (
AADSessionId): This ID is tied to the sign-in session itself. When a user successfully logs in, Entra ID will generate a Session ID. Any tokens issued during that session will include this ID and logs in M365 will have it. - Unique Token Identifier (UTI): The UTI identifies the specific token used. If multiple tokens are issued in the same session (for different scopes or services), each one will have a unique UTI.
The update have been added to the following services according to Microsoft:
- Entra sign-in logs
- Exchange Online audit logs
- Graph activity logs
- Teams audit logs
- SharePoint Online audit logs
And I just tested that the Session ID and the UTI appears in the exported Unified Audit log, however the Session ID field is named AADSessionId and the UTI is called UniqueTokenId.
Why is it great?
I will show you how to do it with the Session ID, but you can do the exact same thing with the UTI.
If you found a log entry that you know is malicious you can now take the Session ID and use it to correlate across all events. For example you find a suspicious succesful logon from a malicious IP like we have here:
The image above shows the sign in logs from Entra ID.
And then take the suspicious Session ID, go to the unified audit log at https://security.microsoft.com/auditlogsearch and put it in the Keyword Search field and then search.
Of course this will take a long time to query if you do it in a big tenant, so I also advice filtering on the specific UPN.
And after the query has ran, you will be able to see everything that happened in M365 in that session.
You will be able to do the exact same thing with the Unique Token Identifier if you want to hunt for what happened with a specific token that was issued. Which I did here, and I can see that with this token a total of 59 operations happened by the adversary.
Update to UTB
I will in the upcoming weeks see if I can find the time to update https://ual-timeline-builder.sagalabs.dk/ to reflect these changes, as it would add a lot of value to the tool.
Closing
More importantly, this fixes a visibility gap that’s been annoying for years. It’s always been a hassle to figure out what actually happened after a login. You’d end up digging through logs from five different services, guessing what belongs together, and hoping the IP didn’t change. Now you just grab the session or token ID and follow the trail properly.
If you’re working detection, you can already start writing logic around it. And if you’re doing IR like me, this is hands down one of the best forensic improvements Microsoft has made in a long time. It won’t stop the attacker, but it might save you a couple hours of log misery.