0.4 Sentinel Logs and Defender Advanced Hunting Compared

Introduction

Security analysts run KQL in two main places. Microsoft Sentinel keeps its data in a Log Analytics workspace and queries it in its Logs view. Microsoft Defender runs queries in Advanced Hunting, in the Defender portal, over the data its products collect. The two have grown closer over time, and Microsoft's Advanced Hunting documentation describes running queries over Sentinel's tables from the Defender portal once a workspace is onboarded.

The language is identical in both, down to the last operator. What differs is the data each holds, the name of the time column on some tables, how far back each can see, and the limits each enforces. This sub sets the two side by side, using the lab, which behaves like a Sentinel workspace with Defender's data streamed into it.

You'll see which tables carry TimeGenerated and which carry Timestamp, and filter the same day in each, getting the counts each table really holds. You'll check how far back the lab's data reaches, and write a query that stays inside either portal's limits. At the end, you'll combine both kinds of table in one query, each read with its own time column.

The diagram summarizes the differences that matter for writing queries, one row per difference. The data, the time column, the row limit and the rule type each differ; the language does not. The limits are Microsoft's documented figures, checked when this sub was written and worth checking again later.

Microsoft Sentinel is Microsoft's cloud SIEM, a security information and event management service: it collects data from many sources into a Log Analytics workspace, and its Logs view, its analytics rules, its workbooks and its hunting queries all use KQL against that workspace. Its tables include everything connected to it, from Entra sign-ins to firewall logs, and its retention is set per workspace and, in places, per table.

Advanced Hunting is the query tool in the Microsoft Defender portal, where Defender's incidents and alerts are worked.

Microsoft's overview describes it as a way to explore up to 30 days of raw data from Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps and Defender for Identity, and from Microsoft Sentinel when a workspace is connected to the Defender portal. Its custom detection rules turn queries into scheduled detections.

union withsource = SourceTable Syslog, CommonSecurityLog, DeviceProcessEvents, EmailEvents
| summarize Rows = count() by SourceTable

The lab holds both kinds of source, as a workspace connected to Defender does, and counts them in one query: Syslog and the firewall's records arrive through Sentinel's data connectors, and the process and mail tables come from Defender. One query reads all four, because the language and the workspace do not care where a table came from; only the columns each table carries differ.

For a learner, the practical point is that everything in this course works in both. A query is written the same way in both; only the tables available, a few column names and the limits change, and each is a check rather than a rewrite.

The two products also differ in who uses them day to day. Sentinel is often where a SOC's detections, investigations and reports live, because it holds every source. Advanced Hunting is often where endpoint and mail investigations start, because Defender's data is richest there and its incidents link straight to it. Many teams use both, and the queries move between them.

Both also come in the same portal for many organizations now. Microsoft's documentation describes onboarding a Sentinel workspace to the Defender portal, after which its tables appear in Advanced Hunting beside Defender's own, and the workspace's limits apply to queries over them as well as Advanced Hunting's.

The most visible difference between the two is the name of the time column, and it is the one most likely to break a query moved between them. Tables that Sentinel ingests use TimeGenerated. Defender's own tables, the Device, Email, Identity and CloudApp tables, use Timestamp.

union (SigninLogs | getschema | where ColumnName in ("TimeGenerated", "Timestamp")
        | extend SourceTable = "SigninLogs"),
    (AuditLogs | getschema | where ColumnName in ("TimeGenerated", "Timestamp")
        | extend SourceTable = "AuditLogs"),
    (DeviceProcessEvents | getschema | where ColumnName in ("TimeGenerated", "Timestamp")
        | extend SourceTable = "DeviceProcessEvents"),
    (EmailEvents | getschema | where ColumnName in ("TimeGenerated", "Timestamp")
        | extend SourceTable = "EmailEvents")
| project SourceTable, ColumnName

The sign-in and audit tables come from Entra and carry TimeGenerated; the process and mail tables come from Defender and carry Timestamp. Defender tables streamed into a Sentinel workspace also carry TimeGenerated alongside their own Timestamp, which is why the lab accepts either on them; in Advanced Hunting, Timestamp is the name to use.

DeviceProcessEvents
| where Timestamp between (datetime(2026-03-12) .. datetime(2026-03-13))
| count

Filtering Defender's process table on Timestamp for 12 March, a Thursday, gives 475 process starts. Because Timestamp is present on Defender's tables in both places, under the same name and with the same meaning in each, it is the safe column to use for any query on those tables that should run in either portal.

The lab, like a Sentinel workspace, also accepts TimeGenerated on them; that convenience should not be relied on in queries meant for Advanced Hunting.

The completed query below uses the Defender column.

475 again. getschema answers the question for any table in a second, as Section 0.2 showed, which is the habit to keep when a table is unfamiliar.

