Incident Response and First Responder Skills practice questions

Begin capturing a memory dump using a forensic tool.

Why it fails: Documentation should precede active collection.

Power off the computer immediately to preserve the disk.

Why it fails: Powering off destroys volatile evidence in memory.

Ask the user to log off so the system can be imaged.

Why it fails: Logging off alters system state and may lose evidence.

Use a write blocker when acquiring the disk image.

Why it fails: A hardware write blocker is a valuable acquisition tool because it intercepts storage commands to prevent writes to the source disk, but that protection exists only during the copy process. It does not produce a cryptographic value that can be compared later to prove the image has not changed since acquisition. A disk image can still be corrupted or tampered with after the write-blocked acquisition, which is why a SHA-256 hash must be computed immediately after collection and recorded.

Document every person who handled the evidence.

Why it fails: Documenting every person who handled the evidence establishes a chain of custody and shows who had physical access, but it does not detect or prevent alteration of the data itself. A paperwork trail provides no checksum or digital verification that would expose a changed file or corrupted sector. The integrity of the acquired image must be independently proven by a cryptographic hash, not by custody documentation.

Place the evidence in an evidence bag and lock it in a secure room.

Why it fails: Placing evidence in a bag and securing it in a locked room protects against physical interference and preserves the chain of custody, but these measure do not verify the bit-level integrity of a digital image. Physical security cannot account for accidental bit rot, imaging errors, or digital tampering that could occur while the image is stored or accessed. Only a cryptographic digest such as SHA-256 can mathematically prove that the data is exactly as it was when collected.

Run an antivirus scan to remove the ransomware.

Why it fails: Running an antivirus scan is an invasive live response action that executes files, modifies the registry, writes scan logs, and updates file system metadata such as timestamps and the MFT. It may also quarantine or delete the ransomware binary before it can be analyzed, destroying the very artifacts needed to identify the attacker and understand the encryption mechanism. Antivirus removal belongs to the remediation phase, only after a full forensic acquisition.

Restore the system from backup to minimize downtime.

Why it fails: Restoring from backup overwrites the compromised logical volume with pre-infection data, erasing the ransomware executable, the ransom note, event logs, prefetch and amcache entries, and any artifacts revealing the initial access vector. This is evidentiary spoliation: analysts lose all ability to scope the breach, determine data exfiltration, or prove criminal intent. Restoration is a recovery step that must be delayed until the original disk has been imaged and the forensic timeline established.

Disconnect the network cable immediately.

Why it fails: Disconnecting the network cable immediately is over-aggressive containment that severs live command-and-control channels and lateral movement sessions before the connection state, peer IPs, and remote session data have been recorded from memory. It also risks triggering a watchdog or scheduled task that may act locally on the affected host. The proper sequence is to capture volatile network evidence first, then isolate the network interface to contain the incident while preserving forensic value.

TCP 0.0.0.0:3389 LISTENING PID 668

Why it fails: Listening on 0.0.0.0:3389 means the Remote Desktop Protocol service is bound to all local IPv4 interfaces and is waiting for inbound connections; this is the default configuration for Windows remote administration and is not inherently malicious. PID 668 should be validated to confirm it maps to Terminal Services, but a listening RDP socket alone is normal and only becomes suspicious when combined with evidence like repeated failed logons or unexpected credentials.

TCP 192.168.1.10:49154 to 192.168.1.1:53 TIME_WAIT PID 2016

Why it fails: The connection from 192.168.1.10:49154 to 192.168.1.1:53 is an internal DNS exchange; TCP/53 is used for zone transfers or large responses, and 192.168.1.1 is the local gateway or private resolver. TIME_WAIT indicates the client initiated closure after the DNS query completed, leaving no active session, and PID 2016 likely belongs to the DNS Client service. This traffic is wholly within the private network and represents standard name resolution activity.

TCP 192.168.1.10:49152 to 10.0.0.5:80 ESTABLISHED PID 3342

