Agent Foskett Investigation • Business Email Compromise • Defender XDR • Exchange Online • KQL
The Email Was Genuine — The Conversation Had Been Hijacked
The supplier’s email was real. The conversation was real. Even the reply arrived in the same thread.
Only the bank details were different.
“Well,” Agent Foskett said, “at least the criminal had the courtesy to use Reply All.”
Was this a spoofed message, a malicious inbox rule, or a genuine account used by someone else?
The Hijacked Conversation
A legitimate thread can carry a fraudulent instruction when an account is compromised.
✓ Establish which mailbox actually sent the message
✓ Reconstruct sign-ins, rules and mail activity
✓ Determine whether the payment instruction was altered
The invoice that arrived in the right conversation
A fictional training scenario, built around a common business email compromise (BEC) pattern. The example names, timestamps and account details are illustrative.
🔎
09:12 — The familiar threadThe finance officer received a reply in an existing supplier conversation, quoting the correct purchase order and invoice.🔎
09:14 — The changed instructionThe message asked for payment to a new account, framed as an urgent banking update.🔎
09:27 — The uncomfortable questionThe sender domain and conversation history looked legitimate. Was the supplier mailbox itself being used by an attacker?A genuine message is not proof of a genuine sender
The analyst must distinguish display-name spoofing, lookalike domains, account takeover and an attacker operating within an existing mailbox.
🔎
Message identityCheck sender, recipient, Message-ID, NetworkMessageId, authentication results and the message trace. SPF, DKIM and DMARC can pass for a message sent from a genuinely compromised tenant.🔎
Thread contextInspect conversation references and prior messages. A matching subject or quoted text alone does not prove that the reply was authorised.🔎
Business validationCall the supplier on a previously trusted number before changing payment details. Do not rely on phone numbers or contact details supplied in the suspicious email.Reconstruct the investigation timeline
Illustrative chronology only. In a real investigation, reconcile UTC timestamps across Exchange Online, Defender XDR, Entra ID and Purview.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
08:41 Unusual supplier account sign-in (requires validation) 08:48 Inbox rule created to hide finance replies 09:12 Existing invoice thread receives a new reply 09:14 Reply requests changed bank details 09:27 Finance flags the unexpected payment instruction 09:36 Security team preserves messages and audit evidence
1. Locate the suspicious email in Defender XDR
Run in Microsoft Defender XDR Advanced Hunting. Replace the example domain and time range. Availability depends on licensing and telemetry retention.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let startTime = datetime(2026-10-19T00:00:00Z);
let endTime = startTime + 2d;
EmailEvents
| where Timestamp between (startTime .. endTime)
| where SenderFromDomain =~ "example-supplier.com"
| where Subject has_any ("invoice", "payment", "bank details")
| project Timestamp, NetworkMessageId, InternetMessageId,
SenderFromAddress, SenderMailFromAddress,
RecipientEmailAddress, Subject, DeliveryAction,
EmailDirection, AuthenticationDetails
| order by Timestamp asc2. Follow the message and post-delivery activity
Use
NetworkMessageId to correlate Defender XDR email tables. A delivered message may later be moved or remediated; this query shows available post-delivery actions, not whether the recipient acted on the instructions.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
let suspiciousMessages =
EmailEvents
| where Timestamp > ago(14d)
| where SenderFromAddress =~ "accounts@example-supplier.com"
| project NetworkMessageId, MailTime=Timestamp,
RecipientEmailAddress, Subject;
suspiciousMessages
| join kind=leftouter (
EmailPostDeliveryEvents
| where Timestamp > ago(14d)
| project NetworkMessageId, ActionTime=Timestamp,
Action, ActionType
) on NetworkMessageId
| project MailTime, ActionTime, RecipientEmailAddress,
Subject, Action, ActionType, NetworkMessageId
| order by MailTime desc3. Look for suspicious mailbox activity
CloudAppEvents can surface relevant Exchange Online activity when that connector and event coverage are available in Defender XDR. Operation names and RawEventData fields vary: inspect your tenant’s schema and sample records before treating any event as conclusive.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
CloudAppEvents
| where Timestamp > ago(14d)
| where Application == "Microsoft Exchange Online"
| where ActionType has_any (
"New-InboxRule", "Set-InboxRule", "Send", "MailItemsAccessed")
| project Timestamp, ActionType, AccountDisplayName,
AccountId, IPAddress, RawEventData
| order by Timestamp desc4. Examine sign-ins for the suspected account
Run in Microsoft Sentinel / Log Analytics if Entra sign-in logs are connected. Successful authentication from an unfamiliar IP is a lead, not proof of compromise. Also review non-interactive sign-ins, session context and Conditional Access results.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
SigninLogs
| where TimeGenerated > ago(14d)
| where UserPrincipalName =~ "accounts@example-supplier.com"
| project TimeGenerated, UserPrincipalName, IPAddress,
Location, AppDisplayName, ClientAppUsed,
ResultType, ConditionalAccessStatus,
AuthenticationRequirement, CorrelationId
| order by TimeGenerated asc5. Check Exchange mailbox audit records
Run in Microsoft Sentinel / Log Analytics if Microsoft 365 audit data is ingested into
OfficeActivity. The available operations depend on audit configuration, licensing and connector coverage.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
OfficeActivity
| where TimeGenerated > ago(14d)
| where OfficeWorkload =~ "Exchange"
| where UserId =~ "accounts@example-supplier.com"
| where Operation has_any (
"New-InboxRule", "Set-InboxRule", "Send", "MailItemsAccessed")
| project TimeGenerated, Operation, UserId,
ClientIP, OfficeObjectId, Parameters
| order by TimeGenerated asc6. Hunt for other recipients of the same instruction
A compromised mailbox may send multiple payment-change requests. Pivot on the sender, subject and observed messages; confirm content separately using approved message review processes.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
EmailEvents
| where Timestamp > ago(14d)
| where SenderFromAddress =~ "accounts@example-supplier.com"
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
Messages=count(),
Subjects=make_set(Subject, 10)
by RecipientEmailAddress, DeliveryAction
| order by Messages descWhat the logs can — and cannot — prove
Do not equate successful email authentication with an authorised human sender.
🔎
Authentication passedSPF, DKIM or DMARC alignment may support the technical origin of the message. They do not establish that the mailbox owner intended the payment change.🔎
Suspicious sign-in observedA sign-in from a new location or IP may support an account takeover hypothesis, but requires corroboration with session, device, MFA and user evidence.🔎
Inbox rule foundA new forwarding, deletion or move rule can indicate attacker persistence or concealment. Establish who created it and whether it operated during the incident.The six-stage investigation
A repeatable workflow helps separate suspicious evidence from confirmed fraud.
🔎
1. PreserveRetain the original messages, headers, message IDs and relevant audit data.🔎
2. AuthenticateVerify supplier banking instructions using a previously trusted channel.🔎
3. CorrelateJoin email, mailbox, identity and audit events by reliable identifiers and time.🔎
4. ScopeFind other recipients, altered messages, suspicious rules and possible data access.🔎
5. ContainCoordinate with the affected tenant owner to revoke sessions, reset credentials, remove malicious rules and secure MFA.🔎
6. RecoverNotify finance and banking contacts quickly if a transfer occurred; document findings and prevent recurrence.What the organisation should do next
Immediate financial containment and identity response should proceed in parallel.
🔎
Protect the paymentPlace the invoice on hold; contact the known supplier contact and bank promptly if money has moved.🔎
Secure the accountRevoke sessions and tokens, rotate credentials, verify MFA methods and remove unauthorised mailbox rules or delegates.🔎
Improve the processRequire independent approval for changed bank details, and alert on risky inbox rules, unusual sign-ins and high-risk mail activity.Investigation findings
In this fictional case, the working hypothesis was a compromised supplier mailbox used to hijack a legitimate conversation. The example telemetry demonstrates how to test that hypothesis; it is not evidence from a real tenant.
🔎
What is establishedA payment-change message arrived in an existing conversation, and the scenario includes suspicious mailbox and identity events.🔎
What still needs proofThe exact actor, how access was obtained, whether messages were read, and whether any payment or data loss occurred.🔎
The central lessonA genuine email address and authentic thread are not sufficient verification for a high-risk financial instruction.Related Agent Foskett investigations
Continue the evidence-first approach across identity, email and cloud security.
Who Invited the Guest Who Could Read the Finance Files?Trace guest identity, permissions and actual access evidence.The Password Was Correct — But Nobody Had Typed ItInvestigate identity signals that challenge a seemingly normal sign-in.The Azure Deployment Succeeded — And Quietly Opened a Security HoleFollow configuration changes beyond a green deployment status.
Final thought
Agent Foskett looked at the message again. “Correct address. Correct thread. Incorrect bank account. Apparently the criminal passed every test except the one that mattered.”
The logs already knew. The invoice approval process needed to ask.
The logs already knew. The invoice approval process needed to ask.
🔎
Investigation takeawayVerify payment changes outside the email conversation, preserve evidence, and correlate mailbox, sign-in and message activity before declaring a cause.