Agent Foskett Academy • Lesson 112 • Incident Response Workflow

Incident Response Workflow: Business Email Compromise.

The email came from a real mailbox.

The signature looked right. The tone sounded familiar. The request was urgent, but believable.

A bank account had changed. An invoice needed paying. The finance team almost approved it.

Agent Foskett knew this was not just an email investigation. Business Email Compromise is an identity, mailbox and fraud investigation wrapped inside a message that looks normal.

Start Lesson 112 Back to Academy

Agent Foskett Academy lesson investigating Business Email Compromise in Microsoft Defender XDR

Lesson overview

Learn how to investigate Business Email Compromise by correlating Microsoft Defender XDR, Exchange Online, Microsoft Entra ID, mailbox activity, suspicious email behaviour and incident response actions.

Validate the reported email

Review sign-ins and mailbox activity

Check inbox rules and OAuth persistence

Contain the account and protect finance

Why Business Email Compromise matters

BEC is dangerous because it often uses trusted identities, familiar language and real business context. The email may look legitimate because the attacker is using a real mailbox or a carefully impersonated sender.

BEC is an identity investigationThe key question is not only whether the email was suspicious. It is whether the sender mailbox, recipient mailbox or trusted relationship was compromised.

Financial fraud moves quicklyAttackers often target invoice changes, payment approvals, executive requests, payroll updates and vendor communication.

Mailbox evidence mattersInbox rules, forwarding, OAuth consent, sign-in activity and cloud activity can reveal what happened before and after the suspicious message.

The BEC incident response workflow

Agent Foskett investigates BEC by moving from the reported message to identity, mailbox, persistence and containment evidence.

1. Confirm the reportIdentify who reported the message, which mailbox sent it, who received it, the subject line, timestamps and the financial request being made.

2. Validate the emailDetermine whether the message was sent internally, spoofed externally, forwarded, replied to or created from a compromised mailbox.

3. Review authenticationInvestigate sign-ins for the suspected account, including unusual IP addresses, locations, failures, MFA behaviour and risky sign-ins.

4. Inspect mailbox persistenceLook for attacker-created inbox rules, forwarding settings, deleted messages, hidden movement and suspicious mailbox changes.

5. Correlate cloud and alert evidenceUse Defender XDR alerts, CloudAppEvents and identity telemetry to understand attacker activity after access.

6. Contain and recoverReset credentials, revoke sessions, remove persistence, notify affected stakeholders and preserve evidence for the post-incident review.

Step 1 — Find the reported message

Start with the message details supplied by the user, finance team or alert. Confirm whether the email exists in Defender XDR telemetry.

let TimeFrame = 14d;
let SubjectKeyword = "bank account";
EmailEvents
| where Timestamp > ago(TimeFrame)
| where Subject has SubjectKeyword
| project Timestamp,
          SenderFromAddress,
          SenderMailFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          DeliveryLocation,
          NetworkMessageId
| order by Timestamp desc

Step 2 — Identify all recipients

BEC rarely targets one person by accident. Determine who received the message and whether the attacker sent similar requests to multiple people.

let TimeFrame = 14d;
let SuspiciousSubject = "updated bank details";
EmailEvents
| where Timestamp > ago(TimeFrame)
| where Subject has SuspiciousSubject
| summarize Recipients = make_set(RecipientEmailAddress, 100),
            MessageCount = count(),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by SenderFromAddress,
         SenderMailFromAddress,
         Subject,
         DeliveryAction
| order by MessageCount desc

Step 3 — Review sign-ins for the sender mailbox

If the message came from a real internal mailbox, investigate whether that account showed suspicious authentication before the email was sent.

let TimeFrame = 14d;
let SenderAccount = "executive@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ SenderAccount
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp asc

Step 4 — Look for inbox rules and mailbox manipulation

Mailbox persistence is common in BEC investigations. Attackers may hide replies, forward messages or delete evidence automatically.

let TimeFrame = 14d;
let MailboxUser = "executive@contoso.com";
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where AccountDisplayName has MailboxUser or AccountId has MailboxUser
| where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "MailItemsAccessed", "Send", "Forward")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          IPAddress,
          DeviceType,
          RawEventData
| order by Timestamp desc

Step 5 — Correlate BEC activity with Defender alerts

A BEC case becomes stronger when email evidence, sign-in activity and Defender alerts line up in the same timeframe.

let TimeFrame = 14d;
let AccountsOfInterest = dynamic(["executive@contoso.com", "finance@contoso.com"]);
AlertEvidence
| where Timestamp > ago(TimeFrame)
| where AccountName in~ (AccountsOfInterest)
   or AccountUpn in~ (AccountsOfInterest)
