The Forwarding Rule

2 hours Modules: M13, M1, M9, M6

Incident Brief

Incident ID: SC-2026-04-003 Date/Time: Thursday, 10 April 2026, 14:32 UTC Alert Source: Microsoft Sentinel — “Inbox rule creation with external forwarding” Assigned to: You

A Sentinel analytics rule fires: an inbox rule was created on the CFO’s mailbox (d.thompson@northgateeng.com) at 14:32 UTC. The rule forwards all email containing “invoice,” “payment,” or “bank details” to an external Gmail address: d.thompson.backup@gmail.com. The rule was created from IP 203.0.113.201.

You check: 203.0.113.201 is NOT in the CorporateExternalIPs watchlist. This looks like BEC — a compromised account with a financial keyword forwarding rule. Classic Module 13 scenario.

But then you check Teams. The CFO posted 10 minutes ago: “In Amsterdam for the board meeting. Hotel WiFi is terrible — using mobile hotspot.”

The question that defines this investigation: did the CFO create this rule, or did an attacker?

D. Thompson’s profile:

Attribute	Value
UPN	d.thompson@northgateeng.com
Title	Chief Financial Officer
Normal sign-in IPs	192.0.2.10, 192.0.2.15, 192.0.2.22 (VPN)
Current location	Amsterdam (board meeting, 9-11 April)
Device	LAPTOP-NGE003 (managed, Intune-enrolled)

Your Investigation

This challenge tests your ability to distinguish between legitimate-but-suspicious and genuinely malicious activity. The wrong call in either direction has consequences: treating a legitimate CFO action as a breach triggers unnecessary incident response and damages trust. Missing a real BEC gives the attacker persistent access to the CFO’s financial email.

Question 1. Examine the sign-in that created the inbox rule. What does the sign-in tell you about whether this is the CFO or an attacker?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// Starting query: the sign-in associated with the inbox rule creation
SigninLogs
| where TimeGenerated between(datetime(2026-04-10T14:00:00Z) .. datetime(2026-04-10T15:00:00Z))
| where UserPrincipalName == "d.thompson@northgateeng.com"
| where ResultType == "0"
| project TimeGenerated, IPAddress, AppDisplayName,
    Location = tostring(LocationDetails.countryOrRegion),
    City = tostring(LocationDetails.city),
    DeviceId = tostring(DeviceDetail.deviceId),
    Browser = tostring(DeviceDetail.browser),
    OS = tostring(DeviceDetail.operatingSystem),
    AuthenticationRequirement, ConditionalAccessStatus

Question 2. Check for other sign-ins from 203.0.113.201 in the last 30 days. Has this IP been used by the CFO before? Has it been used by ANY other user?

Question 3. The CFO says they are in Amsterdam. Does the IP geolocate to Amsterdam? Check the ASN — is it a hotel, mobile network, or something else?

Phase 2: Inbox Rule Analysis

Question 4. Examine the inbox rule in detail. What exactly does it do?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
// Starting query: inbox rule details
CloudAppEvents
| where TimeGenerated between(datetime(2026-04-10T14:00:00Z) .. datetime(2026-04-10T15:00:00Z))
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| where AccountDisplayName has "Thompson"
| extend RuleData = parse_json(RawEventData)
| extend Creator = tostring(RuleData.UserId)
| extend ClientIP = tostring(RuleData.ClientIP)
| extend Parameters = tostring(RuleData.Parameters)
| project TimeGenerated, Creator, ClientIP, Parameters

Question 5. The forwarding address is d.thompson.backup@gmail.com. This could be the CFO’s personal backup address. How do you determine whether it is legitimate without asking the CFO directly? (Remember: if this IS an attacker, asking the CFO tips them off that you are investigating.)

Question 6. Check: has d.thompson.backup@gmail.com received any email from the organisation before? Has the CFO ever created inbox rules before?

1
2
3
4
5
6
7
8
9
// Historical inbox rules for the CFO
CloudAppEvents
| where TimeGenerated > ago(365d)
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| where AccountDisplayName has "Thompson"
| project TimeGenerated, ActionType,
    Parameters = tostring(parse_json(RawEventData).Parameters),
    ClientIP = tostring(parse_json(RawEventData).ClientIP)
| order by TimeGenerated desc

Phase 3: Contextual Evidence

Question 7. Check the CFO’s email activity from the Amsterdam IP. Is the activity pattern consistent with someone doing normal work while travelling?

1
2
3
4
5
6
7
8
// CFO's activity from the suspicious IP
CloudAppEvents
| where TimeGenerated > datetime(2026-04-09T00:00:00Z)
| where AccountDisplayName has "Thompson"
| extend ClientIP = tostring(parse_json(RawEventData).ClientIPAddress)
| where ClientIP == "203.0.113.201" or isempty(ClientIP)
| summarize Actions = count() by ActionType
| order by Actions desc

Question 8. Check for non-interactive sign-ins from other IPs during the same window. Is someone else also using the CFO’s tokens from a different location? (Token replay from Module 14.)

1
2
3
4
5
AADNonInteractiveUserSignInLogs
| where TimeGenerated > datetime(2026-04-10T00:00:00Z)
| where UserPrincipalName == "d.thompson@northgateeng.com"
| summarize count() by IPAddress
| order by count_ desc

