Scenario practice questions

An enterprise incident response team is preparing to contain a confirmed ransomware outbreak that has already encrypted several file servers. The team must preserve forensic evidence while stopping further spread. Which two actions best balance evidence preservation with containment in this scenario? (Choose two.)

Trap 1: Reimage all affected servers immediately to restore business…

Reimaging destroys all forensic evidence on the affected systems, including file system artifacts, logs, and malware remnants. It may restore operations quickly, but it eliminates the ability to determine root cause, scope, and whether the adversary retains persistence elsewhere. This action is premature before evidence is collected and analyzed.

Trap 2: Immediately power off all affected servers to halt encryption…

Powering off servers destroys volatile memory contents such as running processes, network connections, and encryption keys that may be critical for forensics and decryption. It also may leave file system transactions in an inconsistent state. While it stops encryption, it sacrifices volatile evidence and complicates recovery, so it is not a balanced choice.

Trap 3: Delete all encrypted files to prevent the ransomware from spreading…

Deleting encrypted files does not stop ransomware propagation and destroys potential evidence and recovery options. Encrypted files may be needed for ransom negotiation, decryption tool validation, or forensic analysis of the encryption routine. This action is destructive and counterproductive to both containment and investigation.

A
Reimage all affected servers immediately to restore business operations
Why it fails: Reimaging destroys all forensic evidence on the affected systems, including file system artifacts, logs, and malware remnants. It may restore operations quickly, but it eliminates the ability to determine root cause, scope, and whether the adversary retains persistence elsewhere. This action is premature before evidence is collected and analyzed.
B
Isolate affected servers from the network at the switch or EDR level while keeping them powered on
Network isolation via switch ACLs or EDR containment stops lateral spread and command-and-control communication while preserving volatile memory, running processes, and active sessions for forensic capture. It maintains system state for memory acquisition and allows the team to collect live evidence before any shutdown, satisfying both containment and preservation goals.
C
Immediately power off all affected servers to halt encryption activity
Why it fails: Powering off servers destroys volatile memory contents such as running processes, network connections, and encryption keys that may be critical for forensics and decryption. It also may leave file system transactions in an inconsistent state. While it stops encryption, it sacrifices volatile evidence and complicates recovery, so it is not a balanced choice.
D
Capture a memory image of each affected server before any containment action
Acquiring volatile memory first preserves running processes, encryption keys, and network artifacts that would be lost on shutdown or reboot. In a ransomware incident, memory may contain the encryption key or the malware's configuration. Capturing memory before containment ensures the most fragile evidence is secured while the system is still in its compromised state.
E
Delete all encrypted files to prevent the ransomware from spreading further
Why it fails: Deleting encrypted files does not stop ransomware propagation and destroys potential evidence and recovery options. Encrypted files may be needed for ransom negotiation, decryption tool validation, or forensic analysis of the encryption routine. This action is destructive and counterproductive to both containment and investigation.

Question 2easymultiple choice

A forensic analyst is reviewing a compromised Windows 10 host and finds a file named 'lsass.exe' in the C:\Windows\Temp directory. The file has a creation timestamp that coincides with the suspected intrusion time. The analyst wants to determine if this file is a malicious copy of the legitimate Windows process. Which characteristic of the legitimate lsass.exe should the analyst verify first to confirm the file is suspicious?

Trap 1: The file's hash against a threat intelligence database like…

Submitting the hash to a threat intelligence service is useful, but it requires internet access and may not have a record if the file is a custom or newly compiled tool. It is not the first characteristic to verify locally because it depends on external data and may not provide an immediate answer. The digital signature and location can be checked offline and are more definitive for masquerading system files.

Trap 2: The file's access control list (ACL) to see if permissions were…

Modifying the ACL of a copied lsass.exe is not a typical attacker technique for masquerading; the primary indicator is the unusual location and invalid signature. Checking ACLs might reveal tampering but does not directly confirm whether the file is the legitimate Windows binary. It is a secondary check after establishing that the location and signature are anomalous.

Trap 3: The file's size and version information compared to the known-good…

While size and version can differ, attackers often pad or modify binaries to match expected metadata, and version information can be forged. Checking size and version alone may not reveal tampering if the attacker copied the legitimate file and then modified it slightly. More reliable is verifying the digital signature and location, which are harder to fake without invalidating the signature.

A
The file's digital signature and its original location in C:\Windows\System32
The legitimate lsass.exe resides in C:\Windows\System32 and is digitally signed by Microsoft. A copy in C:\Windows\Temp is highly suspicious because system processes do not normally run from temporary directories. Verifying the digital signature and original location quickly confirms whether the file is the genuine Windows component or a masquerading malicious binary, making this the most direct first check.
B
The file's hash against a threat intelligence database like VirusTotal
Why it fails: Submitting the hash to a threat intelligence service is useful, but it requires internet access and may not have a record if the file is a custom or newly compiled tool. It is not the first characteristic to verify locally because it depends on external data and may not provide an immediate answer. The digital signature and location can be checked offline and are more definitive for masquerading system files.
C
The file's access control list (ACL) to see if permissions were modified
Why it fails: Modifying the ACL of a copied lsass.exe is not a typical attacker technique for masquerading; the primary indicator is the unusual location and invalid signature. Checking ACLs might reveal tampering but does not directly confirm whether the file is the legitimate Windows binary. It is a secondary check after establishing that the location and signature are anomalous.
D
The file's size and version information compared to the known-good lsass.exe
Why it fails: While size and version can differ, attackers often pad or modify binaries to match expected metadata, and version information can be forged. Checking size and version alone may not reveal tampering if the attacker copied the legitimate file and then modified it slightly. More reliable is verifying the digital signature and location, which are harder to fake without invalidating the signature.

