Thirty days of raw data, ten minutes per query, and one hundred thousand rows. Hunting is a discipline, not a search box.
Advanced hunting explores up to 30 days of raw Defender XDR data across endpoints, email, cloud applications and identity, with Sentinel tables available at the retention you configured. The published limits are specific, and knowing them is the difference between a hunt that answers a question and a query that times out.
- 30 daysNative Defender XDR data, per query
- 10 minutesQuery timeout, per query
- 100,000 rowsMaximum result set
- Two modesGuided query builder, or KQL from scratch
Seven things that determine whether hunting produces anything.
Five sources in one query surface
Queries can check a broader data set coming from Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, Defender for Identity and Microsoft Sentinel. That is the property that makes hunting different from searching a single product. A question that starts at an email and ends at a process on a workstation is one query rather than three investigations.
Guided mode and advanced mode, and both are legitimate
Microsoft supports two modes and describes them plainly: guided mode for those not yet familiar with Kusto Query Language or who prefer the convenience of a query builder, and advanced mode for those comfortable writing KQL from scratch. Teams get real value from guided mode long before anybody on them is fluent, which matters for adoption.
A hunt can become a detection without rewriting it
Microsoft states you can use the same threat hunting queries to build custom detection rules, which run automatically to check for and then respond to suspected breach activity, misconfigured machines and other findings. That is the payoff loop. A good hunt is not a one-off answer, it is a detection you did not previously have.
Thirty days, and extending it is a deliberate decision
Each query can look up native Defender XDR data from up to the past 30 days. To retain hunting tables longer, Microsoft directs you to onboard a Sentinel workspace and configure analytics-tier retention for those tables, at which point the available range for those tables follows that retention. Streaming to external services is the other route, and retention there starts the day you enable it.
Four hard limits, and you will hit at least two
One hundred thousand rows per result set. Ten minutes per query before the service returns an error. A 64 megabyte results size limit which Microsoft notes is not simply a record count, since column count, data types and field lengths all contribute. And CPU resources allocated by tenant size, refreshed every fifteen minutes.
Data freshness differs by table type
Event and activity data populating alert, security event, system event and assessment tables arrives almost immediately after the collecting sensors transmit it. Entity data about users and devices comes from both static sources such as directory entries and dynamic sources such as event logs, and those tables are updated hourly with the latest comprehensive record for each entity.
Permissions are granular, and that is worth using
Unified role based access control separates access to the email and collaboration tables from access to the alerts and behaviours schema. Email and Collaboration role groups, Exchange Online role groups and several Entra roles each grant defined access, with Global Administrator, Security Administrator, Security Reader and Global Reader granting full read access to all advanced hunting data.
One badly written query can block hunting for the whole tenant.
The CPU quota is shared across the tenant and is documented, but almost nobody reads the quota table before starting to hunt.
- Quoted: CPU resources are allocated based on tenant size and refresh every 15 minutes. The portal displays a warning whenever a query runs and the tenant consumes over 10 percent of allocated resources.
- Quoted: queries are blocked if the tenant reaches 100 percent, until after the next 15-minute cycle. That is a tenant-wide effect, not a per-analyst one, so an unbounded query written during an incident can stop everybody else hunting.
- The other limits interact with this. A query with no time filter, selecting every column across thirty days, will hit the ten minute timeout or the 64 megabyte results limit while consuming a large share of the tenant allocation on its way there.
- The discipline is simple and it is the first thing we teach: filter by time first, project only the columns you need, summarise rather than returning raw rows, and test on a narrow window before widening. It is also why we do not hand an untrained team advanced mode during an active incident.
Four things that turn a training course into a practice.
We teach against your data, not a lab tenant
The tables that matter are the ones your estate actually populates, and those differ by which Defender products are onboarded and how your business works. Learning to query a lab produces people who can write KQL. Learning to query your tenant produces people who know what normal looks like in it, which is the actual prerequisite for hunting.
We start with the limits, because they shape every query
Thirty days, ten minutes, one hundred thousand rows, 64 megabytes, and a CPU allocation shared across the tenant that blocks everyone at one hundred percent. Teaching those first produces query habits that work. Teaching syntax first produces a team that writes elegant queries which time out during the incident they were needed for.
We write hunts as hypotheses with an outcome either way
A hunt that finds nothing is a result, provided the hypothesis was written down and the negative recorded so nobody repeats it in three months. A backlog of hypotheses relevant to your sector is what keeps hunting productive after the enthusiasm of the first fortnight, which is exactly when most programmes stop.
We convert what works into detections that run without us
Microsoft supports using the same hunting queries to build custom detection rules that run automatically and respond to suspected breach activity, misconfigured machines and other findings. That conversion step is what makes hunting compound. Without it, every hunt is a one-off and the capability is worth only the hours put into it.
Four phases, and nobody starts in advanced mode.
- 01Weeks 1 to 2
Access, limits and guided mode
Permissions assigned deliberately, since unified role based access control separates email and collaboration table access from the alerts and behaviours schema and several Entra roles grant full read access. Then the quota table walked through in detail, and first hunts run in guided mode so the team gets results before it gets syntax.
- Permission model chosen rather than defaulting to broad Entra roles
- Quota table understood, especially the tenant-wide CPU limit
- First hunts run in guided mode against real questions
- Time zone convention agreed, since all data is in UTC
- 02Weeks 3 to 6
KQL fundamentals against your own data
Advanced mode, taught against your tenant rather than a lab, because the tables that matter are the ones your estate actually populates. Emphasis on the habits that avoid the limits: filter by time first, project the columns you need, summarise rather than list, and test narrow before widening.
- Working knowledge of the tables your estate populates
- Query habits that respect the timeout and size limits
- A shared query library with comments and owners
- Joins across endpoint, email and identity data understood
- 03Weeks 7 to 10
Hunts that answer real questions
Structured hunts driven by hypotheses relevant to your sector rather than by generic queries copied from the internet. Each hunt produces one of three outcomes: nothing found and the hypothesis retired, something found and escalated, or something found that should have alerted and did not.
- A hunt backlog written as hypotheses, not as queries
- Findings escalated through the normal incident process
- Gaps identified where a hunt found what no detection caught
- Results documented so a negative hunt is not repeated blindly
- 04Ongoing
Convert hunts into detections
The queries that found something become custom detection rules that run automatically to check for and respond to the same activity. That is what makes hunting compound rather than repeat. A team that hunts weekly and converts monthly ends the year with detections nobody could have bought.
- Custom detection rules built from proven hunting queries
- Detection tuning before rules reach the analyst queue
- A cadence for hunting that survives a busy month
- Retention decisions revisited where 30 days proved too short
Six UAE situations where hunting answers a question nothing else will.
A bank asked whether it was affected by a named campaign
A published advisory names indicators, and the question is whether any of them appear in your estate. That is a hunt across up to thirty days of endpoint, email, cloud application and identity data, answered in an afternoon. Without hunting, the honest answer is that nobody knows, which is not an answer a regulator accepts.
A firm investigating a suspicious email after the fact
The email tables cover events, URL information, attachment information, post-delivery events, campaign information and URL click events. That combination answers who received it, who clicked, what happened next on their device, and whether anybody else in the organisation got the same message from a different sender.
A group that suspects a detection gap rather than an absence of threats
The most valuable hunting outcome is finding something real that no alert fired on, because that identifies a specific gap you can close. Converting that hunt into a custom detection rule means the gap closes permanently rather than being noticed again by a different analyst next year.
An operator that needs to look back further than a month
Native Defender XDR data is limited to thirty days per query. Microsoft directs organisations needing longer to onboard a Sentinel workspace and configure analytics-tier retention on the relevant tables. That is a decision to take before the incident that needs ninety days of history, because retention cannot be applied retrospectively.
A team building capability rather than buying hours
Guided mode exists so a team can produce useful results before anybody is fluent in Kusto Query Language, which changes the adoption curve entirely. Starting there, then moving to advanced mode against real questions, builds a capability that persists rather than a dependency on whoever wrote the queries.
An organisation preparing evidence for an audit or an insurer
Being able to demonstrate proactive threat hunting, with a documented hypothesis backlog, recorded outcomes and detections created from findings, is a materially stronger position than a statement that alerts are monitored. It is also one of the clearer signals that a security function is operating rather than merely staffed.
How UAE security teams look for what nobody alerted on.
| Feature | A hunting practice | Query during incidents only | Alerts only |
|---|---|---|---|
Queries data across all Defender products | Yes | Sometimes | No |
Hunts run on a schedule | Yes | No | No |
Hypothesis driven rather than tool driven | Yes | No | Not applicable |
Findings escalated properly | Yes | Yes | Not applicable |
Hunts converted into detections | Yes | Rarely | No |
Detection gaps identified proactively | Yes | No | No |
Query library maintained | Yes | No | No |
Service limits understood | Yes | Learned the hard way | Not applicable |
Retention configured for the questions asked | Yes | No | No |
Capability survives an analyst leaving | Yes | No | Not applicable |
Five quotas, and what each one means in practice.
| Quota or parameter | Published limit | Practical consequence | |
|---|---|---|---|
| Date range | 30 days for native Defender XDR data, Sentinel tables per configured analytics-tier retention | A hunt for something older than a month needs Sentinel retention configured in advance, not afterwards | |
| Result set | 100,000 rows per query | Summarise rather than list. A hunt that needs more than 100,000 rows is asking the wrong question | |
| Timeout | 10 minutes per query | Filter by time in the first line. Every optimisation after that is secondary to this one | |
| CPU resources | Based on tenant size, refreshed every 15 minutes, warning above 10 percent, blocked at 100 percent | A tenant-wide resource. One careless query can stop the whole team hunting until the next cycle | |
| Results size limit | 64 MB, affected by column count, data types and field lengths as well as record count | Projecting fewer columns is often more effective than returning fewer rows | |
| API queries | A separate set of quotas and parameters applies | Automation should be designed against the API limits, not the portal ones | |
| Sentinel data lake | Data stored exclusively in the data lake is not available in advanced hunting | Use data lake exploration for that data. Assuming otherwise produces empty results, not errors | |
| Time zone | All data is in Coordinated Universal Time, and queries must be written in UTC | Results are converted to your configured timezone, which is exactly how off-by-four-hours mistakes happen |
Five steps, and the last one is what makes it worth doing.
- 1
Set up access and confirm what data you can reach
Permissions assigned deliberately rather than defaulting to broad Entra roles, since unified role based access control separates email and collaboration table access from the alerts and behaviours schema. Then which Defender products are onboarded, whether Sentinel is connected, and what analytics-tier retention its tables carry.
- 2
Teach the limits before the syntax
Thirty day range, one hundred thousand row result set, ten minute timeout, 64 megabyte results size affected by columns as well as records, and a tenant-wide CPU allocation that blocks all queries at one hundred percent until the next fifteen minute cycle. Plus the UTC convention, which is the source of most confusing early results.
- 3
Build query capability in guided then advanced mode
Guided mode first so the team produces useful output immediately, then advanced mode against real questions in your own tenant. The emphasis throughout is on habits that respect the limits: time filter first, project only what you need, summarise rather than list, test narrow then widen.
- 4
Run structured hunts against a hypothesis backlog
Hypotheses relevant to your sector and your estate, each with a recorded outcome whether or not anything was found. Findings escalate through your normal incident process rather than into a report, and anything found that no detection caught is flagged explicitly as a gap.
- 5
Convert proven hunts into custom detections
The queries that found something become detection rules that run automatically. Each is tuned before it reaches the analyst queue, because a detection that produces noise is worse than the gap it closed. This is the step that makes the whole engagement compound rather than expire.
What organisations ask about advanced hunting.
Fifteen things worth settling first.
Access and data
- Who needs email and collaboration table access?It is a separate permission.
- Is Sentinel onboarded to the Defender portal?It extends what you can query.
- Is any data only in the Sentinel data lake?That is not available in advanced hunting.
- What retention do your Sentinel tables have?It sets the range beyond 30 days.
- Are all four Defender products onboarded?Each adds tables to hunt across.
Technique
- Does everyone know the CPU quota is shared?One query can block the tenant.
- Is time filtering the first habit taught?It prevents most timeouts.
- Do people project only needed columns?Size limit is not just row count.
- Is everyone writing queries in UTC?All data is UTC, results are converted.
- Is there a shared query library?With comments, so it survives turnover.
Making it a practice
- Is there a recurring hunting slot?Otherwise it is always next week.
- Are hunts written as hypotheses?Not as queries looking for a purpose.
- Where do findings go?The normal incident process, not a document.
- Are proven hunts converted to detections?That is what makes it compound.
- Is a negative result recorded?So nobody repeats it in three months.
The pages around this one.
Pick one question you cannot currently answer about your estate.
Whether a named indicator appeared. Who else received that email. What ran on that machine before the alert. If the honest answer today is that nobody knows, that is exactly the hunt to start with.
Related Services
Explore more solutions that work great with this service
Defender XDR
Eleven signal sources, one incident, and containment without a human
Sentinel SOC Optimization
Coverage gaps and ingestion you are not using
SOC-as-a-Service
24/7 SOC on Microsoft Sentinel
Microsoft Sentinel
Cloud-native SIEM and threat intelligence
Managed Security Services
MSS on Microsoft Defender XDR and Sentinel
Incident Response
24/7 incident response and forensics in Dubai
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you