ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 79 • Phishing Investigation

Correlating EmailEvents with DeviceNetworkEvents in Microsoft Defender XDR.

The phishing email had been delivered.

The attachment was opened.

A suspicious process launched.

But Agent Foskett knew one final question remained.

Did the compromised device communicate with anything on the internet?

To uncover the next stage of the attack, he correlated EmailEvents with DeviceNetworkEvents.

Start Lesson 79 Back to Academy
Agent Foskett Academy lesson correlating EmailEvents with DeviceNetworkEvents in Microsoft Defender XDR
Lesson overview

Learn how to correlate EmailEvents with DeviceNetworkEvents to identify outbound connections after phishing email delivery, attachment execution or suspicious endpoint activity.

Review email delivery evidence
Identify outbound network activity
Connect users, devices and destinations
Build reliable phishing investigation timelines

Why email and network correlation matters

EmailEvents explains what was delivered. DeviceNetworkEvents helps reveal where a device communicated after the user interacted with the email or a payload executed.
It follows the attack pathAfter a phishing email is delivered, outbound network activity may reveal payload downloads, credential harvesting pages or command-and-control communication.
It connects users to devicesCorrelating recipient addresses with endpoint activity helps defenders understand which device generated suspicious connections after the email arrived.
It validates compromiseOutbound connections after suspicious execution can help confirm whether the phishing email led to active endpoint compromise.

The fields used in this lesson

RecipientEmailAddressThe mailbox that received the suspicious email.
SubjectThe email subject used to identify the phishing lure.
AccountUpnThe signed-in user associated with endpoint network activity.
DeviceNameThe endpoint that generated the network connection.
RemoteUrlThe remote domain or URL contacted by the device.
InitiatingProcessFileNameThe process responsible for the outbound connection.

Step 1 — Review recent email deliveries

Start with the email evidence and identify who received the suspicious message.
recent-email-deliveries.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
EmailEvents
| where Timestamp > ago(24h)
| project Timestamp,
          RecipientEmailAddress,
          SenderFromAddress,
          Subject,
          NetworkMessageId
| order by Timestamp desc

Step 2 — Review outbound network activity

Review recent device network connections and focus on destination, device and initiating process evidence.
recent-network-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
DeviceNetworkEvents
| where Timestamp > ago(24h)
| project Timestamp,
          DeviceName,
          AccountUpn,
          RemoteUrl,
          RemoteIP,
          InitiatingProcessFileName
| order by Timestamp desc

Step 3 — Correlate email and network activity by user and time

Use the recipient address from EmailEvents and the account context from DeviceNetworkEvents to identify network activity shortly after delivery.
email-to-network-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 (
    DeviceNetworkEvents
) on $left.RecipientEmailAddress == $right.AccountUpn
| where Timestamp1 between (Timestamp .. Timestamp + 30m)
| project EmailTime = Timestamp,
          NetworkTime = Timestamp1,
          RecipientEmailAddress,
          DeviceName,
          Subject,
          RemoteUrl,
          RemoteIP,
          InitiatingProcessFileName
| order by NetworkTime asc

Step 4 — Hunt for suspicious initiating processes

Focus on scripting engines and command interpreters that often appear after malicious attachments or payload execution.
suspicious-process-network.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
DeviceNetworkEvents
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "cmd.exe",
    "wscript.exe",
    "cscript.exe",
    "mshta.exe"
)
| project Timestamp,
          DeviceName,
          AccountUpn,
          InitiatingProcessFileName,
          RemoteUrl,
          RemoteIP

Step 5 — Summarise destinations contacted after email delivery

Summarise remote destinations to identify repeated domains, IP addresses or infrastructure contacted after the phishing email arrived.
post-email-destinations.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
EmailEvents
| join kind=inner (
    DeviceNetworkEvents
) on $left.RecipientEmailAddress == $right.AccountUpn
| where Timestamp1 between (Timestamp .. Timestamp + 1h)
| summarize Connections = count(),
            Devices = dcount(DeviceName),
            Users = dcount(RecipientEmailAddress)
          by RemoteUrl,
             RemoteIP
