Incident Response practice questions

Clear-M365Session

Why it fails: This command does not exist.

Disable-Mailbox

Why it fails: This disables the account, which is too aggressive for session termination.

Disconnect-ExchangeOnline

Why it fails: This only disconnects the local shell session.

ip.addr == 192.168.1.50

Why it fails: This includes source and destination traffic.

src.ip == 192.168.1.50

Why it fails: This is not valid Wireshark syntax.

filter: 192.168.1.50

Why it fails: This is not valid Wireshark syntax.

AppLocker

Why it fails: This is for access control, not logging.

Credential Guard

Why it fails: This protects credentials, it is not a logging tool.

Audit Process Creation

Why it fails: This only captures the parent command, not the full script.

Event ID 4670

Why it fails: This is for object permission changes.

Event ID 4625

Why it fails: This indicates a failed logon.

Event ID 1102

Why it fails: This indicates audit log clearing.

Employee performance reviews

Why it fails: Irrelevant to IR.

Coffee machine logs

Why it fails: Irrelevant.

Building access badges

Why it fails: Generally not part of the initial digital evidence.

Device ID

Why it fails: This identifies the hardware used.

Risk State

Why it fails: This relates to Identity Protection risk scores.

Conditional Access Status

Why it fails: This shows policy enforcement, not the MFA outcome.

Reboot the machine

Why it fails: Rebooting risks evidence loss.

Delete the malware file

Why it fails: Must be preserved for evidence.

Update antivirus definitions

Why it fails: Not an immediate containment action.

Event Viewer

Why it fails: Event Viewer displays logs from various sources, including security and system logs, but it does not show real-time process information such as parent-child relationships or command lines. It can be used to review past events, but for immediate live analysis of a running process, it is not the appropriate tool. Event Viewer is more suited for after-the-fact log analysis rather than active process investigation.

Resource Monitor

Why it fails: Resource Monitor shows real-time CPU, memory, disk, and network usage per process, but it does not display parent process information or command-line arguments. It is useful for performance troubleshooting but not for forensic analysis of process lineage. An analyst needing to trace a process's origin would not find the necessary details in Resource Monitor, so it is not the correct choice here.

Task Manager

Why it fails: Task Manager shows running processes and basic details but does not display parent process information or full command-line arguments by default. It is useful for ending processes but lacks the depth needed for incident response. While it can show some resource usage, it does not provide the lineage or command-line context required to trace how a process was launched, making it insufficient for this scenario.

The $MFT record for the file server's data volume

Why it fails: The $MFT contains metadata about files and directories, such as creation and modification times, but it does not record execution. While it can show that a suspicious file existed, it cannot confirm that the file was run. In a ransomware case, the dropper may have been deleted, and the $MFT alone would not reveal its execution or link it to the encryption activity.

The Volume Shadow Copy snapshots of the system drive

Why it fails: Volume Shadow Copies contain point-in-time snapshots of files and can be useful for recovering encrypted data or comparing file versions. However, they do not directly record execution of a dropper. Ransomware often deletes shadow copies to prevent recovery, so they may be unavailable. They are not the best artifact for identifying the initial dropper's execution.

The Windows Security event log for Event ID 4688 (process creation)

Why it fails: Event ID 4688 logs process creation if audit policy is enabled, but it may not be configured to capture command-line arguments by default. It could show the dropper's execution, but only if the event was logged and retained. In many environments, 4688 logging is not enabled or is overwritten quickly. Prefetch is more reliable because it is generated automatically for executed programs.

Security event log with Event ID 5145 (Detailed file share access)

Why it fails: Event ID 5145 logs detailed file share access, such as when a client accesses a share. While it may show the account accessing the ADMIN$ share during PsExec, it does not directly link that access to the service creation. It could be noisy and may not capture the exact moment of service installation. It is less direct than other artifacts for identifying the initiating account.

System event log with Event ID 7045 (Service installation)

Why it fails: Event ID 7045 in the System log records the installation of a new service, including the service name and path, which is typical for PsExec (e.g., PSEXESVC). However, it does not include the user account that initiated the service creation. It only shows that a service was installed, not who did it. Therefore, it cannot identify the account used for lateral movement.

Security event log with Event ID 4624 (Logon Type 3)

Why it fails: Event ID 4624 with Logon Type 3 indicates a network logon, which occurs when PsExec establishes an SMB connection. However, it does not directly reveal the account that created the remote service. Many network logons happen legitimately, and the account shown is the one used for authentication, not necessarily the one that initiated the service creation. This log alone cannot definitively identify the PsExec source user.

