ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 80 • Capstone Investigation

Building a Complete Phishing Investigation in Microsoft Defender XDR.

At 8:14 AM the phishing email arrived.

At 8:18 AM a user clicked the embedded link.

Safe Links inspected the destination. One user continued.

A suspicious process started. Moments later, the device contacted an unfamiliar server.

Each event looked small on its own.

Together, they told the full story.

Agent Foskett was not investigating an email anymore. He was investigating an attack.

Start Lesson 80 Back to Academy
Agent Foskett Academy lesson building a complete phishing investigation in Microsoft Defender XDR
Lesson overview

Learn how to combine Microsoft Defender XDR telemetry to investigate a phishing attack from initial email delivery through user interaction, endpoint execution and outbound network communication.

Start with EmailEvents
Follow UrlClickEvents evidence
Pivot into endpoint process and network activity
Build the complete timeline

Why complete investigations matter

Microsoft Defender XDR investigations are rarely solved by one table. The strongest evidence appears when email, click, process, network and file telemetry are reviewed together.
Email shows what arrivedEmailEvents helps identify the sender, recipient, subject, delivery action and message identifiers involved in the phishing attack.
Click evidence shows user interactionUrlClickEvents helps identify who clicked, which URL was visited, whether Safe Links intervened and whether the user continued.
Endpoint evidence shows impactDeviceProcessEvents, DeviceNetworkEvents and DeviceFileEvents help determine whether the phishing attack resulted in execution, outbound communication or file activity.

The complete phishing investigation workflow

Agent Foskett follows the evidence from the first email to the final endpoint activity.
1. Did the email arrive?Use EmailEvents to confirm delivery, sender identity, recipient exposure and message identifiers.
2. Who received it?Use RecipientEmailAddress and NetworkMessageId to determine campaign scope and affected users.
3. Did anyone click?Use UrlClickEvents to identify users who interacted with URLs in the email.
4. Did Safe Links protect the user?Review ActionType, IsClickedThrough and UrlChain to understand click outcomes and redirects.
5. Did anything execute?Use DeviceProcessEvents to determine whether Office, PowerShell, script hosts or other suspicious processes started afterwards.
6. Did the device communicate externally?Use DeviceNetworkEvents to identify remote URLs, IP addresses, payload downloads and command-and-control activity.
7. Did suspicious files appear?Use DeviceFileEvents to investigate downloads, executables, scripts, archives and hashes written to disk.
8. Can the timeline be proven?Order the evidence chronologically to show delivery, click, execution, network activity and file creation.

Step 1 — Confirm the email delivery

Start with EmailEvents to prove the message arrived, who received it and which identifiers can be used for correlation.
step-1-email-delivery.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
EmailEvents
| where Timestamp > ago(24h)
| where Subject contains "Password expiry"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          NetworkMessageId,
          InternetMessageId,
          ReportId
| order by Timestamp asc

Step 2 — Identify URL click activity

Use UrlClickEvents to determine whether recipients clicked links associated with the suspicious message.
step-2-url-clicks.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
UrlClickEvents
| where Timestamp > ago(24h)
| project Timestamp,
          AccountUpn,
          Url,
          UrlChain,
          IsClickedThrough,
          ActionType,
          NetworkMessageId
| order by Timestamp asc

Step 3 — Correlate email delivery with click activity

Join EmailEvents and UrlClickEvents using NetworkMessageId to connect the delivered message with the user's click.
step-3-email-click-correlation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
EmailEvents
| join kind=inner (
    UrlClickEvents
) on NetworkMessageId
| project EmailTime = EmailEvents.Timestamp,
          ClickTime = UrlClickEvents.Timestamp,
          RecipientEmailAddress,
          SenderFromAddress,
          Subject,
          Url,
          UrlChain,
          IsClickedThrough,
          ActionType
| order by ClickTime asc

Step 4 — Look for process execution after the email

After a phishing email or attachment is opened, review suspicious endpoint processes around the same user and timeframe.
step-4-process-execution.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
EmailEvents
| join kind=inner (
    DeviceProcessEvents
) on $left.RecipientEmailAddress == $right.AccountUpn
| where DeviceProcessEvents.Timestamp between (EmailEvents.Timestamp .. EmailEvents.Timestamp + 1h)
| project EmailTime = EmailEvents.Timestamp,
          ProcessTime = DeviceProcessEvents.Timestamp,
          RecipientEmailAddress,
          DeviceName,
          Subject,
          FileName,
          InitiatingProcessFileName,
          ProcessCommandLine
| order by ProcessTime asc

Step 5 — Review outbound network activity