Phase 4: The Decision

Question 9. Based on your evidence: is this the CFO creating a legitimate forwarding rule, or is this an attacker? Build your evidence table:

Evidence	Points to CFO	Points to Attacker
IP geolocation
Device ID
MFA status
Browser/OS
Activity pattern
Rule content
Historical rules
Non-interactive sign-ins

Question 10. Regardless of your conclusion: what is the correct immediate action? If you believe it is the CFO — do you do nothing? If you believe it is an attacker — do you revoke immediately?

Question 11. Write the notification message to the CFO. Consider: you need to verify whether the rule is legitimate, without revealing the investigation details if this turns out to be a compromise.

Solution

Click to reveal the full solution walkthrough

Solution walkthrough

The answer: this IS the CFO. But the investigation process is identical regardless of the outcome — and that is the point of this challenge.

Q1: Sign-in analysis. The sign-in from 203.0.113.201 shows: Location = Netherlands, City = Amsterdam. Device ID matches LAPTOP-NGE003 (the CFO’s managed laptop). MFA was satisfied via Authenticator push. Browser: Edge/120.0. OS: Windows 11. Conditional Access: passed. Every attribute matches a legitimate sign-in from a travelling user on their managed device.

Q2: IP history. 203.0.113.201 has NOT been used before — by the CFO or anyone else. This is consistent with a hotel/mobile hotspot IP (changes each connection). It is also consistent with an attacker’s fresh infrastructure. This evidence is inconclusive.

Q3: Geolocation. The IP geolocates to Amsterdam, Netherlands. ASN: a Dutch mobile network operator. Consistent with the CFO’s stated location and “mobile hotspot” Teams message. If the IP geolocated to, say, Nigeria while the CFO claims Amsterdam — that would be conclusive evidence of compromise.

Q4: Rule content. The rule forwards email matching “invoice OR payment OR bank details” to d.thompson.backup@gmail.com. The financial keywords are concerning — this is the exact pattern an attacker uses for BEC preparation. But it is also a plausible rule for a CFO who wants to monitor financial email while travelling with unreliable connectivity.

Q5: Gmail address verification. Without asking the CFO: check EmailEvents for any previous email sent TO d.thompson.backup@gmail.com from the organisation. If the CFO has previously emailed this address (or received email from it): it is likely their personal address. Also check: is this Gmail address in any previous inbox rules, forwarding configurations, or delegate permissions?

Q6: Historical rules. The CFO has created inbox rules twice before — both during previous travel (category-based rules to prioritise email). Neither involved external forwarding. External forwarding is new behaviour, but the CFO has used inbox rules while travelling before.

Q7: Activity pattern. From 203.0.113.201, the CFO: read 24 emails, replied to 3, opened 2 SharePoint documents, and created the inbox rule. This is a normal work pattern for someone at a board meeting with limited connectivity — reading email between sessions, replying to urgent items, reviewing documents.

Q8: Token replay check. No non-interactive sign-ins from unexpected IPs. All non-interactive traffic comes from the same IP (203.0.113.201) or Microsoft infrastructure IPs. No evidence of concurrent access from a different location. If there were a second IP showing non-interactive sign-ins from, say, Eastern Europe simultaneously: that would confirm token replay.

Q9: Evidence table.

Evidence	CFO	Attacker
IP = Amsterdam	✓ Matches travel
Device = LAPTOP-NGE003	✓ Managed device
MFA = Authenticator	✓ CFO’s method
Browser = Edge/Windows	✓ CFO’s normal
Activity = normal work	✓ 24 reads, 3 replies
Rule = financial keywords	Concerning but plausible	✓ Classic BEC pattern
Historical = rules while travelling	✓ Precedent exists
Non-interactive = clean	✓ No replay evidence

Weight of evidence: 7 indicators point to CFO, 1 is ambiguous. Conclusion: legitimate activity with high confidence.

Q10: Correct immediate action. Even though the evidence points to the CFO: do NOT do nothing. The external forwarding rule is a security risk regardless of who created it — financial email should not be forwarded to a personal Gmail account. The correct action: contact the CFO via phone or Teams (not email — the forwarding rule would forward your message to Gmail). Say: “Hi David, our email monitoring flagged a new forwarding rule on your mailbox created from Amsterdam. Can you confirm you set this up? If so, we can suggest a more secure alternative for monitoring email while travelling.” This verifies without revealing investigation details and provides a security improvement regardless.

Q11: Notification message. “Hi David — our security monitoring flagged a new inbox rule on your mailbox created today from an Amsterdam IP. This is standard monitoring and not a concern — I just want to confirm it was you. The rule forwards certain email to a Gmail address. If this was intentional, I’d suggest using the Outlook mobile app instead, as it keeps email within our protected environment. Can you confirm by Teams or phone?”

The lesson: The investigation process for a false positive is identical to a true positive. You gather evidence, assess each indicator, and make a determination. The 2 hours you spent investigating a legitimate action were not wasted — they confirmed the CFO was not compromised, identified a security improvement (replace forwarding with Outlook mobile), and exercised your investigation skills. In the real world, 70-80% of investigations end with “benign — no further action.” The skill is reaching that conclusion efficiently and with confidence.

← All Challenges