Hard Difficulty Questions

ES app settings.

Why it fails: Retention for the risk index is set in indexes.conf on the indexer, not through Enterprise Security app settings. ES settings are tempting because they configure correlation searches, threat intelligence and risk scoring, and would be correct when tuning ES-specific behaviour rather than index storage policy.

Data model acceleration settings.

Why it fails: Retention for the risk index is set in indexes.conf (or via the Indexes UI), not in data model acceleration, which controls how summarised data model results are built and stored. Data model acceleration is tempting because it also manages storage of precomputed results, but it never governs raw index retention.

Correlation Search Editor.

Why it fails: The Correlation Search Editor configures searches that generate risk events; it cannot change index retention. It is tempting because risk scores and risk notables originate there, and it would be correct when adjusting a correlation search's schedule, throttling or risk object assignment rather than storage.

Increase the risk score to 100 so that only high-risk events trigger notables.

Why it fails: Raising the risk score does not reduce the number of risk events; it only changes their weight. If the search still matches the same false-positive events, those events will continue to contribute risk and may still generate notables when combined with other risk. This approach can also cause legitimate low-risk events to be overlooked or to inflate risk unnecessarily, and it does not address the root cause of the false positives.

Add a throttle to the correlation search to suppress duplicate notable events.

Why it fails: Throttling suppresses duplicate notables but does not reduce the underlying false-positive risk events. If the search is generating many risk events from benign activity, throttling only hides the symptoms, and risk scores will still accumulate. It also does not improve the detection logic, so the same false positives will recur. Throttling is useful for duplicate suppression but is not the primary tuning method for reducing false-positive risk events.

Disable the correlation search and create a new one with a different name.

Why it fails: Disabling the search eliminates the false positives but also removes any true positive detection capability. Creating a new search with a different name does not solve the underlying issue unless the logic is improved; it simply duplicates the problem. This approach is disruptive and does not follow the principle of tuning rather than disabling. It also loses the history and configuration of the original search, which may be needed for audit or comparison.

The correlation search schedule is set to 'Real-time'.

Why it fails: Real-time schedules are supported for correlation searches and still produce notable events, so this would not suppress Incident Review entries. Real-time scheduling is the right choice when detection must fire on events the moment they arrive rather than at fixed intervals.

The user does not have the 'ess_admin' role.

Why it fails: The ess_admin role grants configuration and review capabilities, not the ability to make a correlation search's results appear as notable events; a user lacking it simply cannot view or manage them. It would be the correct answer if the question concerned permissions to administer ES.

The data model acceleration is lagging.

Why it fails: Lagging data model acceleration delays the underlying search results themselves, yet the stem states the search already returns results. Accelerated data models are the correct choice when searches must complete quickly over large datasets rather than scanning raw events.

Maps IP addresses to locations.

Why it fails: That is done via the 'iplocation' command.

Maps fields to a dashboard.

Why it fails: The map command runs a search for each result row and appends the output, enabling per-result subsearches; it does not map fields to a dashboard. Dashboard field mapping tempts because 'map' suggests visual linking, but that is dashboard studio or panel configuration, not SPL.

Creates a map visualization.

Why it fails: Map command is for search loops, not visualization types.

Aggregate bytes transferred per destination and alert when a single destination exceeds a fixed threshold of total data volume per hour.

Why it fails: Beaconing is characterized by small, frequent check-ins rather than large transfers, so a byte-volume threshold targets bulk exfiltration instead. An implant that merely polls for commands would stay well below the threshold and go undetected, while legitimate large downloads and backups would trigger the alert, inverting the intended detection.

Search for any destination whose fully qualified domain name was registered within the last 30 days using a passive DNS lookup and alert on all contacts to it.

Why it fails: Newly registered domains are a useful enrichment signal but are neither necessary nor sufficient for beaconing. Many benign services use recent domains, and mature implants often use aged or compromised domains, so this approach generates false positives and misses periodic communication to established infrastructure that the hunt is meant to reveal.

Count total outbound connections per source host per day and alert on any host in the top decile of connection volume.

