ACSC Logo
© GEMXIT
GEMXIT Logo
Microsoft Defender • KQL • Threat Hunting • Complete Guide

Microsoft Defender KQL Threat Hunting Complete Guide

This is the practical hub for Microsoft Defender KQL threat hunting across email, identity, endpoint and cloud activity.

Use these Defender XDR queries to investigate EmailEvents, DMARC failures, URL clicks, suspicious sign-ins, endpoint behaviour and post-delivery activity.

The goal is simple: move beyond alert chasing and use KQL to prove what happened, who was affected, and what to check next.

Discuss your environment Back to briefings
Microsoft Defender KQL threat hunting complete guide by GEMXIT
Complete guide summary

A central Microsoft Defender KQL threat hunting guide for analysts, administrators and business owners who want to understand what the security data is really showing.

EmailEvents, AuthenticationDetails and UrlClickEvents
Identity, endpoint and cloud activity pivots
Real investigation flow, not just isolated queries
🚨 What this means for your environment
Even if there are no high severity alerts:

• Suspicious email may already have been delivered
• Users may have clicked links without a major incident being raised
• Identity and endpoint behaviour may contain the missing evidence

👉 This is why threat hunting matters — the logs often know before the alerts do

👉 Or explore how we approach Microsoft security operations
Book a security review →

Quick Answer

Microsoft Defender KQL threat hunting uses Defender XDR telemetry across EmailEvents, UrlClickEvents, IdentityLogonEvents, DeviceProcessEvents and CloudAppEvents to investigate suspicious activity, validate alerts and uncover evidence that traditional dashboards may miss.

What you'll learn on this page

Use this complete guide as a Defender XDR hunting path. Start with email evidence, then pivot into clicks, identity, endpoint behaviour, cloud activity and response decisions.
1. Email sender mismatchHunt visible sender and Mail From alignment issues. 2. DMARC failure analysisInvestigate dmarc=fail and delivery outcomes. 3. URL click pivotsJoin EmailEvents to UrlClickEvents. 4. Identity after clickReview sign-ins around suspicious user interaction. 5. Endpoint behaviourFind suspicious PowerShell and process activity. 6. Cloud activityReview file access and after-hours patterns.

What is Microsoft Defender KQL threat hunting?

KQL threat hunting is the process of asking security questions directly of your Microsoft Defender data. Instead of waiting for an alert, you query behaviour across email, identity, endpoint and cloud activity to find patterns that should not exist.
Start with behaviour Something looks unusual: a sender mismatch, a DMARC failure, a click, a strange sign-in, or an endpoint command line.
Ask a better question Did this user normally do this? Was the email really trusted? Did the click lead to identity or device activity?
Follow the evidence KQL lets you move from one signal to the next: message → recipient → click → sign-in → endpoint → response.

How to read these KQL queries

The real value is not just copying a query. The real value is knowing what the result means, what is normal, what is suspicious, and where to pivot next.
What the query finds Each query is designed to surface a behaviour: sender mismatch, authentication failure, click activity, sign-in activity or suspicious process execution.
What to look for Look for delivered messages, repeated subjects, unfamiliar domains, unusual IP addresses, unexpected applications or activity outside normal hours.
When to investigate If the behaviour does not match the user, the sender, the device, the time or the business process, dig deeper.

Email threat hunting: sender mismatch and spoofing

Email spoofing often starts with a trust problem: the address the user sees does not match the underlying sending path. This query surfaces visible sender and envelope sender mismatches in EmailEvents.
email-sender-alignment-threat-hunt.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
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
What this findsMessages where the visible sender domain does not match the Mail From domain.
Why it mattersMismatch is not always malicious, but it becomes important when combined with failed authentication, trusted branding or delivery.
Best next stepCheck AuthenticationDetails, DeliveryAction, recipient spread and URL click activity.

👉 Deep dive → Microsoft Defender email spoofing detection with KQL.

DMARC failure analysis

DMARC failures deserve context. A failed DMARC result may be normal third-party sending, broken forwarding, poor alignment, or a spoofing attempt. The key is to understand delivery, recipients and user interaction.
dmarc-failures-threat-hunt.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
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
What this findsMessages where AuthenticationDetails contains dmarc=fail.
What to checkDeliveryAction, SenderFromDomain, SenderMailFromDomain, subject, recipient and NetworkMessageId.
Best pivotMove to URL clicks if the message was delivered or looked trusted.

👉 Deep dive → DMARC failures explained with KQL.

Pivot from suspicious email to URL clicks

A suspicious email is one thing. A suspicious email with a user click changes the risk. This query joins suspicious message telemetry to UrlClickEvents using NetworkMessageId.
email-to-url-click-threat-hunt.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
let SuspiciousMessages =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail", "spoof")
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction;
SuspiciousMessages
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
What this findsUsers who interacted with suspicious or failed-authentication messages.
What to reviewClickAllowed, blocked clicks, suspicious domains, repeated clicks and timing after delivery.
Next stepUse the AccountUpn and ClickTime to review sign-ins and device activity.

Identity threat hunting after a click

