ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Microsoft Defender • KQL • Threat Hunting • Real Examples

Microsoft Defender KQL Threat Hunting Guide

Nothing triggered an alert.

But the data already knew.

This guide brings together practical Microsoft Defender XDR hunting examples using KQL, EmailEvents, AuthenticationDetails, spoofed domain checks, UrlClickEvents and identity pivots. It is designed for real-world investigation, not just theory.

At GEMXIT, we use KQL to move beyond alert chasing and into behaviour-based investigation across security operations, Microsoft Defender, identity and access, and broader Microsoft Security posture.

Discuss your environment Back to briefings
Microsoft Defender KQL threat hunting guide by Agent Foskett
Guide summary

This page is a practical KQL threat hunting hub for Microsoft Defender XDR. It focuses on the exact investigation paths analysts use when something feels wrong but no obvious alert explains it.

EmailEvents and AuthenticationDetails
Spoofed domain and sender alignment checks
Real pivots into clicks, sign-ins and behaviour
🚨 What this means for your environment
Even if nothing has triggered a major alert:

• Suspicious activity may already exist across email, identity or endpoints
• Low-confidence signals may be getting ignored or missed entirely
• Attack paths may be developing without being fully understood

👉 This is exactly what we uncover during Microsoft 365 security and threat hunting assessments

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

Why this guide exists

People searching for spoofeddomain, EmailEvents, AuthenticationDetails and KQL are usually not browsing casually. They are investigating something. An email looked wrong. A user clicked something. A sender looked trusted. Or the logs showed a pattern that deserved a second look.
No alert triggered The activity may look clean from an alert perspective, but threat hunting asks a better question: does the behaviour make sense?
The email story does not line up A message can look legitimate to the user while SPF, DKIM, DMARC, sender alignment or authentication details tell a different story.
KQL connects the evidence The real value appears when email, URL clicks, sign-ins, endpoint activity and user behaviour are connected into one investigation path.

How to read these KQL queries

These queries are not just for copying and pasting. The real value comes from understanding what they are showing you, why the signal matters, and where to pivot next.
Start with the table EmailEvents, UrlClickEvents, IdentityLogonEvents, CloudAppEvents and DeviceProcessEvents each tell a different part of the story.
Look for behaviour Focus on mismatched domains, failed authentication, unusual timing, repeated senders, unexpected clicks and authentication activity that does not fit the user.
Pivot with purpose Move from email to click, from click to sign-in, from sign-in to device, and from device evidence into a practical response decision.
Agent Foskett rule

Do not stop when a query returns results. Ask what the results mean, whether the behaviour matches the user, and what evidence should be checked next.

Start with failed email authentication

This is the practical starting point for many Microsoft Defender email investigations. It surfaces messages where SPF, DKIM or DMARC failed and provides the key fields needed to understand the sender, recipient, subject and delivery result.
email-authentication-failures.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 AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| project
                            Timestamp,
                            SenderFromAddress,
                            SenderFromDomain,
                            SenderMailFromAddress,
                            SenderMailFromDomain,
                            RecipientEmailAddress,
                            Subject,
                            AuthenticationDetails,
                            ThreatTypes,
                            DeliveryAction
| order by Timestamp desc
What this finds Messages where authentication failed and the sender identity deserves closer review.
Why it matters Authentication failures are not always malicious, but they are often the first crack in the trust story.
Best pivot Move next into sender alignment, recipient targeting, URL clicks and sign-in activity around the same time.
How to read this query
  • Focus on AuthenticationDetails, especially SPF, DKIM or DMARC failures.
  • Check whether DeliveryAction shows the message was delivered, blocked, junked or quarantined.
  • Review the sender, recipient and subject together. One field rarely tells the full story.

👉 If authentication failed and the message was delivered, that is where the investigation should start.

Next step → Review DMARC failure hunting or deep dive into spoofing detection.

Hunt for spoofed domain signals

The spoofeddomain keyword often appears in Defender hunting scenarios where analysts are trying to understand whether a message used a forged sender domain, failed authentication or suspicious alignment. This query keeps the output simple and investigation-friendly.
spoofeddomain-emailevents.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
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "spoof"
                            or AuthenticationDetails has "dmarc=fail"
| project
                            Timestamp,
                            SenderFromAddress,
                            SenderFromDomain,
                            SenderMailFromDomain,
                            RecipientEmailAddress,
                            Subject,
                            AuthenticationDetails,
                            DeliveryAction,
                            NetworkMessageId