Why it fails: This ESTABLISHED connection to 10.0.0.5:80 is a live HTTP session to an internal private IP, and such traffic is typical for an internal web application or device. Since 10.0.0.0/8 is RFC1918 space, the destination is not remotely reachable by nature; PID 3342 should be checked to verify it is a trusted local process, but an active connection to an internal HTTP server by itself does not indicate compromise or unauthorized activity.

/bin/bash (PID 1245)

Why it fails: The presence of /bin/bash (PID 1245) alone is not an indicator of compromise because bash is the standard command interpreter for user sessions and system scripts on virtually every Linux distribution. A benign bash process typically shows a normal command-line argument (or none), a legitimate parent process such as sshd or a terminal emulator, and no unexpected network sockets. Without evidence of command injection, a suspicious parent-child relationship, or outbound connections, PID 1245 should be deprioritized during triage.

nc -lvp 4444 (PID 1302)

Why it fails: While nc -lvp 4444 (PID 1302) is classically associated with a reverse-shell backdoor — the -l flag places it in listen mode and port 4444 is a common choice for attackers — this process is only listening and does not show active CPU usage or an ongoing connection. A listener may be a secondary persistence mechanism or an awaiting handler for a future callback, but in the immediate triage it represents a latent threat rather than the actively executing malicious code. The Python script in /tmp demonstrates current malicious activity, making it a higher-priority subject for forensic acquisition and process interception.

perl /tmp/.script.pl (PID 1325)

Why it fails: The Perl script at /tmp/.script.pl (PID 1325) also warrants scrutiny due to its hidden dotfile naming and staging in /tmp, but its lower CPU usage relative to the Python process suggests it is either idle, blocked on I/O, or performing a less resource-intensive supporting function. In incident triage, analysts prioritize processes that combine hidden execution paths with high resource consumption because those are more likely to be the main payload causing observable impact. For PID 1325, a better classification is a secondary module, a persistence wrapper, or a decoy — not the driving force of the incident.

Disconnect the laptop from the corporate network immediately to stop any ongoing data exfiltration.

Why it fails: Disconnecting the laptop from the corporate network may seem logical to stop data exfiltration, but doing so destroys the very network artifacts that reveal the attacker's activities, such as active connections, ARP/neighbor cache, and remote IP addresses. Those transient states are lost when the interface goes down, and the act of unplugging can also trigger a dead-billts switch or alert the adversary, giving them time to cover tracks. The proper order is to capture memory first, then isolate the host.

Create a forensic image of the hard drive using a write blocker.

Why it fails: Creating a forensic image of the hard drive with a write blocker is essential for evidence preservation, but it is not the first step because disk contents are far less volatile than RAM. Furthermore, if the system uses full-disk encryption (e.g., BitLocker, FileVault), the cryptographic keys needed to decrypt that disk image may exist only in memory; imaging before memory capture leaves you with a ciphertext blob you cannot analyze. Thus, memory acquisition precedes disk acquisition per the Order of Volatility.

Shut down the laptop to prevent further damage and preserve the disk.

Why it fails: Shutting down the laptop to 'preserve' the disk has the opposite effect on the most volatile evidence: it destroys all physical memory, including malware payloads that only run in RAM, open file handles, injected code, unflushed system logs, and decryption keys. Many advanced trojans also hook shutdown and can delete artifacts or encrypt data during the shutdown process. This makes shutdown the single worst first response action in a live system investigation.

Vulnerability Assessment

Why it fails: A vulnerability assessment is a proactive, scheduled security activity that scans systems, networks, and applications to identify and classify weaknesses before an attacker exploits them. It is not a phase of incident response, which only begins after a suspected compromise has occurred. Incident response follows a defined lifecycle (preparation, detection/analysis, containment/eradication/recovery, post-incident activity), and vulnerability assessments feed into preparation but are not executed during the response process itself.

Penetration Testing

Why it fails: Penetration testing is a proactive, authorized simulation of cyberattacks intended to discover exploitable vulnerabilities before malicious actors do. Unlike incident response, which handles real-world compromises, penetration testing is a controlled engagement performed by internal or external testers under explicit scope and rules of engagement. It is a separate security discipline, often used to validate defenses during the preparation phase, but it is not a step in the responsive incident handling workflow.