SigninLogs
| where TimeGenerated between (datetime(2026-03-12) .. datetime(2026-03-13))
| summarize SignIns = count(), Accounts = dcount(UserPrincipalName)

The Entra sign-in table, filtered on TimeGenerated for the same day, the other column name in use, gives the day's sign-ins and the number of accounts that made them. TimeGenerated is the name every table Sentinel ingests uses, which makes the Entra tables' time column the same in both portals.

Getting the time column wrong is not a subtle error in Advanced Hunting: a filter on a column the table does not have fails at once, with a message naming the column.

The subtler problem is the reverse, a query written for Advanced Hunting with Timestamp on a table that, in a workspace, has both, and a colleague who changes one filter but not the other. Choosing one column per table, and writing it the same everywhere a query is used, avoids it.

Both time columns are datetimes in UTC, whichever name they carry, so filters, bins and comparisons work the same way on either. Only the name changes, which is why getschema, not memory, is the reliable way to choose it.

The second difference is how far back a query can see, and it matters most when an investigation starts late. Microsoft's Advanced Hunting documentation states that each query can look up Defender data from up to the past 30 days, or longer if the data is streamed through Microsoft Sentinel. A Sentinel workspace keeps data for its configured retention, which an organization sets and can make much longer.

union withsource = SourceTable SigninLogs, DeviceProcessEvents, EmailEvents
| summarize Earliest = min(TimeGenerated), Latest = max(TimeGenerated) by SourceTable

Checking each table's earliest and latest time shows what period a query can cover. The lab's tables all cover the sample month, 13 February to 15 March, so the difference never arises here.

In a real investigation it often does. An attack discovered six weeks after it began has left its first traces outside Advanced Hunting's window for Defender data, and the only place to find them is a workspace that kept them.

This is a reason to know, before an incident, where each kind of data is kept and for how long, written down where the whole team can find it. An analyst who reaches for Advanced Hunting by habit and finds nothing older than a month may conclude the data never existed.

Retention is also a cost decision for the organization, because keeping data longer costs more, and the decision is usually made before anyone needs the data. Analysts who know the retention of each table can say, when an incident starts, how far back the investigation can go, and can argue for longer retention on the tables that matter most.

The lab removes this question by holding one month in every table, which is right for learning and unlike any real workspace. When the course's techniques are used on real data, the period becomes the first thing to check, before any filter is written.

Across the sub so far, the two portals differed in their time columns and in how far back they see, and in nothing about the language itself. Both read the same KQL, and the lab, which behaves like a Sentinel workspace with Defender data streamed into it, accepts both time columns on Defender tables.

The record collects the differences, with their source, in the form of a reference to keep beside the portal.

The last row matters as much as the others, because figures like these change. These figures are from Microsoft Learn as of October 2026, and Section 10.5 explains why limits are worth checking again before relying on them, and shows exactly what truncation looks like in a result when they are reached.

The first rung costs a count; the second a getschema. The second rung prevents the most common portability problem. A query that names each table's own time column runs in both places; one that assumes TimeGenerated everywhere fails in Advanced Hunting on every Defender table.

The first and third mistakes fail loudly or show up in testing. The second mistake is the one with investigative consequences. A hunt that should reach back three months can only do so where three months of data exist.

The lab does not reproduce either portal's look-back or limits; it holds one month and runs every query against all of it. That is deliberate, so that every number in the course can be reproduced, and Section 0.6 lists it among the ways the lab differs from a real workspace.

In practice, then, an investigation starts with two questions about its tables: which to read, and where they are kept and for how long. A short note of each important table's retention, kept with a team's other reference material, answers it in advance.

Both portals protect themselves with limits, as any shared service must, which Section 10.5 sets out in full from Microsoft's documentation.

Advanced Hunting returns up to 100,000 rows per query and a Log Analytics query up to 500,000, figures Microsoft documents on Microsoft Learn; both stop a query after ten minutes; Advanced Hunting also allocates CPU to each tenant over 15-minute cycles, and Log Analytics limits each user to five concurrent queries.

let Total = toscalar(DeviceProcessEvents | count);
DeviceProcessEvents
| summarize Starts = count() by DeviceName
| top 3 by Starts desc
| extend AllStarts = Total

In either portal, the way to live within any of these limits is to ask for answers rather than raw rows, which is also how questions are best asked anyway. A summary of process starts by device, the top three with the month's total carried beside them, is three rows, far inside either limit, and says more than the 9,576 rows it summarizes.

The exercise below turns raw rows into an answer.

Eighteen rows instead of 9,576, one per device, with the busiest first. In a real tenant, the raw version could reach a portal's row limit in a single day; the summary would not reach it in a year.

