Scenario practice questions

Severity equals Low, Status equals New, and Entities count equals 0.

Why it fails: It uses Severity equals Low instead of Informational. Severity levels in Microsoft Sentinel include High, Medium, Low, and Informational. The scenario specifically requires Informational severity, so using Low would target the wrong incidents and fail to meet the requirement.

Severity equals Informational, Status equals New, and Entities count greater than 0.

Why it fails: It uses Entities count greater than 0. The scenario requires incidents with no entities. Using greater than 0 would select incidents that do contain entities, which is the opposite of what is needed, and would not automatically close the intended incidents.

Severity equals Informational, Status equals Active, and Entities count equals 0.

Why it fails: It uses Status equals Active instead of New. The scenario specifies incidents with a status of New. In Microsoft Sentinel, incident statuses include New, Active, and Closed. Using Active would not match the intended incidents, potentially leaving New incidents unclosed or affecting the wrong set.

DeviceProcessEvents | where TimeGenerated > ago(7d) | where FileName == "powershell.exe" | where ProcessCommandLine contains "-enc" | project Timestamp, DeviceName, ProcessCommandLine

Why it fails: This query filters on powershell.exe with an encoded-command flag, so it never surfaces certutil.exe download activity. It suits hunting obfuscated PowerShell execution, whereas the stem requires matching certutil.exe command lines containing a URL or download verb.

DeviceProcessEvents | where TimeGenerated > ago(7d) | where FileName == "mshta.exe" | where ProcessCommandLine contains "http" | project Timestamp, DeviceName, ProcessCommandLine

Why it fails: Filtering on mshta.exe returns HTML Application host activity, not the certutil.exe downloads the hunter asked for, so every matching row is irrelevant. mshta.exe is the right target when hunting malicious .hta execution or URL-based script invocation, which is a different LOLBin technique.

DeviceProcessEvents | where TimeGenerated > ago(7d) | where FileName == "wscript.exe" | where ProcessCommandLine contains "http" | project Timestamp, DeviceName, ProcessCommandLine

Why it fails: Filtering on wscript.exe returns Windows Script Host activity, not certutil.exe, so the LOLBin named in the scenario is never matched. It is tempting because wscript.exe also downloads payloads via HTTP and belongs in a broader LOLBin hunt; it would be correct had the hunter been investigating script-based downloaders rather than certutil.

Scheduled query rule in Microsoft Sentinel

Why it fails: A scheduled query rule in Microsoft Sentinel requires that all email, process, and network logs first be ingested into a Log Analytics workspace via connectors, which adds cost, latency, and administrative overhead. While you could run a KQL query in Sentinel across these tables, Sentinel is not the native hunting interface for Microsoft 365 Defender data and is better suited for detection, alerting, and incident correlation. Therefore, it is technically possible but less efficient and not the correct answer for a direct hunting task.

Custom detection rule in Microsoft 365 Defender

Why it fails: A custom detection rule in Microsoft 365 Defender is an alerting rule built on top of an advanced hunting query; it schedules that query to run and generates alerts when you define suspicious patterns. For a one-off, interactive threat hunt, you would first use advanced hunting to run the query on demand, and only later, if you want continuous coverage, would you package it as a custom detection rule. Since the question asks for hunting action, the correct approach is advanced hunting itself, not a custom detection rule.

Fusion rule in Microsoft Sentinel

Why it fails: Fusion rules in Microsoft Sentinel are machine learning-based correlation rules that automatically combine related alerts from multiple security products into a single, high-fidelity incident. They do not accept custom KQL queries and give the analyst no direct ability to search across raw email, process, or network tables. Thus, choosing a Fusion rule would not satisfy the need to perform custom event correlation for hunting.

Create a Conditional Access policy to block the IP

Why it fails: A Conditional Access policy that blocks the attacker's source IP does not revoke the user's existing sessions or refresh tokens, so the attacker's already-authenticated activity continues until tokens expire. The policy only applies at the next interactive sign-in attempt, and might take several minutes to propagate; in an active incident that delay allows continued unauthorized access. If the blocked IP is a cloud VPN or proxy, it can be replaced quickly, and the real threat is the compromised identity, not the egress address.

Disable the user's account