Run antivirus scans to identify and remove any malware present.

Why it fails: Running antivirus software is an invasive action that mounts file systems, updates signature databases, and alters metadata such as access times, thereby destroying temporal evidence and potentially triggering malicious code that could overwrite residual data. Scanning also requires executing untrusted software on the volatile original system, which violates the fundamental forensic principle of preserving the evidence's integrity. Any malware analysis must instead be performed on a bit-for-bit forensic image inside a controlled virtual environment.

Reboot the system into safe mode to prevent further damage.

Why it fails: Rebooting into safe mode is completely counterproductive because both the shutdown and startup processes clear volatile memory, kill active processes, release network connections, and may update or modify file system journals and last-access times. Safe mode intentionally loads only select drivers, dramatically altering the system state and potentially activating encryption mechanisms or changing registry keys. The correct protocol is to preserve volatile data first and then perform a controlled shutdown only after acquiring a memory dump and recording system information.

Connect an external hard drive to create a backup of important files.

Why it fails: Connecting an external hard drive to the suspect system introduces a writable device that will immediately cause new system events, such as USB enumeration entries in the event log, device installation files, and possible AutoRun activity, thereby contaminating the evidence source. Copying files manually also updates last-access timestamps and fails to capture deleted data, slack space, or system files in use. Forensic preservation requires using a write-blocker and creating a logical or physical image directly to a validated forensic medium, not engaging in ad-hoc file backup.

Select network interface, then verify administrative privileges, then optionally set capture filters, then start capture and save data

Why it fails: Selecting an interface before verifying administrative privileges inverts the dependency chain: in Wireshark, the Capture Interfaces dialog calls capture devices that may silently hide interfaces or fail to open them with a permission error when the user is unprivileged, so the subsequent capture start would be impossible. Even if an interface appears, its promiscuous mode is turned off, and the tool may only capture own machine's loopback or broadcast traffic, giving a false sense of success. Thus the privilege check is not just a final validation—it is the gatekeeper that makes interface enumeration and later operations trustworthy.

Optionally set capture filters, then verify administrative privileges, then select network interface, then start capture and save data

Why it fails: Setting capture filters before any interface is selected is logically premature because a BPF filter expression (e.g., tcp port 80) is compiled against a capture handle that is bound to a specific interface and its data-link type; without that binding, the filter cannot be validated or applied. Additionally, many Wireshark filter dialogs are not even available until a capture is configured, and trying to configure an output file or ring buffer before choosing the source is meaningless. The correct sequence must establish the privilege context and interface first so the filter has a concrete object to act upon.

Start capture and save data, then verify administrative privileges, then select network interface, then optionally set capture filters

Why it fails: Starting the capture and saving data as the first step puts the cart before the horse—the act of capturing is a result of a successfully opened interface handle, not a prerequisite for it; without admin rights and interface selection, there is no packet source and no data to write into a save file. Trying to 'save' first would also force Wireshark into a capture-to-file mode before a capture filter is defined, causing an infinite wait or a runtime error. This ordering collapses the entire preparatory pipeline into an impossible first action, so it cannot be a valid workflow.

Correlate mount times with Windows Security Event Log (Event ID 4663 or 4656), then identify the USB device in the Windows Registry (USBSTOR and EnumUSB), then extract serial number and vendor/product ID from registry, then locate corresponding device logs in setupapi.dev.log.

Why it fails: Starting with event logs is inefficient because you need the device serial number from the registry first to filter relevant events. Reversing the order would lead to missed correlations or require repeated access to registry.

Locate corresponding device logs in setupapi.dev.log, then identify the USB device in the Windows Registry (USBSTOR and EnumUSB), then extract serial number and vendor/product ID from registry, then correlate mount times with Windows Security Event Log (Event ID 4663 or 4656).

