Introduction to Memory Forensics practice questions

It is faster to acquire than a live capture

Why it fails: Offline acquisition requires shutting down or suspending the system, which takes significantly more time than running a live acquisition tool. Speed is not the primary advantage; the stability and lack of system interaction during the capture process are the main benefits for maintaining the integrity of the evidence.

It requires less storage space on the examiner's device

Why it fails: Memory size is determined by the amount of physical RAM installed in the target system. Whether captured live or offline, the size of the resulting memory image remains identical. Storage requirements do not change based on the methodology of acquisition; the image size is fixed by hardware capacity.

It allows the examiner to edit the memory content

Why it fails: Forensic integrity requires that evidence remain immutable. Editing memory content during the forensic process would destroy the chain of custody and make the evidence inadmissible. The goal of memory forensics is analysis and extraction, not modification or editing of the acquired system memory data.

Reviewing the Event Viewer logs for socket errors

Why it fails: Event Viewer logs are stored on disk and are easily manipulated or cleared by sophisticated malware. Relying on these logs for forensic evidence is risky because the attacker may have modified the logs to hide their activities, making them a less reliable source than raw memory structures.

Scanning the hard drive for browser history files

Why it fails: Browser history files are disk-based and only reflect web browsing activity. They do not provide visibility into raw network sockets, beaconing behavior, or established connections by non-browser processes, making them useless for detecting covert command-and-control traffic or unauthorized network activity.

Checking the system time for synchronization

Why it fails: System time is a general configuration setting. While important for timeline correlation, it does not assist in detecting network connections. Network socket forensics requires inspecting the memory objects created by the networking stack, which is completely independent of the system clock's current time.

The process is currently active.

Why it fails: An ExitTime value indicates that the kernel has recorded a termination event for the process. If a process was currently executing, it would typically have a zero or NULL ExitTime value. Seeing a timestamp suggests the process has already undergone the termination sequence and is no longer actively running.

The memory for the process has been freed.

Why it fails: Having an ExitTime does not automatically mean the memory has been reclaimed by the kernel. The EPROCESS object may persist in memory even after the process has exited, which is why analysts can still view its metadata. The memory pages may still contain evidence, even if the process status is terminated.

The process was launched at that time.

Why it fails: The ExitTime field records the time of termination, not the time of creation. The creation time is stored in a separate field called CreateTime. Confusing these two fields would lead to a significant misunderstanding of the process lifecycle, potentially causing the investigator to overlook the actual duration of the malicious activity.

windows.procdump

Why it fails: windows.procdump dumps the entire process executable from memory, not specific suspicious memory regions. It would not isolate the injected code regions identified by malfind. Using it would capture the entire process image, which may be large and not focused on the injected code.

windows.vadinfo --dump

Why it fails: windows.vadinfo lists virtual address descriptors (VADs) and can dump memory regions associated with a VAD, but it does not specifically target regions flagged by malfind. The analyst would need to manually identify the VAD corresponding to the suspicious region, which is less direct than using a dedicated plugin.

windows.malfind --dump

Why it fails: While windows.malfind can identify suspicious memory regions, it does not have a built-in --dump option in Volatility 3. The plugin is used for detection, not extraction. To dump the memory regions, a different plugin or manual carving is required.

windows.malfind

Why it fails: windows.malfind identifies memory regions with suspicious characteristics such as PAGE_EXECUTE_READWRITE protection and no file backing, which can indicate injected code. While process hollowing often involves injected code, malfind alone does not specifically compare the process's image path to its memory-resident executable. It is useful but not the most targeted plugin for this scenario.

windows.psscan

Why it fails: windows.psscan scans for process objects in pool memory and can find hidden or terminated processes, but like pslist it does not compare the mapped image to the executable file on disk. It would not reveal that the in-memory code differs from the legitimate svchost.exe, so it is not the best plugin for detecting process hollowing.

windows.pslist

Why it fails: windows.pslist walks the active process list and shows basic process metadata such as PID, PPID, and image name. It does not compare the on-disk executable with the in-memory image, so it cannot detect process hollowing where the memory content differs from the file on disk. It might show the suspicious PPID but not the hollowing itself.