Why it fails: Disabling the user's account is a valid containment action but it is unnecessarily disruptive: the user loses all access to Microsoft 365 and is unable to work while the investigation runs, even if the compromise was limited to a single device or app. It also does not by itself invalidate access tokens that were already issued, so the attacker might continue to use those tokens until they expire unless you also perform a session revocation. In contrast, a password reset plus session revocation is targeted, removes the attacker's credential, and minimizes impact on the legitimate user.

Block the source IP address on the firewall

Why it fails: Firewall IP blocking operates at the network layer and is completely unaware of Entra ID authentication: if the attacker's credentials are valid, they can authenticate from any host, IP, or VPN endpoint. Attackers routinely cycle through proxies, cloud VPSes, or residential IP pools, and the blocked address is simply one egress path among many. Even if the block is applied to a firewall or a protection layer like Microsoft Sentinel, it does nothing to revoke the stolen password, tokens, or the attacker's foothold, so this action cannot be the primary response.

Create a firewall rule in Microsoft Defender for Cloud Apps to block the device's IP.

Why it fails: Microsoft Defender for Cloud Apps operates as a cloud access security broker and can apply conditional access app control or block a user's access to sanctioned SaaS apps, but it does not provide host-level isolation for an onboarded Windows endpoint. Blocking the device's IP only affects traffic that traverses the CASB proxy for cloud apps; internal network traffic, lateral movement, and non-cloud destinations remain unimpeded. It is not a recognized containment action in the Microsoft Defender XDR incident response workflow.

Unenroll the device from Microsoft Intune.

Why it fails: Unenrolling the device from Microsoft Intune is a management lifecycle operation, not a security containment step. It removes the MDM profile, compliance policies, and potentially the Defender for Endpoint configuration if co-management settings depend on Intune, so you would lose visibility and control exactly when the device is compromised. The device could even become less restricted, allowing the threat to persist or move laterally without management interference.

Disable the network adapter on the workstation remotely.

Why it fails: Microsoft 365 and Microsoft Defender XDR do not expose a native 'disable network adapter' action, so an analyst cannot perform this from the security portal. Attempting it would require separate remote management tools such as PowerShell/WMI or RMM agents, which may not be present, may be blocked by the attacker, and are not part of a sanctioned automated incident response. Even if executed, severing all network connectivity would also cut off the Defender sensor's telemetry and could prevent further remediation commands, unlike isolation which maintains a controlled channel.

extend

Why it fails: The extend operator is used to add a new calculated column to every row in the input table, typically by referencing existing columns with arithmetic or string expressions. It creates additional data at the row level but does not collapse rows or evaluate data across multiple rows. In a scenario where the analyst needs to count events, extend cannot perform the aggregation because it retains the original row count and simply enriches each row with computed values, making it an auxiliary step rather than the main grouping operator.

project

Why it fails: The project operator shapes the output by selecting a specific subset of columns, renaming them, or creating new columns through expressions, but it operates individually on each row and does not change the number of rows. It is essentially a columnar selection that lets you control the result schema, yet it has no capability to group records or calculate aggregate metrics like count(). For a query that needs to count events by some dimension, project alone would return all individual rows, failing to produce the summarized answer the analyst is after.

where

Why it fails: The where operator filters the input table to rows that satisfy a given boolean condition, such as EventID == 4625 or Severity == 'high', effectively reducing the dataset horizontally while preserving all original columns. It is a predicate-based row filter that can narrow down the events to the ones of interest, but it neither groups rows nor computes a count; the output row count is simply the number of matching rows. In a counting query, where is usually placed before summarize to exclude irrelevant events, but it cannot replace summarize for the actual grouping and counting operation.

Multiple MFA denial events from a single user.

Why it fails: MFA denial events are represented by distinct Microsoft Entra ID error codes such as 500121 (authentication method required) or 500133 (claim in token is missing or invalid), not by 50057. These denials occur only after the user successfully authenticates their password, whereas a disabled account is rejected before any MFA challenge is issued. Because the query filters specifically on ResultType 50057, it would not capture MFA denial events.

Brute force attacks against Microsoft Entra ID accounts using invalid passwords.