Why it fails: Starting with setupapi.dev.log is backwards because this log is organized by installation events and does not give you the device's serial number or VID/PID in a directly searchable form; you would have to scan it blind for a device you haven't yet identified. Without first querying USBSTOR to extract the unique serial number, you cannot build a precise filter for the Windows Security Event Log, so any correlation attempt is based on guesswork rather than the device's actual identity. The registry is the authoritative source for device identifiers and must be read before any log analysis to provide the necessary context.

Identify the USB device in the Windows Registry (USBSTOR and EnumUSB), then extract serial number and vendor/product ID, then correlate mount times with Windows Security Event Log (Event ID 4663 or 4656), without using setupapi logs.

Why it fails: Omitting setupapi.dev.log is a critical gap because those logs capture the precise timestamp of driver installation, the driver file paths, and whether the device enumerated successfully, which can confirm the first time the device was connected to that system. Even when Security Event Log auditing is disabled or the logs have been cleared, setupapi.dev.log often retains a historical record of device arrival, making it essential independent corroboration. This extra evidence can distinguish a device that was merely inserted and registered from one that actually functioned and installed drivers, a distinction the registry alone cannot provide.

FAT32: 4 GB

Why it fails: This answer confuses the maximum file size with the maximum volume size. FAT32's 32-bit file-size field caps each individual file at 4,294,967,295 bytes (4 GB), but the filesystem itself can span up to 2 TB when formatted with 512-byte sectors, so 4 GB is not the volume limit.

exFAT: 2 TB

Why it fails: exFAT was introduced specifically to overcome FAT32's 2 TB volume limit by using 64-bit sector addressing, allowing volumes up to 128 PB in practice. A 2 TB volume is well within exFAT's capacity, so saying that is exFAT's maximum is incorrect; 2 TB is instead the FAT32 volume ceiling.

Windows Event Log: Records DNS queries and responses

Why it fails: This pairing is incorrect because full DNS query/response records are captured by dedicated DNS logging, such as DNS Server debug logs, DNS analytical channels, or packet captures—not by the standard Windows Event Log. While certain DNS server operational errors or auditing events may surface in the Event Log, that is not equivalent to logging every query and response as the log type’s typical content.

Syslog: Records login attempts and authentication events

Why it fails: This pairing confuses a transport standard with an event category: syslog can relay authentication messages, but it has no built-in binding to login attempts. On Unix-like systems, successful and failed logins from PAM, sudo, or SSH are typically written to dedicated authentication logs such as auth.log or /var/log/secure, and syslog is merely one possible route for shipping those messages to a central collector.

Immediately disconnect the system from the network to contain the threat.

Why it fails: Immediately disconnecting the system from the network before imaging changes its volatile state: active TCP/UDP connections, open ports, cached credentials, and recent DNS queries may be terminated or altered, destroying transient evidence of command-and-control communication. Malware can also react to network loss by deleting in-memory artifacts or switching to alternate persistence mechanisms. Proper containment should occur after memory has been captured, or through methods that preserve connection metadata such as span ports or firewall rules.

Check the Windows Event Logs for related entries.

Why it fails: Windows Event Logs are stored on disk and can be acquired later without the same urgency as RAM, so checking them first delays the critical preservation of volatile data. Viewing logs also does not reveal the current in-memory state, such as a process's parent PID, loaded API hooks, or injected payload, and it may miss activity that has not yet been logged. Launching Event Viewer can itself generate additional events and alter the system, whereas memory capture should be the initial, least-invasive step.

Reboot the system to clear any malicious processes from memory.

Why it fails: Rebooting the system is the antithesis of volatile data preservation, as it flushes RAM and destroys the very artifacts—malicious processes, active network connections, and encryption keys—that triggered the alert. Some malware families detect a shutdown event and trigger destructive routines or hide persistent boot components, further complicating the investigation. A forensic responder must avoid any action that degrades volatile evidence, including power cycling, until a complete memory image has been secured.

Capture disk image, then memory, then network connections.

