In this section
4.2 Detection: Inbox Forwarding Rule to External Domain After Anomalous Sign-In
Section 4.1 introduced the three email data sources and the OfficeActivity parsing patterns. This section builds DET-SOC-008: a detection rule for inbox forwarding rules that send email to external domains. You'll learn why this is the most common BEC persistence technique, how to parse the OfficeActivity Parameters field for forwarding destinations, and how to correlate the rule creation with a preceding anomalous sign-in to confirm attacker activity.
The forwarding rule that survives every remediation step except one
Scenario
NE's February AiTM compromise: the IR team reset Harrison's password, revoked sessions, and re-enrolled MFA. The attacker lost access to the account. But 27 minutes after the initial compromise, before the IR team responded: the attacker created an inbox rule named ".." that forwarded all emails containing "invoice," "payment," or "wire" to ext-backup@proton.me. The forwarding rule persisted through the password reset. For three weeks, every payment-related email Harrison received was silently copied to the attacker. The IR team didn't check inbox rules because their playbook focused on credential remediation.
Inbox forwarding rules are the most common BEC persistence mechanism. The FBI's IC3 2024 Internet Crime Report identified BEC as a $2.9 billion loss category, with email forwarding rules present in the majority of cases. The technique works because forwarding rules operate at the mailbox level, they're unaffected by password resets, session revocations, or MFA re-enrollment. The rule forwards email silently, with no notification to the user and no visible indication in their mailbox (the forwarded copy doesn't appear in Sent Items).
The detection has two layers. Layer one: any new inbox rule with a ForwardTo, ForwardAsAttachmentTo, or RedirectTo parameter targeting an external domain. Layer two: correlation with an anomalous sign-in (DET-SOC-001) within the preceding 2 hours, which elevates the alert from medium (possible user automation) to high (probable attacker persistence).
Estimated time: 50 minutes.
Rule specification
Hypothesis: An attacker who compromises a mailbox will create a forwarding rule to exfiltrate email to an external address they control. The forwarding rule is created via New-InboxRule or Set-InboxRule with a ForwardTo/RedirectTo parameter containing a non-organizational domain. When preceded by an anomalous sign-in from unfamiliar infrastructure, this is confirmed BEC persistence.
Data source: OfficeActivity. Operation "New-InboxRule" or "Set-InboxRule", Parameters containing ForwardTo/RedirectTo/ForwardAsAttachmentTo.
MITRE ATT&CK: Collection → T1114.003 (Email Forwarding Rule). Exfiltration → T1020 (Automated Exfiltration).
Severity: High (when correlated with anomalous sign-in). Medium (standalone, may be legitimate user automation).
The KQL detection query
// Hypothesis: BEC persistence via external email forwarding
// ATT&CK: T1114.003 (Email Forwarding Rule)
let org_domains = dynamic([
"northgateeng.com",
"northgateeng.onmicrosoft.com"
]);
let forward_params = dynamic([
"ForwardTo", "ForwardAsAttachmentTo", "RedirectTo"
]);
OfficeActivity
| where TimeGenerated > ago(1h)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend Params = parse_json(Parameters)
// Extract forwarding destination
| mv-apply P = Params on (
where P.Name in (forward_params)
| extend ForwardDest = tostring(P.Value)
)
| where isnotempty(ForwardDest)
// Extract the domain from the forwarding address
| extend ForwardDomain = tostring(
split(ForwardDest, "@")[1])
// Filter: external domains only
| where not(ForwardDomain has_any (org_domains))
// Extract rule name
| mv-apply N = Params on (
where N.Name == "Name"
| extend RuleName = tostring(N.Value)
)
| project
TimeGenerated,
UserId,
Operation,
RuleName,
ForwardDest,
ForwardDomain,
ClientIP,
SessionIdThe query parses the Parameters JSON array to extract the forwarding destination, splits the email address to get the domain, and filters out internal domains. The org_domains list should include all domains your organization owns, production domain, onmicrosoft.com, and any subsidiary domains.
TimeGenerated UserId Operation RuleName ForwardDest ForwardDomain ClientIP
2026-02-06T07:14:33Z j.harrison@northgateeng.com New-InboxRule .. ext-backup@proton.me proton.me 185.234.xx.xxThe rule name ".." is a deliberate evasion technique: the attacker uses a name that's nearly invisible in the Outlook rules list. Two dots are even less visible than the single-period rule name used in the hiding rule (DET-SOC-009). The ForwardDomain (proton.me) is a privacy-focused email provider commonly used by BEC attackers because it doesn't require identity verification to create an account and provides end-to-end encryption that prevents the email provider from cooperating with incident investigations. The ClientIP matches the attacker's infrastructure from DET-SOC-001: the same IP that performed the AiTM credential theft now appears creating a forwarding rule, linking the initial access to the persistence establishment.
All three indicators, suspicious rule name, external privacy-focused domain, and attacker IP, confirm BEC persistence. The forwarding rule is the attacker's insurance policy: even if the SOC detects the compromise and resets Harrison's password, the forwarding rule continues copying email to the external address until it's explicitly removed. Password resets don't affect inbox rules. Session revocation doesn't affect inbox rules. Only explicit rule removal through Exchange administration stops the forwarding. This persistence characteristic is why forwarding rule detection is paired with the hiding rule detection in DET-SOC-009: the attacker creates both rules in the same session, ensuring continued access (forwarding) while concealing the compromise (hiding).
Correlation with anomalous sign-in
The standalone forwarding rule detection is medium severity, users legitimately create forwarding rules to personal email. The correlation with a preceding anomalous sign-in elevates to high severity:
// Correlate forwarding rules with unfamiliar IP sign-ins
let forwarding_rules =
// [insert DET-SOC-008 query from above]
OfficeActivity
| where TimeGenerated > ago(2h)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend Params = parse_json(Parameters)
| where Params has_any ("ForwardTo", "RedirectTo",
"ForwardAsAttachmentTo")
| project RuleTime = TimeGenerated, RuleUser = UserId,
RuleIP = ClientIP, Operation, Params;
let anomalous_signins =
SigninLogs
| where TimeGenerated > ago(4h)
| where ResultType == 0
| where RiskLevelDuringSignIn in ("medium", "high")
or RiskLevelAggregated in ("medium", "high")
| project SignInTime = TimeGenerated,
SignInUser = UserPrincipalName,
SignInIP = IPAddress;
forwarding_rules
| join kind=inner anomalous_signins
on $left.RuleUser == $right.SignInUser
| where RuleTime between(SignInTime .. (SignInTime + 2h))
| project SignInTime, RuleTime,
User = RuleUser, SignInIP, RuleIP,
Operation, ParamsThis correlation joins forwarding rule creation with risky sign-ins for the same user within a 2-hour window. When both fire, anomalous sign-in followed by external forwarding rule: the alert is confirmed BEC persistence with high confidence.
The Sigma equivalent
title: Inbox Forwarding Rule to External Domain
id: det-soc-008
status: production
description: |
Detects creation of inbox forwarding rules that redirect
email to external domains. Primary BEC persistence technique.
FBI IC3 2024: $2.9B losses from BEC, forwarding rules present
in majority of cases.
author: Ridgeline Cyber Detection Engineering
date: 2026/05/17
tags:
- attack.collection
- attack.t1114.003
- attack.exfiltration
- attack.t1020
logsource:
product: m365
service: exchange
detection:
selection:
Operation:
- 'New-InboxRule'
- 'Set-InboxRule'
Parameters|contains:
- 'ForwardTo'
- 'ForwardAsAttachmentTo'
- 'RedirectTo'
filter_internal:
Parameters|contains: '@yourdomain.com'
condition: selection and not filter_internal
falsepositives:
- Users forwarding to personal email for backup
- Shared mailbox forwarding configurations
- IT-configured forwarding for role-based mailboxes
level: mediumPowerShell: enumerate all forwarding rules in the tenant
When DET-SOC-008 fires, the analyst should audit all forwarding rules tenant-wide: the attacker may have created forwarding rules on multiple compromised accounts:
# Connect to Exchange Online
Connect-ExchangeOnline
# 1. Check inbox rules with forwarding (client-side rules)
$mailboxes = Get-Mailbox -ResultSize Unlimited
$suspiciousRules = foreach ($mbx in $mailboxes) {
Get-InboxRule -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue |
Where-Object {
$_.ForwardTo -or
$_.ForwardAsAttachmentTo -or
$_.RedirectTo
} | ForEach-Object {
[PSCustomObject]@{
Mailbox = $mbx.UserPrincipalName
RuleName = $_.Name
ForwardTo = ($_.ForwardTo -join "; ")
RedirectTo = ($_.RedirectTo -join "; ")
Enabled = $_.Enabled
CreatedDate = $_.DateCreated
}
}
}
$suspiciousRules | Format-Table -AutoSize
# 2. Check mailbox-level SMTP forwarding (server-side)
Get-Mailbox -ResultSize Unlimited |
Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
Select-Object UserPrincipalName, ForwardingSmtpAddress,
ForwardingAddress, DeliverToMailboxAndForward |
Format-Table -AutoSizeMailbox RuleName ForwardTo RedirectTo Enabled CreatedDate
j.harrison@northgateeng.com .. ext-backup@proton.me True 2026-02-06
finance-team@northgateeng.com Backup finance-archive@ne.. True 2025-06-15
UserPrincipalName ForwardingSmtpAddress DeliverToMailboxAndForward
(no results — no server-side forwarding configured)Two results. Harrison's ".." rule forwarding to Proton Mail: the attacker's rule. The finance-team shared mailbox forwarding to an internal archive, legitimate. The PowerShell audit checks both client-side rules (Get-InboxRule, created via Outlook or OWA) and server-side forwarding (Get-Mailbox ForwardingSmtpAddress, configured via Set-Mailbox PowerShell). Both are persistence mechanisms. Both need auditing during incident response.
Entity mapping
[
{
"entityType": "Account",
"fieldMappings": [{
"identifier": "FullName",
"columnName": "UserId"
}]
},
{
"entityType": "IP",
"fieldMappings": [{
"identifier": "Address",
"columnName": "ClientIP"
}]
}
]False positive profile and tuning
Legitimate forwarding to personal email: Some users forward work email to a personal Gmail or Outlook.com address for reading on their phone. This is a policy issue (most organizations prohibit it) but not an attack. The correlation layer helps: legitimate forwarding rules aren't preceded by anomalous sign-ins. For the standalone rule, you can add known personal email providers to a watchlist rather than excluding them: the rule still fires, but the analyst sees the user's history and classifies as BTP (Benign True Positive) more quickly.
Shared mailbox configurations: Shared mailboxes (finance-team@, support@) often have forwarding rules configured by IT for archiving or routing. Maintain a watchlist of shared mailboxes with approved forwarding and exclude them:
// Watchlist: approved forwarding configurations
let approved_forwarding = _GetWatchlist("ApprovedForwarding")
| project Mailbox = SearchKey, ApprovedDest;
// Add after ForwardDomain extraction
| join kind=leftanti approved_forwarding
on $left.UserId == $right.MailboxSuspicious rule names: Attackers frequently use rule names designed to be invisible: single characters (".", ".."), empty strings, or names that mimic system rules ("Microsoft", "Sync"). Flag these patterns as additional high-confidence indicators alongside the forwarding destination.
Anti-Pattern
The rule fires on every new inbox rule, regardless of whether it contains a forwarding parameter. The SOC receives alerts for rules that move emails to folders, mark emails as read, or categorize emails, none of which are forwarding. The alert volume is 20-30 per day, all legitimate inbox organization. The analyst stops investigating after the first week. The detection above filters specifically for ForwardTo, RedirectTo, and ForwardAsAttachmentTo parameters, reducing volume to 1-3 alerts per week. The correlation layer further reduces noise to near zero during normal operations, legitimate forwarding rules aren't preceded by anomalous sign-ins.
Response actions for confirmed BEC forwarding
$upn = "j.harrison@northgateeng.com"
# 1. Remove the attacker's forwarding rule
$rules = Get-InboxRule -Mailbox $upn |
Where-Object { $_.ForwardTo -or $_.RedirectTo }
$rules | ForEach-Object {
Write-Host "Removing rule: $($_.Name) → $($_.ForwardTo)"
Remove-InboxRule -Mailbox $upn -Identity $_.Identity -Confirm:$false
}
# 2. Also check and remove server-side forwarding
Set-Mailbox -Identity $upn -ForwardingSmtpAddress $null `
-ForwardingAddress $null -DeliverToMailboxAndForward $false
# 3. Assess what was forwarded — message trace for the period
# the rule was active
Get-MessageTrace -SenderAddress $upn `
-StartDate (Get-Date).AddDays(-21) `
-EndDate (Get-Date) |
Where-Object { $_.RecipientAddress -like "*proton.me" } |
Select-Object Received, Subject, RecipientAddress,
MessageTraceId | Format-Table -AutoSizeStep 3 is critical: the message trace shows exactly what was forwarded during the period the rule was active. At NE, this revealed that 147 emails containing "invoice," "payment," or "wire transfer" were forwarded to the attacker over 21 days. The data loss assessment drives the incident severity and regulatory notification decision.