Question 3mediummultiple choice

During an enterprise incident response, you are examining evidence on a Windows Server 2019 system that may contain a fileless malware infection. You need to determine whether a specific process was injected with malicious code. Which Windows forensic artifact is most directly useful for identifying anomalous memory regions in a process, such as those created by reflective DLL injection?

Trap 1: MFT (Master File Table) entries

The MFT contains metadata about files on an NTFS volume, such as timestamps and sizes. It does not track process memory or code injection. While MFT analysis can show file creation or deletion, it cannot identify anomalous memory regions within a running process. Therefore, it is not the right artifact for detecting injected code.

Trap 2: Prefetch files

Prefetch files record the execution of applications, including the files and directories accessed during startup. They can show that a process ran, but they do not provide details about memory regions or injected code. Prefetch is stored on disk and would not reveal the in-memory modifications typical of reflective DLL injection, making it unsuitable for this specific analysis.

Trap 3: Windows Event Log Security log

The Security log records events like logon attempts, privilege use, and object access. It does not contain memory layout details or code injection evidence. While it can show process creation if auditing is enabled, it cannot reveal the internal memory state of a process. Thus, it is not useful for identifying injected memory regions.

A
MFT (Master File Table) entries
Why it fails: The MFT contains metadata about files on an NTFS volume, such as timestamps and sizes. It does not track process memory or code injection. While MFT analysis can show file creation or deletion, it cannot identify anomalous memory regions within a running process. Therefore, it is not the right artifact for detecting injected code.
B
Memory dump of the process
A memory dump captures the full contents of a process's virtual address space, including loaded modules, heaps, stacks, and any injected code. By analyzing the dump with tools like Volatility or WinDbg, you can identify memory regions that are not backed by a file on disk (e.g., PAGE_EXECUTE_READWRITE) and detect reflective DLL injection. This directly addresses the need to find anomalous memory regions.
C
Prefetch files
Why it fails: Prefetch files record the execution of applications, including the files and directories accessed during startup. They can show that a process ran, but they do not provide details about memory regions or injected code. Prefetch is stored on disk and would not reveal the in-memory modifications typical of reflective DLL injection, making it unsuitable for this specific analysis.
D
Windows Event Log Security log
Why it fails: The Security log records events like logon attempts, privilege use, and object access. It does not contain memory layout details or code injection evidence. While it can show process creation if auditing is enabled, it cannot reveal the internal memory state of a process. Thus, it is not useful for identifying injected memory regions.

Question 4easymultiple choice

An analyst is examining an NTFS volume and finds a file named 'confidential.docx' in a directory. The file's MFT record shows that the $DATA attribute is resident. What does this indicate about the file's data storage, and what is the primary forensic implication?

Trap 1: The file's content is encrypted with EFS, and the resident $DATA…

EFS-encrypted files use the $EFS attribute to store encryption metadata, and the file content itself is typically non-resident and encrypted. A resident $DATA attribute contains the actual file content, not encryption keys. EFS does not store keys in a resident $DATA attribute; it uses a separate $EFS attribute and user key material.

Trap 2: The file's content is stored in clusters outside the MFT, and the…

A non-resident $DATA attribute indicates content stored in clusters outside the MFT, with data runs pointing to those clusters. A resident $DATA attribute means the opposite: the content is small enough to be stored within the MFT record itself. Therefore, this option describes the non-resident case, not the resident case observed here.

Trap 3: The file's content is compressed and stored in the MFT record,…

Compressed files on NTFS use non-resident $DATA attributes with sparse runs and compression flags. Resident $DATA attributes are used for small, uncompressed data that fits in the MFT record. The presence of a resident $DATA attribute does not imply compression; it simply indicates small file size. Decompression is not required for resident data.

