Hunt for Threats by Using Microsoft Defender XDR

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Advanced hunting is a read-only KQL search over ~30 days of raw Defender XDR telemetry

Advanced hunting in the Microsoft Defender portal lets you query the raw event tables Defender XDR collects from endpoints, identities, email, apps, and cloud, going back about 30 days, using Kusto Query Language (KQL). It is proactive: you run a query and pivot from the result table rather than waiting for an alert. The query is read-only against telemetry, so a hunt never changes a device or mailbox; any containment is a separate response action. When you need data older than ~30 days, that is a Microsoft Sentinel job, not advanced hunting.

Read a KQL query as a pipeline: a table in at the top, each pipe transforms the rows below

Every advanced hunting query starts at a table name and flows left to right through operators joined by the pipe character, each one taking the previous step's rows as input, just like a Unix pipe. Read it top to bottom and each line is one transformation of the table above it. The core operators are where (filter), project and extend (choose or compute columns), summarize (aggregate), join and union (combine tables), and order/take (sort and limit). Internalizing the pipeline shape is what lets you compose and debug a hunt rather than memorize snippets.

1 question tests this

• You have a Microsoft Sentinel workspace. You have the following query for a scheduled analytics rule: SigninLogs | where ResultType != '0'…

Filter first: put the time window and selective where conditions right after the table

The performance rule SC-200 leans on is filter early. Place your time filter (where Timestamp > ago(...)) and your most selective where conditions immediately after the table, before summarize, join, or project, so every later operator works on fewer rows. Microsoft's query best practices say to filter before aggregating or joining and to project the columns you want last. A query that aggregates or projects before filtering is the slow, wrong answer on the exam.

Trap Filtering after a summarize or join; the aggregation already processed the full row set, so the late where saves nothing and the query stays slow.

1 question tests this

• You need to write a KQL query in Microsoft Defender XDR advanced hunting that correlates failed logon events from three specific devices…

Match file names with =~ (case-insensitive), not == (case-sensitive)

In KQL == is case-sensitive equality and =~ is case-insensitive equality. When you match a file name or account that an attacker can re-case, use =~ so a query for powershell.exe still catches PowerShell.exe. The classic distractor is == , which silently misses the re-cased value and returns nothing. The same idea extends to string search: prefer the case-insensitive, term-based operators when the value's casing is not guaranteed.

Trap Using == to match a file name; it is case-sensitive, so a re-cased value like PowerShell.exe slips past a query written for powershell.exe.

Prefer has over contains for substring-style matching

KQL has matches a whole indexed term and is fast because it uses the term index; contains matches any substring and is slower because it cannot. For hunting on command lines, file names, or URLs, reach for has or has_any first and fall back to contains only when you genuinely need a partial-token match. On a large estate the operator choice is the difference between a query that returns and one that times out.

Trap Defaulting to contains for every text match; it skips the term index and runs far slower than has on large tables.

1 question tests this

• You are building an advanced hunting query in Microsoft Defender XDR to hunt for suspicious process execution. You need to filter…

Defender XDR splits telemetry into product-named tables; start at the one that owns the entity

There is no single events table. Defender XDR groups telemetry by emitting product: Device* tables (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceLogonEvents) from Defender for Endpoint, Email* and Url tables (EmailEvents, EmailAttachmentInfo, EmailUrlInfo, UrlClickEvents) from Defender for Office 365, Identity* tables (IdentityLogonEvents, IdentityDirectoryEvents) from Defender for Identity, and CloudAppEvents plus AAD sign-in tables from Defender for Cloud Apps and Microsoft Entra ID. The first decision in any hunt is which table owns the entity you care about, because its columns and data depend on it.

Trap Querying DeviceLogonEvents for a directory or identity sign-in; Device* tables come from Defender for Endpoint, while domain logon and directory activity live in the Identity* tables from Defender for Identity.

3 questions test this

• You have the following advanced hunting query in Microsoft Defender XDR. IdentityLogonEvents | where ActionType == 'LogonFailed' | where…
• You are using advanced hunting in Microsoft Defender XDR to investigate a potential credential theft attack. You need to correlate password…
• You use Microsoft Defender XDR advanced hunting. You need to write a KQL query that returns Kerberos and NTLM authentication activities…

Inspect a table's columns with TableName | take 10 or the schema pane before writing the hunt