The svchost.exe process was terminated, and its parent process exited before the memory capture, leaving an orphaned process entry.

Why it fails: If the parent process exited normally, the PPID would still reference a valid but terminated process, not a non-existent PID. In Windows, terminated processes are removed from the active process list but may remain in memory as objects. A non-existent PID suggests the parent was never valid or was manipulated, not a typical orphaned process scenario.

The memory image was captured while the system was in a hibernated state, causing inconsistencies in the process list.

Why it fails: Hibernation writes memory to disk and powers off the system; a memory capture from a hibernated system would typically be a hibernation file, not a live memory image. WinPmem captures live memory, so hibernation is irrelevant. Inconsistencies from hibernation would affect all processes, not just one with a non-existent PPID.

The svchost.exe process is a legitimate child of services.exe, but the PPID was altered by a rootkit using DKOM to hide the parent-child relationship.

Why it fails: While DKOM can alter PPID, the scenario states the PPID points to a non-existent PID, which is not typical for DKOM hiding. DKOM often unlinks processes entirely. A non-existent PID more likely indicates a process that was created with a falsified parent, such as by malware using PPID spoofing, rather than a simple DKOM alteration.

windows.procdump

Why it fails: windows.procdump dumps the entire process executable from memory, which can be useful but does not specifically target the injected regions. It would capture the whole process, not isolate the injected code. Thus, it is less efficient for extracting specific suspicious memory segments.

windows.dumpfiles

Why it fails: windows.dumpfiles extracts memory-mapped files from a process's address space, but it targets regions backed by files on disk. It does not extract unbacked executable regions identified by malfind. Therefore, it is not suitable for extracting injected code from suspicious memory regions.

windows.malfind

Why it fails: windows.malfind identifies suspicious memory regions but does not extract them. It only reports the regions and their properties. To extract the code, a different plugin or manual dumping is required. Hence, running malfind again would not provide the extracted code.

windows.cmdline

Why it fails: windows.cmdline extracts the command line arguments for processes from the PEB, which helps identify how a process was launched but has no visibility into socket state. Running it here would not produce any network endpoint information, so it cannot satisfy the requirement of enumerating active connections from the memory image.

windows.netstat

Why it fails: windows.netstat relies on walking the active process list and correlating each process with its network handles, so connections belonging to terminated processes are missed. In this scenario, the goal is to enumerate connections present at capture time regardless of whether the process still exists, making this plugin less suitable than one that scans kernel connection pools directly.

windows.dlllist

Why it fails: windows.dlllist enumerates loaded modules mapped into each process address space and their base addresses. While useful for detecting unexpected DLLs, it does not parse TCP/IP structures or report remote addresses and ports. It therefore provides no data about network connections that existed at the time of capture.

The process's PEB ImagePathName and the file's $STANDARD_INFORMATION timestamps

Why it fails: The PEB ImagePathName gives the path the process was launched from, but comparing it to $STANDARD_INFORMATION timestamps only reveals file time metadata, not whether the binary content matches a legitimate system file. Timestamps can be trivially modified and do not establish authenticity, so this comparison does not resolve the masquerading question.

The process's VAD tree entries and the file's alternate data streams

Why it fails: VAD entries describe virtual memory ranges mapped into the process and alternate data streams are NTFS metadata, neither of which confirms the identity of the executable on disk. A masquerading binary can have a normal VAD layout and no alternate streams, so these artifacts do not distinguish the legitimate service host from an impostor.

The process's handle table and the file's last access time

Why it fails: The handle table shows kernel objects the process has open, and last access time is a filesystem timestamp that is often disabled or unreliable. Neither artifact verifies that the binary at the recorded path is the legitimate signed service host, so this pairing does not answer the masquerading question.

The memory acquisition tool utilized an unprivileged user-mode API that restricted kernel visibility.

Why it fails: User-mode acquisition tools inherently struggle with full physical memory access, but kernel-level drivers bypass this limitation entirely by executing at ring 0. The missing processes stem from malicious structural manipulation rather than acquisition privilege boundaries.

The operating system automatically paged the missing process control blocks out to the swap file during memory dumping.

Why it fails: Physical memory acquisition captures the entire RAM contents, and active system processes are pinned in physical memory pages rather than being paged out to disk. Paging limitations do not account for systematic structural disappearance during forensic capture.