Why it fails: High connection volume identifies busy or chatty hosts, not periodic beaconing. A beacon sends few, evenly spaced requests, so it would rank low on volume and be missed entirely, while legitimate update services and browsers would dominate the top decile and generate constant false positives unrelated to the implant behavior being hunted.

Initial Access

Why it fails: Initial Access is the tactic used to gain an initial foothold within a network, such as through phishing or exploiting a public-facing application. In this scenario, the attacker already has access and is moving laterally, so Initial Access has already been achieved. It does not describe the current activity of moving between systems.

Privilege Escalation

Why it fails: Privilege Escalation involves gaining higher-level permissions, such as from a standard user to administrator. While lateral movement may sometimes involve privilege escalation, the core activity described is moving from one system to another using a compromised account. Privilege Escalation is a separate tactic that focuses on elevating access rights, not on traversing the network.

Execution

Why it fails: Execution involves running malicious code, such as scripts or binaries, on a local or remote system. While lateral movement may involve execution of tools, the tactic itself is about the movement between systems, not the execution of code. The scenario focuses on the movement using a compromised account, which is more aligned with Lateral Movement.

Manual approval for every alert

Why it fails: Manual approval for every alert introduces human latency and does not define risk scoring, thresholds or response actions, so it cannot make an alert risk-based. It is tempting because approval gates suit high-impact change control, where a person must authorise an action before it executes.

Hardware-level encryption

Why it fails: Hardware-level encryption protects data at rest on physical media and contributes nothing to defining alert risk, thresholds or response logic. It is tempting because encryption appears security-relevant, and it would be the right control when regulatory requirements demand protection of stored data against physical disk theft.

The 'Data Model Acceleration' settings.

Why it fails: Data Model Acceleration speeds up searches over accelerated datasets; it stores neither narrative nor procedural documentation. It is tempting because accelerated data models underpin ES correlation searches, and would be the right choice where the requirement is search performance across large datasets rather than documenting response process.

The 'Threat Intelligence' upload manager.

Why it fails: Threat Intelligence uploads feed correlation searches and indicator matching, supporting Detect and Respond, not Recover documentation. It is tempting because intelligence informs recovery decisions, but NIST CSF Recover documentation maps to ES incident review, response plans and notable event workflows, not the intelligence framework.

The 'Workflow Actions' settings for firewall rule creation.

Why it fails: Workflow Actions trigger automated firewall rule creation during response, not documentation of the process itself. It is tempting because workflow actions do form part of incident response execution, and would be correct where the requirement is automating containment actions rather than recording the documented procedure.

The Splunk License usage report.

Why it fails: The licence usage report tracks daily indexing volume against entitlement, revealing nothing about correlation search logic, scheduling, or alert actions. It is tempting because exceeded licence limits can suppress searching, but that produces a global block, not a single malfunctioning correlation search.

The user's web browser cache.

Why it fails: A correlation search runs server-side in the Splunk search head, so browser cache contents cannot affect its execution or reveal why it failed. Browser cache is tempting because clearing it resolves stale dashboard rendering, which is a client-side display issue rather than a search logic or scheduling fault.

index=firewall action=blocked OR bytes_out>5000

Why it fails: The OR operator broadens the result set, returning events that are blocked regardless of byte count, plus any event with bytes_out above 5000 even if the action is allowed or missing. This violates the requirement to return only events satisfying both conditions, and it would also surface events lacking the action field when their byte count is high.

index=firewall action=blocked NOT bytes_out>5000

Why it fails: The NOT operator inverts the byte condition, so this search returns blocked events with bytes_out of 5000 or less, plus blocked events where bytes_out is null. That is the opposite of the requirement, and it still excludes events missing the action field, but for the wrong reason and with the wrong byte filter.

index=firewall action=blocked bytes_out<5000

Why it fails: Using the less-than operator selects blocked events with byte counts below 5000, which contradicts the scenario's need for large transfers. Although this search does correctly exclude events without the action field, the direction of the numeric comparison is inverted, so it returns the wrong subset of firewall traffic.

