Threat And Attack Types practice questions

Incident Review

Why it fails: Incident Review displays and triages already-generated notables; it does not track raw email URL delivery telemetry. It tempts as the primary analyst workflow, but URL click and delivery tracking belongs to Email Analysis dashboards fed by mail gateway data. Incident Review surfaces outcomes, not delivery events.

Audit Trails

Why it fails: Audit Trails records Splunk platform activity such as logins, searches and configuration changes, not email URL delivery. It tempts because it tracks system events, but those are Splunk-internal, not phishing telemetry. Email Analysis dashboards ingest mail gateway and proxy data to trace URL delivery.

Content Management

Why it fails: Content Management governs app, correlation search and knowledge object deployment across search heads; it holds no email delivery data. It tempts as the place where detection content lives, but tracking URL delivery requires Email Analysis dashboards consuming mail gateway and proxy logs, not content administration.

4720

Why it fails: 4720 records user account creation, not authentication, so it cannot detect Pass-the-Hash, which appears as a successful logon (4624) with type 3 or 9 and NTLM. It is tempting because it is a security-relevant account event, but it tracks account lifecycle, not credential reuse.

4625

Why it fails: 4625 records failed logon attempts, whereas Pass-the-Hash succeeds using stolen NTLM hashes, producing 4624 logon events. It is tempting because failed logons suggest credential attacks, but brute-force or password guessing generates 4625, not hash reuse.

4740

Why it fails: 4740 records account lockouts, a side effect of repeated failed authentication, not the successful NTLM logon that Pass-the-Hash produces. It is tempting because lockouts indicate credential abuse, but they follow failed attempts, while Pass-the-Hash yields 4624 with logon type 3 or 9.

Dashboard > File Intelligence

Why it fails: This is not a default ES dashboard name.

Incident Review > Search by Hash

Why it fails: This is a manual workflow, not a built-in feature path.

Search > File Hash Investigation

Why it fails: This is not a native ES menu path.

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.

Dashboard panels

Why it fails: Dashboard panels only visualise results of searches already run; they perform no correlation between a VPN login and a later file access. They are tempting because panels can display both event types side by side, but that is presentation, not linking. The correct feature joins events across sources using shared identifiers.

Lookup tables

Why it fails: Lookup tables statically enrich events with pre-existing reference data such as asset ownership; they cannot dynamically link a VPN login to a subsequent file access. They are tempting because they associate fields across datasets, but that association is fixed at lookup creation, not derived from event timing or shared session identifiers.

Saved searches

Why it fails: Saved searches merely store a search for later execution or scheduling; they do not themselves correlate a VPN login with a later file access. They are tempting because a scheduled search can run correlation logic, but the linking is performed by the search's commands, not by the saved-search artefact.

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.

Web

Why it fails: Web captures proxy and HTTP request activity, not the internal host-to-host connections lateral movement produces. It is tempting because web logs can reveal command-and-control or exfiltration, and Web would be correct when investigating browsing, URL or user-agent anomalies rather than east-west movement.

Identity

Why it fails: Used for user context, not the movement itself.

dest_port

Why it fails: dest_port describes the destination service port and is not required by the Authentication data model, which expects fields such as user, src and action. It is tempting because port data appears in many network events, but Authentication maps identity and outcome, not transport ports.

file_name

Why it fails: file_name describes file system activity, so it maps to the Endpoint Filesystem data model, not Authentication. It is tempting because file_name appears in many CIM models, but Authentication requires user, src, and action fields instead.

Network connections

Why it fails: Part of the Network Traffic model.

HTTP Requests

Why it fails: Part of the Web data model.

Password spraying

Why it fails: Password spraying attempts a few common passwords against many accounts, but usually with a low number of attempts per account to avoid lockouts. The scenario shows a spike in failures for multiple accounts from one IP, but spraying typically uses a single password per attempt cycle, not many different passwords. The pattern here is more consistent with credential stuffing.

Kerberoasting

Why it fails: Kerberoasting is an Active Directory attack that requests service tickets for accounts with SPNs and cracks them offline. It does not produce a spike in authentication failures across multiple user accounts from an external IP. The observed failed logins are not indicative of Kerberoasting, which focuses on ticket extraction rather than login attempts.

Brute force

Why it fails: Brute force targets a single account with many password guesses. The scenario explicitly states failures for multiple user accounts, not one. Brute force would generate a high volume of failures for the same username, which is not what is observed. Therefore, brute force does not fit the multi-account pattern.

