Perform threat hunting practice questions

Add the IPs to a Microsoft Sentinel watchlist and reference the watchlist in an analytics rule

Why it fails: Watchlists are for temporary reference data, not for formal threat intelligence indicators.

Create a custom analytics rule that includes the IPs as inline indicators

Why it fails: This embeds IOCs in a rule but does not create reusable threat intelligence objects.

Use Azure Logic Apps to create a playbook that blocks the IPs automatically

Why it fails: This is a response action, not a method to persist IOCs for detection.

project

Why it fails: The project operator selects columns but does not help identify changes specifically. It is not useful for filtering or aggregating role assignment changes.

evaluate

Why it fails: The evaluate operator is used for invoking plugin functions and is not relevant for filtering Microsoft Entra ID audit logs for role assignment changes.

mvexpand

Why it fails: The mvexpand operator expands multi-valued fields into multiple rows. While it can be useful for expanding arrays, it is not directly used to identify additions to high-privilege roles.

ActionType

Why it fails: Incorrect. ActionType is not a column in the DeviceNetworkEvents table; it appears in other tables like DeviceEvents.

RemoteIP

Why it fails: Incorrect. RemoteIP is the IP address of the DNS server, not the queried domain, and is not directly useful for detecting tunneling.

AzureActivity

Why it fails: AzureActivity records control-plane operations on Azure resources, such as resource deployments and role assignments, and contains no Microsoft Entra ID sign-in events. It is tempting because it is a common Sentinel table for Azure monitoring, and would be correct when hunting for suspicious resource management activity rather than authentication failures.

OfficeActivity

Why it fails: OfficeActivity logs Microsoft 365 audit events such as file access and admin actions, not sign-in attempts, so it cannot reveal brute-force authentication failures. It is tempting because it does record user activity, and would be correct when hunting suspicious SharePoint, Exchange or Teams operations rather than credential attacks.

AuditLogs

Why it fails: AuditLogs records Microsoft Entra ID directory changes such as user, group and application modifications, not sign-in attempts, so failed logons from a brute-force campaign never appear there. It is tempting because it is a core Entra ID log, and would be correct when hunting for directory object changes or privilege assignments.

The ResultType value 50057 is incorrect; it should be 50058 for disabled account

Why it fails: 50057 is the correct code for user account is disabled.

The query should group by UserPrincipalName only, not by IPAddress

Why it fails: Grouping by UserPrincipalName alone discards the source IP, so the same-IP correlation the hunter needs disappears; the query's grouping is already correct. Grouping by user only suits detecting one account attacked from many IPs, the inverse pattern.

The threshold of 5 is too high; reducing it would show results

Why it fails: Lowering the threshold cannot surface rows the query never produced; the failure lies in the join or time filter, not the count. Threshold tuning is right when genuine low-volume attacks fall below a deliberately high bar.

The FileName list does not include other script hosts like 'mshta.exe'

Why it fails: The stem states the query is syntactically correct and activity occurred; the FileName list matching only some script hosts would exclude mshta.exe launches, but the join's time-window logic is the actual failure. It is tempting because script-host enumeration is genuinely needed when hunting all hosts, not just those listed.

The time range of 7 days is too short; should be 30 days

Why it fails: The hunter knows the activity occurred, and the stem gives no indication it fell outside seven days; extending to 30 days merely widens the search without fixing the join. It is tempting because short lookbacks do miss older events, and widening the range is correct when hunting historical activity.

The RemotePort filter should include 80 for HTTP connections

Why it fails: The stem specifies an HTTPS endpoint, so RemotePort already matches 443; adding 80 addresses plaintext HTTP and cannot explain zero results. It is tempting because broadening port filters is a common troubleshooting step, and it would be correct if the query targeted HTTP traffic.

The triggerThreshold is set to 0, which should trigger on any result

Why it fails: 0 means alert on any result, so this is not the issue.

The queryFrequency is 1 day, which may miss events if they occur right after the query runs

Why it fails: The query looks back 14 days each time, so it should catch events.

The queryPeriod is 14 days, which may be too short

Why it fails: 14 days is usually sufficient; the issue is data availability.

SecurityEvent | where EventID == 4768 | summarize count() by Account | where count_ > 10