You do not have to know every column from memory. The portal's schema reference lists each table and column, and running TableName | take 10 returns a quick sample so you can see the real column names and shapes before you commit to a query. take returns arbitrary rows for sampling, not a ranked top-N; use top when you want the highest values. Inspecting first prevents the dead-end of joining or projecting a column that does not exist on that table.

Trap Treating take 10 as a top-10 ranking; take returns arbitrary rows, so for the highest counts or latest events you need top or order by.

Cross-product hunting is the point: join or union Device, Email, and Identity tables

Advanced hunting exists to follow an attacker across products that a single-product view cannot show: from a phished mailbox (EmailEvents) to the click (UrlClickEvents) to a process on a device (DeviceProcessEvents) to a sign-in (IdentityLogonEvents). You stitch the story with join on a shared key like AccountUpn or DeviceId, or union when several tables share the same entity column. This cross-domain query surface is what distinguishes advanced hunting from running each product's own search.

KQL join defaults to innerunique, so state kind=inner when you need every match

Unlike SQL, KQL join defaults to the innerunique flavor, which de-duplicates rows on the left table before matching. If a hunt needs every left-right pair (for example, all logons that match all of several suspicious devices), an unqualified join can silently drop rows. State join kind=inner explicitly when you want full inner-join semantics, and pick the kind (leftouter, rightsemi, anti, and so on) deliberately rather than relying on the default.

Trap Assuming an unqualified join behaves like a SQL inner join; KQL defaults to innerunique and de-duplicates the left side, so it can quietly drop matching rows.

3 questions test this

• You have a Microsoft Sentinel workspace. You need to write a KQL query for a scheduled analytics rule that matches sign-in events from…
• You have the following advanced hunting query in Microsoft Defender XDR. DeviceLogonEvents | where Timestamp > ago(1h) | where ActionType…
• You are investigating a cross-domain attack using advanced hunting in Microsoft Defender XDR. You write the following KQL query.…

Promote a validated hunt to a custom detection rather than re-running it by hand

The lifecycle is hunt, then operationalize: refine a KQL query interactively until it reliably finds the threat with low noise, then choose Create detection rule to save it as a custom detection that re-runs on a schedule and alerts. A bare advanced hunting query is a one-time manual lookup, so a recurring need (alert whenever, continuously detect) means promote to a rule. Authoring the KQL is the hunting task; the rule's frequency, tuning, and response actions are the detections topic.

Trap Re-running an advanced hunting query by hand on a cadence for something that should be a standing custom detection rule; promotion is what makes it alert automatically.

A query can only become a detection if it projects the columns the alert needs

For a query to promote into a usable custom detection it must return the columns Defender XDR uses to build the alert: a timestamp, an entity that maps the alert to a real asset, plus ReportId for non-endpoint tables or DeviceId for Defender for Endpoint tables so the alert ties back to the originating event. A hunt that summarizes everything away and drops these columns cannot map its alerts to an asset; project them (use take_any or arg_max to carry ReportId through an aggregation) so the alert can build.

Trap Omitting ReportId on a non-endpoint table; without it Defender XDR cannot identify the originating event, so the alert is not tied back to its source even though the rule itself still creates and runs.

1 question tests this

• You create the following advanced hunting query in Microsoft Defender XDR: DeviceProcessEvents | where FileName == 'powershell.exe' | where…

Use built-in functions, sample queries, and guided mode instead of starting blank

Advanced hunting ships helpers so you do not compose every hunt from scratch. Functions like FileProfile() enrich a file hash with prevalence and reputation in one call, Microsoft and the community publish a library of sample queries on GitHub, and guided hunting lets an analyst build a query with dropdowns instead of writing KQL. Reaching for a sample query or a function before hand-rolling a complex join is faster and less error-prone, and guided mode keeps non-KQL analysts able to hunt.

Threat analytics answers "are we affected by this campaign", not "what is this malware"

Threat analytics is a feed of expert reports written by Microsoft security researchers that describe active campaigns, actors, and techniques, then overlay them onto your tenant's own data. So it tells you whether a named campaign is affecting you right now, with your impacted assets and your exposure, rather than giving generic malware background. The SC-200 task here is interpretation and response: read the report and act, not authoring intelligence. When a question asks which mitigations reduce exposure to a specific actor, the answer is threat analytics, not a KQL hunt.

Trap Reaching for advanced hunting to judge whether a named campaign affects you; threat analytics already overlays Microsoft intel on your tenant and shows impacted assets and exposure.

A threat analytics report shows impacted assets, related alerts, and exposure with mitigations

