Azure security telemetry is not complete if it only describes Azure resources. Real attacks move through identities, devices, email, cloud apps, network paths, and management planes. Microsoft Defender XDR advanced hunting gives security teams a cross-domain lens for that movement.

Azure telemetry explains the cloud estate; Defender XDR helps explain the actors and devices moving through it.

This post looks at advanced hunting as part of the security telemetry architecture, not just as an analyst search box.

The Mental Model

Advanced hunting is a query-based threat hunting capability in Microsoft Defender that lets you explore raw telemetry across security domains. Microsoft documentation describes it as a way to inspect events in your network and locate threat indicators and entities. It can query data from Microsoft Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, Defender for Identity, and Microsoft Sentinel when connected through the unified portal.

The mental model is entity-centered investigation. Azure logs can tell you that a role assignment changed, a resource was accessed, or a policy was modified. Defender XDR can help answer what the user, device, mailbox, app, or identity was doing around the same time. That context is what turns a suspicious event into a credible incident story.

For example, a risky Azure administrative operation is more meaningful if the same user had unusual sign-in behavior, endpoint alerts, suspicious cloud app activity, or email compromise indicators. Conversely, an endpoint alert is more concerning if the same identity later changes Azure access controls.

Advanced hunting is also useful because it speaks KQL. That lowers the mental switching cost for teams already using Azure Monitor Logs and Microsoft Sentinel. The schemas are different, but the investigation habit is similar: establish time, entity, action, result, and correlation.

The opinionated design choice is this: Defender XDR should not be used as a dumping ground for every Azure question. It should be used when the Azure event needs actor, device, mailbox, SaaS, or identity context to make the decision defensible. If the question can be answered completely in Azure Monitor or Sentinel, keep it there. If the question depends on what the user or device did before and after the Azure action, advanced hunting becomes the stronger lens.

How It Really Works

Advanced hunting has guided and advanced modes. Guided mode helps users who are less familiar with KQL. Advanced mode supports writing KQL directly. The same hunting queries can also support custom detection rules, which run automatically to check for suspected breach activity, misconfiguration, or other findings.

Data freshness matters. Microsoft separates advanced hunting data into event or activity data and entity data. Event data, such as alerts and security events, is generally available quickly after sensors transmit it. Entity data, such as user and device information, is updated on a different cadence. That distinction matters when a query appears to miss context during a live investigation.

There are also quotas and time windows. Defender advanced hunting can query up to 30 days of Defender data unless data is streamed through Microsoft Sentinel for longer retention. Query results, execution time, and resource usage have limits. These boundaries should influence how teams design operational hunts and custom detections.

Permissions are part of the architecture. Access to advanced hunting can depend on Microsoft Defender XDR unified RBAC, Defender portal permissions, Exchange Online roles, Microsoft Entra roles, and endpoint RBAC settings. A hunt program that works only for global administrators is not a sustainable operating model.

Time zone behavior is another operational detail. Advanced hunting uses UTC for queries, while results can be displayed according to portal time zone settings. Incident processes should be explicit about time normalization to avoid timeline confusion.

Real-World Impact

Advanced hunting improves Azure investigations by adding user and device context. Suppose an identity creates a privileged role assignment in Azure. Activity Log can show the management operation. Entra sign-in logs can add authentication context. Defender XDR can add endpoint, email, app, and identity behavior around the same period. Together, they help determine whether this was expected administration, compromised identity activity, or part of a broader attack path.

Another example is suspicious resource access from a managed device. Azure resource logs may show access to storage, key vault, or application endpoints. Defender for Endpoint telemetry may show process execution, network connections, script activity, or device risk. The combination helps analysts answer whether the resource event was business activity or a compromised workstation reaching into cloud assets.

Custom detections are where hunting becomes operational. A useful hunt can become a detection rule when it describes a repeatable risk pattern. That transition should be governed. Not every clever query should become an alert. The query needs a response owner, severity logic, tuning strategy, and evidence that the signal is worth interrupting someone.

For leadership, advanced hunting supports a more realistic security narrative. It acknowledges that Azure security is tied to identities and endpoints, not isolated resource controls. That is important for risk reporting because many cloud incidents begin outside the cloud control plane.

This is where prioritization becomes concrete. Closing one hundred low-risk findings may look productive, but it can be less valuable than one hunt that proves a compromised endpoint reached a privileged cloud control path. The better success measure is not volume of queries run or alerts created. The better measure is whether a hunt reduces uncertainty about a plausible attack path: identity compromise to endpoint activity, endpoint activity to cloud access, and cloud access to control-plane change.

For a senior security audience, that distinction matters. Advanced hunting should help leaders choose between competing response options. If two issues are both noisy, prefer the one that breaks a trust edge or removes attacker mobility. If two detections both appear severe, prefer the one with clearer entity linkage and a defined response owner. If a hunt cannot change a triage, containment, or remediation decision, it is probably research, not an operational signal.

Gotchas and Edge Cases