| order by Connections desc

Step 6 — Build the investigation timeline

Order the email and network evidence so the sequence can be reviewed clearly.
email-network-timeline.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 Timestamp1 between (Timestamp .. Timestamp + 1h)
| project EmailTime = Timestamp,
          NetworkTime = Timestamp1,
          RecipientEmailAddress,
          DeviceName,
          Subject,
          InitiatingProcessFileName,
          RemoteUrl,
          RemoteIP
| order by EmailTime asc, NetworkTime asc

How to read the results

Correlation does not automatically prove compromise. It provides a timeline that defenders must test against process, file and network evidence.
Check the timingConnections that occur shortly after delivery or execution are more interesting than unrelated background network activity.
Review the processThe initiating process can reveal whether the connection came from a browser, Office application, script engine or suspicious payload.
Validate the destinationRemoteUrl and RemoteIP evidence should be checked against reputation, threat intelligence and other Defender telemetry.

Common investigation uses

Payload downloadsIdentify whether a device downloaded additional content after a phishing attachment or link interaction.
Command-and-controlReview suspicious outbound communication that may indicate malware beaconing or attacker infrastructure.
Endpoint compromise assessmentDetermine whether the phishing email remained harmless or resulted in suspicious network activity from the endpoint.
Timeline reconstructionBuild a sequence from email delivery to execution and outbound communication.

Common mistakes

Assuming correlation proves causationA connection after an email may be related, but defenders still need process, file and destination context.
Ignoring normal browser trafficBrowsers generate many connections. Focus on suspicious processes, unusual destinations and timing around the email event.
Skipping endpoint process evidenceDeviceNetworkEvents is stronger when reviewed alongside DeviceProcessEvents, because the process explains why the connection happened.

What you learned

EmailEvents shows deliveryIt explains which suspicious message reached the user and when it arrived.
DeviceNetworkEvents shows communicationIt reveals remote destinations contacted by the endpoint after suspicious activity.
Correlation completes the timelineTogether, these tables help defenders follow a phishing attack from email delivery to outbound network activity.

Related Agent Foskett Academy lessons

Investigating DeviceNetworkEventsUnderstand outbound connections, remote IPs, ports, domains and suspicious network activity.
Correlating EmailEvents with DeviceProcessEventsDetermine what executed on a device after a phishing email was delivered.
Correlating EmailEvents and UrlClickEventsConnect email delivery evidence with URL click activity.
Investigating UrlChainTrace redirect chains from clicked links to final destinations.
Investigating ActionType in UrlClickEventsUnderstand how Defender recorded URL click outcomes.
Investigating NetworkMessageIdConnect related email, URL, click and attachment telemetry.

Coming next

Lesson 80 — Building a Complete Phishing Investigation in Microsoft Defender XDRNext, Agent Foskett Academy brings email, URL, process and network telemetry together into a complete end-to-end phishing investigation.
Why this mattersEmailEvents shows what arrived. DeviceNetworkEvents shows where the endpoint communicated afterwards. The capstone lesson connects the full story.

Final thought

A phishing investigation rarely ends at the inbox. Network telemetry helps defenders determine whether the endpoint communicated with suspicious infrastructure after the email arrived.
Agent Foskett mindsetDo not stop once the email is found. Follow the device network activity to understand whether the attack continued beyond delivery and execution.
Follow the network evidenceDeviceNetworkEvents turns endpoint communication into evidence that can be reviewed, tested and correlated with the phishing timeline.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Correlating EmailEvents with DeviceNetworkEvents in Microsoft Defender XDR

Agent Foskett Academy Lesson 79 teaches defenders how to correlate EmailEvents with DeviceNetworkEvents during Microsoft Defender XDR phishing investigations.

Learn email and network correlation in Defender XDR

This lesson explains how EmailEvents, DeviceNetworkEvents, RecipientEmailAddress, AccountUpn, DeviceName, RemoteUrl, RemoteIP and InitiatingProcessFileName help defenders follow a phishing attack from email delivery to outbound endpoint communication.