Volatility 3 requires an outdated symbol table to correctly resolve the exact offsets of the Windows 10 kernel structures.

Why it fails: Volatility 3 ships current symbol tables, and missing processes stem from the acquisition tool unlinking entries from the ActiveProcessLinks list, not from offset resolution failures. It is tempting because symbol mismatches do cause analysis errors, and supplying a matching symbol table would be correct when profiling an unfamiliar or patched kernel build.

The Master File Table (MFT) entry

Why it fails: The MFT entry resides on the physical disk and tracks file metadata like timestamps and allocation status. While an examiner might compare memory paths to disk paths, the MFT itself is not the structure manipulated to cause a PEB-to-VAD discrepancy within the memory-resident process structures.

The Thread Environment Block (TEB)

Why it fails: The TEB stores thread-specific information such as the thread local storage and stack pointers. While relevant for analyzing execution flow and synchronization, it does not store the primary executable path for the process, making it an unlikely target for path-based masquerading attacks in memory.

The System Service Descriptor Table (SSDT)

Why it fails: The SSDT is used by the kernel to dispatch system calls. While rootkits may hook the SSDT to hide files or network connections, modifying this table does not cause the specific discrepancy between the PEB path and VAD tree entries observed for a single malicious process.

The PID 1240 is assigned to svchost.exe

Why it fails: Svchost.exe is a standard Windows service host process that typically runs multiple instances. Having multiple instances under different PIDs is expected behavior. The PID value itself is dynamic and does not inherently suggest malicious intent without context regarding its parent or child processes.

The existence of two svchost.exe processes

Why it fails: Windows architecture is designed to host multiple services within separate svchost.exe instances to increase stability and security. Seeing multiple instances of this process is standard behavior and does not represent an indicator of compromise unless the specific services hosted are unidentified or malicious.

The PID of explorer.exe is higher than svchost.exe

Why it fails: Process IDs are assigned by the operating system kernel using a counter. Higher PIDs generally indicate processes that were started later than those with lower PIDs. Since explorer.exe typically starts after system services during the boot sequence, this behavior is perfectly normal and expected for Windows.

The bit-depth of the monitor attached to the server

Why it fails: Monitor settings such as bit-depth or resolution have no impact on the acquisition of physical RAM. Memory forensics focuses on the contents of the system's volatile memory and kernel structures, which are independent of the display configuration or the hardware connected to the machine's external ports.

The total capacity of the hard drive

Why it fails: Hard drive capacity is irrelevant to the acquisition of physical RAM. While storage for the resulting image file must be adequate, the physical disk size itself does not affect the process of dumping volatile memory to an output file or the success of the acquisition tool.

The current time zone of the server

Why it fails: While time zone information is important for correlating logs and timeline analysis, it does not impact the mechanics of memory acquisition. The acquisition process is a technical operation that functions regardless of how the system clock is configured or represented by the local operating system.

The Master File Table (MFT)

Why it fails: The MFT is a disk-based structure used to manage file system metadata. It does not contain information about the current execution state or command-line parameters of running processes. While it can show the file's existence, it cannot explain how that file was executed during the current session.

The Registry Hive files

Why it fails: Registry hives represent persistent configuration data stored on disk. While they may contain historical information about run keys or installed software, they do not track the dynamic command-line arguments passed to an active, running process in volatile memory during the current session of the operating system.

The System Service Descriptor Table (SSDT)

Why it fails: The SSDT is a kernel-mode table used to map system calls to their corresponding functions in memory. It is primarily used for intercepting kernel activity and does not store the user-level command-line strings that were used to launch a specific application process in the system's memory.

To ensure the memory image is encrypted correctly

Why it fails: Memory forensics tools do not typically handle memory encryption during the analysis phase. Encryption is generally handled by the acquisition tool or the platform's hardware features. The profile is used for structure parsing, not for decryption or authentication of the memory image file itself during the analysis.

To increase the speed of the memory dumping process

Why it fails: The memory profile is utilized during the post-acquisition analysis phase, not during the initial capture. It does not influence the speed at which a memory dump is created. Its primary purpose is to provide a map for interpreting raw memory bytes after the image has been acquired.

