ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft Defender XDR • UrlClickEvents

The User Clicked The Link Three Days Later

The email arrived on Monday.

No alert. No incident. No reason to investigate.

It sat quietly in the inbox for three days.

Then somebody clicked the link.

The delivery was not the problem. The click was.

This Agent Foskett investigation explores how defenders can use Microsoft Defender XDR, EmailEvents, UrlClickEvents, NetworkMessageId and KQL to investigate suspicious links long after the original email was delivered.

Discuss URL click investigations Back to Investigation Hub
Agent Foskett investigates delayed URL clicks in Microsoft Defender XDR
Briefing summary

A delivered email may not become dangerous until the user clicks the link. UrlClickEvents helps defenders prove when the interaction happened and connect it back to the original message.

Find delayed user clicks
Correlate clicks with delivered emails
Pivot to post-click activity
🚨 A delayed click can turn an old email into a live incident.
The message may have been delivered days earlier, but the risk begins when the user interacts with the link. UrlClickEvents can reveal the moment the investigation changed.
Book a security review →

Why delayed clicks matter

Security teams often investigate the moment an email is delivered, but user interaction can happen hours or days later. That delayed click can be the real start of the compromise timeline.
The email may look oldA message delivered days ago can still become dangerous if the user opens it later and follows the link.
The click changes the riskOnce a user clicks, the investigation moves from email delivery into user behaviour, URL reputation, browser activity and possible credential exposure.
The timeline proves the storyEmailEvents and UrlClickEvents together can show when the email arrived, when it was clicked and which user interacted with the link.

First hunt: find recent URL clicks

Start with UrlClickEvents. This shows user click activity, the URL involved, the action result and the NetworkMessageId that can connect the click back to the original email.
find-recent-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(7d)
| project ClickTime = Timestamp,
          AccountUpn,
          Url,
          ActionType,
          NetworkMessageId,
          IPAddress,
          ThreatTypes
| order by ClickTime desc
What to reviewLook at the clicking user, click time, destination URL, action type and whether the click can be linked back to a delivered email.
Why it mattersA link clicked days later may be missed if the investigation only focuses on the original delivery event.
Best next pivotUse NetworkMessageId to connect the click back to EmailEvents and identify the sender, subject and delivery outcome.

Second hunt: connect the click back to the email

NetworkMessageId is the pivot that can connect UrlClickEvents to EmailEvents. This helps prove which email delivered the link that was clicked.
url-click-to-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
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
UrlClickEvents
| where Timestamp > ago(7d)
| project ClickTime = Timestamp,
          AccountUpn,
          Url,
          ClickAction = ActionType,
          NetworkMessageId
| join kind=leftouter (
    EmailEvents
    | project EmailTime = Timestamp,
              NetworkMessageId,
              SenderFromAddress,
              RecipientEmailAddress,
              Subject,
              DeliveryAction
) on NetworkMessageId
| order by ClickTime desc

When a delayed click deserves deeper investigation

Not every click is malicious. The investigator mindset is to determine whether the click fits normal behaviour or whether it connects to suspicious sender, authentication or post-click activity.
Suspicious sender contextReview sender alignment, AuthenticationDetails, SpoofedDomain indicators, DMARC results and whether the sender was expected.
Unusual click timingA click at night, on a weekend or days after delivery may change the investigation timeline and user interview questions.
Post-click behaviourCheck for new sign-ins, OAuth consent, mailbox rules, file downloads, endpoint activity or suspicious cloud application events after the click.

Third hunt: calculate the delay between delivery and click

The delay matters. A link clicked three days later can explain why the original email did not appear urgent at the time of delivery.
email-delivery-to-click-delay.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
  17. 17
  18. 18
  19. 19
  20. 20
EmailEvents
| where Timestamp > ago(14d)
| project EmailTime = Timestamp,
          NetworkMessageId,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject
| join kind=inner (
    UrlClickEvents
    | project ClickTime = Timestamp,
              NetworkMessageId,
              AccountUpn,
              Url,
              ActionType
) on NetworkMessageId
| extend DelayHours = datetime_diff("hour", ClickTime, EmailTime)
| order by DelayHours desc

