Select Two (Multi-Select) Questions

Windows Security event ID 4672 indicating special privileges assigned to a new logon for a service account.

Why it fails: Event ID 4672 logs special privileges assigned to a logon, which is common for service accounts and administrative logons. It does not indicate LSASS memory access. This event is not specific to credential dumping and would produce many false positives in a domain controller environment.

Windows Security event ID 4688 with process creation for a known credential dumping tool, including its command line.

Why it fails: Event ID 4688 logs process creation and can show a credential dumping tool being executed, but it does not directly prove that LSASS memory was accessed. The tool might have failed or targeted other processes. It is an indicator of potential intent, but not direct evidence of LSASS memory access.

Windows Security event ID 4624 logon type 3 (network) from a workstation to the domain controller.

Why it fails: Event ID 4624 with logon type 3 indicates a network logon, which is normal in domain environments. It does not provide evidence of LSASS memory access. While it could be part of lateral movement, it is not direct evidence of credential dumping from LSASS.

The system's Event Log files

Why it fails: Event logs are disk-based artifacts that do not contain the fine-grained memory structure information needed to detect process injection. While logs can show related activity, they cannot confirm the actual presence of injected code or modified memory sections within a running process's address space.

The MFT file records

Why it fails: The MFT resides on the disk and contains metadata about the file system. It has no visibility into the volatile memory address space of running processes. It cannot be used to identify code injection or memory modifications happening within a process that is currently running in the system's RAM.

windows.dlllist

Why it fails: The windows.dlllist plugin lists loaded DLLs for a process. While it can show unexpected DLLs, it does not detect injected code that is not part of a DLL, such as shellcode or injected executable code. It is not the primary tool for detecting code injection.

windows.ldrmodules

Why it fails: The windows.ldrmodules plugin compares loaded modules across three lists (InLoad, InInit, InMem) to detect unlinked DLLs. While useful for finding hidden DLLs, it does not detect injected code that is not a DLL. It is not suitable for analyzing raw injected code regions.

windows.handles

Why it fails: The windows.handles plugin lists open handles for processes, such as files, registry keys, and mutexes. It does not analyze memory regions for injected code. While handles can indicate malicious activity, they are not used to detect code injection directly.

The process's token indicates it is running with elevated privileges.

Why it fails: Elevated privileges are common for many legitimate system processes and are not a specific indicator of process hollowing. While malware might seek elevation, the presence of an elevated token alone does not suggest hollowing. The technique focuses on replacing the memory of a process, not on privilege level.

The process's parent process ID (PPID) is a non-existent process.

Why it fails: A non-existent PPID can occur when a parent process terminates before the child, which is common and not necessarily malicious. It is not a specific indicator of process hollowing. Process hollowing involves modifying the memory of a legitimate process, often without changing its parent-child relationship. Therefore, a missing parent is not a reliable indicator.

The process has a large number of open handles to remote named pipes.

Why it fails: While malicious processes may use named pipes for communication, a large number of open handles to remote named pipes is not specific to process hollowing. It could indicate inter-process communication or other malicious activities, but it is not a direct indicator of hollowing. Process hollowing primarily involves memory manipulation, not handle usage.

pslist enumeration

Why it fails: The pslist command follows the ActiveProcessLinks list in the kernel. This is a common API-reliant method that malware can easily evade by unlinking the process structure. It is considered an unreliable method for finding hidden processes, as it only shows what the kernel currently acknowledges as active.

Task Manager API polling

Why it fails: Task Manager relies on the same internal Windows APIs as pslist. If a process is hidden from the kernel's active process list, Task Manager will not display it. Relying on live system APIs during a forensic investigation is dangerous and often leads to missing malicious processes hidden by rootkits.

Registry hive parsing

Why it fails: Registry parsing can reveal persistence mechanisms but does not identify running processes in memory. While useful for finding what should be running, it does not confirm the actual presence of a malicious process in memory at the time of capture, nor does it detect hidden, non-persistent, memory-resident malware.

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.

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.

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.