Why it fails: EventID 4768 is indeed a Kerberos TGT request, but this query simply aggregates all such requests by account and applies a crude threshold of 10. It fails to exclude known service accounts like svc_sql or svc_adfs, which legitimately generate high numbers of TGT requests, thereby producing many false positives. Additionally, it omits any source IP context, making it impossible to distinguish between a single compromised account hammering the KDC and normal behavior from a shared or privileged account.

let knownAccounts = dynamic(['svc_sql', 'svc_adfs']); SecurityEvent | where EventID == 4768 | where Account !in (knownAccounts) | summarize cnt=count() by Account, IpAddress | where cnt > 5

Why it fails: This is the correct detection query because it targets TGT requests (EventID 4768), which is the precise event type that reveals an account requesting Kerberos tickets—the precursor to a kerberoasting attempt. It excludes known legitimate service accounts via the dynamic array `knownAccounts`, reducing false positives. Grouping by both `Account` and `IpAddress` adds necessary source context, so you can spot an anomalous account generating a high volume of TGTs from a single workstation or IP. The `where cnt > 5` threshold, while configurable, provides a practical baseline for flagging unusual behavior rather than just counting every request.

SecurityEvent | where EventID == 4773 | summarize count() by Account

Why it fails: EventID 4773 is documented as a Kerberos service ticket renewal, not an initial ticket-granting ticket (TGT) request. Kerberoasting requires an attacker to request new TGS tickets from the KDC to obtain service tickets encrypted with the target account's password hash; renewing an existing ticket does not yield fresh material to brute-force. Therefore, this query is examining an entirely unrelated event type, and even a high count of 4773 events would not indicate the ticket-request pattern characteristic of kerberoasting. It also lacks any filtering or threshold, making it both semantically wrong and practically useless for this hunt.

Microsoft Purview Information Protection

Why it fails: Microsoft Purview Information Protection is incorrect because its role is to classify data by assigning sensitivity labels and applying encryption or usage restrictions (e.g., do-not-forward), not to monitor or alert on user activities like logon or data exfiltration. While labels can be added to DLP policies to match on, the Information Protection feature itself produces no alerts and provides no investigation context after the fact—it is a governance action, not a detection source.

Microsoft Purview Compliance Manager

Why it fails: Microsoft Purview Compliance Manager is incorrect because it is a risk-assessment and reporting tool that grades your environment against regulatory controls and recommends remediation actions; it does not ingest sign-in or data-correlation telemetry. Since a threat hunt needs event-level evidence from user and data activities, Compliance Manager cannot provide the observed account access or data movement context needed. It shows whether a control is implemented, not whether an actor is performing malicious exfiltration.

Microsoft Purview Audit (Standard)

Why it fails: Microsoft Purview Audit (Standard) is incorrect because, although it records a broad list of sign-in and file access events in Unified Audit Log, it logs activities generically without a classification engine to flag the data's sensitivity level, and the default 90-day retention limits hunting. To identify exfiltration patterns, you would need Audit (Premium)'s specific sensitive-data events or a DLP alert-to-incident workflow; Standard alone cannot correlate user access with content-level risk. It is an evidence store for what happened, not an intelligent detector of whether that action exposed governed data.

Web Protection

Why it fails: Web Protection in Microsoft Defender for Endpoint inspects URLs and IP addresses against reputation and category lists, deciding whether to block access to a site or download. It does not evaluate the behavioral characteristics of a file once it lands on the device, nor does it look at actions like process injection or credential theft. Therefore, it cannot block an unknown malware variant that exhibits lateral movement behavior, because reputation and category data for a brand-new file are not yet available.

Custom file indicators (IoC)

Why it fails: Custom file indicators (IoC) are static artifacts such as SHA-256 hashes, file names, or file paths that you manually add to Defender for Endpoint as a block or allow list. To use them, you must already know the exact file identity of the malicious sample, which is impossible for a new or polymorphic variant that has never been observed. Because the threat is unknown and uncharacterized, there is no IoC to create, and the block would not engage even if the file attempts suspicious behavior.

Network Protection

Why it fails: Network Protection is designed to block outbound connections from a device to malicious IP addresses, domains, or URLs by inspecting network traffic against threat intelligence. It does not monitor the local behavior of a file, such as PowerShell scripts attempting WMI or SMB-based lateral movement. Thus, even if an unknown malware variant tries to spread across the network, Network Protection only sees the resulting network connection, not the file's actions, and it has no rule to stop the process from behaving dangerously.

IdentityDirectoryEvents | where ActionType == 'Replication'