Why it fails: Invalid password attempts trigger ResultType 50126, which indicates a failed primary authentication due to incorrect credentials. In contrast, 50057 means the account exists but is administratively disabled, so even a completely correct password would not allow sign-in. A brute-force attack using guessable passwords would almost exclusively produce 50126 events, not the disabled-account error code this query targets.

Brute force attacks from a single IP address against multiple accounts.

Why it fails: While a single source IP attacking many accounts is a common brute-force pattern, this query's identifying power comes from ResultType 50057, not from the source IP. Brute force attempts against active accounts typically fail with 50126 (bad password) or 50053 (account locked), and only disabled accounts produce 50057. The query groups by user and IP to aggregate results, but the underlying condition is account state, so it cannot be characterized as a general brute-force detection.

Google Cloud Platform audit logs

Why it fails: Google Cloud Platform audit logs are not a built-in Microsoft Sentinel data connector. The Cloud Audit Logs that record admin activity and data access in GCP cannot be streamed natively into Sentinel; you would need a custom pipeline, for example routing Pub/Sub exports to Azure through a Function App or Event Hubs. Because this requires custom ingestion rather than a native connector, it is not a source you can connect to Sentinel directly for this question.

Trello activity logs

Why it fails: Trello activity logs are not a security log source and have no native Sentinel connector. Trello's activity history is designed for project management audits, not for SIEM ingestion, and it does not produce standard security event formats like authentication or authorization logs. To use Trello data in Sentinel, you would need to build a custom API-based connector or Logic App, so it is not directly connectable.

GitHub Actions logs

Why it fails: GitHub Actions logs are CI/CD workflow execution logs, not a built-in Microsoft Sentinel data connector. While Sentinel can integrate with GitHub through certain audit log connectors, the individual Actions run logs are not natively streamed into Sentinel and require a custom API or third-party collector. Thus GitHub Actions logs are an incorrect choice for this question.

Windows Defender Firewall

Why it fails: There is no standalone 'Windows Defender Firewall' data connector in Microsoft Sentinel. Firewall logs from Windows hosts are ingested through the Windows Security Events via AMA connector or legacy Log Analytics agent, where channel 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' can be selected, or via a CEF/Syslog forwarder for non-Windows firewalls. Because it is not in the connector gallery, this option is incorrect.

Microsoft Forms

Why it fails: Microsoft Forms is a survey and quiz application, not a source of security telemetry that Microsoft Sentinel ingests natively. There is no 'Microsoft Forms' data connector in the Sentinel content hub; any Forms data would need to be exported manually or pulled via Power Automate into a custom log before it could be queried. Therefore, this option is not a valid Sentinel data connector.

Azure DevOps

Why it fails: Azure DevOps is a development collaboration suite, and despite having audit logs and REST APIs, Microsoft Sentinel does not provide a native data connector for it. To bring Azure DevOps events into Sentinel, you would need to build a custom Log Analytics ingestion solution using an Azure Function or Logic App. Thus, it is not one of the standard valid connectors in Sentinel.

Trigger a Microsoft Purview data loss prevention policy.

Why it fails: Microsoft Purview DLP policies are designed to inspect and protect sensitive data by applying rules such as blocking uploads or encrypting files, but they lack any capability to disconnect a device from the network. DLP operates at the data plane, not the network plane, so it cannot contain an adversary who is already exfiltrating via an active network session. Consequently, while DLP is a valuable preventive control, it is not a containment action and does not satisfy the requirement to isolate the compromised endpoint.

Run a Microsoft Entra ID playbook to disable the device.

Why it fails: Disabling a device in Microsoft Entra ID revokes its cloud authentication tokens and blocks interactive sign-in, but it does not alter the device's network connectivity or kill existing sessions and cached credentials. An isolated adversary who already has a foothold can continue transmitting data over the LAN, because Entra ID has no visibility or enforcement at the Layer 2/3 network level. Therefore, an Entra ID playbook can at best accelerate re-authentication failures, but it cannot cut off the exfiltration path that MDE's isolation would sever.

Create an automation rule in Microsoft Intune to wipe the device.

Why it fails: An Intune automation rule that wipes the device is a destructive recovery action that erases all data and settings, but it does not, by itself, sever the device from the network quickly enough to prevent ongoing exfiltration. Wiping may take time to deploy, can fail if the device is offline or already disconnected, and it removes forensic evidence needed for an incident investigation. Furthermore, Intune's remote wipe is not a supported containment technique in Sentinel response playbooks — Defender for Endpoint's isolate is the recommended immediate containment action.