The limits rarely matter for a well-written query, and matter a great deal for a careless one. Section 10.4's join of two small tables produced nearly three times Advanced Hunting's row limit, and the same query reduced to the right grain produced sixteen rows. The difference between the portals' limits is far smaller than the difference between those two queries.

Shared budgets are the reason a query's efficiency is a courtesy to colleagues as well as a convenience. An expensive query in Advanced Hunting uses CPU that the whole tenant shares over each 15-minute cycle, and in Log Analytics a slow query occupies one of the user's five concurrent slots for as long as it runs.

Both portals turn queries into detections that run on a schedule, which is where much of a SOC's KQL ends up. Sentinel calls them analytics rules; Defender calls them custom detection rules.

The names differ more than the ideas. Both are KQL queries with a schedule, a look-back window and a description of what to raise when the query returns rows, and both are written with the operators this course teaches.

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"
| summarize Failures = count() by UserPrincipalName
| where Failures > 5

A rule is a query with a schedule. Asked of the last hour of the sample month, this one returns nothing: no account failed more than five sign-ins in that hour. That is the normal case for a rule, and an empty run is not a failure, which runs every hour and alerts only when its shape appears.

Microsoft's Advanced Hunting documentation notes that its quotas and usage parameters apply separately to queries run by hand and to queries run by custom detection rules. Sentinel's analytics rules run in the workspace, with its limits. In either place, the habits of Module 10 decide how much a rule costs to run.

Detection engineering, specifying, testing and tuning those rules, is the subject of a separate course on the platform; this course teaches the queries that rules are built from, and notes along the way which techniques become rules and how.

Rules in both portals also need a look-back window and a frequency, and the arithmetic of Section 10.2 applies: a rule that runs every five minutes over a day of data reads each event hundreds of times. The cheapest rule reads only what has arrived since it last ran, with a small overlap for late data.

A rule's query is held to a higher standard than an investigation's, in either portal, because it runs unattended for months. The checks this course teaches, on names, values, grain and known cases, matter most there, and a rule that has never been tested against a known case has never been shown to work.

The rule-shaped query above also shows a habit worth forming early: writing the threshold and the window as plain numbers in the query, where a reader can see them and question them. Module 7 shows how to name them with let so that they sit at the top of a query, where tuning them is a one-line change.

Many analysts work in both portals, often in the same day, and many queries are shared between people who use one or the other. A few habits make a query portable.

Name each table's own time column, as Section 02 showed, and check it with getschema when the table is new. Check that each table exists in the portal that will run the query; some tables exist only in a workspace, such as Syslog and the firewall's CommonSecurityLog, and some appear in Advanced Hunting only once a workspace is onboarded.

Return answers rather than raw rows, so neither portal's limit is reached. And state the period the query covers, in the query itself rather than in the portal's time picker, so that someone running it in Advanced Hunting knows whether 30 days of Defender data is enough.

DeviceLogonEvents
| where Timestamp between (datetime(2026-03-01) .. datetime(2026-03-08))
| summarize Logons = count(), Devices = dcount(DeviceName), Accounts = dcount(AccountName)

The week's device logons, from 1 to 8 March, filtered on the Defender table's own time column and returned as a single summary row, make a small example of all four habits at once. Nothing in it needs changing to run in a workspace or in Advanced Hunting.

None of these changes the logic of a query. They are the same checks Section 10.6 applies to any borrowed query, applied in advance, which is easier.

Portability is worth the small effort because queries outlive the people who write them. A hunting query saved in one portal is found and reused by a colleague in the other; a rule is migrated when a team changes how it works. Each of those moments goes smoothly if the query was written to run in either, and costs an afternoon of debugging if it was not.

The same habits help with the lab. Queries written in this course name each table's real time column and return answers, so they can be pasted into a real workspace or into Advanced Hunting and run with, at most, a change of period.

The exercise counts one day in two tables from different families, a sign-in table and a Defender table, each filtered on its own time column, and returns the two counts side by side.

The grader checks for two rows, with 475 process starts among them. If one count is zero or the query fails, check that each table is filtered on its own time column, TimeGenerated for the sign-ins and Timestamp for the process starts.

The query is a union of two counts, each with its own filter, which is a pattern worth reusing whenever tables from both families need comparing.

Read the two rows as a small portable query, and as a template for comparing any two table families on one day. Each table is read with the column it really has, the result is two rows, and the period is stated in the query itself. Written this way, it runs in a Sentinel workspace and, once the workspace is onboarded to the Defender portal, in Advanced Hunting.

Practice

Check the tables exist, use each table's own time column, return answers, and mind how far back each portal sees.

The next sub, Section 0.5, takes one question from words to a checked answer: your first full query.