Authentication data model, field ticket_encryption_type

Why it fails: The Authentication data model tracks authentication events like logins, not Kerberos ticket requests. It does not contain a field for ticket encryption type. Kerberoasting involves requesting service tickets with specific encryption types, which are captured in the Endpoint data model's Kerberos events, not in Authentication.

Identity_Management data model, field ticket_encryption

Why it fails: The Identity_Management data model tracks identity-related events such as user account changes, not Kerberos ticket requests. It lacks fields for ticket encryption. Kerberoasting detection requires examining Kerberos service ticket requests, which are found in the Endpoint data model's Kerberos event category, not in Identity_Management.

Network_Traffic data model, field encryption_type

Why it fails: The Network_Traffic data model focuses on IP flows and does not capture Kerberos ticket details like encryption type. While network traffic may include Kerberos packets, the data model does not extract ticket encryption types. Analysts need endpoint-level Kerberos event logs to detect Kerberoasting, not network flow data.

Detect Large Outbound Transfers

Why it fails: The 'Detect Large Outbound Transfers' correlation search monitors for significant data transfers leaving the network, typically based on byte counts in network traffic. While DNS tunneling can transfer data, the volume is usually small and spread across many queries, so this search may not trigger. It is not specifically designed to detect the low-and-slow pattern of DNS tunneling.

Detect Exfiltration via HTTP

Why it fails: The 'Detect Exfiltration via HTTP' correlation search focuses on data exfiltration over HTTP, not DNS. It analyzes web traffic for signs of data being uploaded to external sites. Since the scenario involves DNS queries, this search would not be effective. It is a plausible but incorrect choice because it addresses exfiltration but not via the DNS protocol.

Detect Anomalous DNS Activity

Why it fails: While 'Detect Anomalous DNS Activity' might sound relevant, it is not a standard correlation search name in Splunk ES. Splunk ES includes specific searches like 'Detect DNS Tunneling' for this purpose. This option is a distractor that could confuse analysts who are not familiar with the exact search names in the content library.

Authentication data model, using the Successful_Authentication node to review root logons around the time the binary was created.

Why it fails: Authentication events show who logged in and when, which can establish initial access timing, but they do not record socket connections or process-to-network mappings. A reverse shell is confirmed by the connection itself, not by logon records. This data model would provide context but cannot validate the raw socket and external port activity.

Web data model, using the Web_Traffic node to search for HTTP requests from the server to the external IP.

Why it fails: The Web data model covers HTTP proxy and web server logs, but a raw socket on port 4444 is not HTTP traffic and would not appear there. Reverse shells typically use non-web ports and custom protocols, so this data model would produce no relevant events and would misdirect the investigation away from the actual connection evidence.

Endpoint data model, using the Processes node to correlate process_name, parent_process_name, and user, then pivot to network connections by process ID.

Why it fails: The Endpoint data model and Processes node are useful for process lineage, but the parent is gone, so parent_process_name is empty. Raw socket behavior and the external connection are better confirmed through network telemetry. Relying on process lineage alone would leave the reverse shell unconfirmed because the missing parent removes that key linkage.

Web data model, field bytes_in

Why it fails: In the Web data model, bytes_in typically represents bytes received by the client from the server. For outbound POST requests, the data is sent from the client to the server, so bytes_in would not capture the outgoing payload size. Analysts should look at the bytes sent by the client, which is not bytes_in in the Web data model.

Web data model, field bytes_out

Why it fails: The Web data model contains fields for HTTP traffic, but bytes_out represents the number of bytes sent from the server to the client, not from the client to the server. For outbound POST requests from an internal host, the bytes sent by the client would be captured in a different field, such as bytes_in, depending on perspective. Thus, bytes_out is not the correct field for client-to-server exfiltration.

Network_Traffic data model, field bytes_in

Why it fails: In the Network_Traffic data model, bytes_in represents bytes received by the source IP, not sent. For outbound exfiltration, the source is the internal host sending data, so the relevant field is bytes_out. Using bytes_in would show incoming traffic, which is the opposite of what is needed to detect large outbound POST requests.

Verify the digital signature of the update package using endpoint or file integrity monitoring telemetry available in Splunk ES.

Why it fails: Digital signature verification is valuable, but the scenario asks for activities that determine tampering with the update mechanism. Signature checks confirm authenticity of a signed package, yet a compromised update mechanism could deliver a validly signed but malicious payload or bypass signing. This option is less directly tied to detecting the tampering than hash comparison and post-install behavior review.

