# Exchange Online Monitoring (TryHackMe) ## Introduction Email is a critical communication channel in any organisation, which makes it a prime target for attackers. Once a mailbox is compromised, attackers can read emails, exfiltrate sensitive data, and even weaponise the account to launch different phishing campaigns. This room will explore how attackers abuse Microsoft Exchange Online post-compromise and how SOC analysts can detect these attacks using Splunk. ## **Learning Objectives** * Understand how Exchange Online generates logs and where to find them * Identify suspicious mailbox rules creation and email forwarding * Detect phishing campaigns launched from compromised mailboxes * Use message trace and audit logs to scope an incident * Investigate a real-world Exchange Online compromise ## **Prerequisites** * [Entra ID Monitoring](https://tryhackme.com/room/entraidmonitoring) ## Exchange Online Overview Exchange Online is Microsoft's cloud-based email and calendaring service, part of the Microsoft 365 suite. You may also know it as **Outlook.** Unlike traditional on-premise Exchange servers, which require organisations to manage their own mail infrastructure, Exchange Online is fully hosted and maintained by Microsoft. ![Exchange admin center showing all the mailboxes.](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772702668484.png align="center") ## **What Happens When Exchange Online is Compromised?** Email is a critical part of every organisation. It contains sensitive business communications, financial data, credentials, and personal information. This makes Exchange Online a prime target for attackers. Once inside a mailbox, an attacker has access to a goldmine of information and a powerful platform to launch further attacks. While every attack is different, security researchers and SOC analysts have observed a common pattern in Exchange Online compromises. A typical attack chain looks like this: ![Typical attack chain during exchange online compromise showing Credential Theft, Initial Access, Discovery, Persistence, and Lateral Movement.](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1774006561741.png align="center") * **Credential Theft:** Before gaining access, the attacker first obtains valid credentials. This typically happens through phishing emails, credential-stuffing attacks using leaked password databases, or the purchase of stolen credentials from dark web marketplaces. * **Initial Access:** Using the stolen credentials, the attacker authenticates to Microsoft 365 and gains access to the victim's Exchange Online mailbox. This authentication is processed through Entra ID and leaves a trace in sign-in logs. * **Discovery:** Once inside, the attacker explores the mailbox. They read emails to understand the organisation, identify sensitive information, find other potential targets, and gather intelligence that can be used for further attacks. * **Persistence:** To maintain long-term access even if the victim changes their password, the attacker sets up mechanisms to keep receiving data. This includes creating forwarding rules to silently copy all incoming emails to an external address, or setting up inbox rules to delete specific emails so the victim stays unaware. * **Lateral Movement:** Finally, the attacker weaponises the compromised account. By sending phishing emails from a trusted internal address, they can bypass email security filters and trick colleagues into clicking malicious links or revealing their own credentials. Not every attacker follows this exact sequence, and some steps may be skipped or reordered. However, understanding this pattern gives SOC analysts a solid foundation for investigating Exchange Online incidents. In the upcoming tasks, we will explore the logs generated by each of these activities, learn how to detect them in Splunk, and ultimately investigate a real-world Exchange Online compromise from start to finish. ### Answer the questions below Which attack stage involves sending phishing emails from a compromised account to other employees? `Lateral Movement` ## Exchange Online Logging SOC analysts investigate Exchange Online compromises using three main log sources: Exchange Online sign-in logs, M365 unified audit logs, and message trace logs. Each reveals a different aspect of the incident. **Note:** Before we explore the Splunk queries for these logs, it is important to note that all of these queries are intended to be applied for "All time" in this room. ## **Exchange Online Sign-In Logs** Every time a user accesses Exchange Online, they first authenticate through Entra ID. This authentication generates a sign-in event regardless of whether the login was successful. These logs are invaluable during an investigation because they tell you who tried to access the account, from which IP and location, whether the attempt succeeded or failed, and some other valuable details. In Splunk, Exchange Online sign-in logs can be queried using: | **Investigate Exchange Online Sign-in Logs** | | --- | | | ```c index=* sourcetype="azure:aad:signin" appDisplayName="One Outlook Web" | table _time userPrincipalName appDisplayName ipAddress location.city status.errorCode | sort - _time ``` ![Exchange Online Signin Logs in Splunk](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1774004305908.png align="center") ## **M365 Unified Audit Logs** Once authenticated, any action the user performs inside Exchange Online is recorded in the Microsoft 365 unified audit logs. These logs capture mailbox activities such as emails sent, inbox rules created, forwarding settings changed, and mailbox access events. In Splunk, Exchange Online audit logs can be queried using: | **Investigate Exchange Online audit logs** | | --- | | | ```c index=* sourcetype="o365:management:activity" Workload=Exchange | table _time UserId Operation Workload ``` ![Splunk showing Exchange audit log with Operation and Workload fields visible](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772725427360.png align="center") The `Workload` field identifies which Microsoft 365 service generated the event. For Exchange Online activities, this will always be `Exchange`. The `Operation` field tells you exactly what action was performed. The most important operations to know for this room are: | **Operation** | **Description** | **Why does it matter?** | | --- | --- | --- | | `MailItemsAccessed` | Someone accessed and read emails in the mailbox | Helps identify if an attacker has read sensitive emails after gaining access | | `Send` | An email was sent from the mailbox | Detects phishing emails sent from a compromised internal account | | `New-InboxRule` | A new inbox rule was created | Attackers create rules to delete replies or forward emails to hide their activity | | `Set-InboxRule` | An existing inbox rule was modified | Attackers may modify existing rules to avoid detection instead of creating new ones | | `Set-Mailbox` | Mailbox settings were changed, including forwarding | Used by attackers to configure silent email forwarding to an external address | | `Add-MailboxPermission` | Delegate access was granted to another user | A common persistence method by which attackers grant themselves access to return to the mailbox even after a password reset | ## **Message Trace Logs** While the unified audit logs indicate that an email was sent, they don't indicate who received it. This is where message trace comes in. Message trace is a separate log source that tracks the full delivery journey of every email, including the sender, recipient, subject, delivery status, and timestamp. This makes message trace particularly useful in two scenarios. First, when scoping a phishing campaign, if you identify a suspicious email that was sent from a compromised account, message trace tells you exactly how many people received it and whether it was delivered successfully. Second, for timeline construction, message trace provides precise delivery timestamps that help piece together the sequence of events during an incident. In Splunk, message trace logs can be queried using: | **Investigate Message Trace logs** | | --- | | | ```c index=* sourcetype="o365:reporting:messagetrace" | table Received SenderAddress RecipientAddress Subject Status FromIP ``` ![Splunk showing the Message Trace log with SenderAddress, RecipientAddress, and Subject fields](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772725427418.png align="center") ### Answer the questions below Which `appDisplayName` value confirms that a user accessed their Exchange Online mailbox? ```shell index=* sourcetype="azure:aad:signin" appDisplayName="One Outlook Web" | table _time userPrincipalName appDisplayName ipAddress location.city status.errorCode | sort - _time ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/132b1138-2fbd-4fda-a6cf-9d1ba0dc39f2.png align="center") Which Exchange Online feature can attackers abuse to automatically delete replies to phishing emails? `New-InboxRule` ## Detecting Mailbox Rule Abuse The attacker is in. They have successfully authenticated to the victim's Exchange Online mailbox and spent time reading emails. Now their priority shifts: they need to stay hidden and keep receiving data, even if the victim becomes suspicious. To achieve this, attackers typically abuse three powerful Exchange Online features: **inbox rules**, **email forwarding**, and **delegate access**. ## **Inbox Rules** Inbox rules are a legitimate Exchange Online feature that allows users to automatically manage incoming emails. A user might create a rule to move newsletters to a specific folder, flag emails from their manager, or forward emails from a particular sender. These are normal day-to-day actions. When a user creates inbox rules, their activity will appear in Splunk under two operations: * `New-InboxRule` is logged when a new inbox rule is created * `Set-InboxRule` is logged when an existing inbox rule is modified **New-InboxRule** When a new inbox rule is created, it will appear as a `New-InboxRule` operation. Attackers typically create inbox rules for one of two purposes: **Delete rules:** The attacker creates a rule that automatically deletes incoming emails matching certain criteria. The most common use case is deleting replies to phishing emails sent from the compromised account. When colleagues receive a suspicious email and reply to ask if it is legitimate, those replies are silently deleted before the victim ever sees them. This keeps the victim unaware that their account is being abused. **Forwarding rules:** The attacker creates a rule that automatically forwards incoming emails matching specific conditions to an external address they control. For example, forwarding only emails containing words like "invoice", "payment", or "credentials" to avoid raising suspicion through high email volumes. In Splunk, use this query to find inbox rule creation events: | **Investigate inbox rule creation** | | --- | | | ```plaintext index=* Workload=Exchange Operation=New-InboxRule | table _time UserId Name DeleteMessage ForwardTo SubjectContainsWords ``` ![Splunk showing the New-InboxRule log with DeleteMessage=True visible](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772729065021.png align="center") The parameter fields in a `New-InboxRule` log contain the full details of what the rule does. The most important parameters to look for are: | **Parameter** | **Description** | | --- | --- | | `Name` | The name given to the rule | | `SubjectContainsWords` | Condition: triggers if the subject contains specific words | | `DeleteMessage` | Action: if True, matching emails are deleted | | `ForwardTo` | Action: forwards matching emails to a specified address | The key red flag is `DeleteMessage = True`; this is rarely a legitimate use case and should always be investigated. **Set-InboxRule** When a user modifies an existing inbox rule, it will appear as a `Set-InboxRule` operation. An important distinction here is that `Set-InboxRule` only logs the fields that were changed, not the full rule configuration. This means the absence of a field does not mean that the action no longer exists on the rule. Red flags to watch for across both operations: * `DeleteMessage = True`, indicating the attacker is hiding replies * `ForwardTo` pointing to an external domain * Rules created or modified outside business hours * Rule names that look generic or system-like to avoid suspicion ## **Mailbox-Level Email Forwarding** Unlike the forwarding rules we saw above, which only forward emails matching specific conditions, mailbox-level email forwarding applies to every single incoming email unconditionally. The attacker configures this directly in the mailbox settings, meaning that every email the victim receives, regardless of sender, subject, or content, is silently copied to the attacker's external address. In Splunk, mailbox-level email forwarding appears as a `Set-Mailbox` operation. | **Investigate mailbox-level email forwarding** | | --- | | | ```c index=* Workload=Exchange Operation=Set-Mailbox | table _time UserId ForwardingSmtpAddress DeliverToMailboxAndForward ``` ![Splunk showing the Set-Mailbox log with ForwardingSmtpAddress visible](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772729065075.png align="center") Red flags to watch for: * `ForwardingSmtpAddress` pointing to an external domain like Gmail or ProtonMail * `DeliverToMailboxAndForward = False` * Forwarding configured shortly after a suspicious sign-in `DeliverToMailboxAndForward = False` is particularly suspicious; it means the victim will not even see the emails in their own inbox. Everything goes silently to the attacker. ## **Delegate Access** Delegate Access abuse is not very common, but it is a highly effective persistence technique. Attackers add themselves or another account they control as a delegate to the victim's mailbox, thereby gaining persistent access even after the victim changes their password. Unlike forwarding rules, delegate access gives the attacker full interactive access to the mailbox; they can read, send, and manage emails as if they were the victim. Delegate access changes appear in Splunk as an `Add-MailboxPermission` operation. The `Trustee` field shows which account was granted access. Any unexpected delegate, especially one added outside business hours or shortly after a suspicious login, should be investigated immediately. ## **Remediation** Upon detecting mailbox rule abuse or unauthorised forwarding, a SOC analyst should take the following steps: * Identify and delete any suspicious rules immediately * Remove any unauthorised forwarding addresses from the mailbox * Force a password reset to lock out the attacker * Revoke all active tokens and sessions for the compromised account * Determine how long forwarding was active and what emails may have been exfiltrated * Check if any unexpected delegates were added and remove them **Practice** To answer the questions, use the provided Splunk instance. You will use the `index=task4_5` query. Search for **All Time** and start investigating. ### Answer the questions below A suspicious inbox rule was created by a user. What is the name of the rule that forwards emails to an external address? ```shell index=* Workload=Exchange Operation=New-InboxRule | table _time UserId Name DeleteMessage ForwardTo SubjectContainsWords ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/215512e4-236a-4230-a26a-ebb68970de89.png align="center") What word does this forwarding inbox rule trigger on in the subject? `Verify` The same user configured mailbox-level email forwarding. To which external address were emails being forwarded? ```shell index=task4_5 DeliverToMailboxAndForward ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/f6ccefa7-4009-4e7c-af9c-04758bcd573b.png align="center") ## Detecting Phishing from Compromised Mailbox Now the attacker wants to expand their reach. With persistent access established and mechanisms in place to stay hidden, the **compromised mailbox** becomes a weapon. Sending **phishing emails** from a legitimate internal account is one of the most effective techniques in an attacker's arsenal. The email comes from a trusted colleague, bypasses external email security filters, and is far more likely to be clicked than a message from an unknown sender. ## **MailItemsAccessed** Before launching a phishing campaign, a sophisticated attacker will first spend time reading the victim's emails. By understanding ongoing conversations, the attacker can craft highly convincing phishing emails that reference real projects, real colleagues, and real business context. This reconnaissance activity is captured in the `MailItemsAccessed` operation. `MailItemsAccessed` logs are generated whenever emails in a mailbox are accessed or read. From a SOC analyst's perspective, this operation is important for two reasons. First, it can reveal that an attacker was actively reading emails before launching further attacks. Second, it is critical for data exposure assessment. If sensitive emails were accessed, the organisation may have a data breach notification obligation under GDPR or other regulations. In Splunk, use this query to investgate mail items accessed: | **Investigate Mail Items Accessed** | | --- | | | ```plaintext index=* Workload=Exchange Operation=MailItemsAccessed | table _time UserId ClientIPAddress OperationCount ``` ![Splunk showing the MailItemsAccessed log](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772731811051.png align="center") Red flags to watch for: * `MailItemsAccessed` events from an unusual IP address or location * High `OperationCount` indicating a large volume of emails being read * Access occurring outside business hours ## **Send Operation** When the attacker sends phishing emails from the compromised account, each email generates a `Send` operation in the Exchange audit logs. This is how SOC analysts can identify that a compromised account was used to send suspicious emails. The key fields in a `Send` log are: | **Field** | **Description** | | --- | --- | | `UserId` | The account that sent the email | | `Item.Subject` | The subject line of the email sent | | `Item.SizeInBytes` | Size of the email | | `ClientIP` | IP address from which the email was sent | | `SaveToSentItems` | Whether the email was saved to Sent Items | `SaveToSentItems=False` is a red flag. Attackers sometimes configure this to prevent the sent email from appearing in the victim's Sent folder, further hiding their activity. In Splunk, use this query to investigate sent emails: | **Investigate Sent Emails** | | --- | | | ```plaintext index=* Workload=Exchange Operation=Send | table _time UserId Item.Subject ClientIP SaveToSentItems ``` ![Splunk showing the Send operation log with Item.Subject field](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772731811720.png align="center") Red flags to watch for: * High volume of `Send` operations in a short time window * `SaveToSentItems=False` * `Send` events from an IP that does not match the victim's normal sign-in IP * Suspicious subject lines like invoice updates, password resets, or urgent requests ## **Message Trace** The `Send` operation shows that an email was sent and its subject, but it does not indicate who received it. To understand the full scope of the phishing campaign, how many people received the email, and whether it was successfully delivered, a SOC analyst pivots to message trace. In Splunk, use this query to investigate message trace: | **Investigate Message Trace Logs** | | --- | | | ```plaintext index=* sourcetype="o365:reporting:messagetrace" | table Received SenderAddress RecipientAddress Subject Status FromIP ``` ![Splunk showing the Message Trace with multiple recipients of the same phishing email](https://tryhackme-images.s3.amazonaws.com/user-uploads/6645aa8c024f7893371eb7ac/room-content/6645aa8c024f7893371eb7ac-1772731811054.png align="center") By filtering on the suspicious sender and the phishing email subject, you can quickly identify every recipient, confirm delivery status, and build a list of potentially compromised users who need to be contacted and warned. Red flags to watch for: * Multiple recipients receiving the same email from a compromised internal account in a short time window * `Status = Delivered`, confirming the phishing email reached the recipient's inbox * Recipients across different departments, suggesting a broad campaign ## **Remediation** Upon detecting phishing activity from a compromised mailbox, a SOC analyst should take the following steps: * Block the compromised account immediately to prevent any further emails from being sent * Identify all recipients of the phishing email by using message trace * Notify all recipients and warn them not to click any links or open any attachments from that email * Check for further compromised accounts, as any recipients who replied or clicked links may also be compromised * Review sent items and check the compromised account's sent folder for any other suspicious emails that may have been missed **Practice** To answer the questions, use the provided Splunk instance. You will use the `index=task4_5` query. Search for **All Time** and start investigating. ### Answer the questions below All TechCorp employees work from the same office network. A colleague reported receiving a suspicious email from an internal account. What was the subject line of this email? ```shell index=task4_5 action=delivered ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/9e535fd9-22c8-4527-b4d8-abf540966704.png align="center") How many colleagues received the phishing email according to message trace? ```shell index=task4_5 action=delivered Subject="Urgent: Verify Your Account" ``` Based on the output, there are three events, but two of the recipients are the same email; that's why it's only two ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/9ef4df31-b9c8-4267-b1c9-5a210e3186b8.png align="center") From which IP address were the suspicious emails sent? ```shell index=task4_5 james.wilson@techcorp.thm ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/db943599-0241-476f-aa77-2f735bd5d966.png align="center") ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/f1e0d4c6-ac38-41af-82eb-738926709d22.png align="center") ## Incident Investigation An unusual sign-in alert for Robert Green, Finance Manager at TechCorp, was triaged by a Level 1 analyst earlier today. The sign-in originated from an unfamiliar location and has been escalated to you as the Level 2 analyst on shift. Review the available logs in your Splunk and answer the questions below. To answer the questions, use the provided Splunk instance. You will use the `index=task6` query and search for **All Time**. **Note:** All TechCorp employees work from the same office network. **Tip:** When investigating a sequence of events, sort your results by time using `| sort - _time` at the end of your Splunk queries. This ensures events are displayed in chronological order, making it easier to follow the attacker's timeline. ### Answer the questions below From which **city** was the malicious login performed? ```shell index=task6 sourcetype="azure:aad:signin" appDisplayName="One Outlook Web" | table _time userPrincipalName appDisplayName ipAddress location.city status.errorCode | sort - _time ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/13d7049b-b88d-4348-a2de-b408f300f80b.png align="center") Needed help to justify the `status.errorCode` that represents the performance of a malicious login ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/45f0067c-a117-4c5c-8fe4-8097c9f2247d.png align="center") ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/d4da1481-2931-4206-84f3-63fc5445ff3c.png align="center") What was the name of the suspicious inbox rule created by the attacker? ```shell index=task6 robert.green@techcorp.thm Operation=New-InboxRule ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/b7eaee5e-3f16-4dcc-a256-871cf5314c8e.png align="center") The attacker configured email forwarding. What was the email in `ForwardingSmtpAddress`? ```shell index=task6 ForwardingSmtpAddress ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/78a611bf-165d-4375-b7cf-2bb6185431c0.png align="center") Robert's colleagues received a phishing email. What was the subject line? ```shell index=task6 robert.green@techcorp.thm action=delivered ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/c78ade79-025a-4d46-b2fc-8bb031cad7e9.png align="center") ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/fc98af19-2c62-46dc-87c3-d59a168e4f7f.png align="center") It seems the attacker was using a VPN. From which IP address did the attacker send the phishing emails? ```shell index=task6 robert.green@techcorp.thm action=delivered Subject="Action Required: Password Reset" ``` ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/ec4d89ea-08d7-44b9-b62a-801933f7b0b5.png align="center") One of the recipients replied to the phishing email. Which user replied? ```shell "adrian.mercer@techcorp.thm" "allan.senna@techcorp.thm" "emma.clarke@techcorp.thm" ``` Looking through each of the emails to check if they sent anything on the queries, none of them did except Emma ![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/290926b8-3cee-4351-ab21-a576ce9d9cf4.png align="center") ## Conclusion In this room, you investigated how attackers abuse Microsoft Exchange Online after compromising a mailbox. You learned how to identify suspicious sign-in activity using Entra ID logs, detect mailbox rule abuse and email forwarding through Exchange audit logs, identify phishing campaigns launched from compromised accounts, and scope the impact of an attack using message trace. In the next room, [SharePoint Online Monitoring](https://tryhackme.com/room/sharepointonlinemonitoring), we will explore SharePoint Online and how attackers abuse it to exfiltrate data and maintain persistence within a compromised Microsoft 365 environment.