To bypass the system's kernel-mode security drivers

Why it fails: The profile is a map of memory structures, not an exploit tool. It does not bypass security drivers or provide elevated access to the target machine. Its role is solely to interpret the data contained within a memory dump that has already been acquired from the system.

The presence of standard DLLs in the loading list

Why it fails: Standard system DLLs like kernel32.dll or ntdll.dll are expected to be present in almost every process. Their existence is a sign of normal process behavior. While they can be hooked, the presence of the files themselves is not an indicator of injection or malicious activity.

The thread environment block (TEB) memory region

Why it fails: The TEB is used for thread-local storage and is not a common target for code injection because it is too small and structured for large payloads. While some advanced techniques may touch the TEB, it is generally not an primary indicator for identifying successful code injection compared to heap or stack.

The memory segment is a standard heap allocation

Why it fails: Standard heap allocations typically use PAGE_READWRITE protection. Marking a heap segment as executable is highly anomalous and risky. Therefore, labeling this as a standard heap allocation ignores the high-risk nature of the PAGE_EXECUTE_READWRITE permission, which is a strong indicator of potential malicious activity.

The memory segment is a legitimate shared library

Why it fails: Shared libraries (DLLs) are mapped to memory with specific protection flags, usually PAGE_EXECUTE_READ. Furthermore, they are always backed by a file on the file system. Since this segment has no file-backing and anomalous permissions, it cannot be a legitimate shared library loaded by the OS.

The memory segment is part of the system kernel

Why it fails: Kernel memory segments are managed differently than user-mode VAD entries and follow strictly defined permission models to ensure system stability. A user-mode process would not have a VAD entry with these characteristics as part of the operating system kernel. This is clearly a user-mode memory artifact.

The Master File Table (MFT)

Why it fails: The MFT contains file metadata and has no inherent relationship to the Windows scheduler's process list. It cannot be used to detect hidden processes because it does not maintain a record of which applications are currently active or scheduled for execution by the Windows kernel.

The user-mode Process Environment Block (PEB)

Why it fails: The PEB is managed by the user-mode process and can be easily modified or unlinked by malicious software. Relying on the PEB to verify a process list is ineffective because the rootkit can update the PEB to match the fake process list, maintaining the deception.

The System Service Descriptor Table (SSDT)

Why it fails: The SSDT handles system calls for kernel functions. While it can be hooked to redirect execution, it does not contain a list of all processes that are currently running. Using the SSDT to verify process existence is technically incorrect and would not reliably surface hidden process objects.

Analyzing the process environment block (PEB)

Why it fails: The PEB is a user-mode structure. Rootkits that hook kernel functions operate at a higher privilege level and reside in the kernel space. Analyzing the PEB will not reveal kernel-mode hooking, as the hooks exist within the operating system kernel's own internal function dispatch tables.

Enumerating all running threads

Why it fails: While thread enumeration is useful for finding hidden processes, it is not the correct technique for detecting kernel-level function hooking. Hooking involves redirecting code execution at the call site, not necessarily creating new threads, so this method would fail to identify the specific rootkit hooks.

Scanning for file system changes in the MFT

Why it fails: The MFT is a disk-based metadata structure. Kernel hooks exist in memory and do not necessarily involve changing files on the disk. Scanning the MFT will not detect active, volatile kernel-mode hooks, making this an ineffective strategy for identifying rootkits that operate solely within system memory.

It stores the process command line arguments

Why it fails: Command line arguments are stored in the Process Environment Block (PEB), which is a user-mode structure. The object header is a kernel-mode structure that manages metadata for object management, not the user-supplied input or command-line parameters associated with a specific process instance.

It is used for memory page table translations

Why it fails: Page table translations are handled by the MMU using page directory and table structures. The object header is not involved in virtual-to-physical memory translation; it is an administrative structure used by the kernel to track the lifecycle and security state of kernel objects.

It provides a mapping for disk-based sectors

Why it fails: Mapping virtual memory to disk sectors is performed by the file system driver and the memory manager's file-backed section objects. The object header is a generic structure for all kernel objects and does not handle the mapping of memory pages to specific physical sectors on disk.