Disable the user's account in Active Directory.

Why it fails: Disabling the user's account may be a step if the account is compromised, but the scenario describes a malware infection on the workstation, not necessarily credential theft. Disabling the account could disrupt the user's work and is not directly related to containing the malware's C2 communication. The priority is to stop the malware from spreading and communicating, which is better achieved by blocking C2 and capturing evidence.

Run a full antivirus scan on all domain controllers.

Why it fails: Running an antivirus scan on domain controllers is not an immediate containment action for a workstation malware infection. Domain controllers are critical infrastructure, and scanning them could impact performance. The focus should be on the infected workstation and its C2 communications. While ensuring domain controllers are clean is important, it is not the next step after isolating the workstation.

Reimage the workstation immediately to remove the malware.

Why it fails: Reimaging the workstation destroys valuable forensic evidence and may not be necessary if the malware can be removed through other means. It also does not address the containment of the C2 channel or prevent other systems from being infected. Reimaging should only be done after forensic analysis and with proper approval, as it can impede the investigation and remediation efforts.

Windows Security event logs showing successful logons from the user account

Why it fails: Security event logs record authentication events but do not show data transfer activities. While they can confirm that the account was used, they do not reveal the exfiltration channel or destination. In an exfiltration investigation, authentication logs are supporting evidence but not the primary source for identifying how data left the network.

NetFlow data showing large outbound transfers to a known cloud storage IP

Why it fails: NetFlow provides metadata about connections, such as IPs, ports, and byte counts, but it does not reveal application-layer content or the specific domain. Large outbound transfers to a known cloud storage IP could be legitimate business activity. While NetFlow can indicate volume, it lacks the context to definitively identify the exfiltration channel or the destination domain, making it less useful than proxy or DNS logs.

Antivirus logs showing a quarantined file on the user's workstation

Why it fails: Antivirus logs indicate malware detection but do not provide details about exfiltration channels or destinations. A quarantined file might be unrelated to the exfiltration or could be a secondary payload. These logs are useful for understanding the infection but do not directly help identify where data was sent or how it was exfiltrated.

Run a full antivirus scan on the file server

Why it fails: Running an antivirus scan can be resource-intensive and may not stop an active ransomware infection. It could also alert the attacker or cause the malware to accelerate encryption. Antivirus scans are more suitable for post-containment cleanup. The priority is to prevent further damage, not to scan for additional malware, which can be done later.

Shut down the file server immediately

Why it fails: Shutting down the server may stop encryption but will erase volatile memory, which can contain critical evidence such as encryption keys or malware binaries. It also causes downtime that might be avoided with network isolation. Powering off is generally a last resort unless the system is causing immediate harm, such as spreading ransomware to many hosts. Network isolation is preferred as it stops the threat while preserving evidence.

Disconnect the file server from the network

Why it fails: Disconnecting the server from the network can stop the spread of ransomware, but it may also destroy volatile evidence such as active network connections and memory-resident malware. Additionally, if the server is critical, disconnecting it could disrupt business operations. Best practices suggest isolating the system in a way that preserves evidence while containing the threat, such as disabling network interfaces via a controlled method or using network segmentation.

lsof -i

Why it fails: The lsof -i command lists open files that are network sockets, showing processes and their network connections. While it is a valid alternative, it may be slower and less commonly available on minimal Linux installations. The question asks for the command to capture current network connections and associated processes; netstat -antp is more universally available and directly tailored for this purpose.

ifconfig -a

Why it fails: The ifconfig -a command displays network interface configuration, such as IP addresses and MAC addresses, but it does not show active connections or associated processes. It is useful for understanding the network interfaces but does not provide the connection-to-process mapping required for live response. Therefore, it does not meet the analyst's need.

ps -ef

Why it fails: The ps -ef command lists all running processes with full details, but it does not show network connections. While it can help identify suspicious processes, it does not map those processes to network sockets. In a live response scenario focused on network connections, ps alone is insufficient; it must be combined with a tool like netstat or ss to correlate processes with connections.

Services console for the Windows Event Collector service

Why it fails: The Windows Event Collector service runs on the collector, not typically on the forwarding domain controller. Checking this service on the domain controller would not confirm the WEF subscription status; the subscription is configured and monitored through Event Viewer's Subscriptions node, not the local service state.

Performance Monitor with the Event Tracing for Windows counter set

Why it fails: Performance Monitor with ETW counters measures event tracing sessions, not Windows Event Forwarding subscriptions. It would not reveal subscription health, heartbeat failures, or configuration issues on the domain controller, so it cannot verify why the SIEM stopped receiving forwarded logs from this host.