After a user clicks, the next question is whether their identity behaviour changed. This query connects click activity to sign-in activity around the same time window.
click-to-identity-threat-hunt.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
let ClickedUsers =
UrlClickEvents
| where Timestamp > ago(7d)
| where ActionType has_any ("ClickAllowed", "UrlScanInProgress")
| project AccountUpn, ClickTime = Timestamp, Url;
ClickedUsers
| join kind=inner (
    IdentityLogonEvents
    | where Timestamp > ago(7d)
    | project AccountUpn, SignInTime = Timestamp, IPAddress, Location, Application, LogonType
) on AccountUpn
| where SignInTime between ((ClickTime - 2h) .. (ClickTime + 6h))
| order by ClickTime desc
What this findsSign-ins around the same time as a suspicious click.
What to look forNew locations, unfamiliar IPs, unexpected applications or timing that does not match the user.
Best next stepReview Conditional Access, MFA behaviour, session activity and device signals.

👉 Related guide → Using impossible travel sign-ins in investigations.

Endpoint threat hunting: suspicious PowerShell

PowerShell is not automatically malicious. But encoded commands, hidden execution, download cradles and suspicious command lines should be reviewed.
suspicious-powershell-threat-hunt.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
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
    "-enc", "-encodedcommand", "iex", "downloadstring",
    "invoke-webrequest", "frombase64string", "hidden"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    FileName,
    ProcessCommandLine,
    InitiatingProcessFileName
| order by Timestamp desc
What this findsPowerShell executions with obfuscation, download behaviour or suspicious flags.
Why it mattersAttackers often use legitimate tools. The command line tells the story.
Best pivotReview the initiating process, device, account and any network activity around the same time.

Cloud activity threat hunting: after-hours file access

Not every incident starts with malware. Sometimes the first useful signal is file activity that does not match the user’s normal working pattern.
after-hours-file-activity-threat-hunt.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
CloudAppEvents
| where Timestamp > ago(14d)
| where ActionType has_any ("FileDownloaded", "FileAccessed")
| extend HourOfDay = datetime_part("hour", Timestamp)
| where HourOfDay < 6 or HourOfDay > 20
| project
    Timestamp,
    AccountDisplayName,
    AccountId,
    IPAddress,
    Application,
    ActionType,
    ObjectName
| order by Timestamp desc
What this findsFile downloads or access events outside expected business hours.
Why it mattersData access behaviour can reveal compromise or insider risk even when malware is not present.
Best pivotCompare IP address, location, device, file sensitivity and user history.

Defender XDR Tables Used In This Guide

These are the primary Microsoft Defender XDR tables referenced throughout this investigation workflow.
TablePurpose
EmailEventsEmail delivery and authentication analysis
UrlClickEventsUser interaction with email links
IdentityLogonEventsAuthentication and sign-in investigations
DeviceProcessEventsProcess execution and endpoint behaviour
CloudAppEventsCloud activity and file access
PostDeliveryEventsPost-delivery remediation and message actions

The real investigation flow

The strongest investigations do not stop at one query. They follow the evidence across Microsoft Defender and Microsoft 365 until the activity makes sense.
1. EmailStart with delivery, sender alignment, DMARC, SPF, DKIM and message metadata.
2. ClickCheck whether the message led to user interaction through UrlClickEvents.
3. IdentityReview sign-ins, sessions, IP address, location and application use after interaction.
4. EndpointLook for unusual process execution, suspicious scripts and device-level behaviour.
5. Cloud activityReview file downloads, mailbox activity and after-hours access patterns.
6. ResponseDecide whether this is benign, misconfiguration, suspicious activity or confirmed compromise.

What dashboards miss

Most organisations already have the tools. But they struggle to interpret the data. Modern Microsoft security investigations often fail because teams focus only on high severity alerts while ignoring the quieter telemetry surrounding delivery, authentication, clicks and identity behaviour.
Low severity does not mean low risk A delivered phishing email, informational alert or unusual sign-in may still become a major compromise when correlated together.
Delivered messages matter Many investigations stop once spoofing or DMARC failures are identified. The more important question is whether the message reached the user and triggered interaction.
Correlation changes the story EmailEvents, UrlClickEvents, IdentityLogonEvents and endpoint telemetry together reveal far more than any single alert ever could.

Understanding AuthenticationDetails

AuthenticationDetails is one of the most important fields in Microsoft Defender XDR email investigations. It explains how the message authenticated, whether alignment failed, and whether the sender identity should be trusted.
SPF, DKIM and DMARC AuthenticationDetails often contains the real evidence behind email trust failures including spf=fail, dkim=fail and dmarc=fail.
DMARC fail does not always mean blocked Messages can still be delivered due to forwarding behaviour, policy configuration, allow rules or partial alignment.
Context matters The investigation should combine authentication results with delivery outcome, URL clicks, identity behaviour and user impact.

When the inbox changes after delivery

Not every dangerous message is blocked immediately. Microsoft Defender may later quarantine or remediate messages after additional intelligence becomes available. Post-delivery visibility is critical.
post-delivery-remediation-hunt.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
PostDeliveryEvents
| where Timestamp > ago(30d)
| project
    Timestamp,
    RecipientEmailAddress,
    Subject,
    Action,
    ActionTrigger,
    NetworkMessageId