Application Event ID 1000 (Application Error) entries referencing a crashing service.

Why it fails: Application Error events record user-mode crashes and faulting module paths. While a crashing service could occasionally be a symptom of a poorly written implant, crash events are not correlated with periodic outbound traffic and do not demonstrate beaconing. Many benign applications crash routinely, so this artifact offers little direct value for confirming command-and-control timing or destination.

System Event ID 7045 (A service was installed in the system) recorded once during the investigation window.

Why it fails: Event ID 7045 records service installation, which is a persistence mechanism rather than a beaconing indicator. A single service-install event does not show repeated outbound communication or timing patterns. Investigators should treat 7045 as a pivot to examine the installed binary and its network behavior, but on its own it does not directly evidence periodic C2 beaconing.

Security Event ID 4624 (An account was successfully logged on) with Logon Type 3 repeated every few minutes.

Why it fails: Logon Type 3 denotes a network logon, commonly generated by SMB, IIS, or remote administration activity. Beaconing malware typically uses raw HTTP, HTTPS, or DNS rather than SMB, so it does not generate 4624 Type 3 events. Repeated network logons may indicate scanning or a service account, but they are not direct evidence of periodic C2 beaconing to an external controller.

windows.netscan

Why it fails: windows.netscan enumerates network connections and listening sockets from memory, which is useful for identifying command-and-control activity but does not inspect process memory for injected code. It would not reveal the injected region or its properties, so it does not fulfill the detection requirement in this scenario.

windows.handles

Why it fails: windows.handles lists open handles such as files, registry keys, and mutexes for each process. While useful for understanding process behavior, it does not analyze memory protections or detect unbacked executable regions, so it cannot identify or characterize the injected code described in the scenario.

windows.registry.hivelist

Why it fails: windows.registry.hivelist enumerates registry hives loaded in memory, which supports registry analysis but has no bearing on process memory protections or injected code. It cannot detect or characterize an injection, so it is not the right complement to malfind in this scenario.

Shut down the instance immediately to stop the attack.

Why it fails: Shutting down the instance wipes the volatile memory, destroying the most critical evidence of the attacker's activity. Forensically sound procedure dictates memory capture before any state-altering actions are taken. This approach ensures that all evidence is preserved for investigation, rather than being discarded during a hasty, poorly planned containment.

Delete all ephemeral logs to save on cloud storage costs.

Why it fails: Logs are vital evidence in any forensic investigation. Deleting them is a violation of basic incident response principles and destroys the timeline information needed to reconstruct the attacker's activities. Storage costs are a minor consideration compared to the legal and operational costs associated with an incomplete forensic investigation.

Active process list pointer

Why it fails: The active process list is a kernel-mode structure managed by the OS executive, not the user-mode TEB. The TEB is local to the thread, whereas the process list is a global structure used by the kernel to track all running processes on the system, which is inaccessible from user-mode structures.

Kernel-mode privilege level

Why it fails: Privilege levels are managed by the processor hardware via the Current Privilege Level (CPL) and kernel-mode security tokens. The TEB is a user-mode structure and does not contain or control the security token or privilege level, as such information would be a major security vulnerability if exposed directly to user mode.

Updating system drivers

Why it fails: Updating system drivers is a standard administrative task. While it changes file timestamps, it is not considered an 'anti-forensic' technique. It is a predictable, documented activity that is part of normal system maintenance and does not involve the malicious intent to hide evidence or deceive investigators during a timeline analysis.

Using a web browser

Why it fails: Using a web browser is a standard user activity. While it creates history files and temporary artifacts, these are the expected byproducts of normal usage. They are not anti-forensic in nature, as they provide valuable evidence rather than destroying it, and are essential for reconstructing user-level activity in an investigation.

Renaming a file

