Hard Difficulty Questions

Report the email to Microsoft for analysis and block the sender domain.

Why it fails: Reporting to Microsoft and blocking the sender domain does not purge the delivered message from the Finance user's mailbox, leaving the phishing link accessible. Submission is for tuning detections, and domain blocks suit recurring campaigns; here the immediate requirement is removing the specific delivered email.

Provide security awareness training to the user and mark the incident as resolved.

Why it fails: Training alone leaves the delivered phishing email and malicious URL active, so other recipients remain exposed; the incident needs investigation and purge. It is tempting as a low-effort user-focused fix, and would be correct for recurring awareness gaps rather than an active delivered threat.

Add the sender's domain to the Tenant Allow/Block List as allowed to avoid future false positives.

Why it fails: Allow-listing the sender domain suppresses future detections for that domain, directly enabling the phishing campaign to reach Finance again. Tenant Allow/Block List allow entries exist to override false positives on verified-benign senders, not to whitelist a domain implicated in a confirmed delivered phishing alert.

where

Why it fails: The 'where' operator filters rows based on a predicate, returning only the subset of rows that satisfy the condition. It does not group rows or apply aggregation functions, so it cannot calculate distinct user counts per IP. While where is often used before summarize to narrow the dataset, it alone cannot produce the required aggregated result.

extend

Why it fails: The 'extend' operator appends new computed columns to each existing row, preserving the original number of rows in the result set. It does not perform any grouping or reduction, and it cannot calculate aggregated values like distinct counts across IP addresses. Its purpose is purely transformational, adding fields such as derived timestamps or normalized data, not summarizing.

project

Why it fails: The 'project' operator selects, renames, or reorders a specified set of columns from the input, effectively shaping the output schema. It does not group rows or compute aggregate functions, so it cannot calculate distinct user counts per IP. Project is used for column manipulation, not for data reduction or aggregation.

timechart()

Why it fails: timechart() is a rendering operator in KQL that aggregates values over time to produce a trend chart. It is designed for visualizing time-series data, such as login counts per day, not for maintaining a historical set of values per user. In this detection scenario, timechart() cannot return or compare a set of previously seen countries against a new login, so it is not a viable option for detecting a user logging in from a new country.

dcount()

Why it fails: dcount() returns an approximate count of distinct values in a column using the HyperLogLog algorithm, which is efficient for large volumes of data but yields only a numeric cardinality. Since dcount() does not return the actual set of values, you cannot check whether a specific country, such as the one in the current login, is present in the user's historical set. Consequently, dcount() cannot support the comparison required for detecting a login from a new country.

startofday()

Why it fails: startofday() is a scalar datetime function that rounds a given timestamp down to the beginning of its day, commonly used for grouping or binning log events into daily periods. It has no capability to store or retrieve historical data such as a list of countries per user, nor does it perform any set operations. While it might be useful for aggregating logins by day, it cannot help determine whether a specific country is new for a user.

Delete the document from SharePoint Online.

Why it fails: Deleting the document from SharePoint Online is irreversible unless the item is still in the recycle bin, and it would destroy the original content needed for forensic analysis in Microsoft Purview audit logs or Sentinel. The file may also be required to determine the blast radius, identify the exact sharing link that exposed credit card data, and preserve business records. It also prevents you from validating whether the external guest actually accessed or exfiltrated the data.

Modify the DLP policy to block sharing of credit card numbers.

Why it fails: Modifying the DLP policy to block future sharing of credit card numbers is a preventive control that only affects newly created sharing links or uploads after the policy takes effect. It does nothing to revoke the guest's existing access to the document, because the sharing link or direct permission remains valid. The current incident requires immediate containment—revoking access—not a long-term policy adjustment that will take time to propagate across Microsoft 365.

Disable the user's account in Microsoft Entra ID and investigate.

Why it fails: Disabling the user's account in Microsoft Entra ID is an over-broad response that would block the user from accessing all resources, not just the exposed document, potentially halting critical business operations. The incident may be the result of an accidental misconfigured sharing link rather than a compromised identity, so disabling the account is premature without evidence of unauthorized account activity. You should instead investigate the sharing metadata and audit logs to confirm whether the user's credentials were used to share the file.

Use advanced hunting to find devices and then manually isolate