| order by Timestamp desc
What this finds Messages that were later quarantined, removed or remediated after initial delivery.
Why it matters The inbox can change after delivery. A message that looked legitimate earlier may later be confirmed malicious.
Best next pivot Correlate the message with UrlClickEvents, sign-ins and user activity before remediation occurred.

Complete Defender XDR investigation path

A complete KQL threat hunt follows the evidence across tables instead of stopping at the first result.
1. Start with the signalEmail delivery, DMARC failure, click activity, sign-in anomaly, process execution or cloud access.
2. Confirm the evidenceProject the fields that prove time, user, device, sender, recipient, process or object activity.
3. Pivot with intentMove from EmailEvents to UrlClickEvents, then into identity, endpoint and cloud activity where needed.
4. Look for repetitionUse summarize to identify repeated senders, users, devices, IPs, subjects or processes.
5. Decide impactAsk whether the message was delivered, clicked, signed into, executed or used to access data.
6. Improve controlsUse findings to improve Defender tuning, Conditional Access, DMARC, endpoint hardening and investigation playbooks.

Related Agent Foskett investigation clusters

These pages connect this complete guide to the strongest Microsoft Defender and KQL topic clusters on the site.
EmailEvents KQL GuideCopy-ready email investigation queries for spoofing, DMARC failures, delivery and click pivots. Email Spoofing KQL InvestigationInvestigate spoofed email, sender alignment and suspicious authentication evidence. DMARC Failures KQLReview dmarc=fail, SPF, DKIM, delivery outcomes and URL click pivots. The Email Came From MeA practical case showing why visible sender identity does not prove trust. The User Passed MFA But It Wasn't Really ThemMove from identity success to session and access investigation. The Process Tree Told The Real StoryFollow endpoint process evidence when the alert alone is not enough.

Learn the KQL fundamentals behind this guide

These Academy lessons support the KQL techniques used throughout the complete guide.
What is KQL?Start with how KQL helps security teams ask better questions of Defender data. Microsoft Security TablesUnderstand EmailEvents, UrlClickEvents, IdentityLogonEvents, DeviceProcessEvents and CloudAppEvents. Filtering KQL ResultsUse where filters to focus on suspicious behaviour. Choosing Useful ColumnsProject the evidence fields that make investigations readable. Connecting Tables with joinCorrelate email, click, identity and endpoint evidence. Building Investigation TimelinesPut events in order and tell the story clearly.

Frequently asked questions

What is Microsoft Defender KQL threat hunting?

It is the process of using KQL in Microsoft Defender XDR advanced hunting to query email, identity, endpoint and cloud telemetry for suspicious behaviour before or beyond alerts.

Which Defender tables are useful for threat hunting?

Common starting tables include EmailEvents, UrlClickEvents, IdentityLogonEvents, DeviceProcessEvents, DeviceNetworkEvents, CloudAppEvents and PostDeliveryEvents.

How do I pivot from email to identity evidence?

Start with EmailEvents, use NetworkMessageId to join to UrlClickEvents, then use the clicked account and timestamp to review IdentityLogonEvents around the same time.

Why does threat hunting matter if Defender already creates alerts?

Alerts are important, but many investigations require context. KQL helps correlate quiet telemetry such as delivery, clicks, sign-ins, process execution and cloud access into one story.

Continue your investigation

This guide connects the core pages across the GEMXIT Microsoft Defender, Entra ID and KQL threat hunting investigation ecosystem.
Email spoofing investigations Compare sender alignment, spoofing indicators, AuthenticationDetails and URL click behaviour.
DMARC failure hunting Investigate dmarc=fail results, delivery decisions, sender alignment and hidden email trust failures.
Modern threat investigations Explore how modern attacks increasingly target identities, sessions and trusted access rather than traditional malware alone.
KQL threat hunting hub Explore broader KQL investigation workflows, Defender XDR telemetry and practical Microsoft security hunting examples.

Related investigations → The Email Came From Me , MFA Session Hijacking , The Session Token Never Expired and When Nothing Looks Wrong .

Need help with Microsoft Defender KQL threat hunting?
Running queries is one thing. Knowing what matters is another. GEMXIT helps organisations review Microsoft Defender signals, Sentinel visibility, Microsoft 365 email security, identity behaviour and practical threat hunting workflows.
Book a Security Review →
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Microsoft Defender KQL Threat Hunting Complete Guide

A complete Microsoft Defender KQL threat hunting guide covering EmailEvents, AuthenticationDetails, UrlClickEvents, identity pivots, endpoint process activity and cloud activity investigation workflows.

Microsoft Defender XDR KQL Examples

This page targets technical searches around Microsoft Defender KQL, threat hunting, EmailEvents, dmarc=fail, sender alignment, URL click investigation, suspicious PowerShell and identity investigation.

GEMXIT Microsoft Security Operations

GEMXIT uses Microsoft Defender, Sentinel, Entra ID and Microsoft 365 security data to support practical security operations, threat hunting, email security reviews and response planning.