Check the Authentication data model for failed logons on the update server in the last 24 hours.

Why it fails: Failed logons on the update server indicate authentication problems or brute-force attempts, not whether a delivered update package was modified. Supply chain tampering can occur without any failed logons, so this data model does not address the integrity of the update itself and would likely produce irrelevant findings.

Search the Web data model for HTTP 404 responses from the vendor's download site.

Why it fails: HTTP 404 responses show missing resources on a website, which is unrelated to whether a downloaded update was tampered with. A successful tampering could still return HTTP 200, so this search would not confirm alteration of the package and would misdirect the investigation toward website availability issues.

Notable Event Aggregation

Why it fails: Notable Event Aggregation groups existing notable events by shared fields such as entity, correlating detections rather than raw events across a long duration. It is the right choice when reducing duplicate notables from the same host or user into a single incident.

Asset Investigator

Why it fails: Asset Investigator displays all activity tied to one asset, but it does not correlate events over a long duration into a single entity-based detection. It is the correct choice when pivoting on a known asset to review its historical behaviour and associated events.

Threat Activity

Why it fails: Threat Activity dashboards surface matches against threat intelligence lookups, not long-duration event correlation to one entity. Threat Activity is the correct choice when reviewing which indicators matched, their severity, and the intelligence sources that produced them.

User Activity Center

Why it fails: User Activity Center focuses on individual user behaviour and authentication patterns, not correlating a burst of failures against a subsequent success from a new source. It is tempting for identity investigations, but brute-force confirmation requires the Access Anomalies or Authentication dashboards that surface failed-then-successful login sequences.

Protocol Intelligence

Why it fails: Protocol Intelligence analyses network traffic protocols and sessions, not authentication event sequences. It is tempting because new IP addresses appear in network data, but confirming brute force requires correlating failed logins with a later success, which the Access Anomalies dashboard presents rather than protocol-level traffic analysis.

Threat Intelligence Activity

Why it fails: Threat Intelligence Activity matches events against known indicators of compromise, so it only helps if the attacking IP is already on a threat feed. It is tempting because malicious IPs feature in brute force, but the failed-then-successful pattern is confirmed through Access Anomalies, not intelligence matching.

Notable Event Suppressor

Why it fails: Notable Event Suppressor only suppresses matching notable events from triggering again; it performs no threat-intelligence lookup against external IP addresses. It is tempting as a triage tool for reducing noise, but verifying a TOR exit node requires the Threat Intelligence framework's ip_intel lookup.

Identity Table

Why it fails: The Identity Table stores identity attribution data such as user names, email addresses and prioritised identity categories, not external IP threat intelligence. It is tempting because it enriches events with contextual lookups, but TOR exit-node verification requires the ip_intel lookup within the Threat Intelligence framework.

Asset Table

Why it fails: The Asset Table holds internal asset metadata such as hostnames, owners and priority classifications, not external IP reputation data. It is tempting because it performs lookup enrichment on fields, but confirming a TOR exit node needs the ip_intel lookup from the Threat Intelligence framework.

src_user

Why it fails: src_user identifies the originating account, which pivots to identity or authentication dashboards rather than the File domain. It is tempting because email investigations often involve the sender, but file_hash is the field that links a notable event to file-based analysis.

signature

Why it fails: signature describes the detection rule or analytic that generated the notable event, not the attachment itself. It is tempting because it summarises the alert, but file_hash is the field that pivots to the File domain investigation dashboard.

dest_port

Why it fails: Destination port carries no file identity, so it cannot pivot to the File domain dashboard, which keys on file hash, name or path. It is tempting because port fields do appear in the Network Traffic data model, and dest_port is genuinely useful when investigating connection-level activity rather than attachment artefacts.

Network Traffic

Why it fails: Network Traffic models packet flows, sessions and protocol metadata, so audit policy changes made via auditpol.exe never populate it. It is tempting because auditpol activity can traverse the network, but the Change data model, which records policy and configuration modifications, is what captures this event.

Endpoint

Why it fails: Endpoint models process execution, file and registry activity, not the audit policy configuration change itself, so auditpol.exe modifications do not populate it. It is tempting because auditpol.exe runs locally on a host, yet the Change data model specifically records policy and configuration modifications.

Authentication

Why it fails: Authentication models logon, logoff and credential validation events, not modifications to audit policy settings, so auditpol.exe changes never populate it. It is tempting because auditpol relates to security auditing, but the Change data model is the one that records policy and configuration modifications.