Fourth hunt: look for activity after the click

Once a user clicks, the next question is what happened afterwards. Look for sign-ins, device events, mailbox activity or cloud activity after the click time.
post-click-signin-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
let Clicks = UrlClickEvents
| where Timestamp > ago(7d)
| project ClickTime = Timestamp, AccountUpn, Url, NetworkMessageId;
Clicks
| join kind=leftouter (
    AADSignInEventsBeta
    | where Timestamp > ago(7d)
    | project SignInTime = Timestamp, AccountUpn, IPAddress, City, Country, Application
) on AccountUpn
| where SignInTime between (ClickTime .. (ClickTime + 6h))
| order by ClickTime desc

What delayed click telemetry can prove

UrlClickEvents does not prove compromise by itself. It proves user interaction. When that interaction connects to suspicious email, authentication weakness or post-click activity, the evidence becomes much stronger.
The user interactedThe click confirms that the message was not only delivered. It was opened and acted upon.
The timeline shiftedThe incident may not begin when the email arrived. It may begin when the link was clicked.
The pivot is availableNetworkMessageId can connect the user click back to the original sender, subject, recipient and delivery action.

The Agent Foskett investigator mindset

Do not stop at delivery. Do not stop because the email is old. Follow the user interaction and rebuild the timeline from delivery to click to post-click activity.
Ask when the risk beganWas the risk created when the email arrived, or when the user finally clicked the link?
Follow the messageUse EmailEvents, UrlClickEvents, AuthenticationDetails and identity telemetry together instead of treating them as separate logs.
Correlate weak signalsA delivered email, failed authentication, a delayed click and a strange sign-in together can explain what no single alert could.

How GEMXIT approaches URL click investigations

GEMXIT helps organisations use Microsoft Defender XDR telemetry to move beyond simple email delivery checks and understand what users actually did after suspicious messages reached the inbox.
We review click visibilityWe help check whether UrlClickEvents, EmailEvents, Safe Links and Defender telemetry are available and useful for investigations.
We build hunting logicWe help connect EmailEvents, UrlClickEvents, AuthenticationDetails, identity telemetry and endpoint telemetry into practical KQL workflows.
We improve response readinessWe help teams understand when to purge email, warn users, block URLs, reset credentials, revoke sessions and investigate post-click activity.
The email arrived days ago. The click happened now.
GEMXIT helps organisations investigate Microsoft Defender XDR URL click telemetry, EmailEvents, NetworkMessageId pivots, user behaviour and KQL hunting workflows.
Contact GEMXIT

Final thought

The email arrived quietly.

Nothing happened on Monday.

Nothing happened on Tuesday.

Nothing happened on Wednesday.

Then the user clicked.

The old message became a new incident.

The delivery was history. The click was evidence.
At GEMXITWe help organisations investigate Microsoft Defender XDR, Microsoft Sentinel, Entra ID, email telemetry, user clicks, URL behaviour and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Was the email delivered?”

It is: “When did the user interact with it, and what happened next?”

Continue the investigation with The Link Was Clicked After The Email Was Delivered, The Inbox Rule Hid The Evidence, The Disney Email Wasn’t From Disney, EmailEvents KQL Guide, Investigating EmailEvents in Microsoft Defender XDR, SpoofedDomain and EmailEvents in Microsoft Defender, Microsoft Defender KQL Threat Hunting Complete Guide, Microsoft Defender and the GEMXIT Security Review.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The User Clicked The Link Three Days Later

This Agent Foskett investigation explains how Microsoft Defender XDR, EmailEvents, UrlClickEvents, NetworkMessageId and KQL can reveal when users click suspicious links days after the original email was delivered.

Microsoft Defender XDR UrlClickEvents investigation

GEMXIT helps organisations investigate delivered email, delayed user clicks, suspicious URLs, NetworkMessageId pivots, EmailEvents, UrlClickEvents and Microsoft Defender Advanced Hunting telemetry.

EmailEvents, NetworkMessageId and UrlClickEvents threat hunting

NetworkMessageId can help defenders connect delivered emails to URL click activity, user interaction, suspicious destinations and post-click investigation workflows in Microsoft Defender XDR.