Cyber Landscape And Industry Frameworks practice questions

search sourcetype=sysmon | rename command as powershell.

Why it fails: Renaming a field does not help identify malicious patterns.

| inputlookup mitre_tactics | where process=powershell.

Why it fails: This queries a lookup, not the actual process data.

index=main | lookup mitre_attack_id.

Why it fails: This is not a valid search command.

Manually edit the 'Data Model' accelerations for NIST compliance.

Why it fails: Data models accelerate search performance, not framework compliance.

Modify the 'Notable Event' aggregation policy to NIST standards.

Why it fails: Aggregation policies control incident grouping, not framework reporting.

Update the 'Threat Intelligence' index settings to include NIST tags.

Why it fails: Threat intelligence handles IoCs, not framework alignment.

Hardcoding the technique description into the 'dest_host' field.

Why it fails: This would overwrite vital host metadata and not perform the mapping.

Configuring the 'correlation_rule_id' to match the ATT&CK tactic name.

Why it fails: Correlation rule IDs identify the rule, not the technique.

Mapping the source IP to the 'mitre_source_id' field.

Why it fails: This field does not exist in the ES threat intelligence mapping schema.

An XML-based 'Incident Review' dashboard export.

Why it fails: This is for reporting, not data ingestion.

A custom .yml file uploaded to the /etc/system/local directory.

Why it fails: This is not the standard mechanism for threat feed ingestion.

A static .conf file in the app bin folder.

Why it fails: Static configuration files are not used for dynamic feed management.

Windows Security Event Logs (specifically 4688).

Why it fails: 4688 is for process creation, not registry keys.

DNS query logs.

Why it fails: DNS logs monitor domain resolution, not host persistence.

Netflow logs.

Why it fails: Netflow tracks network connections, not system changes.

The `_time` value of the notable event's initial triggering event combined with the `status` field transition to "Closed" on the investigation timeline.

Why it fails: This measures detection-to-closure time, not detection-to-breach-confirmation time. The `status` field changing to Closed reflects when the analyst finished the investigation, which may be hours or days after the breach was actually confirmed. HIPAA notification clocks start when the incident is determined to be a reportable breach, not when the ticket is closed, so this pair of timestamps systematically overstates elapsed time.

The `create_time` of the investigation record and the `status` field value "New" on the notable event.

Why it fails: `create_time` marks when the investigation artifact was generated, and "New" is the default untouched state of a notable event. Neither captures analyst confirmation of a breach. A notable event can sit in "New" indefinitely, so this pairing measures nothing meaningful about elapsed detection-to-confirmation time and would understate or randomly distort the interval depending on queue backlog.

The `firstTime` and `lastTime` fields on the correlated notable event in the Incident Review dashboard.

Why it fails: `firstTime` and `lastTime` bound the aggregation window of the correlation search that produced the notable event, not the moment a human confirmed a breach. They answer "how long did the suspicious activity span," which is useful for scoping but unrelated to confirmation time. Using them would report the attack's duration rather than the regulatory clock, producing a misleading figure for HIPAA reporting.

Weaponization

Why it fails: Weaponization is the phase where the attacker creates the malicious payload, such as the document with an exploit. This phase occurs before delivery and exploitation. Since the document has already been opened and a script executed, Weaponization has already passed. Investigating it now would not address the current active threat on the workstation.

Actions on Objectives

Why it fails: Actions on Objectives is the final phase where the attacker achieves their goal, such as data exfiltration or destruction. While the PowerShell execution could be part of that, it is more likely a step toward installation or establishing persistence. Focusing on Actions on Objectives prematurely would overlook the intermediate steps that often occur, such as maintaining access and moving laterally.

Command and Control

Why it fails: Command and Control typically involves establishing a communication channel with an external server to receive instructions. In this scenario, the execution of a PowerShell script after a malicious document is more indicative of an action that occurs immediately after exploitation, such as installing malware or establishing persistence. Command and Control would come later, after the attacker has established a foothold and moved laterally.

DNS logs

Why it fails: DNS logs are useful for detecting domain generation algorithms (DGAs) and DNS tunneling, but they do not provide the full picture of C2 communications, which may use HTTP or other protocols. They are complementary but not the most critical data source for general C2 detection.

Endpoint logs