Task Scheduler under Microsoft\Windows\EventLog

Why it fails: Task Scheduler may show the EventLog-ForwardingPlugin task, but it does not provide subscription status or heartbeat information. The task could be running while the subscription itself is misconfigured or disabled, so this check would not confirm whether WEF is actually delivering events to the collector, making it an unreliable first step.

Get-Process | Format-List *

Why it fails: Get-Process lists process details but does not include full command-line arguments by default and does not show network connections. It would not satisfy the requirement to capture both network connections and complete process command lines, making it insufficient for this volatile evidence collection task.

netstat -anob

Why it fails: netstat -anob shows active connections with owning process IDs and executable names, but it does not capture full command-line arguments for processes. Command lines are critical for identifying malicious scripts or arguments, so relying only on netstat would leave a major evidence gap during live response on this workstation.

wmic process get ProcessId,CommandLine

Why it fails: WMIC can retrieve process command lines, but it does not capture network connections. The analyst also needs network connection data, so WMIC alone would miss a required evidence category. Additionally, WMIC is deprecated in newer Windows versions, making it less reliable for modern live response.

Threat Intelligence dashboard

Why it fails: Threat Intelligence dashboards correlate indicators and threat feeds, not ATT&CK technique mappings for authentication events. It would be the right destination when investigating whether an observed IP or hash matches known adversary infrastructure, not for confirming which ATT&CK technique a failed-then-successful login pattern represents.

Access Anomalies dashboard

Why it fails: Access Anomalies highlights deviations in authentication behaviour, yet it does not display the MITRE ATT&CK technique mapping required here. It would be the right dashboard when triaging which access events are statistically unusual, not when confirming the ATT&CK technique that a failed-login-then-success pattern maps to.

User Activity Monitoring

Why it fails: User Activity Monitoring surfaces per-user session and behaviour detail, but it does not present the ATT&CK technique mapping the question asks you to verify. It is the correct dashboard when profiling a specific account's activity over time, not when confirming which ATT&CK technique an authentication pattern corresponds to.

Delete the ticket and create a new one

Why it fails: Deleting the ticket destroys the incident record and its audit trail, and creates no notification to the security manager, so escalation cannot occur. It is tempting when a ticket was raised in error, where deletion is the correct cleanup action, but escalation requires reassignment or a workflow that alerts the manager while preserving the record.

Manually email the manager with incident details

Why it fails: Emailing the manager bypasses ServiceNow's escalation workflow, leaving the ticket unassigned and untracked, so no auditable notification occurs. It is tempting as a quick manual nudge, and would suffice for informal updates, but standard escalation requires changing assignment or state within SIR so the platform notifies the manager automatically.

Change the State to 'Closed'

Why it fails: Closing the ticket ends the incident workflow and suppresses further notifications, so the security manager is never alerted and the escalation is lost. It is tempting once an incident is genuinely resolved, where closing is correct, but escalation demands an assignment or state change that actively notifies the manager.

Assign it to another team to verify

Why it fails: Assigning the ticket to another team adds a handoff and delays closure, since no verification is required once the alert is confirmed as a false positive. Reassignment suits alerts needing specialist investigation, such as suspected malware requiring endpoint analysis, where the current analyst lacks the tools or authority to resolve it.

Ignore the ticket and let it expire

Why it fails: Leaving the ticket to expire keeps the false positive open, skewing metrics and risking later re-escalation. Expiry is acceptable only for low-severity informational events with no triage obligation, not an alert an analyst has already assessed.

Delete the incident

Why it fails: Deleting the incident erases the audit trail needed to tune detection rules and evidence the triage decision. Deletion suits duplicate or test records, whereas a genuine false positive should be closed with its classification recorded.

Host Timeline

Why it fails: Host Timeline lists chronological endpoint events such as file writes and registry changes, but does not present the hierarchical parent-child process relationships needed to identify the parent. It is tempting for reconstructing an intrusion sequence, yet the process tree view is what maps ancestry directly.

Detection Details

Why it fails: Detection Details summarises the detection's metadata and severity, not the process lineage. The process tree with parent-child relationships appears in the Process Explorer or Investigation view. Tempting because it sounds like the deepest drill-down, but it is designed for reviewing detection context and triage notes, not for tracing execution ancestry.

Network Activity

Why it fails: Network Activity shows connections and traffic, not the parent-child relationships between processes, so the process tree cannot be reconstructed there. It is tempting because network data genuinely helps trace command-and-control or lateral movement, but parent process identification requires the Process Timeline or process tree view.