Threat Hunting Exercise: Analyzing Office 365 Mailbox Forwarding Rule Exfiltration Dataset
This hunt uses a simulated Microsoft 365 Unified Audit Log export (o365_mailbox_forwarding_exfil_2022-05-02T082500.json) to trace T1114.003: Email Collection - Email Forwarding Rule, the direct follow-on from this series' VPN impossible-travel hunt - once an adversary has a live mailbox session, a covert forwarding rule is the single most efficient way to passively exfiltrate all future correspondence without repeated logons.
Step 1: Hypothesis Formation
Hypothesis: Following unauthorized mailbox access, the adversary creates an inbox rule that silently forwards (or forwards-and-deletes) incoming mail matching broad or no criteria to an external address, and/or grants a new delegate/ApplicationImpersonation right for persistent access, all while suppressing visible notification to the legitimate user (e.g., marking forwarded copies as read, or using New-InboxRule rather than the visible Outlook forwarding toggle). Indicators:
- UAL
New-InboxRule/Set-Mailboxoperation withForwardTo/RedirectToset to an external SMTP address, especially withDeleteMessage=Trueor broad/empty conditions. - Operation performed via PowerShell (
Set-InboxRulecmdlet) rather than the OWA UI - often a sign of scripted/automated abuse (though legitimate admins use PS too, so context matters). - Absence of a corresponding user-initiated OWA session event immediately prior (i.e., the rule creation doesn't line up with normal user behavior).
- Subsequent
MailItemsAccessed/Sendoperations matching the external forwarding address.
Null Hypothesis: Legitimate user-configured auto-forward (e.g., to a personal address while on leave) or an approved third-party integration. Invalidate via correlation with a known-compromised session (per the VPN hunt), destination domain reputation, and the DeleteMessage flag (users forwarding to themselves rarely also delete the original).
Rationale: This report intentionally chains off the VPN Impossible Travel hunt's finding (an OWA rule creation event was flagged there) - demonstrating how M365 UAL analysis completes the picture once network-layer compromise is suspected.
Step 2: Data Sources and Scope
- Sources: Microsoft 365 Unified Audit Log (Exchange admin/mailbox operations:
New-InboxRule,Set-Mailbox,MailItemsAccessed,Send); Azure AD sign-in logs for session correlation. - Scope: ~2022-05-02T08:25:00-08:35:00 UTC; Mailbox: rharris@theshire.com; Session correlates to the Bucharest VPN/IdP session from the companion hunt.
- SIEM Queries (KQL for Sentinel/Log Analytics, or Splunk on UAL export):
- Rule creation:
OfficeActivity | where Operation in ("New-InboxRule","Set-InboxRule") | where Parameters has "ForwardTo" or Parameters has "RedirectTo" - External destination:
OfficeActivity | where Operation == "New-InboxRule" | extend fwd = extractjson('$.ForwardTo', Parameters) | where fwd !endswith "@theshire.com" - Suppression check:
OfficeActivity | where Operation == "New-InboxRule" | where Parameters has "DeleteMessage" and Parameters has "true"
Step 3: Key Findings
Parsed UAL entries (8 shown) confirm a covert forwarding rule created via PowerShell within minutes of the anomalous Bucharest session, followed by active exfiltration of subsequent mail.
| Timestamp (UTC) | Operation | Actor/ClientIP | Key Details | IOC/Why Suspicious? |
|---|---|---|---|---|
| 2022-05-02 08:25:01 | UserLoggedIn | rharris / 185.81.157.9 | ResultStatus=Succeeded; ClientInfoString="Client=OWA". | Confirms the OWA session tied to the anomalous Bucharest VPN session identified in the companion hunt. |
| 2022-05-02 08:25:20 | New-InboxRule | rharris / 185.81.157.9 (via Exchange Online PowerShell) | Name="Server Rule #2b1"; ForwardTo="finance.updates@0utlook-secure.com" (typosquatted external domain); DeleteMessage=True; conditions=none (matches all mail). | Core IOC: Blank-condition rule (matches everything) forwarding to a typosquatted external domain, with the original deleted after forwarding - hides the rule's effect from the mailbox owner entirely. |
| 2022-05-02 08:25:22 | Set-Mailbox | rharris / 185.81.157.9 | AuditEnabled changed from True to False (attempted, partially blocked by tenant policy). | Evasion IOC: Attempt to disable mailbox auditing to reduce future detection - blocked by org policy but the attempt itself is a strong signal. |
| 2022-05-02 08:26:00 | Add-MailboxPermission | rharris / 185.81.157.9 | User="svc-backup-sync" (same name pattern as the AWS backdoor account in the companion cloud hunt - likely actor reuse); AccessRights=FullAccess. | Persistence IOC: Grants a secondary identity full mailbox access - a fallback if the forwarding rule is discovered and removed. |
| 2022-05-02 08:40:15 | MailItemsAccessed | rharris / (Exchange internal, triggered by inbound mail) | Folders=Inbox; InternalLogonType=0; ClientInfoString="Client=REST;Client=RESTSystem". | Rule engine processes an incoming email matching the (empty) condition - first exfil trigger. |
| 2022-05-02 08:40:16 | Send | rharris (system, on behalf of rule) | Recipient="finance.updates@0utlook-secure.com"; Subject matches the just-received internal email's subject. | Exfil IOC: Confirmed forwarding in action - an internal email is silently copied to the external address within one second of arrival. |
| 2022-05-02 08:40:17 | SoftDelete | rharris (system, on behalf of rule) | ItemSubject matches the forwarded email; Folder=Deleted Items → permanently removed per DeleteMessage=True. | Original evidence removed from the mailbox owner's view entirely. |
| 2022-05-02 09:15:00 - (ongoing) | Send x14 | rharris (system, on behalf of rule) | 14 additional emails forwarded and deleted over the following hours, including two containing "wire transfer" in the subject line. | Business impact IOC: Rule actively captured financially sensitive correspondence, indicating likely BEC (Business Email Compromise) follow-on intent. |
Validation:
- Timeline: Login → rule creation → audit-disable attempt → permission grant, all within 90 seconds of the compromised session starting; first exfil trigger 14 minutes later, confirming the rule was immediately live and functional.
- False Positives: rharris has no history of external forwarding rules in 12 months of UAL history;
0utlook-secure.comis a typosquat (zero for 'o') registered 9 days prior with no legitimate business relationship. - Correlation: Directly chains to the VPN Impossible Travel hunt's Bucharest session (same ClientIP 185.81.157.9) and reuses a persistence-account naming pattern (
svc-backup-sync) seen in this series' AWS PassRole hunt - strong evidence of a single actor operating across VPN, mailbox, and cloud IAM.
Step 4: Recommendations & Next Steps
- Response: Remove the malicious inbox rule and the
svc-backup-syncmailbox permission immediately; force password reset and full session/token revocation; notify recipients of the two wire-transfer-related emails to check for fraudulent follow-up; report the typosquat domain for takedown. - Detection: Sentinel/UAL analytic:
title: Covert Mailbox Forwarding Rule→selection: Operation in ("New-InboxRule","Set-InboxRule") AND ForwardTo domain not in approved_list AND DeleteMessage=true. - Pro Tip: Always chain mailbox-rule hunts to identity/network hunts (VPN, sign-in logs) and to cloud IAM hunts - actors frequently reuse naming conventions and infrastructure across an intrusion, which is often the fastest way to scope the full blast radius.
Hypothesis confirmed - covert, self-deleting forwarding rule actively exfiltrating financially sensitive email! Chaining this hunt to the VPN and AWS findings in this series revealed a single coordinated actor across three distinct log sources.