Why it fails: Endpoint logs can show process executions and network connections, but they may not capture the full context of C2 traffic, especially if encrypted. While valuable, they are not as comprehensive as proxy logs for identifying C2 communications, which often traverse the network perimeter.

Firewall logs

Why it fails: Firewall logs can show allowed and denied connections, but they often lack application-layer detail needed to identify C2 protocols. While they can indicate suspicious outbound connections, they are not the most critical data source for detecting C2, which often uses HTTP, DNS, or other protocols.

rex

Why it fails: The `rex` command is used to extract fields using regular expressions. While it can extract the Base64 string, it does not decode it. The analyst would still need to use another command to decode the extracted string. Therefore, `rex` alone does not fulfill the requirement to decode the command. It is a step, but not the complete solution.

eval

Why it fails: The `eval` command can perform calculations and manipulate fields, but it does not have a built-in Base64 decoding function. While you could use `eval` with a custom function or a series of calculations, it is not the straightforward command for decoding Base64. The typical approach is to use a dedicated decoding function, not `eval` alone. So, `eval` is not the best choice.

urldecode

Why it fails: The `urldecode` function is used to decode URL-encoded strings, not Base64. Attackers often use Base64 for obfuscation, not URL encoding. Applying `urldecode` to a Base64 string would not yield the original command and could produce garbled output. Thus, `urldecode` is not appropriate for this task.

Command and Control

Why it fails: Command and Control (C2) is the phase where the attacker communicates with the compromised system to issue commands. While macro execution may lead to C2, the immediate action of executing a macro is not C2 itself. C2 typically occurs after installation, when the malware establishes a channel back to the attacker.

Exploitation

Why it fails: Exploitation is the phase where the attacker leverages a vulnerability to execute code. While macro execution can involve exploiting a vulnerability, in this scenario the user enabled macros, which is more accurately classified as Installation or Execution depending on the framework. The Cyber Kill Chain's Exploitation phase typically refers to exploiting a software vulnerability, not user-driven macro execution.

Delivery

Why it fails: Delivery is the phase where the attacker transmits the weaponized payload to the victim, such as via email. However, the execution of the malicious macro occurs after the payload has been delivered and the user has interacted with it. Therefore, this activity represents a later phase, not Delivery.

Firewall logs

Why it fails: Firewall logs primarily provide information about network connections allowed or denied. While they can help detect the Delivery phase by showing inbound malicious files or connections, they are not the most relevant for Weaponization, which occurs on the adversary's side and is not directly observable in network logs. Firewall logs are more useful for later phases like Command and Control.

Endpoint detection and response (EDR) logs

Why it fails: EDR logs are valuable for detecting Exploitation, Installation, and later phases by monitoring process execution and file changes. However, they are less directly relevant to Weaponization (which occurs before delivery) and Delivery, as EDR typically observes activity after the payload has been delivered and executed. Thus, EDR is not the best choice for these early phases.

DNS logs

Why it fails: DNS logs can be useful for detecting Command and Control and some Delivery via domain lookups, but they are not the primary source for Weaponization or Delivery. Weaponization is not observable in DNS, and Delivery via email or web is better detected through email and proxy logs. DNS is more relevant for later phases like C2.

Authentication logs

Why it fails: Authentication logs record successful and failed logon attempts, which are relevant to techniques like brute force or credential dumping, not application layer protocol C2. They do not capture network traffic or protocol details. While authentication logs can show lateral movement, they are not useful for detecting T1071. Including them would divert attention from the actual C2 communication evidence.

Firewall logs

Why it fails: Firewall logs provide information about allowed and denied connections at the network layer, including IP addresses and ports. While they can show connections to suspicious IPs, they do not inspect application layer protocols. T1071 specifically involves application layer protocols like HTTP, HTTPS, or DNS, so firewall logs lack the granularity to confirm protocol usage. They are supplementary but not primary for this technique.

DNS query logs

Why it fails: DNS query logs are relevant for T1071.004 DNS, which is a sub-technique of T1071. However, the question asks for the technique overall, and DNS is a specific sub-technique. While DNS logs are useful, they are not the most direct evidence for application layer protocol usage in general. Focusing solely on DNS could miss HTTP-based C2. Therefore, DNS logs are less central than proxy logs for the parent technique.

