Contextualizing Attacker Activity within Sessions in Exchange Online


Overview

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.

Session ID

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:

Context1

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

Set up your organization to use Session ID

Turn on Auditing for your Organization

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.

Block Basic Authentication

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.

Investigating Attacker Activities using Session ID

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.

Scenario: Correlate attacker action when they use third-party VPNs

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.

Scenario: Distinguish attacker actions when they have compromised the corporate VPN

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.

Additional Resources

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

Comments (9)

  1. That’s great stuff. One question though – the only MailboxLogin type of events I can find in the unified audit logs are the ones corresponding to OWA and PowerShell logins – no trace of Outlook logins on my desktop machine. Which might as well be due to the fact that I have a valid refresh token, but it makes it hard to identify “trusted” sessions.

    1. Right now MailboxLogins are not mostly audited for modern auth, which also happens to be required for session ID. This is a known issue that we are working on rectifying. All other mailbox audit actions are audited for both legacy and modern auth and you should use them to identify suspicious/malicious sessions.

  2. For those wondering how to find all the audit entries for a session, here’s how I’d approach the problem: https://office365itpros.com/2019/01/07/using-exchange-session-identifiers-audit-log/

  3. Mike Crowley says:

    Excellent! Any plans to include this as a Search-MailboxAuditLog parameter?

    1. Yes, the search parameter will be coming soon in the first half of this year.

  4. Tony Mex says:

    This was great until I hit the part “you have to Block Basic Authentication”. It is a shame one has to pay more to have this feature since you have to have an Azure license in order to implement the conditional access for this to work. If you have office 365 or Microsoft 365, you should be able at least to create this rule.

    1. You will still get session ID if you allow basic authentication. It’s just that if the actor logs on through basic auth, no session ID will get tracked since this is only present in Azure AD tokens.

  5. Thanks for the update. I’ve heard that next month, Microsoft plans to make additional data elements, including “Message Read,” tracked and available by default in unified audit logs. This would be HUGE! A) Is this correct? B) When? C) Will historical data be available or will the data be prospective only?

    1. There are plans to audit reads but with 2 caveats:
      1) Initially the data will not be sent to the UAL due to volume challenges (it can be accessed via Search-MailboxAuditLog)
      2) The rollout of this feature will begin next month, a message center post will be sent out once rollout is completed; stay tuned for it!
      3) Only data from the point after which rollout is completed will be available.

Skip to main content