DeviceRegistryEvents

Why it fails: DeviceRegistryEvents logs changes to the Windows registry, which often signal persistence mechanisms or configuration tampering. However, for threat hunting specifically focused on lateral movement, these events are secondary because they do not directly capture the network connections or process creation required to detect tools like PsExec. While an attacker may modify service keys to enable remote execution, this occurs after the movement, making registry telemetry less immediate and less specific for hunting active lateral movement.

DeviceEvents

Why it fails: DeviceEvents is a broad catch-all table that includes many unrelated system events such as driver loads, object access, and other internals, making it noisy and difficult to pinpoint attacks. Although it might occasionally contain a relevant telemetry item, it lacks the focused schema of dedicated tables like DeviceNetworkEvents or DeviceProcessEvents, which directly map to the MITRE ATT&CK techniques used for lateral movement. As a threat hunter, you would prefer the high-signal, purpose-built event types over this generic rollup.

DeviceFileEvents

Why it fails: DeviceFileEvents logs file creation, modification, and file-related activities, but it does not record process creation or the command line associated with execution. While attackers often drop binaries or scripts that later run, the file event alone does not show the actual execution or the tool used, such as services.exe spawned by PsExec. For lateral movement, it is more effective to correlate file drops with process creation, so file events are less central on their own.

Near-real-time (NRT) rule

Why it fails: Near-real-time (NRT) rules are built for low-latency detection and execute approximately every minute, but they restrict query complexity to a limited set of KQL operators and support only a single data table. NRT rules do not permit multi-table joins, which immediately rules them out for correlating Syslog with other sources. They are best suited for simple threshold or pattern detections on one table, not for cross-source correlation.

Fusion rule

Why it fails: Fusion rules are Microsoft's prebuilt analytics that use machine learning to combine alerts across multiple security products into a multi-stage attack narrative. They are not customizable with KQL, nor do they allow you to define your own raw data sources or join logic. Since the question requires correlating Syslog data explicitly, a Fusion rule cannot be adapted to that purpose—you would be limited to the predefined alert-correlation patterns Microsoft provides.

Anomaly rule

Why it fails: Anomaly rules in Microsoft Sentinel are powered by built-in machine learning models that analyze temporal patterns in specific data sources to identify deviations from established baselines. They are not designed for custom KQL correlation logic, so you cannot write a query that joins Syslog with other tables like SecurityEvent or CommonSecurityLog. Because the underlying ML models and data source selections are predefined, anomaly rules cannot fulfill a requirement to correlate raw syslog events with additional signals across multiple tables.

Run a full antivirus scan on the unmanaged device.

Why it fails: Because the device is unmanaged, you cannot reliably initiate or enforce a full antivirus scan through Microsoft Defender for Endpoint unless it is onboarded; even if a scan could run, it focuses purely on malware presence and does not stop the active, ongoing data exfiltration to the external host. Meanwhile, the scan time gives the attacker a continued window to transfer more data, and any detected malware would not necessarily correlate with the user account compromise triggering the alert.

Contact the user to verify if the download was intentional.

Why it fails: Contacting the user to ask whether the download was intentional effectively tips off a potentially compromised account, because if an attacker is actively using that identity, they will see the outreach and may immediately escalate, destroy evidence, or push through the remaining data before investigators can contain the session. It also relies on the user's self-reporting, which is neither audit-proof nor fast enough, and in a false-positive case it wastes time that should be spent validating the alert through telemetry. This is why identity containment is performed before any user interaction.

Create a detection rule for similar behavior in Microsoft Sentinel.

Why it fails: Creating a Microsoft Sentinel detection rule for similar behavior is a valuable post-incident hardening step, but it is not a response to the current event: the rule only matches future log events and has no effect on the already-active download or the compromised user's current access. Writing, testing, and deploying a KQL rule can take significant time, during which the attacker continues to exfiltrate data, so it must be deferred until after containment is achieved. In the immediate triage phase, containment actions take priority over detection engineering.

Scheduled query