Use the 'threat_intel' macro in correlation searches to automatically enrich events with ATT&CK technique context from the threat intelligence framework.

Why it fails: The 'threat_intel' macro in Splunk ES is used to look up threat intelligence matches in events, but it does not automatically enrich events with ATT&CK technique context. ATT&CK technique context is typically added through the threat intelligence framework's mapping capabilities or through specific correlation searches. Relying solely on this macro would not provide the necessary mapping to techniques.

Deploy the Splunk Add-on for MITRE ATT&CK to automatically tag all events with technique IDs based on keyword matching.

Why it fails: There is no official Splunk Add-on for MITRE ATT&CK that automatically tags events with technique IDs via keyword matching. MITRE ATT&CK mappings in Splunk ES are typically done through correlation searches and threat intelligence framework configurations, not a dedicated add-on. This option is plausible but incorrect because such an add-on does not exist and the approach is not how Splunk ES integrates ATT&CK.

Create a custom lookup file that maps every possible ATT&CK technique to a Splunk ES correlation search name and manually update it daily.

Why it fails: While custom lookups can be used for various purposes, manually maintaining a lookup that maps every ATT&CK technique to correlation search names is not a necessary or efficient action for effectively mapping threat intelligence to ATT&CK. Splunk ES provides built-in mechanisms for threat intel mapping and correlation, making this manual approach redundant and error-prone.

Endpoint detection and response (EDR) process telemetry

Why it fails: EDR telemetry can show processes that may be involved in data staging or exfiltration, but it typically does not capture the actual network payload. While EDR can detect suspicious process behavior like archiving files, it may not reveal the exfiltration channel itself. Therefore, it is less direct for detecting T1041 compared to network-based sources with content visibility.

NetFlow data and firewall logs

Why it fails: NetFlow and firewall logs can show large outbound data transfers, but they lack the application-layer context to distinguish exfiltration over C2 from other types of traffic. T1041 specifically involves exfiltration over the existing C2 channel, which may be encrypted or use common protocols. Without payload inspection or proxy logs, these sources may only indicate volume anomalies, not the specific technique.

DNS logs with query logging

Why it fails: DNS logs can reveal DNS tunneling exfiltration (T1048.003), but T1041 is exfiltration over a command and control channel, which may not use DNS. DNS logs would only be useful if the C2 channel itself uses DNS, which is not guaranteed. Thus, DNS logs are not the primary source for detecting T1041.

Command and Control (C2)

Why it fails: Command and Control (C2) involves communication between compromised systems and adversary-controlled infrastructure to send commands or receive instructions. While outbound connections can be part of C2, the scenario describes a server that typically only communicates internally, making unexpected outbound connections more indicative of exfiltration rather than ongoing C2, which often involves regular beaconing. The focus here is on data leaving the network, not command traffic.

Exfiltration

Why it fails: Exfiltration is indeed the stage where data is stolen from the network. However, in the Cyber Kill Chain, Exfiltration is not a separate stage; it falls under Actions on Objectives. The Cyber Kill Chain stages are Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. Thus, Exfiltration is a specific action within Actions on Objectives, but the question asks for the stage, which is Actions on Objectives.

Exploitation

Why it fails: Exploitation is the stage where the adversary takes advantage of a vulnerability to gain access. The scenario describes outbound connections from an already compromised server, indicating that exploitation has already occurred. The focus is on data leaving the network, not the initial compromise, so Exploitation is not the correct stage.

Detect Kerberoasting

Why it fails: Kerberoasting (T1558.003) is indeed a Credential Access technique, so this search is relevant. However, the question asks for the most relevant to address a general gap in Credential Access. Credential dumping via LSASS is a more fundamental and widely applicable technique, often used to obtain credentials for further attacks. Kerberoasting is specific to service accounts in Active Directory, so while it addresses part of the gap, it is narrower in scope.

Detect Pass-the-Hash

Why it fails: Pass-the-Hash (T1550.002) is a technique under Lateral Movement, not Credential Access. While it involves credentials, it is about using hashed credentials to move laterally, not about accessing or stealing credentials. Therefore, this search would address a gap in Lateral Movement detection, not Credential Access.

Detect Excessive Failed Logins