Why it fails: Advanced hunting is a Kusto Query Language (KQL)-based threat hunting tool for querying raw telemetry across tables such as DeviceInfo, DeviceProcessEvents, and DeviceNetworkInfo. While it can enumerate potentially compromised devices, it is a read-only investigation interface and has no action engine to execute containment steps; isolating a device from a hunting result would require a separate manual action in Microsoft Defender for Endpoint, which is slow and inconsistent. For automated, policy-driven response, you need an automation rule or playbook that acts on alert triggers, not a hunting query.

Use PowerShell scripts in a playbook

Why it fails: A Microsoft Sentinel playbook built on Azure Logic Apps can run PowerShell scripts via the log analytics connector, but this introduces significant overhead: you must integrate Defender XDR with Sentinel, create and monitor the logic app, and ensure the service principal has appropriate permissions to call isolation APIs. Playbooks also execute asynchronously after an incident is created, adding latency and potential failure points, and they are not a native Defender XDR capability. Automation rules are purpose-built for this scenario, providing immediate, reliable response without the need to orchestrate external compute via PowerShell.

Create a custom detection rule

Why it fails: Custom detection rules in Microsoft 365 Defender are KQL-based scheduled queries that generate alerts when they find matches in the raw event data; they are part of the detection layer and do not include any remediation actions. While a custom detection could surface a suspicious device, it has no capability to isolate that device or run antivirus on it, so it would only add another alert for a human to triage. The actual response—isolation—must be implemented separately, making this option insufficient for automated containment.

Configure a Logic Apps trigger to poll for new incidents every minute

Why it fails: Polling for new incidents every minute with a Logic Apps trigger is inefficient and adds latency, because it introduces a scheduled delay and requires custom HTTP calls to the Microsoft Sentinel API instead of using the native event-driven integration. Automation rules, by contrast, respond instantly to incident creation via a subscription-scoped trigger, eliminating the need for polling and providing immediate, serverless execution without additional compute costs.

Train analysts to manually run the playbook when they see the incident

Why it fails: Manual playbook execution depends on analyst availability and reaction time, so isolation and account disabling are delayed, letting lateral movement continue. Automation rules with playbook triggers are designed for this, whereas manual running suits rare, judgement-heavy incidents where automated containment would be risky.

Create an analytics rule that runs a playbook as part of its alert generation

Why it fails: An analytics rule cannot directly invoke a playbook as part of alert generation; analytics rules are designed to evaluate data and create alerts, not to orchestrate response actions. Playbooks are executed by automation rules, which listen for incident creation or update events and run the playbook as an action. While an analytics rule can alert on a detection, the playbook must be attached via an automation rule, or else you would need unsupported custom extensions to call it from the rule logic.

Alert tuning rules are causing the alerts to be excluded.

Why it fails: Tuning rules reduce alert volume but do not prevent incident creation from remaining alerts.

Automation rules in Microsoft Sentinel are deleting the alerts.

Why it fails: Sentinel automation rules apply to Sentinel alerts, not Defender XDR incidents.

Alert suppression rules are blocking the alerts.

Why it fails: Suppression rules hide alerts but do not prevent incident creation.

Notify the user about the policy violation

Why it fails: Sending a notification to the user about the policy violation is a governance or remediation step, not a containment control. The user may be the attacker or have compromised credentials, so the notification does not stop ongoing exfiltration or encryption, and it could even tip the attacker off. Notification is only useful after active containment has secured the environment.

Initiate a legal hold on the user's data

Why it fails: Placing a legal hold (litigation hold) on the user's data preserves content in-place for eDiscovery and legal investigations, ensuring that evidence is not deleted or altered. It does not revoke access, block uploads, or halt active ransomware activity, and it does not affect real-time data movement. Thus it is an evidence-preservation step, not a contain-and-respond action.

User-reported message settings

Why it fails: User-reported message settings in Microsoft Defender for Office 365 configure how users submit suspicious messages to the admin Submissions portal for analysis. They do not define any inbound filtering or block actions for email delivery, so they cannot be the policy that prevented the message from reaching the inbox. This setting only affects the reporting experience and workflow, not the actual safety of the email.

SPF record for the sender domain