| order by Timestamp desc
Used for Finding messages where Defender telemetry suggests spoofing, authentication failure or suspicious domain usage.
Why it matters A spoofed domain can exploit user trust before the user ever notices the technical warning signs.
Agent Foskett tip Do not stop at the word spoof. Check whether the message was delivered, who received it and whether anyone clicked.
Need the exact spoofing detection queries?
See the full Microsoft Defender email spoofing guide with copy & paste KQL using EmailEvents and AuthenticationDetails.
View Full Spoofing Guide
How to read this query
  • The word spoof in AuthenticationDetails is useful, but context still matters.
  • A blocked spoofed message is different from a delivered spoofed message.
  • Multiple recipients or repeated subjects may indicate a campaign rather than a one-off message.

👉 Do not stop at the word spoof. Check who received it, whether it was delivered, and whether anyone clicked.

Continue investigation → Full spoofing case walkthrough.

Compare visible sender and envelope sender

The user sees the visible From address. The email infrastructure also records the Mail From path. When those values tell different stories, the investigation gets interesting.
sender-domain-alignment.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
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project
                            Timestamp,
                            SenderFromAddress,
                            SenderFromDomain,
                            SenderMailFromAddress,
                            SenderMailFromDomain,
                            RecipientEmailAddress,
                            Subject,
                            AuthenticationDetails,
                            DeliveryAction
| order by Timestamp desc
Used for Finding messages where the identity shown to the user does not match the underlying sending path.
What to check Review the sender, subject, authentication details and delivery action before deciding whether this is normal forwarding, a third-party sender or impersonation.
Best pivot Group by sender and subject to decide whether this is a one-off mismatch or part of a broader campaign.
How to read this query
  • SenderFromDomain is what the user sees as the visible sender domain.
  • SenderMailFromDomain helps show the underlying sending path.
  • A mismatch may be normal for some third-party systems, but it should always be validated.

👉 The question is not “are these different?” The question is “does this difference make sense for this sender and this message?”

Find repeated spoofing or failed-authentication campaigns

One suspicious email is interesting. The same sender, subject or domain pattern across multiple recipients is a campaign. This query turns individual messages into patterns.
campaign-patterns-by-sender.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
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail", "spoof")
| summarize
                            MessageCount = count(),
                            RecipientCount = dcount(RecipientEmailAddress)
                            by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| where MessageCount >= 3
| order by MessageCount desc
Used for Finding repeated subject lines, sender identities or authentication failures across several recipients.
Why it matters Campaign patterns help separate background noise from active targeting.
How GEMXIT uses it To decide whether response should stay with one mailbox or expand into user communication, blocking, investigation and reporting.
How to read this query
  • MessageCount shows how often the pattern appeared.
  • RecipientCount helps identify whether the activity affected one user or many.
  • Repeated subject lines can reveal phishing campaigns, payroll scams, fake document notifications or impersonation attempts.

👉 One suspicious email is a finding. Repeated suspicious emails across users can become an incident.

Pivot from suspicious email to user clicks

A suspicious message is one thing. A suspicious message with a user click is something else entirely. This query joins suspicious email telemetry to URL click activity using NetworkMessageId.
email-to-url-click-pivot.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 SuspiciousMessages =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail", "spoof")
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject;