CPU core count

Why it fails: CPU core count is a host hardware metric, not a parameter of the Risk Analysis adaptive response action, which configures risk score thresholds, risk objects and risk message fields. It would be relevant when sizing search-head capacity for correlation searches, not when defining how risk is scored and attributed.

Network interface speed

Why it fails: Network interface speed is an infrastructure performance metric, not a configurable field within the Risk Analysis adaptive response action, which sets risk score, risk object and risk object type values. It would matter when diagnosing throughput bottlenecks on indexers, not when assigning risk to entities.

inputlookup

Why it fails: inputlookup reads rows from a lookup file and cannot count connections between a workstation and an external server. It is the correct choice when enriching or filtering events against a static lookup table rather than analysing network traffic frequency.

map

Why it fails: The map command plots geographic coordinates, so it cannot count connection frequency to a port; it fails because the stem needs aggregation, not visualisation. It is tempting because map is genuinely useful for plotting IP-based attack origins on a world map, which is the correct choice when location, not frequency, is the question.

search

Why it fails: A bare search returns raw matching events without aggregating them, so it cannot produce the frequency count the stem requires. It is tempting because search is the correct starting point for isolating the traffic, and would suffice if the question asked merely to display matching events rather than quantify them.

Web

Why it fails: This is for web traffic.

Endpoint

Why it fails: Endpoint captures files/processes, but Change Analysis is the specific model for configuration audits.

Authentication

Why it fails: This is for user logins.

The severity level of the notable event.

Why it fails: risk_score is a numeric risk contribution, not the notable's severity level, which is a separate field set by the correlation search. It tempts because both influence prioritisation, yet severity drives urgency display while risk_score feeds the risk framework's object scoring.

The threshold for triggering a notable.

Why it fails: risk_score carries the numeric risk value written to the risk index for the object, not a trigger threshold. Thresholds belong in correlation search configuration or notable event suppression rules, which is why this option attracts candidates familiar with alerting logic rather than adaptive response parameters.

The total risk score for the object.

Why it fails: The risk_score parameter supplies the numeric value assigned to the object when the adaptive response runs, not an aggregate total. It is tempting because risk frameworks do accumulate scores per object over time, but that aggregation is performed by risk correlation searches, not by this parameter.

Incident Review

Why it fails: Incident Review is a dashboard for triaging and managing notable events, allowing analysts to assign, comment, and track status. While it supports response workflows, it does not automate actions like blocking IPs or disabling users. It is primarily an analysis and collaboration tool, not an automation engine. Relying on it for automated response would leave manual steps in the critical path.

Threat Intelligence Framework

Why it fails: The Threat Intelligence Framework allows ingestion and management of threat feeds to enrich events and generate findings. It supports the Detect function by identifying known malicious indicators, but it does not perform response actions like blocking or disabling. Using it for Respond would be a misalignment because it lacks the automation and action orchestration capabilities required.

Risk Analysis

Why it fails: Risk Analysis in Splunk ES aggregates risk scores from various detections to prioritize investigations. It helps analysts focus on high-risk entities but does not execute response actions. It is a prioritization tool that supports the Detect and Respond functions indirectly, but it cannot block IPs or disable users. Confusing it with an automation feature would result in no actual containment.

Endpoint

Why it fails: The Endpoint data model covers process, file and registry activity, not Windows event log clearing, which surfaces through audit-policy change events. It is tempting because endpoint telemetry often reveals attacker behaviour, and in scenarios involving process execution or file modification it would be the correct choice.

Network Traffic

Why it fails: Network Traffic covers flows, sessions and protocol metadata, none of which record Windows event log clearing. It is tempting because network data frequently exposes attacker activity, and in scenarios involving exfiltration or command-and-control traffic it would be the correct choice.

Authentication

Why it fails: Authentication covers logon and credential events, not the clearing of the Windows Security Event log itself. It is tempting because failed and successful logons often reveal attacker access, and in scenarios involving brute-force or credential-stuffing activity it would be the correct choice.