Why it fails: SPF (Sender Policy Framework) is an email authentication protocol that verifies that the sending server is authorized to send on behalf of the sender's domain, typically via a DNS TXT record. Even if the SPF check fails due to domain spoofing, the message may still be delivered to Junk or marked with a composite authentication result; SPF alone does not enforce a blocking action based on domain reputation. The anti-phishing policy uses threat intelligence and impersonation protection to actively block or quarantine such messages, which is beyond SPF's scope.

Safe Attachments policy

Why it fails: Safe Attachments policy in Microsoft Defender for Office 365 detonates email attachments in a sandbox environment and blocks messages when malware is detected in the attachment payload. However, it does not analyze the sender domain's reputation or detect impersonation attempts where the domain name is spoofed to appear legitimate but contains no malicious attachment. Since the incident involves a phishing message that was blocked based on domain reputation, the Safe Attachments policy would not be the specific control responsible for that action.

Move the user account to an Organizational Unit (OU) with blocked logon hours.

Why it fails: Blocked logon hours only restrict interactive logon at scheduled times; the account remains enabled and can still authenticate via non-interactive methods, so the attacker keeps modifying groups. OU-based logon-hour restrictions suit limiting when legitimate staff may sign in, not containing an active compromise.

Reset the user's password in on-premises Active Directory.

Why it fails: Resetting the on-premises password leaves the account enabled, so the attacker retains access through existing sessions and can continue modifying groups. Password reset suits credential-theft recovery after containment, but immediate containment requires disabling the account to terminate its ability to authenticate and act.

Disable the user account in Microsoft Entra ID.

Why it fails: Disabling the account in Microsoft Entra ID blocks cloud authentication, but the compromised identity is an on-premises admin whose group modifications occur in Active Directory, so the threat persists. Entra ID disablement suits cloud-only accounts, not hybrid on-premises administrative compromise.

Use the CommonSecurityLog table to analyze network traffic from management tools.

Why it fails: CommonSecurityLog holds network and security appliance events, not Azure Resource Manager control-plane operations, so it cannot surface resource-creation calls from unusual IPs. It is tempting because it does capture IP addresses and traffic metadata, and would suit hunting network-level intrusions, but ARM writes never appear there.

Use the AzureActivity table in Microsoft Sentinel to query for any operation where the OperationNameValue contains 'write' and then manually review each result.

Why it fails: AzureActivity does record ARM operations, but filtering only OperationNameValue containing 'write' returns every write across all subscriptions with no IP or time anomaly logic, forcing manual review. It is tempting because it targets the correct table and operation type, and would suit broad auditing, but it cannot identify unusual IPs or times.

Query the SigninLogs table in Microsoft Sentinel for all interactive sign-ins to the Azure portal, then cross-reference with Azure Activity logs.

Why it fails: SigninLogs captures interactive portal authentication events, not ARM resource-creation operations, so it cannot reveal which subscriptions created VMs or storage accounts. It is tempting because unusual sign-in IPs and times do indicate compromise, and it would suit investigating suspicious authentication, but it stops short of control-plane activity.

EmailPostDeliveryEvents and AADSignInEventsBeta

Why it fails: EmailPostDeliveryEvents tracks actions taken on emails after delivery (e.g., ZAP, remediation) and does not contain the original sender address. Therefore, it cannot be used to link the email sender to the sign-in IP address.

EmailEvents and CloudAppEvents

Why it fails: Incorrect. CloudAppEvents focuses on cloud application activities and does not directly provide email sender metadata needed to link to sign-in IP in this scenario.

EmailAttachmentInfo and AADSignInEventsBeta

Why it fails: Incorrect. EmailAttachmentInfo contains attachment metadata (e.g., file hashes) but lacks the sender's email address required for the join with AADSignInEventsBeta.

Use only broad patterns to avoid missing anything

Why it fails: Broad patterns alone generate excessive noise and false positives, defeating the precision that effective hunting queries require. It is tempting because wide queries feel thorough and reduce the risk of overlooking activity, but hunting depends on targeted hypotheses, so broad-only patterns would be the choice when performing initial exploratory sweeps, not focused hunts.

Use wildcards extensively to capture variations

Why it fails: Extensive wildcards degrade query performance and inflate false positives, undermining the precision hunting queries need. It is tempting because wildcards do capture variations in indicators, which suits fuzzy matching, but recommended practise favours specific, tuned patterns; heavy wildcard use would fit broad exploratory searches rather than targeted hunts.

