Incident Detection And Response practice questions

Indicator of Compromise (IOC) search

Why it fails: Identifies files but not their specific execution flow.

Detection dashboard filter

Why it fails: Provides aggregate views, not process-specific visualization.

Host search history

Why it fails: Lists commands but lacks the visual graph of movement.

Data filtering logs

Why it fails: Data filtering logs record which security profiles matched traffic and the resulting allow, block, or alert action; they carry no session timing or byte counts, so periodic beacon intervals cannot be measured. Data filtering is the right log when auditing policy enforcement or troubleshooting why traffic was permitted or denied.

Threat logs

Why it fails: Threat logs record signature, spyware, and vulnerability detections, so they only show beaconing once a known signature fires; low-and-slow or custom C2 traffic generates no threat entry. Threat logs are the right source when confirming which exploit or malware signature triggered an alert.

URL filtering logs

Why it fails: URL filtering logs capture requested web addresses and URL category verdicts, not repeated connections to an IP or domain at regular intervals. URL filtering is the correct source when investigating web-browsing policy violations or categorised site access, not command-and-control beacon detection.

Apply a filter: 'data.len > 1MB'

Why it fails: 'data.len' is not a standard Wireshark filter syntax.

Apply a display filter: 'ip.addr == 10.0.0.5 && tcp.len > 1048576'

Why it fails: This filters packets, not whole streams.

Use 'Analyze > Expert Info'

Why it fails: This shows packet-level errors and alerts, not stream size.

Containment, Eradication, and Recovery

Why it fails: Focuses on stopping the damage and restoring operations.

Post-Incident Activity

Why it fails: Focuses on lessons learned after the event.

Preparation

Why it fails: Deals with policy and training before an incident.

Normal web browsing

Why it fails: Does not typically exhibit high-volume, random, short-duration connection attempts.

VPN connection

Why it fails: Usually a persistent tunnel to a single gateway.

Data exfiltration

Why it fails: Typically involves a single, large session or sustained connection to a known destination.

Application log

Why it fails: Generally records application crashes, not internal macro operations.

System log

Why it fails: Tracks core Windows services.

Security log

Why it fails: Does not typically track Office macro execution.

Detection and Analysis

Why it fails: Primarily a technical investigative task.

Containment and Eradication

Why it fails: Mostly technical work.

Power management logs

Why it fails: Irrelevant to lateral movement.

Windows Update logs

Why it fails: Only tracks update status.

DNS client logs

Why it fails: Less relevant for tracking lateral movement between hosts.

notable_event_id

Why it fails: This is a unique identifier assigned to the event after creation, not a configuration field for aggregation.

drilldown_search

Why it fails: This defines the search query for the incident review dashboard, not the aggregation logic.

suppression_period

Why it fails: This is a general configuration parameter but not the specific field for event aggregation logic.

Event ID 4688 with Command Line Auditing enabled

Why it fails: While this logs the process execution, it often truncates long command lines and does not capture the full script block content.

Event ID 1102

Why it fails: This indicates that the audit log was cleared, which is a sign of anti-forensics, not evidence of command execution.

Event ID 4624

Why it fails: This logs user logon events, not the specific code execution details.

Remove the container image from the registry

Why it fails: This is a global action that affects all nodes and does not contain the running instance on the specific compromised host.

Update the Kubernetes NetworkPolicy to deny all ingress and egress

Why it fails: While this prevents communication, it does not stop the malicious process from running or modifying memory within the host.

Delete the pod immediately to stop the communication

Why it fails: Deleting the pod destroys the ephemeral storage and volatile memory, losing critical forensic evidence.

Deleting all incident logs to preserve storage space

Why it fails: Logs should be archived for compliance and future forensic needs.

Decommissioning the entire production network

Why it fails: This is an extreme and unnecessary action for most incidents.

Changing the domain administrator password

Why it fails: While good practice, it is not the specific step for verifying the recovery of an individual affected system.

The DNS queries are likely the result of a misconfigured application performing reverse DNS lookups.

Why it fails: Reverse DNS lookups typically query PTR records for IP addresses, not random subdomains of a single domain. Misconfigured applications might generate unusual DNS traffic, but the pattern of random subdomains is not typical for reverse lookups. This option is incorrect because it does not match the observed behavior.

This behavior is indicative of a DNS amplification attack targeting the internal network.

Why it fails: A DNS amplification attack involves sending queries with a spoofed source IP to open DNS resolvers, causing large responses to be sent to the victim. The scenario describes a host making many queries for random subdomains, which is outbound behavior, not an inbound amplification attack. This option is incorrect.

The queries are benign because they are directed to a single domain and not to multiple external domains.

Why it fails: Benign DNS traffic rarely involves a high volume of randomly generated subdomains. Attackers use this technique to hide data in DNS queries. Assuming it is benign because it targets one domain is a dangerous misconception; the randomness and volume are red flags. This option is incorrect.

Process injection into the signed binary

Why it fails: Process injection would cause malicious code to run inside the signed process itself, potentially altering its behavior or memory. However, the scenario describes a child process making outbound connections, not the signed binary directly exhibiting malicious network activity. Injection into the parent would not typically create a separate child process with its own network connections.

DLL search order hijacking