A
The file's content is encrypted with EFS, and the resident $DATA attribute stores the encryption keys.
Why it fails: EFS-encrypted files use the $EFS attribute to store encryption metadata, and the file content itself is typically non-resident and encrypted. A resident $DATA attribute contains the actual file content, not encryption keys. EFS does not store keys in a resident $DATA attribute; it uses a separate $EFS attribute and user key material.
B
The file's content is stored entirely within the MFT record, and the analyst can recover it directly from the MFT without carving the disk.
A resident $DATA attribute means the file's content is small enough to fit within the MFT record, typically under approximately 700 bytes. The data is stored directly in the MFT entry, so the analyst can extract it by parsing the MFT record. This is a straightforward recovery because no cluster allocation or disk carving is required.
C
The file's content is stored in clusters outside the MFT, and the analyst must use the data runs to locate it on disk.
Why it fails: A non-resident $DATA attribute indicates content stored in clusters outside the MFT, with data runs pointing to those clusters. A resident $DATA attribute means the opposite: the content is small enough to be stored within the MFT record itself. Therefore, this option describes the non-resident case, not the resident case observed here.
D
The file's content is compressed and stored in the MFT record, requiring decompression before analysis.
Why it fails: Compressed files on NTFS use non-resident $DATA attributes with sparse runs and compression flags. Resident $DATA attributes are used for small, uncompressed data that fits in the MFT record. The presence of a resident $DATA attribute does not imply compression; it simply indicates small file size. Decompression is not required for resident data.

Question 5mediummultiple choice

An investigator notices that a file's 'Birth' time is later than its 'Modification' time. What is the most likely forensic explanation for this phenomenon?

Trap 1: The file system is corrupted

File system corruption usually manifests as invalid MFT entries or cross-linked clusters, not as a logically inconsistent relationship between creation and modification timestamps. While corruption can occur, it is an unlikely explanation for a predictable pattern like birth times being newer than modification times in a functioning system.

Trap 2: The system clock was updated via NTP

NTP updates shift the system time globally. If an NTP update occurred, it would potentially impact all timestamps during that window, but it would not selectively reverse the order of birth and modification times for a specific file. This logic is inherent to the file copy process, not clock synchronization.

Trap 3: The file is a system-level shadow copy

Shadow copies are snapshots of the file system state. They do not alter the relationship between birth and modification timestamps within the files they contain. The timestamps in a shadow copy reflect the state of the original file at the time the snapshot was taken, maintaining the original metadata.

A
The file system is corrupted
Why it fails: File system corruption usually manifests as invalid MFT entries or cross-linked clusters, not as a logically inconsistent relationship between creation and modification timestamps. While corruption can occur, it is an unlikely explanation for a predictable pattern like birth times being newer than modification times in a functioning system.
B
The file was copied from an external source
When copying a file, the OS creates a new entry on the destination volume, setting a new birth time. However, many copy utilities and APIs preserve the original modification timestamp from the source file. This results in the metadata anomaly where the file appears to be 'modified' before it was 'born'.
C
The system clock was updated via NTP
Why it fails: NTP updates shift the system time globally. If an NTP update occurred, it would potentially impact all timestamps during that window, but it would not selectively reverse the order of birth and modification times for a specific file. This logic is inherent to the file copy process, not clock synchronization.
D
The file is a system-level shadow copy
Why it fails: Shadow copies are snapshots of the file system state. They do not alter the relationship between birth and modification timestamps within the files they contain. The timestamps in a shadow copy reflect the state of the original file at the time the snapshot was taken, maintaining the original metadata.

Question 6mediummultiple choice

An analyst is reviewing a Windows 10 memory image captured from a workstation suspected of malware infection. While examining a process, the analyst notices that the process's page directory base (DTB) points to a valid address, but the process's image path on disk cannot be found. Which Volatility 3 plugin should the analyst use to determine if the process memory contains injected code?

Trap 1: windows.netscan

windows.netscan enumerates network connections and listening sockets, which is useful for identifying network activity but not for detecting injected code in process memory. It would not reveal memory anomalies like unbacked executable pages. Thus, it is not the appropriate plugin for this scenario.

Trap 2: windows.pslist

windows.pslist lists active processes by walking the active process list, but it does not analyze memory regions for injected code. It would only show the process exists but not whether it contains injected code. Therefore, it does not address the analyst's need to detect injected code in process memory.

Trap 3: windows.cmdline

windows.cmdline displays command-line arguments for processes, which can provide context but does not analyze memory for injected code. It would not detect suspicious memory regions or unbacked executable pages. Consequently, it is not the right tool for identifying injected code in this case.

A
windows.netscan
Why it fails: windows.netscan enumerates network connections and listening sockets, which is useful for identifying network activity but not for detecting injected code in process memory. It would not reveal memory anomalies like unbacked executable pages. Thus, it is not the appropriate plugin for this scenario.
B
windows.malfind
windows.malfind scans for memory regions with suspicious characteristics, such as executable permissions and no corresponding file on disk, which are typical of code injection. It helps identify injected code even when the process image is missing. This plugin is specifically designed to detect hidden or injected code in process memory, making it the correct choice for this scenario.
C
windows.pslist
Why it fails: windows.pslist lists active processes by walking the active process list, but it does not analyze memory regions for injected code. It would only show the process exists but not whether it contains injected code. Therefore, it does not address the analyst's need to detect injected code in process memory.
D
windows.cmdline
Why it fails: windows.cmdline displays command-line arguments for processes, which can provide context but does not analyze memory for injected code. It would not detect suspicious memory regions or unbacked executable pages. Consequently, it is not the right tool for identifying injected code in this case.