Why it fails: Renaming a file is a routine file system operation. While it might be used by an attacker to hide a malicious file in plain sight, the act of renaming does not fundamentally destroy evidence or provide a technical hurdle to forensic timeline reconstruction, unlike true anti-forensic measures like log deletion.

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.

Immediately shut down the system to prevent further malicious activity and then create a forensic image of the hard drive.

Why it fails: Shutting down the system destroys volatile evidence in memory, such as running processes and network connections. While creating a forensic image of the hard drive is important, it should not come at the expense of volatile data. The order should be: capture memory, then other volatile data, then consider shutting down for disk imaging if necessary. This option is a common mistake that leads to loss of critical evidence.

Use a write blocker when connecting the hard drive to a forensic workstation to create a bit-for-bit image.

Why it fails: Using a write blocker is a best practice for disk imaging, but it is not related to collecting volatile evidence. Volatile evidence resides in memory, network connections, and running processes, which are lost on shutdown. This option is about preserving non-volatile storage, which is important but not the focus of volatile evidence collection. It does not address the immediate need to capture data that will disappear.

Disconnect the workstation from the network before capturing any volatile data to prevent data leakage.

Why it fails: Disconnecting from the network can cause loss of volatile network connections and may alert the attacker. It also prevents remote collection tools from working. In most cases, it is better to capture volatile data while the system is still connected, unless there is active data exfiltration that must be stopped immediately. Disconnecting should be a containment decision, not a default step before volatile data collection.

nmap -sS 127.0.0.1

Why it fails: nmap is a network scanning tool used to discover hosts and services. Running it against localhost would generate new network traffic and could be considered disruptive. It does not collect existing connection information and is not a forensic collection tool for volatile data. It is inappropriate for live response evidence gathering.

lsof -i

Why it fails: lsof -i lists open files associated with network connections, which can be useful, but it is not as comprehensive as netstat or ss for showing all network connections with process details. It may miss some connections or require additional parsing. While non-disruptive, it is not the best choice for a quick snapshot of volatile network state.

tcpdump -i any -w capture.pcap

Why it fails: tcpdump captures packet data, which is useful for network forensics, but it does not provide a snapshot of current connections with process attribution. It also generates significant I/O and may require additional storage, potentially disrupting the system. For volatile connection information, netstat or ss is more appropriate.

Export the Windows Event Logs to a secure location.

Why it fails: Windows Event Logs are stored on disk and are less volatile than memory or network connections. While they should be collected, they are not the most volatile evidence. Exporting them can be done after capturing RAM and network state, as they are not immediately lost on shutdown. Focusing on logs first would delay the capture of more perishable data.

Take screenshots of the desktop and open applications.

Why it fails: Screenshots can provide context but are not a priority for volatile evidence collection. They capture visual information that may be useful for documentation, but they do not preserve critical forensic artifacts like memory-resident malware or network connections. This action should be performed after the most volatile data has been secured.

Create a forensic image of the system drive using FTK Imager or dd.

Why it fails: Creating a forensic image of the system drive is important but less volatile than memory or network state. Disk contents persist across reboots and can be acquired later without significant loss. Prioritizing disk imaging over memory and network connections would risk losing critical volatile evidence that cannot be recovered from the disk image alone.

Application event log (Event ID 1000)

Why it fails: Event ID 1000 in the Application log typically indicates an application error or crash. It is not related to user account creation or logon activity. This log would not contain evidence of the attacker's actions in this scenario.

System event log (Event ID 7045)

Why it fails: Event ID 7045 indicates a new service was installed. While attackers sometimes create services for persistence, the scenario specifies a new local user account, not a service. Therefore, the System event log is not the best source for this specific evidence.

Prefetch files

Why it fails: Prefetch files record the execution of applications to improve performance. They might show that tools like 'net.exe' were used to create a user, but they do not directly show the account creation or logon events. They are less direct than Security event logs or the SAM hive for this purpose.

Prefetch files showing that the Windows Credential Manager UI was launched by the user.