Why it fails: DLL search order hijacking loads a malicious DLL from an attacker-controlled directory when a legitimate application resolves a library by name. In this scenario, the signed binary itself is intact and its hash matches a known good file, so the initial execution is not the result of a hijacked DLL. The suspicious behavior comes from the child process, not from the signed parent loading a rogue library.

Code signing certificate compromise

Why it fails: If the attacker had compromised a code signing certificate, the malicious binary itself would carry a valid signature, but its hash would not match a known good application. In this scenario, the hash matches a legitimate application, meaning the binary is unmodified. The abuse lies in how the legitimate binary is used, not in a forged signature.

A pass-the-hash attack is being attempted against the service account from the workstation.

Why it fails: Pass-the-hash attacks typically succeed without knowing the plaintext password and would generate successful logons (Event ID 4624) or lateral movement artifacts, not a uniform stream of 4625 failures. The regular 30-second interval and single source host are more consistent with an automated process retrying outdated credentials.

The service account password was changed on the workstation but not replicated to the domain controller.

Why it fails: If a password change had not replicated, the workstation would still authenticate successfully with the old password against a domain controller that had not yet received the update, and the failures would be transient. Persistent 4625 events over many days point to the client itself presenting an obsolete password, not a replication delay.

The server's account lockout policy is misconfigured and is generating false 4625 events.

Why it fails: Account lockout policy settings affect when a locked account is disabled and when lockout events are logged, but they do not fabricate repeated network logon failures from a specific source IP. Event ID 4625 reflects an actual failed authentication attempt, so a policy misconfiguration alone would not produce this steady, host-specific pattern.

The NTFS USN journal on the domain controller's system volume, which tracks file and directory changes.

Why it fails: The USN journal records changes to files and directories on a volume, not Active Directory object creation. It might show that the ntds.dit file was modified but would not reveal the account name created within the directory. It is not suitable for reconstructing directory service events.

The Windows System event log on the domain controller, which records account management changes.

Why it fails: Account creation events are written to the Security event log, not the System log. The System log records service starts, driver loads, and other system-level events. Therefore, it would not contain Event ID 4720 or the account name, making it an incorrect source for this specific information.

The Active Directory database file (ntds.dit) from a recent system state backup.

Why it fails: The ntds.dit file contains current account objects, but it does not record the account creation event or the account name if the account was later deleted. It also lacks the audit trail of who created it and when. While useful for other forensic purposes, it is not the best source to determine the specific account name from the creation event.

Perform full packet capture and analyze payload entropy

Why it fails: While full packet capture is useful, the traffic is encrypted, so payload entropy analysis would only show high entropy typical of encryption, which is not conclusive. It does not distinguish malicious from benign encrypted traffic. Certificate and JA3 analysis provide more actionable indicators without needing decryption.

Run a vulnerability scan against the destination IP

Why it fails: A vulnerability scan against the destination IP is unlikely to be authorized and may alert the attacker. It also does not analyze the traffic itself. The goal is to confirm maliciousness of the outbound connection, not to assess vulnerabilities on a remote system.

Check firewall logs for allowed outbound connections

Why it fails: Firewall logs show allowed connections but do not indicate whether the traffic is malicious. They only confirm that the connection was permitted, which is expected for exfiltration over 443. This does not help confirm the covert channel; deeper inspection of TLS characteristics is needed.

Re-image the compromised server immediately to restore service

Why it fails: Re-imaging destroys volatile evidence such as memory and running processes before forensic capture, and restoration belongs to the recovery phase. It is tempting because it quickly restores service, but containment instead isolates the host, for example by network segmentation, while preserving evidence for investigation.

Shut down the entire corporate firewall

Why it fails: Powering down the whole firewall severs all corporate network traffic, including the monitoring and response channels needed to investigate and contain the incident. It is tempting as an aggressive blocking move, but containment instead applies targeted rules isolating only affected segments or hosts.

Notify the local police department

Why it fails: Contacting police is an escalation and notification step, typically handled during preparation or post-incident coordination, not a containment action. It is tempting because legal involvement matters in severe breaches, but containment focuses on limiting spread through isolation, account disablement and evidence preservation.

Throttle field

Why it fails: Throttling suppresses repeated notables for the same alert.

Notable event urgency

Why it fails: Urgency levels define the severity status of the resulting incident.

Risk score adjustment

Why it fails: Risk scoring relates to incident prioritization, not trigger conditions.

Run an 'Update By Query' API call

Why it fails: Update By Query modifies stored documents; it performs no aggregation and would rewrite matching records instead of returning counts. It is tempting because it accepts Lucene-style queries, and would be correct for backfilling a field across existing documents after a mapping change.

Use a regex filter in the search bar

Why it fails: A regex filter matches raw message text but cannot aggregate or rank, so it returns matching documents rather than the top 10 counts per source IP. Regex is tempting for pattern extraction, and would be correct when isolating a known string signature across logs, not for terms aggregation.

Export all logs to CSV and use Excel

Why it fails: Exporting to CSV and pivoting in Excel moves analysis outside Kibana, so the one-hour window and destination filter must be reapplied manually and results are stale on arrival. It is tempting because spreadsheets suit ad-hoc counting, and would be correct for offline forensic reporting where live query speed is irrelevant.