Each threat analytics report turns intel into action through its tabs: an Overview and analyst report with the narrative and MITRE ATT&CK techniques, an Impacted assets view of the exact devices, users, and mailboxes with related activity, Related incidents and alerts already in your queue for that threat, and an Endpoints exposure plus Recommended actions view ranking the missing secure-configuration settings the campaign exploits. Mitigation status updates as you remediate, so the report doubles as a checklist for closing the gaps that leave you exposed.

3 questions test this

• Your company uses Microsoft Defender XDR. You review a threat analytics report and navigate to the Endpoints exposure tab to assess…
• Your company uses Microsoft Defender XDR. You review a threat analytics report for an active ransomware campaign. You need to assess the…
• You use Microsoft Defender XDR. Your security team is investigating a tracked ransomware campaign. The team needs to identify the MITRE…

Triage by the dashboard's High-impact and Highest-exposure lenses, not a generic severity

The threat analytics dashboard summarizes the feed three ways: Latest threats (most recently published or updated), High-impact threats (greatest effect on your organization by active and resolved alert count), and Highest-exposure threats (where your configuration leaves you most exposed). Use High-impact and Highest-exposure to decide which campaign to hunt or harden first, because they are scored against your own telemetry and configuration rather than a one-size severity label. Reports also surface ready hunting queries that pivot you straight into advanced hunting.

Trap Prioritizing by a report's generic severity rating; that ignores your tenant, whereas High-impact and Highest-exposure are scored against your own affected assets and configuration gaps.

Advanced hunting tops out near 30 days; long retention and search jobs are Sentinel

Advanced hunting queries about the last 30 days of Defender XDR data, so an investigation reaching months back belongs in Microsoft Sentinel, where long-term retention, archived log restore, and search jobs live. Keep each hunt's lookback as tight as it allows (ago(7d) returns faster than ago(30d) and is usually enough to confirm or rule out an indicator). A stem mentioning data older than 30 days, archived logs, or search jobs is pointing at Sentinel, not Defender XDR advanced hunting.

Trap Trying to hunt months-old data in Defender XDR advanced hunting; its window is about 30 days, so older investigations need Microsoft Sentinel retention and search jobs.

KQL hunting is read-only; remediation is a separate response action

A KQL query surfaces evidence but never changes anything: it cannot isolate a device, disable a user, or delete an email. Those containment actions are taken from the incident, device, or user page in the response workflow, or are wired into a custom detection rule's automatic actions, not into the hunt itself. Knowing the read-versus-act split keeps you from expecting a hunting query to remediate and points you to the incident-response surface when the question asks how to contain.

Network indicators (IP, URL, domain) do not support the BlockAndRemediate action

For network indicators in Microsoft Defender for Endpoint, only Allow, Audit, Block, and Warn actions are supported. A CSV import in which network indicators use BlockAndRemediate fails to import those entries; use Block instead.

Trap BlockAndRemediate is valid only for file indicators, not for IP/URL/domain network indicators.

4 questions test this

• You have Microsoft Defender for Endpoint Plan 2. You have the Custom network indicators advanced feature enabled. A security analyst…
• Your company uses Microsoft Defender for Endpoint. You prepare a CSV file that contains IP address indicators. Each indicator has the…
• Your company uses Microsoft Defender for Endpoint Plan 2. You prepare a CSV file containing 200 URL indicators. Each indicator in the CSV…
• Your company uses Microsoft Defender for Endpoint. You receive a CSV file containing 200 IP address indicators from a threat intelligence…

For URL/domain/IP indicators, conflicting actions resolve Allow > Warn > Block

When several Defender for Endpoint URL, domain, or IP indicators target the same value, the precedence order is Allow over Warn over Block, so an Allow indicator overrides both Warn and Block.

Trap This precedence differs from file-hash indicator conflict handling, where the more secure/longer hash (SHA-256 over MD5) wins instead.

5 questions test this

• Your company uses Microsoft Defender for Endpoint. You have three separate URL/domain indicators configured for the domain contoso.com. One…
• Your company uses Microsoft Defender for Endpoint. A security analyst creates three custom indicators for the domain malicious-example.com…
• You have Microsoft Defender for Endpoint. A security analyst creates three custom indicators for the same external domain, all scoped to…
• You have Microsoft Defender for Endpoint Plan 2. Three custom indicators exist for the same domain: Indicator A has the Block action,…
• Your company uses Microsoft Defender for Endpoint. A security analyst creates three custom indicators for the same domain in the Microsoft…