Why it fails: This order violates the order of volatility by starting with disk, which is persistent, before capturing memory and active network connections. Memory holds live attacker artifacts—such as decrypted data, process memory, and injected code—that vanish immediately on power loss, while network sessions can terminate before a disk image completes. Additionally, running an acquisition tool on the live system while prioritizing disk can alter volatile evidence. Therefore, disk imaging must come after memory and network state are secured.

Record network connections, capture disk image, then memory.

Why it fails: This order incorrectly captures network connections before memory, but more critically it saves memory for last. Memory is the most volatile category and must be acquired first; active TCP/UDP connections are also volatile, but they can be re-identified from memory and later from packet captures, whereas the contents of RAM cannot be recovered after a reboot. Placing disk imaging before memory means the RAM image, which could contain the attacker's active tooling, encryption keys, or staged exfiltration data, is lost. The correct sequence is memory, then network state, then disk, not the reverse.

Collect backups first, then disk image, then memory.

Why it fails: This order is wrong on two counts: backups are the least volatile evidence and should be collected last, and memory is the most volatile and must be captured first. Collecting backups first adds significant time and I/O overhead, during which RAM and active sessions may be lost, and any pre-existing backups are unaffected by the incident timeline—so they pose no preservation urgency. Moreover, performing a disk image before memory means that the most volatile evidence is gone, making this sequence ineffective for capturing an ongoing breach.

Use dd if=/dev/sda of=/mnt/evidence/image.dd conv=noerror,sync

Why it fails: This command uses conv=noerror,sync, which instructs dd to continue after read errors and replace the unreadable sectors with null bytes. That padding alters the bit-for-bit integrity of the forensic image and masks physical or media damage, so the output hash will never match the original disk. Standard forensic acquisition avoids these flags specifically so any read error aborts the process and is documented, rather than being silently filled with zeros.

Use dd if=/dev/mapper/root of=/mnt/evidence/image.dd

Why it fails: /dev/mapper/root is a device-mapper logical volume node exposed by LVM, not the raw physical disk. Copying it only captures that one logical volume and omits other logical volumes, volume group metadata, physical volume headers, and any unallocated space outside the LV. For a forensic image, you must acquire the whole physical device, because valuable evidence can reside in areas not represented by a single mapper device.

Use dd if=/dev/sda1 of=/mnt/evidence/image.dd

Why it fails: /dev/sda1 is a single partition, so this command would omit the master boot record, the partition table, and all other partitions on the disk. A partition-level image may be appropriate only if the scope is strictly that filesystem, but an incident response investigation demands a complete physical-disk image to recover deleted data and artifacts from unallocated space. The target must be the entire disk /dev/sda, not merely one of its partitions.

Collect the Windows Event Logs.

Why it fails: Windows Event Logs are stored as .evtx files on disk and contain records of logons, process creation, service installs, and other security-related activities, making them valuable for timeline reconstruction. However, they are non-volatile and persist across reboots, so they can be collected later without losing evidence. Moreover, merely opening or querying the live Event Log can generate new events and potentially modify metadata, so you should defer log collection until after a RAM image has been securely captured.

Export the contents of the Windows Registry.

Why it fails: Exporting the Registry captures persistent configuration data but does not capture volatile artefacts such as running processes, network connections, or memory-resident malware. In a live incident, the correct first step is to acquire RAM, which holds the current execution state. This option is tempting because Registry hives often contain persistence mechanisms like Run keys, making it a valid choice after memory acquisition.

Create a forensic image of the hard drive.

Why it fails: Creating a forensic image of the hard drive preserves persistent artifacts such as executables, registry hives, browser history, and deleted files, but it does not capture live system state. Volatile data like running processes, established TCP connections, memory-resident malware, and encryption keys exist only in RAM and vanish once the system is powered down or overwritten by further activity. Since disk data is non-volatile and can be imaged later with a write-blocker, the incident responder must prioritize the memory dump over disk imaging in a live malware investigation.

Compute a hash of the hard drive using a live CD.

Why it fails: Booting a forensic live CD alters the system state: it reads/writes to the disk (e.g., swap, temporary files, and access times) and leaves traces that undermine evidentiary integrity. Hashing an active disk also yields a non-consistent snapshot, whereas proper acquisition requires a hardware write-blocker and a bit-for-bit image captured in a controlled environment.

