Incident Response and First Responder Skills practice questions

Capture disk image, then memory, then network connections.

Why wrong: 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 wrong: 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 wrong: 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 a write blocker when acquiring the disk image.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

192.168.1.100:1047 to 10.0.0.1:22 (ESTABLISHED)

Why wrong: 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 wrong: 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 wrong: 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.

Run a full disk imaging tool to capture the hard drive contents.

Why wrong: Full disk imaging captures only non-volatile storage, so it misses the dynamic evidence in RAM that is essential for identifying the attack vector, such as active processes, injected DLLs, or inter-process communication. A disk image takes considerable time to complete, during which the live system continues executing and memory changes, and the imaging tool itself may overwrite free disk sectors or cause the OS to swap memory to disk, further contaminating the evidence. Correct protocol is to snapshot memory first, then image the disk.

Disconnect the network cable to isolate the system from the network.

Why wrong: Disconnecting the network cable is a containment response to stop further exfiltration or propagation, but it does nothing to preserve volatile evidence; in fact, the act of running a 'disconnect' command or even physically pulling the cable can trigger application or OS events that modify memory, such as generating network timeout errors or updating connection tables. Because the system remains powered on, processes continue to allocate memory and change the evidence, so network isolation should be deferred until after memory capture.

Immediately shut down the system by pulling the power cord.

Why wrong: Immediately pulling the power cord drops voltage to RAM, and without a fresh power source all dynamic contents are lost within milliseconds—cryptographic keys, process tokens, and malware artifacts are irretrievably gone. It also leaves the file system in an unclean state (potentially corrupting journal or NTFS metadata) and may cause swap files to be stale, while the disk itself remains unchanged but the live evidence is gone. For forensic integrity, a proper memory dump before shutdown is the only acceptable method.

Run antivirus scans to identify and remove any malware present.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: /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 wrong: /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.

Begin capturing a memory dump using a forensic tool.

Why wrong: Documentation should precede active collection.

Power off the computer immediately to preserve the disk.

Why wrong: Powering off destroys volatile evidence in memory.

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

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

Collect the Windows Event Logs.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Registry is stored on disk and is less volatile.

Forensic image of the hard drive.

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