SuspiciousMessages
| join kind=inner (
                            UrlClickEvents
                            | where Timestamp > ago(30d)
                            | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
Used for Confirming whether suspicious delivery became user interaction.
What to look for Successful clicks, allowed actions, repeated clicks, strange URLs and users who interacted shortly after delivery.
Best next step Take the user and timestamp into sign-ins, device activity and mailbox activity to validate impact.
How to read this query
  • NetworkMessageId connects the suspicious email to URL click activity.
  • ActionType helps show whether the click was allowed, blocked or scanned.
  • The URL, user and click time are the starting point for identity and endpoint pivots.

👉 A suspicious email becomes more urgent when a user clicked the link.

Related scenario → The Missing Click.

Pivot from email click to sign-in activity

The next question after a suspicious click is whether the same user showed risky or unusual authentication behaviour. This helps connect email interaction to identity activity.
click-to-signin-pivot.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
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
Used for Checking whether a click was followed by authentication activity that deserves investigation.
What to look for New locations, unusual IP addresses, unexpected applications, strange timing or authentication patterns that do not match the user.
Important note Table names can vary depending on licensing, connectors and data availability. The hunting mindset matters more than one exact table name.
How to read this query
  • Start with the clicked user, then look for sign-ins close to the click time.
  • Review unfamiliar IP addresses, locations, applications and logon types.
  • Watch for activity that looks technically valid but does not match the user’s normal pattern.

👉 This is where session hijacking, credential capture and suspicious post-click behaviour can start to appear.

Related investigation → MFA session hijacking.

Hunt for after-hours file activity

Not every incident starts with malware. Sometimes the first useful signal is a file downloaded at a time that does not match normal user behaviour.
after-hours-file-downloads.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
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
Used for Finding activity that may be legitimate but deserves a second look because of timing.
Why it matters Attackers often blend into legitimate services. Time-of-day analysis can expose activity that alerts ignore.
Best pivot Compare the user’s normal access history, location, IP address and file sensitivity before deciding response.
How to read this query
  • After-hours access is not automatically malicious, but it deserves context.
  • Check whether the user normally accesses files at that time.
  • Review the IP address, application, file name and sensitivity of the content accessed.

👉 A 2:14 AM file download may be harmless. It may also be the first visible sign of data leaving the environment.

Hunt for suspicious PowerShell behaviour

PowerShell is not automatically bad. But encoded commands, hidden windows, download cradles and suspicious process chains are exactly the type of behaviour KQL is good at finding.
suspicious-powershell.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
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
Used for Finding PowerShell commands that deserve review because of obfuscation, download behaviour or suspicious execution flags.
Why it matters Attackers often use legitimate administration tools. The command line tells the story.
Best pivot Investigate the initiating process, parent chain, device timeline and related network connections.
How to read this query
  • Encoded commands, hidden execution and download strings are investigation signals.
  • Review the initiating process to understand how PowerShell was launched.
  • Pivot into device timeline, file events and network connections if the command line looks suspicious.

👉 PowerShell is not the problem. Suspicious PowerShell behaviour is the signal.

What good KQL threat hunting looks like

Good hunting is not running one magic query. It is asking better questions, validating the evidence and connecting small signals into a useful security story.
Start with behaviour Ask what looks unusual, not just what looks malicious. Timing, sender alignment, repeated activity and context matter.
Use pivots, not guesses Move from email to click, from click to sign-in, from sign-in to device, and from device to response.
Turn findings into action The goal is not a pretty query. The goal is a decision: dismiss, monitor, block, investigate, contain or improve controls.
If you are relying on alerts alone, you are only seeing part of the picture.
KQL helps show what actually happened, not just what triggered.
Contact GEMXIT

Continue your investigation

Use this guide as the central KQL investigation hub, then pivot deeper into identity, email, session and Microsoft security telemetry based on what the logs reveal.
Email and spoofing investigations Email spoofing detection
DMARC failure hunting
The Email Came From Me
EmailEvents investigation guide
Identity and session risk MFA session hijacking
The Session Token Never Expired
Impossible travel sign-ins
Identity and access security
Modern threat investigations Cyber Security Is Not Just Antivirus
When Nothing Looks Wrong
The PowerShell Never Triggered An Alert
The Alert Wasn't Understood
Microsoft Security services Microsoft Defender services
Microsoft Sentinel services
Security operations
GEMXIT Security Review

Related Agent Foskett investigations

This guide is designed to sit beside the practical Agent Foskett stories that show how these hunting patterns appear in real environments.
Email spoofing Read The Email Came From Me for a practical story about spoofed email, sender trust and authentication checks.
Identity investigation Read The Logs Already Knew for a Sentinel-style look at impossible travel and session hijacking investigation.
Security operations Review Microsoft Security Operations to see how hunting, response and visibility fit into a broader security capability.
After-Hours File Access When nothing looks wrong, timing often tells the real story. Detect late-night SharePoint downloads and unusual data access patterns. Read more →
EmailEvents investigation guide Understand how EmailEvents reveals sender details, authentication results and delivery behaviour behind DMARC failures.
Need help investigating this in your environment?
Running queries is one thing. Knowing what matters is another.

At GEMXIT, we help with Microsoft Sentinel deployments, Defender threat hunting, KQL analytics, workbook design and practical investigation workflows.
Book a Security Review →

Final thought

KQL does not replace security judgement. It sharpens it.
At GEMXIT We use Microsoft Defender, Sentinel and Entra ID visibility to turn scattered security signals into practical investigation paths.
Agent Foskett mindset The best investigations do not start with panic. They start with one clear question: what does the data say?
Detect Email Spoofing (Full Investigation Guide) Follow a complete real-world investigation using Microsoft Defender — from spoofed emails and DMARC failures through to user clicks, identity pivots and full attack path visibility.

If you want help improving Microsoft Defender hunting, alert investigation and security visibility, 👉 review Microsoft Defender services

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Microsoft Defender KQL Threat Hunting Guide

This guide explains how GEMXIT uses Microsoft Defender XDR and KQL to investigate suspicious email, spoofed domains, authentication failures, URL clicks, sign-in activity and endpoint behaviour.

EmailEvents AuthenticationDetails SpoofedDomain KQL

Practical KQL examples include EmailEvents queries, AuthenticationDetails filtering, spoofed domain checks, sender alignment analysis, campaign pattern detection, email-to-click investigation pivots, click-to-sign-in review, after-hours file activity and suspicious PowerShell behaviour.

Microsoft 365 Security Operations and Threat Hunting

GEMXIT uses KQL to support Microsoft 365 security operations, Microsoft Defender hunting, Sentinel investigation, Entra ID visibility and practical response planning.