Agent Foskett Academy • Lesson 111 • Incident Response Workflow Series

Incident Response Workflow: Phishing Investigation in Microsoft Defender XDR.

The user reported the email.

The subject looked familiar. The sender looked convincing. The link looked like it belonged to a real service.

But Agent Foskett did not start with the screenshot.

He started with the evidence: who received it, where it landed, who clicked, what Defender saw and whether the attacker gained access after the message arrived.

Start Lesson 111 Back to Academy

Agent Foskett Academy lesson phishing investigation workflow in Microsoft Defender XDR

Lesson overview

Learn how to investigate a suspected phishing incident from the first report through message scoping, URL clicks, attachment analysis, identity checks, endpoint pivots and remediation.

Locate the original message

Scope recipients and delivery

Review clicks, attachments and execution

Contain, remediate and document

Why phishing investigations need a workflow

A phishing report is rarely just an email problem. It can become an identity, endpoint, mailbox, OAuth and data access investigation.

The message is only the starting pointA reported email tells you what the user saw. Defender telemetry tells you who received it, whether it was clicked and what happened next.

Scope mattersOne recipient is different from one hundred recipients. The first job is to determine delivery, exposure and user interaction.

Response depends on evidenceContainment decisions should be based on clicks, credential entry, malware execution, suspicious sign-ins and mailbox activity.

The phishing investigation workflow

Agent Foskett follows the evidence from the reported message to the full impact assessment.

1. Capture the reportRecord the reporting user, time, subject, sender, URLs, attachments and any user actions already known.

2. Locate the original emailUse EmailEvents to find the message, sender, recipient, NetworkMessageId, delivery action and delivery location.

3. Scope all recipientsIdentify everyone who received the same message or related campaign activity.

4. Review URLs and attachmentsUse EmailUrlInfo, EmailAttachmentInfo and UrlClickEvents to identify links, files and user interaction.

5. Pivot into endpoint and identityCheck whether a click led to process execution, suspicious sign-ins, OAuth consent or mailbox persistence.

6. Contain and remediateBlock indicators, remove messages, reset credentials, revoke sessions and document lessons learned.

Step 1 — Locate the original message

Start with the subject, sender or reporting user to find the message inside EmailEvents.

let TimeFrame = 7d;
let ReportedSubject = "invoice";
EmailEvents
| where Timestamp > ago(TimeFrame)
| where Subject has ReportedSubject
| project Timestamp,
          NetworkMessageId,
          SenderFromAddress,
          SenderMailFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          DeliveryLocation
| order by Timestamp desc

Step 2 — Scope all recipients

Once you have the NetworkMessageId or a reliable sender/subject pattern, identify everyone who received the campaign.

let TimeFrame = 7d;
let SuspiciousSender = "alerts@example.com";
EmailEvents
| where Timestamp > ago(TimeFrame)
| where SenderFromAddress =~ SuspiciousSender
| summarize RecipientCount = dcount(RecipientEmailAddress),
            Recipients = make_set(RecipientEmailAddress, 100),
            DeliveryActions = make_set(DeliveryAction, 20),
            DeliveryLocations = make_set(DeliveryLocation, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by SenderFromAddress,
         Subject
| order by RecipientCount desc

Step 3 — Review URLs in the message

A phishing message often becomes dangerous when the link is clicked, so extract the URLs connected to the campaign.

let TimeFrame = 7d;
let SuspiciousMessages =
    EmailEvents
    | where Timestamp > ago(TimeFrame)
    | where Subject has "invoice"
    | project NetworkMessageId;
EmailUrlInfo
| where Timestamp > ago(TimeFrame)
| where NetworkMessageId in (SuspiciousMessages)
| project Timestamp,
          NetworkMessageId,
          Url,
          UrlDomain
| order by Timestamp desc

Step 4 — Identify who clicked

UrlClickEvents helps determine whether users interacted with malicious or suspicious links after delivery.

let TimeFrame = 7d;
let SuspiciousDomains = dynamic(["example-login.com", "secure-update.example"]);
UrlClickEvents
| where Timestamp > ago(TimeFrame)
| where Url has_any (SuspiciousDomains)
| project Timestamp,
          AccountUpn,
          Url,
          ActionType,
          Workload,
          IPAddress,
          ThreatTypes
| order by Timestamp desc

Step 5 — Review attachments

If attachments were present, check filenames, hashes and whether the file appeared on endpoints.

let TimeFrame = 7d;
let SuspiciousMessages =
    EmailEvents
    | where Timestamp > ago(TimeFrame)
    | where Subject has "invoice"
    | project NetworkMessageId;
EmailAttachmentInfo
| where Timestamp > ago(TimeFrame)
| where NetworkMessageId in (SuspiciousMessages)
| project Timestamp,
          NetworkMessageId,
          FileName,
          FileType,
          SHA256,
          ThreatTypes,
          DetectionMethods
| order by Timestamp desc

Step 6 — Check endpoint execution after the click

If a user clicked or opened an attachment, pivot into process activity around the same timeframe.

let TimeFrame = 7d;
let UsersWhoClicked =
    UrlClickEvents
    | where Timestamp > ago(TimeFrame)
    | where ActionType has_any ("ClickAllowed", "ClickedThrough", "Allowed")
    | distinct AccountUpn;
DeviceProcessEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn in~ (UsersWhoClicked)
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "mshta.exe", "rundll32.exe")
| project Timestamp,
          DeviceName,
          AccountUpn,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp desc