Why it fails: Excessive failed logins are typically associated with brute force attacks, which fall under Credential Access. However, this search is more about detecting the attack attempt rather than the successful credential access. It is relevant but not the most direct for detecting actual credential dumping or theft, which are core Credential Access techniques.

Create a custom search that manually extracts IOCs from the STIX/TAXII feed and uses the 'lookup' command to match against events.

Why it fails: While manually extracting IOCs and using the 'lookup' command could work, it is not the most accurate or efficient method. The Threat Intelligence framework in Splunk ES automates the ingestion and management of IOCs from STIX/TAXII feeds, and the 'threat_intel' macro is purpose-built for this correlation. Manual extraction is error-prone, lacks automation, and does not leverage the framework's capabilities.

Configure the 'Threat Intelligence' framework to automatically generate notable events for every IOC match without additional correlation searches.

Why it fails: The Threat Intelligence framework does not automatically generate notable events for every IOC match. While it can be configured to create threat intelligence matches, generating notable events typically requires correlation searches that leverage the 'threat_intel' macro or similar. Without correlation searches, IOC matches might be recorded but not surfaced as actionable notables, limiting their utility for analysts.

Enable the 'Threat Intelligence' data model acceleration and run searches against the 'Threat_Intelligence' data model.

Why it fails: The 'Threat Intelligence' data model in Splunk ES stores threat intelligence data, but simply enabling acceleration and searching the data model does not directly correlate IOCs with internal events. Correlation requires matching IOCs from the threat intel store against events from various data sources, which is done via the 'threat_intel' macro in correlation searches. Searching the data model alone would only show the threat intel data, not matches with internal events.

Installation.

Why it fails: Installation establishes persistence on the compromised host through malware or backdoors, which occurs locally and is not governed by outbound firewall rules. Egress filtering is tempting as a containment measure, but it targets Command and Control and exfiltration traffic leaving the network, not the on-host installation phase.

Reconnaissance.

Why it fails: Egress filtering constrains outbound traffic, so it cannot stop reconnaissance, which is inbound scanning and information gathering against exposed services. It is tempting because reconnaissance precedes intrusion, but the phase actually mitigated by egress filtering is Command and Control or exfiltration, where outbound channels are blocked.

Exploitation.

Why it fails: Exploitation delivers the payload against a vulnerable service, typically inbound, so outbound egress rules do not prevent it. Egress filtering is tempting because it limits what a compromised host can reach, but its actual kill-chain target is Command and Control or exfiltration, not the exploitation phase itself.

Domain Controller authentication logs.

Why it fails: Domain Controller authentication logs evidence credential access and lateral movement, later kill-chain phases, not Delivery of the payload. They are tempting because identity telemetry is valuable across intrusion investigations, but Delivery requires visibility of the transmission vector, such as email gateway, web proxy or removable media records.

Internal host process creation logs.

Why it fails: Process creation logs evidence Execution, where malicious code runs, not Delivery of the payload to the victim. They are tempting because endpoint telemetry is central to later kill-chain phases, but Delivery concerns the transmission vector itself, such as email, web or removable media, so mail gateway and proxy data fit this stage.

Endpoint file integrity monitoring.

Why it fails: File integrity monitoring detects installation or modification on the endpoint, evidencing Installation or Actions on Objectives, not Delivery. It is tempting because endpoint monitoring underpins many kill-chain detections, but Delivery concerns the inbound transmission vector, so email gateway, web proxy or removable media telemetry is prioritised.

Vulnerability Data Model.

Why it fails: The Vulnerability Data Model tracks findings such as CVEs and affected hosts, not the asset inventory itself. It is tempting because vulnerability management also depends on knowing assets, and it would be correct for CIS Control 7 remediation reporting, but it does not enumerate enterprise assets.

Endpoint Data Model.

Why it fails: The Endpoint Data Model covers endpoint processes, services, filesystem and registry activity, not a consolidated asset inventory. It is tempting because endpoints are assets, and it would be correct for endpoint detection and process-level hunting, but it does not provide the inventory visibility CIS Control 1 requires.

Network Traffic Data Model.

Why it fails: The Network Traffic Data Model describes sessions, flows and protocol communications rather than device inventory. It is tempting because network data can reveal connected hosts, and it would be correct for traffic analysis and anomaly detection, but it does not maintain the asset records CIS Control 1 demands.