Detecting Threats with Microsoft Defender XDR for SC-200: Advanced Hunting Tables, KQL, Threat Analytics, Hunting Graphs and Sentinel Graph

Advanced hunting is the query-based threat-hunting tool in the Microsoft Defender portal: you write Kusto Query Language (KQL) against a shared schema of Defender XDR tables to find threats that no alert has flagged yet. The same page runs queries over endpoint, email, identity, cloud-app and alert data, and, when a Microsoft Sentinel workspace is onboarded to the Defender portal, over that workspace's tables as well.

Two ways to build a query. Guided mode is a query builder for people new to KQL or who prefer menus: you choose a data domain, add conditions from drop-down lists and run it. Advanced mode is the KQL editor for writing queries from scratch. Both read the same data.

Limits that shape every query.

Custom detection rules run under their own quotas, so manual hunting that exhausts the CPU cycle doesn't pause them. Data that lives only in the Sentinel data lake tier is not queryable from advanced hunting; moving a table to the data lake does not extend the hunting window.

Everything is UTC. All advanced hunting data is stored in UTC and queries must be written in UTC. The portal converts results to the time zone in your settings, so a local time copied from the screen into a datetime() literal points at the wrong hour unless you convert it first.

Pick the endpoint table by the activity you are looking for: process launches in DeviceProcessEvents, file activity in DeviceFileEvents, registry changes in DeviceRegistryEvents, DLL loads in DeviceImageLoadEvents, connections in DeviceNetworkEvents, sign-ins in DeviceLogonEvents, and miscellaneous security-control events in DeviceEvents. Each table is written by the Defender for Endpoint sensor on the device, so it records the activity however it was triggered.

Two distinctions come up often. First, the event beats the tool: a script that creates a scheduled task or changes a service through API calls never starts a separate command-line tool, so a hunt built on one tool's command lines misses it, while the table that records the resulting change (registry, file or process) sees it whatever made the change. Second, DeviceLogonEvents is collected on the device itself, so it sees local-account sign-ins; its LogonType tells session types apart, for example RemoteInteractive for Remote Desktop and Network for access such as a file share. In general, a network table records connections and a logon table records authentication; a connection to a remote-access port proves traffic reached the service, not that anyone signed in.

Outside the endpoint, pick the table by the object: email delivery and its parts in the Email* tables, Safe Links clicks in UrlClickEvents, on-premises Active Directory activity in the Identity* tables, detections in AlertInfo and AlertEvidence, and activity inside Microsoft 365 and other cloud apps in CloudAppEvents.

Near-twins to keep apart. IdentityQueryEvents is someone reading a group; IdentityDirectoryEvents is someone changing it. IdentityLogonEvents comes from domain controllers, so it covers every workstation that authenticates against AD but cannot see local-account sign-ins; DeviceLogonEvents is the reverse and needs the device onboarded to Defender for Endpoint. IdentityInfo describes accounts rather than events, so it is what you join to when a hunt filters on an attribute such as department. Microsoft Entra ID cloud sign-ins have their own tables: EntraIdSignInEvents holds interactive and non-interactive user sign-ins, and EntraIdSpnSignInEvents holds sign-ins by service principals and managed identities; neither records on-premises AD authentication or local device sign-ins. EmailEvents reflects where a message finally sits, but only EmailPostDeliveryEvents gives each removal as its own row.

Typical joins. Email to endpoint goes through the file hash: EmailAttachmentInfo and DeviceFileEvents both carry SHA256, which links every message to every device that saved the attachment. Alerts to their files go through AlertId. Mail-flow tables join to each other on NetworkMessageId.

The operators that decide most hunting queries are the string comparisons (which differ in case sensitivity and index use), the parent/child column choice, and summarize with the right aggregation.

String operators

Microsoft's guidance: prefer has over contains when you are looking for a full term; use case-insensitive matches (=~, in~) for file names and command lines because their capitalisation varies; and identify known tools by FileName rather than by searching the command line. Very short terms aren't indexed, so has gains little on them. A prefix or substring match is broader than it looks: startswith "cert" also returns certreq.exe and certmgr.exe alongside certutil.exe, so when the requirement names specific binaries, match those names exactly. The cost column is relative guidance drawn from how each operator uses the term index; Microsoft does not publish a ranking.

Parent and child columns

Each DeviceProcessEvents row describes a process being created. FileName and ProcessCommandLine belong to the new process; the InitiatingProcess* columns belong to the process that started it; InitiatingProcessParent* columns go one generation further up. So "Word started PowerShell" filters InitiatingProcessFileName for winword.exe and FileName for powershell.exe. The same InitiatingProcess* columns appear in the file, registry, network and image-load tables to name the process behind each event.

summarize

Pick the measure from the wording: "how many different devices per hour" is dcount(DeviceId) by bin(Timestamp, 1h), because count() lets one noisy device dominate. For snapshot tables such as DeviceInfo, which get many records a day, summarize arg_max(Timestamp, *) by DeviceId gives the latest state of each device.

An example that combines these choices, listing hosts that connected to many different SMB targets:

