In this section
Check My Knowledge
Scenario 1. An analyst at Northgate Engineering receives an alert that j.morrison authenticated from a Tor exit node. The analyst needs to determine whether this IP has appeared in j.morrison's sign-in history across the full 180-day retention period. The Sentinel portal investigation view shows only the last 30 days by default. What should the analyst do?
Open the Entra ID sign-in logs in the Azure portal and manually scroll through pages until the IP appears or the analyst reaches the 180-day mark. a
The Entra ID portal sign-in log viewer does not support filtering by IP across the full retention period. Manually scrolling through months of paginated results is not a viable investigation method — it would take hours and you would likely miss the record. Section 0.1 demonstrates the KQL alternative that answers this in seconds.
Create a Sentinel workbook that aggregates IP addresses per user over the full retention period, then check j.morrison's entry. b
A workbook could answer this question, but building one from scratch to answer a single investigation question is the wrong tool for an active triage. Workbooks are for recurring operational reporting, not ad-hoc investigation pivots. The correct approach is a direct query against the raw table. Section 0.1 covers the three question categories — this is a historical scope question that KQL answers in a single query.
Write a KQL query against SigninLogs filtering by UserPrincipalName and IPAddress with a 180-day time window, and check whether any prior sign-ins match. c
Correct. This is a historical scope question — one of the three question categories from Section 0.1. A direct KQL query against SigninLogs with where UserPrincipalName and where IPAddress filters, scoped to ago(180d), returns every matching sign-in in seconds. If the query returns zero rows, the IP is new. If it returns rows, the analyst can examine the historical pattern to determine whether this is recurring VPN behavior or a genuine anomaly.
Export the SigninLogs table to a CSV file and use Excel to filter for j.morrison and the Tor exit node IP. d
Exporting to CSV loses the analytical power of KQL and introduces unnecessary delay. A 180-day SigninLogs export for an active user could contain tens of thousands of rows. KQL answers the question in the query editor in seconds without any data export. Section 0.4 demonstrates that the four-operator pattern handles this type of investigation directly.
Scenario 2. A SOC analyst queries EmailEvents in the Sentinel Logs blade to investigate a reported phishing email. The query returns zero results, but the user confirmed they received the email two hours ago. What is the most likely cause?
The email was delivered but the phishing filter retroactively deleted it before the event was logged. a
Retroactive deletion (ZAP — Zero-hour Auto Purge) removes the email from the mailbox but does not remove the delivery event from the log. The EmailEvents record would still exist showing the original delivery. The issue is not about ZAP. Section 0.2 explains the two query surfaces and which tables exist in each.
EmailEvents with full metadata exists in Defender XDR Advanced Hunting, not in the Sentinel Log Analytics workspace. The analyst is querying the wrong query surface. b
Correct. Section 0.2 opens with this exact scenario. EmailEvents with complete email metadata lives in Defender XDR Advanced Hunting. Sentinel ingests email-related data into OfficeActivity, which has a different schema and different field names. The analyst needs to either query EmailEvents in the Defender portal's Advanced Hunting or query OfficeActivity in Sentinel with adjusted field names.
The email was delivered to a shared mailbox, and shared mailbox events are not recorded in EmailEvents. c
EmailEvents records delivery events for both user and shared mailboxes. The mailbox type does not affect event logging. The issue is querying the wrong table in the wrong query surface, as explained in Section 0.2.
Ingestion latency means the event has not yet appeared — the analyst should wait 24 hours and retry. d
While ingestion latency is real (Section 0.2 covers this), typical latency for email events is minutes, not hours. A two-hour-old event should have been ingested. Waiting 24 hours before investigating a phishing report is operationally unacceptable. The real issue is querying the wrong query surface entirely.
Scenario 3. An analyst writes the following query and gets zero results, despite knowing that failed sign-ins occurred in the last hour:
SigninLogs | where TimeGenerated > ago(1h) | where ResultType != 0 | project UserPrincipalName, IPAddress
What is wrong with this query?
The ago(1h) function should be ago(1d) because SigninLogs has a minimum query granularity of one day. a
SigninLogs has no minimum query granularity. You can query down to the minute or even second with ago(). The one-hour window is valid. The problem is elsewhere in the query. Section 0.4 covers common first-query mistakes including this specific error.
The where clause should use where ResultType not in ("0") instead of the != operator. b
The != operator works correctly for string comparisons in KQL. Using not in would also work, but it is not necessary for a single-value exclusion. The issue is not the operator choice. Section 0.4 identifies the specific mistake in this query.
The project operator should come before the where clauses to reduce the column set before filtering. c
Placing project before where would remove the columns the where clause needs to filter on — the query would fail because ResultType would no longer exist in the dataset. Filter first, then project. Section 0.4 covers operator ordering. But this is not the error causing zero results.
ResultType is a string column. The comparison ResultType != 0 compares a string to an unquoted integer, which produces unexpected results. It should be ResultType != "0". d
Correct. Section 0.4 identifies this as one of the four common first-query mistakes: unquoted string comparisons. ResultType in SigninLogs is typed as string, not integer. Comparing a string column to an unquoted number either fails silently or performs a type coercion that produces incorrect filtering. The fix is where ResultType != "0" with the value in quotes.
Scenario 4. During an investigation into a compromised account, the analyst needs to determine whether the attacker created inbox rules to hide evidence. Which table should the analyst query, and which field identifies the specific operation?
OfficeActivity, filtering on Operation == "New-InboxRule". The OfficeObjectId or Parameters field contains the rule configuration details. a
Correct. Section 0.3 profiles OfficeActivity as the table recording what users do inside their mailbox — rule creation, message sends, forwarding configuration, and folder operations. Section 0.4 demonstrates the New-InboxRule query pattern as part of the BEC investigation example. The Operation field identifies the action type, and OfficeObjectId contains the rule parameters including keyword filters and destination folders.
EmailEvents, filtering on Subject containing "inbox rule" to find the system notification about the new rule. b
EmailEvents records email delivery events, not mailbox configuration actions. Inbox rule creation is a mailbox management operation, not an email delivery. Section 0.3 distinguishes between these two tables: EmailEvents answers "what was delivered?" while OfficeActivity answers "what did the user do in their mailbox?"
AuditLogs, filtering on OperationName == "New-InboxRule". Inbox rules are directory-level configuration changes. c
AuditLogs records Entra ID directory operations — role assignments, application consent grants, CA policy changes, and authentication method registrations. Inbox rules are Exchange Online operations, not Entra ID directory changes. Section 0.3 profiles AuditLogs as the directory change table.
SecurityAlert, filtering for alerts with AlertName containing "inbox rule". Detection products flag suspicious inbox rule creation. d
SecurityAlert might contain an alert about suspicious inbox rule creation if a detection rule fired. But the question asks which table contains the evidence of the action itself, not the alert about the action. Relying on SecurityAlert means you only find inbox rules that triggered a detection. Querying OfficeActivity directly finds all inbox rule creation regardless of whether a detection rule exists. Section 0.3 covers this distinction.
Scenario 5. A detection engineer writes a scheduled analytics rule that runs every 5 minutes with a 5-minute lookback window. The rule queries SigninLogs for failed authentications. After a week in production, the engineer discovers that some failed sign-in events are never evaluated by the rule. What architectural issue explains this?
Scheduled analytics rules cannot query SigninLogs because it is classified as a high-volume table with query restrictions. a
SigninLogs has no restrictions preventing scheduled analytics rules from querying it. It is one of the most commonly used tables in Sentinel analytics rules. The issue is not table classification. Section 0.2 explains the actual cause.
Ingestion latency causes some events to arrive after the lookback window has passed. An event that takes 6 minutes to ingest falls between two 5-minute windows and is never evaluated. The lookback window should exceed the schedule interval by at least the expected ingestion latency. b
Correct. Section 0.2 explains ingestion latency and its impact on detection rule scheduling. A 5-minute schedule with a 5-minute lookback creates a blind spot for events that take longer than 5 minutes to ingest. The recommended fix is a lookback window that exceeds the schedule interval — for example, a 5-minute schedule with a 15-minute lookback. Some events get evaluated twice, but none are missed.
The rule has exceeded the analytics rule query limit of 10,000 results per execution, causing events beyond the limit to be silently dropped. c
While analytics rules do have result limits, the scenario describes events that are never evaluated at all — not events that were evaluated and truncated. The root cause is events arriving outside the evaluation window, not result-set truncation. Section 0.2 covers this as an ingestion latency issue.
The rule is running in the Sentinel workspace but the SigninLogs data is ingested into the Defender XDR data store. The rule cannot see data in a different data store. d
If the Entra ID data connector is configured in Sentinel, SigninLogs flows into the Log Analytics workspace and is queryable by analytics rules. The two data stores (Sentinel and Defender XDR) are relevant when choosing a query surface, but a properly configured analytics rule queries its own workspace. The issue is timing, not data location.
Scenario 6. An analyst needs to investigate a suspected AiTM (adversary-in-the-middle) token replay attack. The analyst queries SigninLogs for the compromised user and finds only legitimate interactive sign-ins from the user's normal device and location. The attacker's sessions do not appear. Where is the missing evidence?
The attacker's sessions were blocked by Conditional Access and recorded with ResultType 53003 (blocked by CA policy), which the analyst's where clause excluded by filtering for successful sign-ins only. a
If the analyst filtered for ResultType == "0" only, they would miss blocked attempts. However, AiTM token replay is specifically characterized by non-interactive sign-ins, not interactive ones. Even removing the ResultType filter from SigninLogs would not surface the attacker's sessions. Section 0.3 identifies the specific table where this evidence lives.
The attacker used a different AppDisplayName than the legitimate user, so the analyst's filter on the user's normal application excluded the attacker's sessions. b
While attackers may access different applications, the fundamental issue is not the application filter. AiTM token replay generates non-interactive authentication events, not interactive ones. The evidence is in a different table entirely. Section 0.3 covers this.
AiTM token replay generates non-interactive authentication events. The attacker's sessions appear in AADNonInteractiveUserSignInLogs, not SigninLogs. Token refreshes and replayed session tokens are recorded as non-interactive sign-ins. c
Correct. Section 0.3 identifies AADNonInteractiveUserSignInLogs as the ninth table — the one that records token refreshes, application-initiated authentication, and service principal sign-ins. When an attacker replays a stolen session token, the authentication is non-interactive. The detection pattern is a non-interactive sign-in from an IP and device that do not match the user's normal interactive sign-in profile. Querying only SigninLogs during an AiTM investigation misses the attacker's operational sessions entirely.
The attacker authenticated through a federated identity provider, and federated sign-ins are recorded in IdentityLogonEvents in Defender for Identity, not in SigninLogs. d
Federated sign-ins do appear in SigninLogs when the authentication completes against Entra ID, regardless of the identity provider. IdentityLogonEvents records on-premises Active Directory authentication events captured by Defender for Identity sensors. The AiTM evidence is specifically in the non-interactive sign-in table, not in a federation-related table.
Scenario 7. An analyst runs a query with where AppDisplayName == "azure portal" and gets zero results, despite Azure Portal sign-ins occurring regularly. What should the analyst change?
Use case-insensitive comparison: where AppDisplayName =~ "azure portal" or where AppDisplayName has "Azure Portal". The == operator is case-sensitive and the stored value uses title case. a
Correct. Section 0.4 identifies case sensitivity as one of the four common first-query mistakes. The == operator compares exact bytes. The stored value is "Azure Portal" (title case), not "azure portal" (lowercase). Using =~ for case-insensitive equality or has for term matching (which is case-insensitive by default) resolves this. The general rule: use == only when you know the exact casing, which is rare for display names.
Replace == with contains because == only matches exact full-string matches and AppDisplayName may include additional text before or after "azure portal". b
The issue is case sensitivity, not substring matching. The AppDisplayName value is exactly "Azure Portal" — no additional text before or after. Using contains would also work because contains is case-insensitive, but it is the wrong fix for the wrong reason. And Section 0.4 explains that has is preferred over contains for performance. The root cause is case sensitivity in the == operator.
Query the CloudAppEvents table instead. Azure Portal sign-ins are recorded in CloudAppEvents, not SigninLogs. c
Azure Portal sign-ins are recorded in SigninLogs. CloudAppEvents records SaaS application activity captured by Defender for Cloud Apps. The table selection is correct — the issue is the case-sensitive comparison operator. Section 0.3 profiles which tables record which types of events.
Add a time filter. Without a TimeGenerated constraint, KQL returns zero results by default to prevent full-table scans. d
KQL does not return zero results when a time filter is missing. It scans the full retention period, which is slow and produces large result sets, but does not return empty results. A missing time filter causes performance issues (Section 0.4), not zero results. The root cause is the case-sensitive string comparison.
Scenario 8. A new analyst runs the workspace discovery query from Section 0.2 and notices that DeviceProcessEvents is missing from the results. The organization uses Microsoft Defender for Endpoint on all managed devices. What should the analyst investigate first?
Defender for Endpoint is not compatible with the organization's Log Analytics workspace region. DeviceProcessEvents is only available in workspaces hosted in US or EU regions. a
DeviceProcessEvents is available in all supported Log Analytics workspace regions. There is no regional restriction for Defender for Endpoint data ingestion. The issue is elsewhere. Section 0.2 covers the data connector architecture that explains this.
DeviceProcessEvents requires Sentinel to be onboarded to the unified Defender portal. In the Azure portal Sentinel experience, only OfficeActivity and SigninLogs are available. b
DeviceProcessEvents is available in both the Azure portal Sentinel experience and the Defender portal, provided the data connector is configured. The unified portal consolidation does not change which tables are available in the Log Analytics workspace. The issue is a missing connector, not a portal limitation.
The workspace discovery query uses the Usage table, which does not track Defender for Endpoint tables. The analyst needs to query DeviceProcessEvents directly to check for data. c
The Usage table tracks ingestion volume for all tables in the workspace, including Defender for Endpoint tables. If DeviceProcessEvents has data, it appears in the Usage results. If it is missing, no data is being ingested for that table. Section 0.2 demonstrates the Usage query specifically to identify which data sources are active.
The Microsoft Defender for Endpoint data connector in Sentinel is not enabled. The organization uses MDE, but the connector that streams endpoint telemetry from the Defender data store into the Sentinel Log Analytics workspace has not been configured. d
Correct. Using MDE and ingesting MDE data into Sentinel are separate configurations. The organization may have MDE deployed to every endpoint, generating telemetry in the Defender XDR data store. But unless the Defender for Endpoint data connector is enabled in Sentinel, that telemetry does not flow into the Log Analytics workspace. The data exists in Defender Advanced Hunting but is invisible to Sentinel queries. Section 0.2 covers the product-to-table mapping and Section 0.6 lists this as a common troubleshooting scenario.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.