The first gotcha is retention. If teams assume advanced hunting is a long-term archive, they may be surprised by the default 30-day Defender data query window. Longer-term requirements may need Microsoft Sentinel, streaming APIs, or another retention architecture.

The second gotcha is query cost and limits. Advanced hunting has limits around result size, timeout, and CPU resources. Broad queries over large data sets can be blocked or return partial results. Detection engineers should optimize early, filter by time and entity, and avoid using production hunts as exploratory data dumps.

Permissions can create blind spots. An analyst may be able to query some tables but not others. Email, endpoint, identity, and cloud app data can have different access requirements. If the team does not understand those boundaries, investigations can produce incomplete conclusions.

Schema differences also matter. Defender advanced hunting tables are not the same as Sentinel tables, even when KQL is used in both places. Joining data across systems requires care with timestamps, entity identifiers, device names, account formats, and casing.

Finally, be careful with custom detections. A query that is useful during a guided hunt may be too noisy as an always-on detection. Operational detections need tuning, suppression logic, ownership, and response playbooks.

The reporting anti-pattern is rewarding activity instead of consequence. A program that celebrates query count, alert count, or ticket closure can still miss the one linked identity and device chain that matters. The corrected metric is path clarity: how quickly the team can explain who acted, from which device, through which control, against which Azure resource, and what changed because of the investigation.

Best Practices

Create a set of investigation pivots that connect Azure events to Defender entities. Common pivots include account object ID, user principal name, device ID, IP address, cloud app, URL, file hash, and timestamp windows. Document how each pivot should be normalized.

Keep high-value hunts small and explainable. A hunt should answer a question, not prove that a query author understands every table. Start with a specific scenario such as privileged Azure change after risky sign-in, endpoint alert before cloud access, or suspicious email leading to cloud app activity.

Use custom detections only for repeatable risks. Before promoting a hunt, define severity, owner, expected volume, response steps, and tuning rules. Review detections after incidents and after false positives.

Use a simple routing rule for hunt outcomes. Treat a finding as an incident lane when it indicates active compromise or suspicious control-plane change. Treat it as a systemic control lane when it reveals a recurring weakness such as unmanaged devices reaching administrative paths. Treat it as an architecture debt lane when the hunt exposes missing telemetry, weak retention, or unclear ownership. Reclassify the lane when new evidence changes impact, likelihood, or response urgency.

Plan for retention explicitly. If your organization needs to investigate beyond 30 days, design the export or Sentinel path before the incident. Retention is difficult to retrofit under pressure.

Train analysts on time handling. Use UTC in queries and be clear when screenshots or portal results display local time. Timeline errors are one of the simplest ways to undermine an otherwise strong investigation.

Practical advanced hunting pivots

These examples run in Microsoft Defender XDR advanced hunting, not Azure Monitor Logs. They add identity, device, cloud app, and alert-evidence context around Azure investigations. Do not assume you can directly join to AzureActivity in Defender XDR unless Microsoft Sentinel tables are onboarded into the Defender portal and visible to your role.

1
2
3
4
5
6
7

let lookback = 1d;
let adminIndicators = dynamic(["Add member to role", "Add app role assignment", "Consent to application", "Update application"]);
CloudAppEvents
| where Timestamp >= ago(lookback)
| where IsAdminOperation == true or ActionType has_any (adminIndicators) or ActivityType has_any (adminIndicators)
| project Timestamp, AccountObjectId, AccountId, AccountDisplayName, Application, ActionType, ActivityType, IPAddress, CountryCode, OSPlatform, ObjectName, ObjectType
| order by Timestamp desc

1
2
3
4
5
6
7

let lookback = 1d;
let accountUpn = "admin@contoso.com";
DeviceEvents
| where Timestamp >= ago(lookback)
| where InitiatingProcessAccountUpn =~ accountUpn
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessSHA1, RemoteIP, RemoteUrl, ReportId
| order by Timestamp desc

1
2
3
4
5
6

let lookback = 7d;
AlertEvidence
| where Timestamp >= ago(lookback)
| where CloudPlatform =~ "Azure" or isnotempty(ResourceID) or EntityType in~ ("CloudResource", "AzureResource", "User", "Device")
| project Timestamp, AlertId, Title, Severity, ServiceSource, EntityType, EvidenceRole, AccountUpn, DeviceName, CloudResource, ResourceType, ResourceID, SubscriptionId
| order by Timestamp desc

The table boundary matters. Microsoft documents CloudAppEvents as Defender for Cloud Apps activity, DeviceEvents as Defender for Endpoint device events, and AlertEvidence as alert entities from Defender services and onboarded Sentinel workspaces. Use these as pivots from an Azure investigation, not as proof that all Azure control-plane data exists inside XDR.

Learn More

• Azure Security Telemetry Toolkit
• Advanced hunting overview
• Advanced hunting best practices
• Custom detections in Defender XDR
• Microsoft Sentinel in the Defender portal