Thirty days back, ten minutes of runtime, a hundred thousand rows returned. Those are the walls you work inside. Hunting is a practice, not a search field.
You get up to 30 days of raw Defender XDR data covering endpoints, email, cloud applications and identity, alongside Sentinel tables held for whatever retention you configured. The service limits are published and precise. Knowing them is what separates a hunt that returns an answer from a query that dies at the ten minute mark. We build the practice alongside your analysts, remotely, working in your own tenant rather than a lab.
- 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
A single query reaches across data from Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, Defender for Identity and Microsoft Sentinel together. That breadth is what distinguishes hunting from searching inside one product. A question beginning with an email attachment and ending at a process running on a laptop becomes one query instead of three separate investigations handed between people.
Guided mode and advanced mode, and both are legitimate
Two modes are supported. Guided mode is aimed at people who do not yet know Kusto Query Language, or who simply prefer working through a query builder. Advanced mode is for anyone happy writing KQL from a blank page. The point worth making is that teams extract genuine value from guided mode well before a single analyst becomes fluent, and that is what makes adoption realistic.
A hunt can become a detection without rewriting it
The same query you wrote for a hunt can be promoted into a custom detection rule that runs on its own, checking for and then responding to suspected breach activity, misconfigured machines and whatever else you defined. That loop is where the return comes from. A hunt that ends in an answer is worth something once. A hunt that ends in a detection is worth something permanently.
Thirty days, and extending it is a deliberate decision
Native Defender XDR data reaches back 30 days per query, no further. Extending that means onboarding a Sentinel workspace and setting analytics-tier retention on the tables you care about, after which those tables become queryable for as long as that retention holds. Streaming to an external service is the alternative path, with one caveat worth stating out loud: retention there begins on the day you switch it on, not retroactively.
Four hard limits, and you will hit at least two
Four numbers govern everything. A result set caps at one hundred thousand rows. A query gets ten minutes before the service errors out. Results are bounded at 64 megabytes, and the documentation is careful to say this is not a row count, because column count, data types and field lengths all feed into it. And CPU is allocated according to tenant size, with the allowance refreshed every fifteen minutes.
Data freshness differs by table type
Two freshness models operate side by side. Event and activity data filling the alert, security event, system event and assessment tables lands almost as soon as the collecting sensors send it. Entity data covering users and devices is assembled from static sources such as directory entries and dynamic ones such as event logs, and those tables refresh hourly with the most complete record available for each entity.
Permissions are granular, and that is worth using
Under unified role based access control, permission to read the email and collaboration tables is held separately from permission to read the alerts and behaviors schema. Access can arrive through Email and Collaboration role groups, through Exchange Online role groups, or through several Entra roles. Four of those, Global Administrator, Security Administrator, Security Reader and Global Reader, carry full read access to every advanced hunting table.
A single careless query is enough to shut hunting down across the entire tenant.
That CPU quota is tenant-wide and its allocations are published, yet hardly anyone opens the quota table before they start hunting.
- Straight from the service limits: the allocation follows tenant size and resets on a fifteen minute cycle. Cross ten percent of it on a running query and the portal starts warning you.
- Hit one hundred percent and queries stop being accepted until the next fifteen minute cycle comes round. The block applies to the tenant, not to the analyst who caused it, so one unbounded query typed during an incident takes the rest of the team offline with it.
- These limits compound rather than sit independently. Ask for every column across thirty days with no time filter and you will meet either the ten minute timeout or the 64 megabyte ceiling, having burned through a substantial slice of the tenant allocation getting there.
- Four habits cover almost all of it, and they are the first thing we teach. Filter on time before anything else. Project the columns you actually need and nothing more. Summarize instead of pulling back raw rows. Prove the query on a narrow window before opening it up. The same reasoning is why we will not put an untrained team into advanced mode in the middle of a live incident.
Four things that turn a training course into a practice.
We teach against your data, not a lab tenant
Which tables matter depends on which Defender products you have onboarded and how your business actually operates, so the answer is different in every tenant. Train someone in a lab and you get an analyst who can write KQL. Train them in your tenant and you get an analyst who knows what normal looks like there. The second is the real prerequisite for hunting; the first is just syntax.
We start with the limits, because they shape every query
Thirty days of history. Ten minutes of runtime. A hundred thousand rows. Sixty four megabytes. And a CPU allocation shared tenant-wide that locks everybody out at one hundred percent. Teach those constraints first and the query habits that follow are sound. Teach syntax first and you get a team writing elegant queries that time out during the one incident they were needed for.
We write hunts as hypotheses with an outcome either way
Finding nothing is still a finding, as long as the hypothesis was written down beforehand and the negative result recorded so nobody runs the identical hunt again next quarter. What sustains the practice past the initial fortnight of enthusiasm, which is precisely when most of these programs quietly stop, is a standing backlog of hypotheses that matter in your industry.
We convert what works into detections that run without us
The same hunting query can be turned into a custom detection rule that runs automatically and responds to suspected breach activity, misconfigured machines and anything else you defined. That conversion is what lets the effort accumulate. Leave it out and every hunt is disposable, worth exactly the hours somebody spent on it and nothing more.
Four phases, and nobody starts in advanced mode.
- 01Weeks 1 to 2
Access, limits, and guided mode
Permissions get assigned on purpose rather than inherited, because unified role based access control holds email and collaboration table access apart from the alerts and behaviors schema, and because several Entra roles hand out full read access. We then go through the quota table line by line, and run the first hunts in guided mode so the team sees results before it has to learn syntax.
- A permission model decided deliberately instead of falling back on 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
We teach advanced mode inside your own tenant, never a lab, because the tables worth knowing are the ones your estate genuinely fills. The emphasis throughout is on habits that keep you inside the service limits: time filter first, only the columns you need, summarize rather than list, and prove it narrow before you widen it.
- 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
Hunts are structured around hypotheses that mean something in your industry, not around queries lifted off a blog. Every hunt closes with one of three results: nothing there and the hypothesis retired, something there and escalated, or something there that your detections should have caught 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
- Every result written down, so nobody reruns a negative hunt a quarter later without knowing
- 04Ongoing
Convert hunts into detections
Any query that found something gets promoted into a custom detection rule, running on its own to catch and respond to the same activity next time. This is the step that makes the effort compound instead of repeat. Hunt weekly, convert monthly, and by December you hold detections that were not available from any vendor.
- 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 US situations where hunting answers a question nothing else will.
A financial firm asked whether it was affected by a named campaign
An advisory lands from CISA, or a vendor publishes a bulletin, and it names indicators. The question that follows is whether any of them are present in your environment. With hunting that is one query across up to thirty days of endpoint, email, cloud application and identity data, closed out the same afternoon. Without it, the truthful answer is that nobody knows, and neither an examiner nor a board will accept that.
A firm investigating a suspicious email after the fact
Six email tables are available: events, URL information, attachment information, post-delivery events, campaign information and URL click events. Between them they answer the questions that matter after a phishing report. Who received it. Who clicked. What ran on the recipient machine afterwards. And whether the same message reached anyone else in the building from a different sender address.
An organization that believes it has a detection gap rather than an unusually quiet estate
Nothing a hunt produces is worth more than a genuine finding that no alert covered, because it names a specific gap you can actually close. Turn that hunt into a custom detection rule and the gap stays closed, rather than being rediscovered by a different analyst twelve months from now.
An operator that needs to look back further than a month
Thirty days is the ceiling on native Defender XDR data in any single query. Going further means onboarding a Sentinel workspace and setting analytics-tier retention on the tables that matter to you. Make that decision well before the incident that turns out to need ninety days of history, because retention is not something you can apply backwards.
A team building capability rather than buying hours
The whole point of guided mode is that a team can return useful results before a single person is fluent in Kusto Query Language, and that reshapes the adoption curve completely. Begin there, then graduate into advanced mode against questions the business actually has, and what you end up with is a capability rather than a dependency on whoever happened to write the original queries.
An organization preparing evidence for an audit or an insurer
Walking into a SOC 2 audit, a HIPAA risk analysis or an insurance questionnaire able to evidence proactive hunting, with a hypothesis backlog on paper, outcomes recorded and detections built from what was found, puts you in a far stronger position than a sentence saying alerts are monitored. It is also one of the clearest indicators that a security function is genuinely operating and not simply staffed.
How US 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
Date range
- Published limit
- Native Defender XDR data reaches back 30 days; Sentinel tables follow whatever analytics-tier retention you set
- Practical consequence
- Anything you want to hunt beyond a month has to have had Sentinel retention configured before the fact
Quota or parameter
Result set
- Published limit
- 100,000 rows per query
- Practical consequence
- Summarize instead of listing. If a hunt genuinely requires more than 100,000 rows, the question needs rewriting
Quota or parameter
Timeout
- Published limit
- 10 minutes per query
- Practical consequence
- Filter by time in the first line. Every optimization after that is secondary to this one
Quota or parameter
CPU resources
- Published limit
- Sized to the tenant, reset every 15 minutes, warned at 10 percent, blocked outright at 100
- Practical consequence
- Shared across the whole tenant, so a single careless query takes the team offline until the cycle resets
Quota or parameter
Results size limit
- Published limit
- 64 MB, driven by column count, data types and field lengths, not just how many records came back
- Practical consequence
- Cutting columns usually helps more than cutting rows does
Quota or parameter
API queries
- Published limit
- A separate set of quotas and parameters applies
- Practical consequence
- Anything automated has to be built against the API limits rather than the portal figures
Quota or parameter
Sentinel data lake
- Published limit
- Anything held only in the data lake cannot be reached from advanced hunting
- Practical consequence
- That data needs data lake exploration instead. Assume otherwise and you get empty results rather than an error message
Quota or parameter
Time zone
- Published limit
- Everything is stored in Coordinated Universal Time, and every query has to be written that way
- Practical consequence
- The results come back converted into your configured timezone, and that mismatch is where hour-shifted mistakes come from
Five steps, and the last one is what makes it worth doing.
- 1
Set up access and confirm what data you can reach
We assign permissions on purpose instead of letting broad Entra roles cover it, because unified role based access control keeps email and collaboration table access apart from the alerts and behaviors schema. Alongside that we establish which Defender products are actually onboarded, whether Sentinel is connected, and what analytics-tier retention sits on its tables.
- 2
Teach the limits before the syntax
Six things get covered: the thirty day range, the hundred thousand row result set, the ten minute timeout, the 64 megabyte size limit that columns influence as much as records, the tenant-wide CPU allocation that stops every query at one hundred percent until the next fifteen minute cycle, and the UTC convention, which is behind most of the puzzling results a new hunter gets in their first week.
- 3
Build query capability in guided then advanced mode
We start in guided mode so the team is producing something useful straight away, then move into advanced mode against questions your business actually has, inside your own tenant. Throughout, the habits being drilled are the ones that keep queries inside the limits: filter on time first, project only what is needed, summarize instead of listing, and prove it narrow before widening.
- 4
Run structured hunts against a hypothesis backlog
Each hypothesis is grounded in your sector and your estate, and each gets an outcome written down whether or not anything turned up. Real findings go into your normal incident process rather than sitting in a deliverable, and anything discovered that no detection had caught is recorded explicitly as a coverage gap.
- 5
Convert proven hunts into custom detections
Queries that produced a finding get turned into detection rules running on their own schedule. Every one is tuned before it ever reaches an analyst queue, because a noisy detection costs more than the gap it was meant to close. This step is why the engagement accumulates value instead of expiring on the last day.
What organizations 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.
Choose a single question about your environment that you cannot answer today.
Did a named indicator show up anywhere. Who else was sent that email. What was running on the machine before the alert fired. Wherever the truthful answer right now is that nobody knows, you have found your first hunt.
Related Services
Explore more solutions that work great with this service
Microsoft Sentinel UEBA
Behavioral analytics that surface the quiet anomalies
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn moreMicrosoft Sentinel SOC Optimization
Sentinel SOC optimization reviews for US organizations: ingestion
Learn moreSOC-as-a-Service
24/7 security operations delivered as a service
Learn moreMicrosoft Sentinel
Cloud-native SIEM and threat intelligence
Learn moreManaged Security Services
Managed security services (MSS) for US businesses, delivered remotely
Learn more