List all users with any risk level during sign-in in the last 7 days

Why it fails: This option misstates the query's risk filter: the hunting query specifically filters for medium-risk sign-ins only, not any risk level. Moreover, the query aggregates and joins sign-in events with service principal sign-ins on IP address, so it is a correlation hunt rather than a simple listing of users. The goal is to surface shared-IP anomalies indicative of token theft, not to enumerate every risky user.

Detect users who have granted admin consent to malicious OAuth apps

Why it fails: The query contains no reference to OAuth consent grants, app role assignments, or admin consent events. To detect malicious admin consent, you would need to inspect the ConsentGrant table or audit logs for OAuth2 PermissionGrant events, which are entirely different telemetry sources. This option conflates application permissions with sign-in risk, whereas the query is focused on IP-based correlation between user and service principal sign-ins.

Identify service principals that have been compromised and are performing high-risk sign-ins

Why it fails: The query's primary entity is the user sign-in log; the risk level is applied to user sign-ins, not to service principal events. Although service principals appear in the join, the query does not assess whether the service principal itself is compromised or performing high-risk activity. Detecting compromised service principals would require separate anomaly or risk detections on the AADServicePrincipalSignInLogs table rather than a user-centric IP correlation.

Create an automation rule for all High severity incidents, then use a playbook to check the rule ID and skip if needed

Why it fails: This would trigger the playbook for every High incident, wasting resources.

Create one automation rule with condition: Severity equals High and Analytics rule ID not equals '12345'

Why it fails: Automation rules do not support 'not equals' condition for rule ID.

Create one automation rule with conditions: Severity equals High OR Analytics rule name not equals '12345'

Why it fails: The OR condition would trigger for all High severity incidents regardless of rule.

CommonSecurityLog

Why it fails: CommonSecurityLog carries CEF-formatted events from third-party security appliances such as firewalls and proxies, not identity sign-in telemetry. It is tempting because it feeds many analytics rules, and would be correct for correlating network security events, but unusual authentication patterns require sign-in and audit logs.

OfficeActivity (Office 365)

Why it fails: OfficeActivity records user and admin actions within Microsoft 365 workloads such as SharePoint and Exchange, not Entra sign-in events. It tempts because it is a rich audit source, and would be correct for detecting anomalous file sharing or mailbox rule creation, but authentication anomalies need SigninLogs and AuditLogs.

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.

Microsoft Defender for Endpoint Web Protection

Why it fails: Web Protection blocks malicious websites, not cloud app detection.

Microsoft Defender for Identity

Why it fails: Defender for Identity detects on-premises identity threats, not cloud app usage.

Microsoft Defender for Office 365 Safe Links

Why it fails: Safe Links protects against malicious URLs, not cloud app discovery.

The query should filter on a specific time range instead of using FirstSeen.

Why it fails: Using FirstSeen is a valid approach, though the issue is syntax.

The join key should be DeviceName instead of DeviceId.

Why it fails: DeviceId is typically the correct key for device identity.

The join type should be innerunique, not leftsemi.

Why it fails: Leftsemi is valid; it returns only records from the left that have a match.

Use a workbook to create a triage dashboard and instruct analysts to manually claim incidents from the dashboard.

Why it fails: A workbook only displays data; it cannot assign incidents or trigger Teams notifications, so triage stays manual. It tempts because workbooks visualise incident trends, which suits reporting and hunting dashboards, but automation requires an automation rule or playbook acting on incident creation.

Modify each analytics rule to include a custom details field that specifies the analyst, and use a playbook to send Teams notification based on that field.

Why it fails: Custom details are static fields populated from analytics query output, so they cannot dynamically map tactics and severity to the correct analyst. They tempt as a way to enrich incidents, which is their real purpose, but assignment and Teams notification need an automation rule.

Create a single playbook that checks the incident's tactics and severity, assigns it to the appropriate analyst, and sends a Teams notification, then configure that playbook to run automatically on all new incidents.

Why it fails: A single playbook triggered on all incidents cannot branch assignment by tactics and severity without duplicating logic, and Sentinel's automation rule is the native trigger for per-incident assignment. Playbooks suit orchestrating response actions once an incident already exists and is assigned.