Anomalous number of failed logon attempts

Why it fails: Failed logon attempts are indicative of brute force or password guessing, not credential dumping. Credential dumping involves extracting credentials from a compromised system, which typically results in successful authentications. While failed logons may accompany an attack, they are not a specific indicator of credential dumping and would not be the best evidence to search for.

Creation of a new service with a random name

Why it fails: While attackers may create services for persistence, this is not a specific indicator of credential dumping. Credential dumping focuses on extracting credentials from memory or files, not on creating services. Service creation could be part of other malicious activities, but it lacks the direct link to credential theft that lsass access provides.

Unexpected modification of the hosts file

Why it fails: Modification of the hosts file is often used for redirecting traffic or persistence, but it is not directly related to credential dumping. Credential dumping targets credential stores like lsass memory or SAM database, not network name resolution. Therefore, hosts file changes are not a valid indicator for this specific attack.

The Network Traffic data model, which captures sessions and can reveal authentication attempts embedded in network flows.

Why it fails: The Network Traffic data model focuses on network sessions, bytes transferred, and related flow metadata. While some authentication activity may traverse the network, this data model does not normalize authentication outcomes such as success or failure by user. It is not designed to correlate login failures with subsequent successes, making it a poor fit for this authentication-focused investigation.

The Risk data model, which aggregates risk events and can show whether authentication failures contributed to an entity's score.

Why it fails: The Risk data model stores risk events and their contributions to entity scores. It reflects the output of detections, not the raw authentication telemetry needed to correlate individual failures with later successes. Using it would show that risk was assigned, but not the underlying sequence of authentication events the analyst needs to examine across indexers.

The Web data model, which captures HTTP activity and can include login attempts to web applications.

Why it fails: The Web data model covers HTTP traffic such as requests, responses, and URLs, and may include web application logins. However, it does not normalize authentication outcomes for non-web protocols like SSH, VPN, or directory services. Since the scenario involves authentication failures broadly across systems, the Web data model is too narrow and lacks the normalized authentication fields required.

Index-time field extraction.

Why it fails: Index-time extraction parses fields as events are ingested; it creates no persistent record of which applications are sanctioned. It is correct when you need searchable fields for performance, but maintaining an authorised-software list requires an inventory lookup, not extraction configuration.

Correlation search thresholding.

Why it fails: Thresholding suppresses or triggers alerts when a correlation search's result count crosses a limit; it produces no software inventory. Correlation search thresholding is correct for reducing alert noise on detection rules, whereas the Identify function needs an asset inventory of approved applications.

Dynamic Threat Intelligence updates.

Why it fails: Threat intelligence feeds supply indicators of compromise for detection, not an inventory of sanctioned applications. Dynamic threat intelligence is the right choice for enriching detections and correlating known malicious infrastructure, whereas authorised-software tracking needs an asset or software inventory data source.

Use the lookup command with a threat intelligence feed of known malicious IP addresses and drop every DNS event whose source is not in the feed.

Why it fails: Dropping events that are not in a threat feed assumes the attacker's infrastructure is already catalogued, which is exactly what a proactive hunt cannot rely on. Novel exfiltration domains will not appear in the feed, so this approach discards the very evidence being sought and biases the hunt toward known indicators only.

Use the dedup command on the query field to remove repeated queries and then count the remaining events per host to determine exfiltration volume.

Why it fails: Deduplicating on the query field collapses repeated identical lookups, but tunneling generates unique encoded queries that are rarely exact duplicates. This removal does not measure length or entropy and distorts volume counts, so it provides no reliable signal for identifying the abused destination domain or the anomalous encoding pattern.

Use the transaction command to group all DNS events from a single source IP over a 30-minute window into one event and inspect the raw payload.

Why it fails: The transaction command groups related events but does not compute length or entropy, and dumping raw grouped payloads does not scale to large DNS volumes. It also risks memory pressure and produces output that is hard to compare quantitatively, so it fails to directly quantify the abnormally long query names the hunt requires.