Step 7 — Check for account compromise

Credential phishing requires identity validation. Review sign-ins after the click or credential submission window.

let TimeFrame = 7d;
let UsersWhoClicked =
    UrlClickEvents
    | where Timestamp > ago(TimeFrame)
    | distinct AccountUpn;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn in~ (UsersWhoClicked)
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp desc

Step 8 — Build a phishing incident timeline

A timeline turns separate Defender events into a clear story that responders can act on.

let TimeFrame = 7d;
let TargetUser = "user@contoso.com";
let EmailTimeline =
    EmailEvents
    | where Timestamp > ago(TimeFrame)
    | where RecipientEmailAddress =~ TargetUser
    | project Timestamp, EventType = "Email", Detail = Subject, Entity = SenderFromAddress;
let ClickTimeline =
    UrlClickEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ TargetUser
    | project Timestamp, EventType = "URL Click", Detail = Url, Entity = ActionType;
let SignInTimeline =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ TargetUser
    | project Timestamp, EventType = "Sign-in", Detail = IPAddress, Entity = ActionType;
union EmailTimeline, ClickTimeline, SignInTimeline
| order by Timestamp asc

Containment and remediation actions

The response should match the evidence. Do not treat a delivered message, a clicked link and a compromised account as the same severity.

Remove or quarantine messagesUse Microsoft Defender actions or Exchange tools to remove malicious messages from affected mailboxes.

Block sender and URLsBlock malicious domains, URLs, senders and file hashes where appropriate.

Reset credentials when neededIf credential compromise is suspected, reset the password, revoke sessions and review MFA methods.

Review mailbox persistenceCheck for malicious inbox rules, forwarding settings and delegated access after credential theft.

Review OAuth consentConfirm whether the user granted permissions to suspicious applications after clicking the phishing link.

Document the timelineRecord first seen, last seen, recipients, clicks, impact, containment and prevention actions.

Investigation checklist

Use this checklist before closing a phishing incident.

Was the original message located?Confirm the sender, subject, NetworkMessageId, recipient and delivery details.

Who received it?Scope every recipient and determine whether the message reached the inbox, junk, quarantine or was blocked.

Who clicked?Review UrlClickEvents and Safe Links outcomes for every recipient.

Were attachments involved?Check filenames, hashes, threat types and endpoint file activity.

Was identity compromised?Review sign-ins, MFA changes, session activity and risky authentication after the click.

Was persistence created?Check inbox rules, OAuth applications, forwarding and suspicious mailbox access.

Related Agent Foskett Academy lessons

These lessons support complete phishing investigation workflows.

Investigating EmailEventsFind message delivery, sender, recipient, subject and campaign evidence.

Investigating EmailUrlInfoExtract URLs and domains from suspicious messages.

Investigating UrlClickEventsDetermine whether users clicked suspicious links.

Hunting Playbook: Credential TheftValidate whether phishing led to compromised credentials.

Hunting Playbook: Malicious Inbox RulesCheck mailbox persistence after compromise.

Building Reusable Hunting QueriesTurn phishing investigation steps into repeatable Defender XDR workflows.

Coming next

The Incident Response Workflow series continues with business email compromise.

Lesson 112 — Incident Response Workflow: Business Email CompromiseNext, Agent Foskett investigates BEC activity, mailbox access, suspicious rules, impersonation, financial redirection and account takeover evidence.

Why this mattersPhishing investigations often reveal wider compromise. Business email compromise is where identity, mailbox and financial fraud evidence come together.

Final thought

A phishing email is not the incident. It is the doorway into the incident.

Agent Foskett mindsetDo not stop when you find the email. Follow the delivery, the click, the identity activity and the timeline until the story is complete.

Incident Response Workflow SeriesLesson 111 begins the next Academy phase: complete Microsoft Defender XDR incident response workflows.

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

Incident Response Workflow Phishing Investigation in Microsoft Defender XDR

Agent Foskett Academy Lesson 111 teaches defenders how to investigate phishing incidents using Microsoft Defender XDR, EmailEvents, EmailUrlInfo, EmailAttachmentInfo, UrlClickEvents, IdentityLogonEvents and KQL workflows.

Learn phishing incident response with KQL and Microsoft Defender XDR

Phishing investigation workflows help Microsoft security analysts locate suspicious messages, scope recipients, analyse URL clicks, review attachments, validate identity compromise and perform containment.

Microsoft Defender XDR phishing investigation tutorial

This lesson explains how to investigate reported phishing emails, determine delivery, identify users who clicked, review endpoint activity, check account compromise and document incident response actions.