Why it fails: A scheduled query rule executes a KQL query at a fixed frequency (e.g., every 15 minutes) and compares the result to a static threshold like a count or aggregation. This approach lacks adaptive learning of a user's typical sign-in pattern; any threshold you set will either be too strict or too permissive as the normal behavior shifts. Because it cannot dynamically establish a baseline, it is not the right choice for detecting a sign-in anomaly.

Near-real-time (NRT) rule

Why it fails: Near-real-time (NRT) rules run on streaming data in intervals as short as one minute, using explicitly defined conditions written in KQL. They are not backed by machine learning and do not maintain a baseline of historical behavior; every evaluation uses the same fixed criteria. Consequently, an NRT rule can catch fast signal but cannot identify subtle deviations from normal sign-in activity.

Fusion rule

Why it fails: Fusion rules are correlation-based analytics that ingest alerts from multiple sources (e.g., Microsoft Defender products, Identity Protection) to detect multi-stage attack chains, such as initial access followed by lateral movement. They do not evaluate a single sign-in against a learned baseline; instead they require multiple distinct signals to fire. Therefore, a Fusion rule cannot satisfy the requirement to alert on one anomalous sign-in event.

has_any(SigninIP, dynamic(['192.168.0.0/16']))

Why it fails: The has_any operator checks whether the source string contains any of the specified substrings using substring matching, and it does not interpret values as network addresses. When given dynamic(['192.168.0.0/16']), it looks for the literal text '192.168.0.0/16' inside the SigninIP string, which never appears because an IP address does not include a slash or the /16 suffix. Consequently, this expression always evaluates to false (or behaves incorrectly) and completely fails to perform CIDR range evaluation.

ipv4_is_private(SigninIP)

Why it fails: The ipv4_is_private function determines whether an IP address belongs to any of the RFC1918 private address blocks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. While 192.168.0.0/16 is one of those blocks, this function tests membership across the entire private address space, not just the specified /16 range. An IP such as 172.16.5.10 would also return true, causing the detection rule to trigger for unintentional ranges and thereby producing false positives if the intent was to monitor only 192.168.0.0/16.

SigninIP startswith '192.168.'

Why it fails: The startswith operator performs a literal string prefix comparison rather than an IP-aware network calculation. It will match any IP address whose textual representation begins with '192.168.', without understanding CIDR boundaries or subnet masks. For example, a rule intended to detect 192.168.1.0/24 would incorrectly also match 192.168.2.0/24 because the string prefix remains identical. This makes it unsuitable for precise subnet scoping in security detections.

Create a conditional access policy in Microsoft Entra ID to block the user

Why it fails: Conditional Access policies are evaluated only at authentication time when a token is requested. A policy that blocks the user will not revoke tokens that have already been issued, and it can take several minutes for the policy to propagate across Microsoft Entra ID, so an already-authenticated attacker can keep accessing applications until those existing sessions expire.

Disable the user account in Microsoft Entra ID

Why it fails: Disabling the user account in Microsoft Entra ID prevents new sign-ins but does not revoke or invalidate access tokens and refresh tokens that were already issued. It also relies on directory replication and token lifetime, so active sessions may continue for minutes or even hours, which is too slow and incomplete for immediate containment during an active incident.

Reset the user's password from Microsoft Entra ID

Why it fails: Resetting the user’s password invalidates password-based authentication, but it does not revoke existing access tokens, refresh tokens, or federated session cookies. An attacker who already has a valid session or token can continue operating without needing to re-authenticate, so password reset alone fails to cut off active unauthorized access.

Device

Why it fails: While a device can be the source or target of a credential compromise, Microsoft Sentinel UEBA anchors its behavioral analytics on entities such as users, hosts, and IP addresses, with the user account as the primary subject for credential-based attacks. A device provides context—like the machine from which a login originates—but does not itself embody the credential; multiple users may share a device, so its baseline is less indicative of account takeover. Therefore, Device is not the primary entity when investigating a credential compromise.

Application

Why it fails: Applications (such as enterprise apps or OAuth integrations) serve as access targets or authentication registrations in Microsoft Entra ID, not as the behavioral subject in Sentinel UEBA for detecting credential compromise. A malicious sign-in to a corporate app is attributed by Sentinel to the user account that authenticates and to the source IP/host, while the application itself only reflects which resource was accessed. Since compromised credentials can be used across many applications, the Application entity provides no standalone behavioral signal for account takeover.