If suspicious processes executed, check whether the device contacted external infrastructure afterwards.
step-5-network-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
EmailEvents
| join kind=inner (
    DeviceNetworkEvents
) on $left.RecipientEmailAddress == $right.AccountUpn
| where DeviceNetworkEvents.Timestamp between (EmailEvents.Timestamp .. EmailEvents.Timestamp + 1h)
| project EmailTime = EmailEvents.Timestamp,
          NetworkTime = DeviceNetworkEvents.Timestamp,
          RecipientEmailAddress,
          DeviceName,
          Subject,
          InitiatingProcessFileName,
          RemoteUrl,
          RemoteIP
| order by NetworkTime asc

Step 6 — Check file activity

Use DeviceFileEvents to identify suspicious downloads, extracted archives, scripts or payloads created after the phishing activity.
step-6-file-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
DeviceFileEvents
| where Timestamp > ago(24h)
| where FileName has_any (".exe", ".js", ".vbs", ".lnk", ".zip", ".iso")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountUpn,
          FileName,
          FolderPath,
          SHA256,
          InitiatingProcessFileName
| order by Timestamp asc

How to read the complete timeline

A strong timeline should show the order of events and explain why each stage matters.
Delivery before interactionThe email must be confirmed before click, process or network activity can be confidently associated with the campaign.
Click before executionA click or attachment interaction helps explain why endpoint activity began shortly afterwards.
Execution before networkSuspicious process execution followed by outbound connections often indicates payload retrieval or command-and-control behaviour.
File activity closes the loopNew files, hashes and payloads can confirm what was delivered, downloaded or written during the attack.

Real-world investigation

The reported emailAn employee reports a Microsoft 365 password expiry email that appears legitimate and contains a sign-in link.
The user clickUrlClickEvents shows nine users clicked the link. Three users continued beyond Safe Links protection.
The endpoint activityDeviceProcessEvents shows PowerShell launching on one workstation shortly after the click.
The outbound connectionDeviceNetworkEvents shows the device contacting an unfamiliar external domain associated with the suspicious process.
The file evidenceDeviceFileEvents records an executable written to disk shortly after the network connection.
The conclusionThe investigation confirms the phishing email led to active endpoint compromise and requires containment, account review and remediation.

Investigation checklist

Email deliveredConfirm sender, recipient, subject, delivery action and message identifiers.
User clickedReview UrlClickEvents, UrlChain, ActionType and IsClickedThrough.
Process executedLook for suspicious Office child processes, scripts, PowerShell or command-line activity.
Network contactedReview RemoteUrl, RemoteIP and initiating process context.
File createdInspect downloaded files, hashes, archives and executables.
Timeline completedDocument the attack path from email delivery to endpoint impact.

Related Agent Foskett Academy lessons

Advanced UrlClickEvents InvestigationsInvestigate user clicks, Safe Links behaviour and phishing URL activity.
Investigating UrlChainTrace redirect chains from the original click to the final destination.
Investigating IsClickedThroughDetermine whether a user continued through Safe Links protection.
Investigating ActionType in UrlClickEventsUnderstand how Defender recorded the URL click outcome.
Correlating EmailEvents and UrlClickEventsConnect email delivery evidence with user click activity.
Correlating EmailEvents with DeviceProcessEventsDetermine what executed after a phishing email was delivered.
Correlating EmailEvents with DeviceNetworkEventsIdentify outbound connections after phishing activity.

Academy milestone

Congratulations. You have reached Lesson 80 of the Agent Foskett Academy.
80 lessons completedFrom your first KQL query to end-to-end Defender XDR phishing investigations, the Academy now covers a serious investigation journey.
Think like an investigatorThe goal is not just to query data. The goal is to connect evidence, test assumptions and build timelines that explain what really happened.
Agent Foskett continuesThis is not the end of the Academy. It is the point where table knowledge becomes real investigation practice.

Coming next

Lesson 81 — Advanced DeviceProcessEvents Investigations in Microsoft Defender XDRNext, Agent Foskett Academy expands endpoint investigation skills by exploring advanced DeviceProcessEvents techniques for suspicious process trees, parent-child activity and command-line evidence.
Why this mattersLesson 80 showed how phishing can lead to endpoint activity. Lesson 81 goes deeper into process evidence so defenders can understand exactly what executed and why it matters.

Final thought

A phishing email is not the whole incident. It is the first clue.
Agent Foskett mindsetDo not stop at the inbox. Follow the evidence through clicks, processes, network connections and files until the full story is clear.
The timeline told the storyWhen the events are placed in order, the investigation becomes easier to explain, defend and remediate.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Building a Complete Phishing Investigation in Microsoft Defender XDR

Agent Foskett Academy Lesson 80 teaches defenders how to build a complete phishing investigation in Microsoft Defender XDR.

Complete Defender XDR phishing investigation workflow

This capstone lesson explains how EmailEvents, UrlClickEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, NetworkMessageId, InternetMessageId, ReportId, UrlChain, IsClickedThrough and ActionType help defenders reconstruct a phishing attack from email delivery to endpoint compromise.