ACSC Logo
© 2026 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.

It brings together real-world investigation workflows across email security, DMARC failures, URL click activity, identity pivots, endpoint behaviour and cloud activity.

The goal is simple: move beyond alert chasing and use KQL to prove what happened, who was affected, whether the activity was delivered or clicked, 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 →

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.

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.

Continue your investigation

This complete guide connects the key pages in the GEMXIT Microsoft Defender and KQL threat hunting library.
Email spoofing detectionCompare sender alignment, spoofing indicators and URL click behaviour.
DMARC failuresInvestigate dmarc=fail results, delivery decisions and sender alignment.
KQL threat hunting hubExplore the broader KQL threat hunting guide and investigation examples.

Related case studies → The email came from me… but I never sent it and MFA session hijacking.

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 2026

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.