Why it fails: IdentityDirectoryEvents captures changes, not replication requests.

DeviceProcessEvents | where FileName contains 'ntdsutil'

Why it fails: DeviceProcessEvents captures process creation, not replication requests.

IdentityLogonEvents | where ActionType == 'DirectoryReplication'

Why it fails: IdentityLogonEvents does not include replication actions.

4672 (Special Logon)

Why it fails: Event ID 4672 (Special Logon) is triggered when special privileges are assigned to a logon, but it does not directly indicate pass-the-hash.

4648 (Explicit Credential)

Why it fails: Event ID 4776 (Credential Validation) logs credential validation attempts on a domain controller, but it is not specific to pass-the-hash attacks.

4776 (Credential Validation)

Why it fails: Event ID 4648 (Explicit Credential) logs when credentials are explicitly supplied, which could be part of a PtH attack, but it is not the primary event to focus on.

find

Why it fails: The `find` operator is highly appropriate for hunting anomalous Kerberos service ticket requests because it enables a broad, unconstrained search across all tables in the Microsoft Sentinel workspace. This is crucial when investigating sophisticated attacks like golden tickets, where relevant indicators might be dispersed across various log sources, including Windows Security Events or Microsoft Entra ID sign-in logs. Utilising `find` facilitates initial exploratory analysis to uncover patterns or events that deviate from normal behaviour, satisfying the requirement to identify anomalies without prior knowledge of the specific table containing the malicious activity.

evaluate

Why it fails: evaluate is for plugin functions, not for cross-table search.

union

Why it fails: Union combines tables but doesn't search across them with a pattern.

Data exfiltration

Why it fails: Data exfiltration via SMB is technically possible by copying files to a remote share, but it is rarely the primary channel because outbound SMB (port 445) is typically blocked at the perimeter by default or explicitly denied in enterprise firewalls. Attackers prefer HTTP/HTTPS, DNS, or even FTP to blend with normal egress traffic and bypass data-loss prevention controls. The observed pattern of successive SMB connections to multiple internal hosts is not consistent with a one-way bulk data transfer to an external destination, which would involve sustained traffic to a single IP rather than a burst of handshakes. Thus, while SMB can carry stolen data, the behavior described aligns more with systemic network mapping, not exfiltration.

Command and control beaconing

Why it fails: Command and control (C2) beaconing commonly leverages HTTP/HTTPS, DNS, or occasionally custom protocols on allowed ports to maintain covert, periodic communications with an external server. SMB is a session-based, handshake-heavy protocol that is noisy, connection-oriented, and often restricted at the network perimeter, making it a poor choice for stealthy C2. Even if malware employs SMB for C2 (e.g., SMBDoor), it typically connects to a single fixed server on a regular interval, whereas the observed successive SMB connections to numerous internal hosts suggest active scanning rather than established beacon communications. Therefore, this traffic pattern is more indicative of lateral movement reconnaissance than of a C2 channel.

Internal reconnaissance

Why it fails: Internal reconnaissance is a broad category that includes network scanning, user enumeration, DNS queries, and ICMP pings, all aimed at mapping the environment. SMB scanning specifically targets shared folders and named pipes, which are immediate enablers for lateral movement because they allow file access and remote execution. In contrast, general reconnaissance might involve ARP sweeps or port scans across many protocols, whereas the successive SMB connections in this scenario are specifically focused on identifying reachable SMB services and accessible shares. This focused, protocol-specific behavior is more precisely characterized as lateral movement preparation, because the discovered shares are then used to transfer tools or execute commands on remote hosts, rather than mere information gathering.

Honeytoken activity

Why it fails: Honeytoken activity is a detection based on a decoy account or credential that, when used, signals malicious activity. While an attacker who has obtained a hash might use a honeytoken, this alert is not specific to Pass-the-Hash or Overpass-the-Hash; it triggers on any use of the decoy credential. The alert in question is a dedicated detection for the overpass-the-hash technique, which is a specific Kerberos-based attack, so honeytoken activity is a different and less precise indicator.

Privilege escalation

Why it fails: Privilege escalation is a broad attack category where an attacker gains higher-level permissions, and while Overpass-the-Hash can be a step in such an attack, the alert 'Suspected overpass-the-hash attack' is a specific technique-based detection. Privilege escalation detections typically monitor for actions like adding a user to a privileged group or modifying ACLs, not for the NTLM hash-to-Kerberos ticket misuse that characterizes this alert. Choosing this option would ignore the precise signature of the hash-based authentication anomaly.