Check the power cord and peripherals for tampering.

Why it fails: Inspecting the power cord and peripherals for tampering is a valid physical triage step, but doing so before seizing the system risks losing volatile data if cables are disconnected and delays the priority of preserving the device under chain of custody. Physical tampering evidence should be documented and packaged, yet the mission-critical action is to secure and transport the computer for controlled forensic analysis.

Turn on the computer to see if it boots normally.

Why it fails: Powering on the suspect computer triggers writes to the pagefile, registry, and file system metadata (such as last access times), and may also trigger encryption or decryption operations. Additionally, without first capturing RAM, you destroy volatile evidence that exists only in memory. A forensic first responder must never boot the suspect system; the correct action is to preserve its state exactly as found.

Windows registry hives.

Why it fails: Registry is stored on disk and is less volatile.

Forensic image of the hard drive.

Why it fails: Disk is non-volatile and can be collected later.

Create a full disk image before taking any other action.

Why it fails: Imaging is an essential forensic step, but performing it first while the host remains connected to the network risks continued command-and-control traffic and further data exfiltration during the lengthy acquisition. This also violates the order of volatility because network connections, memory-resident data, and running processes are lost before the disk is copied. A first responder must first physically isolate the system, then preserve volatile data, and only then create a full forensic image.

Immediately shut down the system to prevent further data exfiltration.

Why it fails: An immediate shutdown destroys the very volatile data that often contains the best evidence of compromise: RAM holds malware payloads, decryption keys, open network sockets, and command-line history, all lost on power-off. A graceful shutdown is even worse because the OS and malware can execute cleanup routines that delete event logs, alter registry keys, or wipe artifacts during shutdown. This does not contain exfiltration; it destroys key evidence and may leave an encrypted disk inaccessible without the memory-resident key.

Run a full antivirus scan to remove the malware.

Why it fails: Running an antivirus scan at this point contaminates the evidentiary value of the system: it updates last-access timestamps across the filesystem, quarantines or deletes malware binaries, and can modify registry or restore-point data before any preservation has occurred. Modern malware often lives only in memory or uses kernel-level protection, so a live AV scan may miss it entirely while simultaneously signaling the attacker that they have been discovered. The proper sequence is to preserve volatile memory and disk evidence first, leaving malicious code intact for forensic analysis.

192.168.1.100:1047 to 10.0.0.1:22 (ESTABLISHED)

Why it fails: This connection to 10.0.0.1 on port 22 (SSH) is a legitimate administrative session to an internal server, not a C2 channel. The destination is a private RFC 1918 address, indicating the traffic stays within the trusted network, and SSH's strong encryption is appropriate for secure remote management. While SSH can be abused for tunneling, there is no evidence of that here—the source port is a normal ephemeral port, and the established state reflects a routine, authorized control session that aligns with standard operational behavior.

192.168.1.100:1046 to 192.168.1.1:443 (ESTABLISHED)

Why it fails: HTTPS to 192.168.1.1:443 is likely the internal gateway's management web interface or a captive portal, making this connection benign. The destination is the local router (default gateway) on a private IP, so the traffic never leaves the trusted segment, and the use of TLS provides confidentiality without indicating malicious intent. An established HTTPS connection to a known internal device is expected in a typical network and lacks the external destination and suspicious port pairing that would flag it as command-and-control.

192.168.1.100:1048 to 198.51.100.7:80 (TIME_WAIT)

Why it fails: This entry shows an HTTP request to 198.51.100.7 on port 80, but the TIME_WAIT state reveals that the connection is already completing its teardown, meaning no active data exchange is occurring. Short-lived HTTP connections like this are normal for web browsing or API calls, and TIME_WAIT simply indicates the client is waiting for a final ACK to ensure the connection closed cleanly. Command-and-control typically requires persistent, established sessions, so a connection in TIME_WAIT—especially to a documentation-range IP on a common web port—does not align with active attacker communication.