IP address

Why it fails: An IP address is an ephemeral, shareable network attribute that Microsoft Sentinel UEBA treats as a contextual indicator, not as the entity that is compromised. IPs can be changed, spoofed, or shared behind NAT/VPN, so they cannot represent a distinct identity; a single IP may host multiple user accounts, and a single user may constantly change IPs. While impossible-travel detections use IP geography, the investigation still pivots on the user account whose credentials are being abused, making IP only a supporting clue.

Use a watchlist to map incident types to email addresses and configure a scheduled query.

Why it fails: Watchlists serve as lightweight reference tables for enrichment and correlation in queries, not as response mechanisms. Pairing a watchlist with a scheduled query can only produce alerts based on those mappings; scheduled queries lack native email delivery. Triggering an email on incident creation still requires an automation rule coupled with a playbook.

Modify the analytics rule to include an email action in the rule settings.

Why it fails: Analytics rules configure query logic, frequency, and alert/incident generation, but their settings do not include notification actions like 'send email'. The rule can only create alerts that feed into Sentinel, not directly contact users. Any email action must be implemented as a separate playbook and attached to a corresponding automation rule.

Create a workbook that alerts via email when new incidents appear.

Why it fails: Workbooks are interactive dashboards built on KQL queries for visualizing security data; they are not event-driven responders. They have no ability to send emails when new incidents appear because they render only on-demand or when opened. In contrast, real-time notification is handled by automation rules and playbooks, which are active components of incident handling.

Block the IP address in the Conditional Access policy.

Why it fails: Blocking the IP address in a Conditional Access policy applies only to future authentication requests and does not invalidate an already-issued session token. An active attacker with a valid token can continue accessing resources until that token expires, and many exit nodes (cloud services, VPNs) are shared or dynamic, causing the block to impact legitimate users. A sophisticated adversary can also switch to a different IP or proxy, so this is not a reliable or immediate containment step.

Investigate the sign-in logs to determine if there are other compromised accounts.

Why it fails: Investigating sign-in logs to identify other compromised accounts is a critical part of the incident response, but it is not the immediate first action when a single account is confirmed compromised. The priority is to stop the threat by revoking the active session; broadening the investigation can happen afterward without risking further attacker activity. Delaying containment while reviewing logs gives the adversary more time to move laterally, escalate privileges, or persist in the environment.

Reset the user's password.

Why it fails: Resetting the user's password stops the attacker from using the stolen credentials for future sign-ins, but it does not invalidate the session tokens the attacker already holds. Without an explicit session revocation, those tokens remain valid until they expire, allowing the attacker to continue accessing resources even after the password is changed. Therefore, a password reset alone is insufficient as an immediate containment measure; session revocation must be performed to terminate the active, token-based access.

Add the user to a watchlist and configure a fusion rule.

Why it fails: Watchlists are user-defined tables of data used for enrichment, correlation, and filtering in analytics rules—they do not create incidents when users are added. Fusion rules apply machine learning to combine multiple alerts and related signals into a single incident, but they cannot be configured to act on a simple watchlist assignment. Therefore, adding the user to a watchlist and configuring Fusion would not generate an incident or assign it to the security team.

Create a playbook that triggers on the alert and creates an incident manually.

Why it fails: Playbooks are Azure Logic Apps-based workflows that run automated response actions such as sending emails, resetting credentials, or blocking network traffic after an alert or incident is generated. They lack native capability to create an incident record; incident creation is reserved for analytics rules and automation rules. Attempting to create an incident manually within a playbook is unsupported and bypasses Sentinel's designed orchestration flow.

Modify the analytics rule to set the incident creation setting to 'Create incident from alert'.

Why it fails: The analytics rule's 'Create incident from alert' setting is a binary toggle that controls whether Sentinel generates an incident for each alert the rule triggers. While enabling this toggle will produce an incident, it does not assign an owner or perform any other triage actions, so the security team would not be automatically designated. In the given scenario, an automation rule is the appropriate place to both create the incident and set the owner, because it can chain multiple actions on alert creation.