Suspected brute force attack

Why it fails: A suspected brute force attack is characterized by many failed authentication attempts, often with different passwords against a single account, to guess credentials. Overpass-the-Hash does not involve guessing; the attacker already possesses a valid NTLM hash and uses it to request a Kerberos ticket, so there is no high volume of failed logons. The alert engine distinguishes this by looking for Kerberos ticket requests with a known hash-based encryption (RC4) from unusual actors, which is entirely different from brute-force failure patterns.

DnsEvents | where ResponseSize > 1000

Why it fails: DNS tunneling often uses small queries; size alone is not a good indicator.

DnsEvents | where ResultCode != 0

Why it fails: Non-zero result codes indicate failures, not tunneling.

DnsEvents | where QueryType == 'A'

Why it fails: Filtering by query type alone is not specific to tunneling.

Workbooks

Why it fails: Visualization and reporting, not hunting.

Analytics rules

Why it fails: Used for alert generation, not hunting.

Playbooks

Why it fails: Automation of responses, not hunting.

The time range is too short

Why it fails: While expanding the query window could capture events from a slower attack, a zero-result response points to a structural flaw in the query's correlation logic, not insufficient data. The failed-to-successful logon sequence may still exist within the current range, but the join condition demanding identical SourceIP will exclude those sequences because the attacker changed IPs. Extending time only yields more events; it does not alter the equality predicate that is preventing matches. Thus, this is not the root cause.

The threshold is too low

Why it fails: A low failed-attempt threshold (for example, setting it to 2 instead of 10) makes the query more permissive and would add more user accounts to the candidate set, not empty it. If the threshold were too high, you might plausibly get zero results because no account meets the minimum; but the note specifies it is too low, which would inflate rather than deflate results. The empty output remains explained by the SourceIP join, as the threshold only controls how many failures must precede a success, not whether a success is linked to those failures. Therefore, this option cannot be the cause of zero findings.

The EventID for successful logon is incorrect

Why it fails: In Windows Security auditing, event ID 4624 is the definitive ID for a successful logon, while 4625 denotes a failed logon; using 4624 in the query is accurate. An incorrect ID, such as 4634 (logoff) or 4626 (user/device claims), would fail to select actual successful logon events, but the note confirms the query references the proper ID. Because the events are being collected correctly under 4624, the zero-result problem cannot be attributed to an invalid success identifier. This option is therefore incorrect.

The query should use 'and' instead of 'or'

Why it fails: Replacing `or` with `and` would demand that both the file name and the initiating process file name contain the indicator at the same time, which is almost never the intended logic because the goal is usually to catch either side of the process creation relationship. An attacker-controlled file could be named normally but launched by a suspicious process, or vice versa, so an OR condition is necessary to cover both possibilities. Moreover, using `and` does not address the missing parentheses—it would still evaluate according to operator precedence and produce a query that is too restrictive.

The required data connector should be 'MicrosoftThreatProtection'

Why it fails: The `MicrosoftThreatProtection` data connector is used to ingest signals from Microsoft 365 Defender, but it is not something you reference inside a KQL query, and its presence or absence does not change how `contains`, `or`, or parentheses are parsed. Custom hunting queries in Sentinel run against logs already collected in your Log Analytics workspace, such as `DeviceProcessEvents` from Microsoft Defender for Endpoint; the query itself is independent of which connector brought that data in. Therefore, blaming the connector for a logical flaw in the query is a misunderstanding of both query execution and data flow.

The 'contains' operator should be 'startswith'

Why it fails: The `contains` operator performs a substring match anywhere in the string, which is appropriate when hunting for indicators that may appear as a folder path, file name, or part of a larger process name. In contrast, `startswith` anchors the match to the beginning of the field, so it would silently miss relevant events where the indicator appears in the middle or end of the string. The original flaw is not about the choice of comparison operator but about how the conditions are combined, so switching to `startswith` would change matching semantics and still leave the precedence issue unresolved.

DC01 is exfiltrating data via SMB

Why it fails: Data exfiltration via SMB is uncommon and would not target many IPs.

DC01 is scanning the network for open SMB shares

Why it fails: Less likely for a DC; scanning is more suspicious.

DC01 is compromised and spreading malware

Why it fails: Possible but not the most likely explanation for a DC.