Defender XDR Advanced Hunting Tables Cheat Sheet for MSP SOCs

When an alert lands at 3am, the slowest part of triage is often working out which Defender XDR table holds the answer. This cheat sheet maps the advanced hunting tables your analysts use most, the columns worth remembering and starter KQL for each, plus the extra rules you need when one SOC queries many client tenants.

Match the question to the table

Advanced hunting groups its tables by the product that feeds them. If your analysts learn which family answers which question, they stop scrolling the schema pane and start querying. Print this grid for the shift wall or pin it in your runbook.

Learn the endpoint tables and their key columns

Most triage starts on a device. These are the endpoint tables your team will open every shift, with the columns that answer the first questions in a ticket.

Table	Answers	Key columns
DeviceProcessEvents	What ran and what launched it	FileName, ProcessCommandLine, InitiatingProcessFileName, AccountName, SHA256
DeviceNetworkEvents	Where a device connected	RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName, ActionType
DeviceFileEvents	Files created, changed or deleted	FileName, FolderPath, SHA256, ActionType, InitiatingProcessFileName
DeviceRegistryEvents	Registry changes, often persistence	RegistryKey, RegistryValueName, RegistryValueData, ActionType
DeviceLogonEvents	Who logged on to a device and how	AccountName, LogonType, RemoteIP, ActionType
DeviceEvents	Mixed events: antivirus, exploit protection, scheduled tasks	ActionType, AdditionalFields
DeviceInfo	Context about the device itself	DeviceName, OSPlatform, MachineGroup, PublicIP

For the WS-114 alert, the first query is a simple parent and child process view for Office applications on that device.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName startswith "ws-114"
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "outlook.exe")
| project Timestamp, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, SHA256
| order by Timestamp desc

Know the email, identity and cloud app tables

Once you know what ran, the next question is how it arrived and who else is affected. These tables link through shared keys: NetworkMessageId joins the email tables, and AccountUpn or AccountObjectId joins identity and cloud activity.

Table	Answers	Key columns
EmailEvents	Delivery of each message	NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction, ThreatTypes
EmailUrlInfo	URLs found in messages	NetworkMessageId, Url, UrlDomain
EmailAttachmentInfo	Attachments on messages	NetworkMessageId, FileName, SHA256
EmailPostDeliveryEvents	Actions after delivery, such as ZAP	NetworkMessageId, Action, ActionType, ActionResult
UrlClickEvents	Safe Links clicks in email, Teams and Office apps	Url, AccountUpn, ActionType, IsClickedThrough, NetworkMessageId
IdentityLogonEvents	Authentication seen by Defender for Identity and Defender for Cloud Apps	AccountUpn, Protocol, LogonType, ActionType, DeviceName
EntraIdSignInEvents	Entra interactive and non interactive sign ins (needs Entra ID P2)	AccountUpn, IPAddress, ErrorCode, Application
CloudAppEvents	Activity in Microsoft 365 and connected apps	Application, ActionType, AccountObjectId, IPAddress

This query follows a suspicious domain from delivery to click, so you can see who received the lure and who went through to the site.

let suspectDomain = "invoice-portal.example";
EmailUrlInfo
| where Timestamp > ago(7d)
| where UrlDomain == suspectDomain
| join kind=inner (
    EmailEvents
    | where Timestamp > ago(7d)
    | project NetworkMessageId, RecipientEmailAddress, Subject, DeliveryAction
) on NetworkMessageId
| join kind=leftouter (
    UrlClickEvents
    | where Timestamp > ago(7d)
    | project NetworkMessageId, ClickedBy = AccountUpn, ClickAction = ActionType, IsClickedThrough
) on NetworkMessageId
| project RecipientEmailAddress, Subject, DeliveryAction, ClickedBy, ClickAction, IsClickedThrough

Start triage from AlertInfo and AlertEvidence

AlertInfo holds one row per alert, from every Defender product, with title, severity and source. AlertEvidence holds one row per entity attached to an alert: devices, users, IP addresses, files and mailboxes. Join them on AlertId and you get a quick scoping view for the handover sheet.

AlertInfo
| where Timestamp > ago(24h)
| where Severity in ("High", "Medium")
| project AlertId, Title, Severity, ServiceSource
| join kind=inner (
    AlertEvidence
    | where Timestamp > ago(24h)
    | project AlertId, DeviceName, AccountUpn, RemoteIP
) on AlertId
| summarize Devices = make_set_if(DeviceName, isnotempty(DeviceName), 10),
            Users = make_set_if(AccountUpn, isnotempty(AccountUpn), 10),
            IPs = make_set_if(RemoteIP, isnotempty(RemoteIP), 10)
    by AlertId, Title, Severity, ServiceSource
| order by Severity asc

Sweep every client tenant for one indicator

When one client's incident produces a solid indicator, the obvious next question is whether any other client has seen it. Microsoft Defender multitenant management lets your analysts run advanced hunting across many tenants at once: load a query, open the tenant scope selector, pick the tenants and run it. Each result row carries a TenantId column so you can tell clients apart.

let badIp = "203.0.113.45";
let badHash = "4f2a9c1e7b3d5a6f4f2a9c1e7b3d5a6f4f2a9c1e7b3d5a6f4f2a9c1e7b3d5a6f";
union
    (DeviceNetworkEvents
    | where Timestamp > ago(7d)
    | where RemoteIP == badIp
    | project Timestamp, DeviceName, Source = "Network", Detail = strcat(InitiatingProcessFileName, " to ", RemoteIP, ":", RemotePort)),
    (DeviceFileEvents
    | where Timestamp > ago(7d)
    | where SHA256 == badHash
    | project Timestamp, DeviceName, Source = "File", Detail = FolderPath)
| order by Timestamp desc

Three limits are worth putting in your playbook before analysts rely on this view:

• Result cap: multitenant queries return at most 50,000 records in total, and each tenant's share is 50,000 divided by the number of tenants queried. Broad queries across 40 clients quietly truncate, so filter on the indicator first.
• Sentinel data: each tenant's primary Sentinel workspace onboarded to the Defender portal can be queried alongside XDR data. Querying a secondary workspace in another tenant still needs Azure Lighthouse and the workspace() operator.
• Access: analysts only see tenants they have been granted roles in, so an empty result for one client might mean missing access rather than a clean estate.

• Record which tenants were in scope and when the sweep ran.
• Raise a ticket under each affected client, never one shared ticket.
• Never paste one client's results or tenant name into another client's ticket or report.
• Note any tenants you could not query and why, so the next shift can finish the sweep.
• Tell the originating client only that their indicator was checked, not who else matched.

Avoid the mistakes that waste a shift

These are the errors that most often turn a five minute query into an hour of confusion. Build the fixes into your query templates and peer reviews.

Key takeaways

---

A cheat sheet only helps if it matches how your team works. Copy these queries into your own template library, add the client names and device naming patterns you see every day, and review it at each quarterly tuning session so new tables and renamed columns never catch the night shift out.

Written by Stacey, SOC Manager, MSP