| project Timestamp,
          AlertId,
          AccountName,
          AccountUpn,
          EntityType,
          EvidenceRole,
          DeviceName,
          RemoteIP
| order by Timestamp desc

Step 6 — Build the BEC timeline

A timeline helps explain when compromise may have started, when the fraudulent email was sent and what the attacker did afterwards.

let TimeFrame = 14d;
let UserToInvestigate = "executive@contoso.com";
let IdentityTimeline =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ UserToInvestigate
    | project Timestamp, EventType = "Identity", Account = AccountUpn, Detail = strcat(ActionType, " from ", IPAddress, " ", Location);
let MailTimeline =
    EmailEvents
    | where Timestamp > ago(TimeFrame)
    | where SenderFromAddress =~ UserToInvestigate
    | project Timestamp, EventType = "Email", Account = SenderFromAddress, Detail = strcat("Sent to ", RecipientEmailAddress, " | ", Subject);
union IdentityTimeline, MailTimeline
| order by Timestamp asc

Common BEC investigation clues

BEC investigations are strongest when multiple signals align across identity, mailbox and email telemetry.

Unusual successful sign-insThe sender account authenticated from a new location, unfamiliar IP address or suspicious hosting provider before the fraudulent message.

Inbox rules or forwardingRules that delete, hide, move or forward replies can help attackers maintain control of the conversation.

Financial languageLook for bank account changes, urgent payment requests, invoices, gift cards, payroll changes or vendor payment redirection.

OAuth consentA malicious or over-permissioned application can allow attackers to keep access after password resets.

User denialIf the sender denies sending the message, treat the account as potentially compromised until evidence proves otherwise.

Follow-on activityCloud file access, mailbox access, replies, forwarding and deleted messages help explain impact and scope.

Containment and remediation checklist

Use this checklist before closing a BEC incident.

Confirm the fraudulent messagePreserve the message, recipients, timestamps, headers and NetworkMessageId where available.

Protect the accountReset the password, revoke sessions, review MFA methods and remove suspicious authentication changes.

Remove mailbox persistenceDelete malicious inbox rules, disable external forwarding where needed and review mailbox delegates.

Review OAuth applicationsRemove suspicious consent grants and investigate application permissions.

Notify finance and stakeholdersConfirm whether payment changes were actioned and alert affected business teams.

Document the timelineRecord the initial access, fraudulent message, affected recipients, actions taken and lessons learned.

Related Agent Foskett Academy lessons

These lessons support BEC investigations.

Incident Response Workflow: Phishing InvestigationStart with the reported email and investigate delivery, clicks, attachments and containment.

Hunting Playbook: Credential TheftInvestigate suspicious authentication, token usage and compromised accounts.

Hunting Playbook: Malicious Inbox RulesDetect hidden forwarding, deletion and mailbox persistence after compromise.

Hunting Playbook: OAuth AbuseInvestigate persistent access through suspicious application consent.

Investigating EmailEventsUse EmailEvents to trace senders, recipients, delivery actions and message identifiers.

Building Reusable Hunting QueriesTurn repeated BEC investigation steps into reusable KQL workflows.

Coming next

The Incident Response Workflow series continues with compromised user account investigations.

Lesson 113 — Incident Response Workflow: Compromised User AccountNext, Agent Foskett investigates a user account compromise from initial alert through authentication review, token revocation, mailbox checks, endpoint pivots and recovery.

Why this mattersBEC investigations often begin with a suspicious email, but the deeper question is whether a trusted identity has been compromised and misused.

Final thought

Business Email Compromise is successful because it abuses trust.

Agent Foskett mindsetDo not stop at the message. Investigate the identity, the mailbox, the rules, the consent grants and the business process the attacker tried to manipulate.

Incident Response Workflow SeriesLesson 112 turns email, identity and mailbox telemetry into a repeatable BEC response process.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Incident Response Workflow Business Email Compromise in Microsoft Defender XDR

Agent Foskett Academy Lesson 112 teaches defenders how to investigate Business Email Compromise using Microsoft Defender XDR, Exchange Online, Microsoft Entra ID, mailbox telemetry, identity signals and KQL workflows.

Learn BEC investigation with KQL and Microsoft Defender XDR

Business Email Compromise investigations require analysts to validate suspicious messages, review sender identity, inspect mailbox activity, check inbox rules, review OAuth apps and contain compromised accounts.

Microsoft 365 Business Email Compromise incident response tutorial

This lesson explains how to investigate fraudulent payment requests, compromised mailboxes, suspicious sign-ins, mailbox forwarding, OAuth persistence and Defender XDR evidence during BEC incidents.