Why it fails: Prefetch records execution of a specific binary with load statistics but has no visibility into handle requests or memory reads against another process. Launching the Credential Manager UI is a normal user action that does not touch LSASS memory in the way a dumping tool does, so it does not indicate unauthorized access to the LSASS process space.

Security Event ID 4688 process creation records showing the parent image of every long-running service.

Why it fails: 4688 records process creation and parent image, which is useful for building a process tree, but it does not record handle requests or access masks against a target process. It cannot by itself show whether lsass.exe memory was read, so it is a supporting artifact at best and not a direct indicator of unauthorized LSASS access.

Amcache entries listing hashes of binaries installed under 'Program Files' on the host.

Why it fails: Amcache tracks execution and installation metadata for binaries, which helps identify tooling that ran from disk, but it does not record inter-process access or target a specific process's memory. It cannot establish that lsass.exe was opened with credential-dumping access masks, so it is not a direct artifact for this question.

The process's token has been modified to include SeDebugPrivilege.

Why it fails: SeDebugPrivilege in a token can indicate privilege escalation or debugging activity, but it is not a marker of process hollowing. Hollowing replaces image memory; it does not inherently alter the process token. This artifact is more relevant to credential or privilege investigations and does not pair with the other options to indicate hollowing.

The process has a working set larger than the system average.

Why it fails: Working set size varies widely with application behavior and is a poor discriminator for hollowing. A hollowed process may even have a smaller working set than the original. Large working sets appear in browsers, databases, and many benign programs, so this observation neither supports nor refutes process hollowing and would not pair meaningfully with another artifact.

The process has a large number of handles open to named pipes.

Why it fails: Named pipe handles are common in legitimate inter-process communication and are not specific to process hollowing. Many benign applications open numerous pipe handles. While unusual handle counts may warrant attention, they do not corroborate hollowing, and this artifact would not combine with another to strongly support that conclusion.

Processes present in windows.pslist but absent in windows.psscan indicate that the process terminated normally and its memory was freed.

Why it fails: If a process is in pslist but not psscan, it is more likely that psscan missed it due to memory corruption or that the process is in the process of terminating. However, normally terminated processes are removed from both lists. This statement is not accurate because psscan is designed to find all EPROCESS structures, so absence in psscan is unusual and not indicative of normal termination.

If windows.psscan and windows.pslist produce identical output, it definitively proves that no rootkit is present on the system.

Why it fails: Identical output does not guarantee the absence of a rootkit. Some rootkits may hide processes from both methods, or may not hide processes at all. Other rootkit techniques, such as SSDT hooking or DKOM on other structures, could still be present. Therefore, this statement is overly absolute and incorrect.

windows.pslist relies on pool tag scanning, while windows.psscan walks the active process list.

Why it fails: This statement reverses the actual methods: windows.pslist walks the active process list (via PsActiveProcessHead), while windows.psscan uses pool tag scanning. Understanding this distinction is crucial for interpreting discrepancies. Since the statement is factually incorrect, it is not a valid description of the tools' behaviors.

Volume Boot Record (VBR) timestamps

Why it fails: The Volume Boot Record contains file system metadata such as cluster size and volume serial number, but it does not store per-file timestamps. It is not relevant for detecting timestomping on individual files. Comparing VBR timestamps would not provide information about file modification or creation times, so it is an incorrect choice.

$Bitmap timestamps

Why it fails: $Bitmap is a metadata file that tracks cluster allocation, but it does not contain timestamps for file events. It records which clusters are in use, not when files were modified or created. It is not a source of timestamp information for detecting timestomping, making it an incorrect choice for this comparison.

Master File Table (MFT) record header timestamps

Why it fails: The MFT record header contains fields such as the record's allocated status and sequence number, but it does not store the four standard file timestamps. While the MFT record itself contains $STANDARD_INFORMATION and $FILE_NAME attributes, the header timestamps are not a separate artifact for comparison. This option is not a valid choice for detecting timestomping.