DeviceNetworkEvents
| where Timestamp > ago(1d)
| where RemotePort == 445
| summarize Targets = dcount(RemoteIP)
    by DeviceId, InitiatingProcessId, InitiatingProcessCreationTime
| where Targets > 20

A process ID alone does not identify a process, because operating systems reuse IDs; identify an instance by device + process ID + process creation time, or on Windows by the unique process ID columns when they are populated.

• ProcessUniqueId / InitiatingProcessUniqueId. On Windows, Defender for Endpoint adds a unique ID for each process. To find the children of one exact parent, match the child's InitiatingProcessUniqueId to the parent's ProcessUniqueId. Matching InitiatingProcessId to ProcessId can link unrelated processes that happened to get the same ID.
• When the unique ID is empty (for example on devices or platforms that don't populate it), group or join on DeviceId (or DeviceName), the process ID and its creation time, such as InitiatingProcessId, InitiatingProcessCreationTime. The creation time separates two runs that reused an ID; grouping on an empty unique ID collapses unrelated processes into one blank group.
• Columns that don't work as an identity. FileName can't separate two runs of the same binary, and Timestamp is per event, so grouping on it splits one process into one row per event.

A KQL join without a kind uses innerunique, which keeps only one left-side row per key value before matching; to keep every matching left row, specify kind=inner. This is the most common surprise in hunting joins: if several left rows share a key, such as five sign-ins from the same IP address, innerunique keeps just one of them.

Baselines use leftanti. Put recent events on the left and a distinct list of values seen earlier on the right; leftanti keeps only what is new:

let Known = DeviceImageLoadEvents
    | where Timestamp between (ago(14d) .. ago(1d))
    | distinct SHA256;
DeviceImageLoadEvents
| where Timestamp > ago(1d)
| join kind=leftanti Known on SHA256

Microsoft's join guidance for advanced hunting:

• Put the smaller table on the left, so fewer records are matched.
• Apply time filters to both sides before the join, not after it, so fewer records are checked.
• Project only the columns you need before joining.
• Use hint.strategy = broadcast when the left table is small and the right is large.

The flavor decides which rows come back; the four practices above decide how fast. Pick the flavor from the requirement first, then optimize.

Advanced hunting can enrich results with built-in functions, save queries for others, and act directly on result rows through Take actions, provided the results contain the identifier columns each action needs.

Enrichment functions

• invoke FileProfile(x, y) adds file intelligence: GlobalPrevalence, GlobalFirstSeen, GlobalLastSeen, Signer, Issuer, SignatureState, IsExecutable, ThreatName and ProfileAvailability. x is the hash column (SHA1, SHA256, InitiatingProcessSHA1 or InitiatingProcessSHA256; MD5 is not accepted) and y the number of records to enrich, from 1 to 1,000 with a default of 100. Rows beyond the limit come back unenriched, with an empty ProfileAvailability. The Global* columns describe the file across Microsoft's worldwide telemetry, while any count you compute from your own tables describes only your tenant.
• DeviceFromIP() returns the devices that were assigned an IP address at a given time, and AssignedIPAddresses() the addresses a device had, which helps when logs name only an IP.

Saving and sharing queries

A query can also be turned into a custom detection rule that runs on a schedule; building and tuning those rules belongs to the detections topic of the exam.

Take actions on results

The Take actions wizard only offers an action when the selected rows contain the columns it needs:

A hybrid account synced from Active Directory to Entra ID is both kinds of identity, so results for it need both AccountSid and AccountObjectId. Soft delete from advanced hunting can also remove the sender's copy from Sent Items for internal and outbound messages; that works from EmailEvents and EmailPostDeliveryEvents results. Every action taken is recorded in the Action center history.

Threat analytics is Microsoft's library of threat reports in the Defender portal, each one tying a tracked threat (an actor, campaign, technique or vulnerability) to the alerts, incidents, exposed devices and recommended mitigations in your own tenant.

The dashboard

Threat tags (such as ransomware, phishing, vulnerability or activity group) filter the list by theme; they don't rank anything. A separate Category filter narrows by report type, such as Actor profiles or OSINT, with counters at the top of the page showing how many reports of each type exist. Besides Microsoft's own reports, the library surfaces OSINT articles: open-source intelligence that Microsoft links to its tracked threats, shown alongside the Microsoft-authored analysis. The list also shows Misconfigured devices (devices where the threat's linked recommended actions aren't turned on) and Vulnerable devices (devices running software with the threat's linked vulnerabilities). Not available means researchers haven't linked any recommendations or vulnerabilities to the threat, so there is nothing to count; 0 means the count was calculated and no device qualifies.

Inside a report

• Overview: a summary with charts of impact and exposure.
• Analyst report: Microsoft's full write-up, including every mitigation, whether or not Secure Score tracks it.
• Related incidents: incidents in your tenant linked to the threat.
• Impacted assets: devices, users, mailboxes, apps and cloud resources with active or resolved alerts linked to the threat.
• Endpoints exposure: from Defender Vulnerability Management data and regardless of alerts, an exposure level calculated from the severity of the vulnerabilities and misconfigurations the threat exploits and the number of devices with those weaknesses, plus the deployment status of the relevant security updates.
• Recommended actions: a checklist with status, limited to recommendations that Microsoft Secure Score tracks; other advice is only in the analyst report.
• Indicators (preview): indicators of compromise for the threat, updated by Microsoft researchers in real time, with expired IOCs kept for reference. Only verified customers can see this tab, so a tenant must be verified before analysts get access.

Reading the evidence together. The impact tabs (Related incidents, Impacted assets) are driven by alerts; the exposure tabs are driven by vulnerability and configuration data. They answer different questions, "has this threat touched us?" versus "could it?", so a report can show one without the other, and each points to a different response: investigate what was hit, or remediate the weakness before it is used.

Permissions, links and notifications

• With Defender XDR unified RBAC, Security data basics (read) lets a user view reports, related incidents and alerts, and impacted assets. Exposure data and recommended actions also need Vulnerability management (read) and Exposure Management (read). Each product's data appears only for users with that product's licence and role.
• When you create a custom detection rule, you can link it to a threat analytics report. Its incidents then appear in the report's Related incidents tab and show the report, as Microsoft's own detections do.
• Email notifications for threat analytics updates tell people who aren't in the portal daily when reports are published or updated. They are configured separately from alert notifications.

The hunting graph draws entities and their relationships as an interactive map from advanced hunting, using predefined scenarios that need no KQL; blast radius applies the same graph to an incident to show what a compromised entity could reach next. Both are powered by Microsoft Sentinel graph.

Prerequisites. Besides an advanced hunting role, the tenant must be onboarded to the Microsoft Sentinel data lake (which provisions Sentinel graph), and users need at least read-only access in Microsoft Security Exposure Management. For tenants already on the data lake, the hunting graph and blast radius are provisioned automatically; there is no job or rule to set up.

Predefined scenarios

Each scenario is a prebuilt query that asks for specific inputs, or none:

Choose by the direction of the question: from a device outward (exfiltration by device) or from data inward (users with access), and whether you can name a target (paths between two entities, attack paths) or not. Filters then refine the graph, for example Show only the shortest paths, node filters on properties such as internet exposure, and an Edge direction filter (Incoming, Outgoing or Both); Incoming on an entity relationship map keeps only the relationships that point into the chosen entity.

Blast radius

In the Defender incident graph, blast radius shows both the current impact of a breach and the possible next paths from a compromised entity, such as a user or device, to critical assets, in the same view as the incident's evidence. The hunting graph's attack path scenario can show similar paths, but it runs separately in advanced hunting from a target you choose.

Microsoft Sentinel graph models security data as nodes (entities) and edges (relationships); you analyze it with KQL in advanced hunting through the exposure graph tables, or with Graph Query Language (GQL) on custom graphs that you build from data lake data.

Exposure graph tables in advanced hunting

Exposure Management computes a graph of assets, identities and their standing relationships, including device criticality. Advanced hunting exposes it as two tables: ExposureGraphNodes (each entity, with NodeId, NodeLabel, the dynamic Categories array and NodeProperties) and ExposureGraphEdges (each relationship, with SourceNodeId, TargetNodeId and EdgeLabel). Use them when the question is about who can reach what; logon and inventory tables only record events and entities, not computed access paths.

KQL's graph operators query them: make-graph builds a graph whose edges run from SourceNodeId to TargetNodeId, and graph-match describes a pattern. In a pattern, -[e]-> is exactly one hop in the stored direction, -[e*1..3]-> a chain of one to three hops, <-[e]- the reverse direction, and -[e]- either direction.

let UsersAndVMs = ExposureGraphNodes
| where set_has_element(Categories, "identity")
    or set_has_element(Categories, "virtual_machine");
ExposureGraphEdges
| make-graph SourceNodeId --> TargetNodeId
    with UsersAndVMs on NodeId
| graph-match (User)-[e]->(VM)
    where set_has_element(User.Categories, "identity")
      and set_has_element(VM.Categories, "virtual_machine")
    project UserIds = User.EntityIds, Relation = e.EdgeLabel,
      VmIds = VM.EntityIds

Filtering dynamic arrays. Categories and NodeProperties are indexed. has uses that index but matches a term, so has "data" also matches a longer category containing the term. set_has_element() checks for the exact element but doesn't use the index (nor do isempty and isnotnull). Microsoft's guidance is to combine them: has for speed, then set_has_element for precision.

Custom graphs (preview)

Custom graphs model your own entities and relationships from data in the Sentinel data lake, including non-Microsoft logs. You author them in Jupyter notebooks provided by the Microsoft Sentinel extension for Visual Studio Code (PySpark with a graph library), then make them available to others:

Once a job materializes a graph, analysts open it on the Graphs page under Microsoft Sentinel in the Defender portal, view its schema, visualize results and query it with GQL. KQL, including make-graph and graph-match, runs in advanced hunting and on data lake tables, not on that page. Sentinel's own hunting queries, KQL jobs, summary rules and notebook hunting with the Sentinel MCP Server belong to the sibling topic on hunting in the Sentinel platform.