The
Exchange audit log is an important tool in the defender toolbox to understand the activity of users (or attackers masquerading as users) in an organization. Defenders can manually browse through their audit logs for user activity that indicates malicious activity. These audit logs feed many first-party and third-party protect, detect, and investigate capabilities in Security Information and Event Managers (SIEMs). This data can be consumed via both the
Security and Compliance Center (SCC) and
Microsoft Cloud App Security (MCAS) for their detections.
Today, we are offering session context in the exchange audit logs to empower defenders to better understand account activity and better distinguish malicious attackers from regular employees. Session ID will be audited as a part of
mailbox audit logs and
admin audit logs. Session ID is a guid identifier encoded in the Azure AD token. The session ID is preserved over token refreshes and can group all actions a user has taken in a single logon session (a user has to re-enter credentials in order for the session ID to change). A few of the ways that this contextualization becomes useful:
- In the case of compromise coming through a corporate VLAN where the IP address of the attacker matches that of the user, you can still distinguish attacker activity from that of a user via the session ID.
- In the case that attackers use a third-party VPN with hundreds of IPs and compromise credentials for an account, you can track the actions through the user session even across varying IP addresses.
- You can build a profile of what actions users typically take during a session and compare each new session for signs of anomalous behavior that may be indicative of a compromise.
- You can understand how many individual sessions are occurring at one time on a user’s account.
The case where session ID can no longer help is when the attacker manages to steal the token. Since they are using the exact same token as the user, you would no longer be able to distinguish between attacker and the user actions. Token theft usually requires the attacker to control the user endpoint, however, which has other implications for the severity of the breach.
The session ID is encoded in the claims of the token; since the tokens can only be created by Azure AD, they offer protection against falsifying session information. For every action audited by Exchange, we are including the session ID in the audit logs. You can see an example of the audit log below:
In the case that a user’s credentials get compromised and the attacker logs to execute malicious user activity, exchange auditing will log the actions with session IDs below:
red (12bce…) denotes attacker with
green (bdcea…) denoting the user. As shown in the table below, you can distinguish between two kinds of user activity simply based on the session ID below.
| TimeStamp |
Action |
Session ID |
| 3:42 |
MailboxLogin |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
| 4:35 |
MailboxLogin |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 4:45 |
MoveToDeleted |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
| 4:59 |
AddInboxRules |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 5:12 |
AddFolderPermissions |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 5:30 |
Set-Mailbox |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
Turning on auditing is an important all-up security measure for your organization. Audit data is important to understand not only what actions were taken in the organization but in what context did the actions take place (IP address, user, session ID, etc.) To get the full range of audit data in Exchange, you need to make sure mailbox auditing is turned on. Starting from the 2019 calendar year, auditing will be enabled by default but you should check if your organization has auditing enabled from this
blogpost.
You should also turn on Office 365 Unified Auditing to record audit data from workloads besides Exchange as well as enable Microsoft 365 detection capabilities and scalable consumption of audit data across your organization. You can find instructions to turn on Unified Auditing in this
documentation.
One caveat to using the Session ID is that it is an AAD construct which does not exist in the case of legacy authentication; it can only be tracked when the logon occurs through
modern authentication. Since the session ID is not present unless a user is authenticating via modern authentication through Azure AD, you need to disable legacy authentication throughout your organization. The benefits of blocking basic authentication cannot be overstated; they enable a host of protection capabilities. You can find more information about how to block legacy authentication and the benefits in
this blogpost.
When investigating an incident, defenders use pivots through with which they can identify attackers to link together actions and understand the full attack chain. Examples of pivots used are properties such as user account, IP address, target mailbox, activity pattern, resource/asset, etc.
In order to hide their tracks, attackers use VPNs or TOR to hide their IP addresses to avoid law enforcement retaliation. These networks regularly have thousands of servers with different IP addresses that attackers can constantly switch between; defenders cannot depend on simply filtering on a single IP address to get the full story of actions that the attacker took. Filtering on the user agent on the other hand would result in activities bleeding into the search query from the day-to-day benign operations (from the organization itself) on that account which could be incredibly noisy. However, since a single AAD session can persist for as long as 180 days, filtering on the session ID will allow defenders to quickly and accurately filter and understand what the attacker had done during that session.
A common attack vector is the compromise of a corporate VPN. This compromise helps attackers get around a host of protections and detections that corporations set up against access from an external network. Furthermore, investigating these breaches can be challenging because the IP address cannot be used to distinguish between corporate and external traffic since it would be the IP address of the VPN service. In this case, defenders can distinguish between separate logon sessions by filtering on the session ID; this will allow defenders to remove the noise of the day-to-day organization activity and focus on the session during which the attacker operated.
In the example below, there is a chronological list of audit records from a service account in exchange. One of the actions, AddInboxRules, would be an action of interest though not representative by a breach by itself.
| 3:42 |
MailboxLogin |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
| 4:35 |
MailboxLogin |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
| 4:45 |
New-MailboxAuditLogSearch |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
| 4:59 |
AddInboxRules |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 5:12 |
Set-Mailbox |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
| 5:30 |
Set-Mailbox |
bdcea574-5cfd-48b1-ab5b-d826f164da53 |
Let’s imagine that while investigating a breach a defender finds it odd that at some point that service account would create an inbox rule, especially over mail protocols rather than PowerShell. In this case the defender might be inclined to filter the mailbox audit records for all actions in that session and find the following list of actions.
| 1:00 |
AddInboxRules |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 1:34 |
AddFolderPermissions |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 1:42 |
AddFolderPermissions |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 4:59 |
AddInboxRules |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 12:34 |
AddFolderPermissions |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
| 15:23 |
AddFolderPermissions |
12bce6d0-bfeb-4a82-abe6-98ccf3196a11 |
At this point, the defender might be very suspicious that they see so many AddInboxRules and AddFolderPermissions activities over mail protocols in a single session when they don’t have any automation to do this. Digging deeper into this session, the defender would reach out to the user responsible for all these actions through another medium (ie. phone) and find out that the user had no recollection of taking these actions. The defender might also look into the specific inbox rules being created and notice that they are forwarding mails to an external entity with the keyword “invoice”.
During this investigation, the defender moved from seeing something that is a little odd, to quickly understanding everything that occurred during that session, to recognizing that the session belongs to an attacker who has malicious motives. Now that the defender was able to quickly identify the session as malicious, they could close access to the account and move to study which accounts has the attacker compromised, scope the extent of the compromise and remediate by removing the inbox rules/folder permissions.
We hope this post has helped you understand more about how to use your audit data effectively to protect your organization. Leave us a comment below with feedback!
Jeff Sun
In the case that a user’s credentials get compromised and the attacker logs to execute malicious user activity, exchange auditing will log the actions with session IDs below: red (12bce…) denotes attacker with green (bdcea…) denoting the user. As shown in the table below, you can distinguish between two kinds of user activity simply based on the session ID below.
Microsoft
