Identification of Malicious and Normal Activity practice questions

lsass.exe process opening a handle to a browser process.

Why it fails: LSASS typically does not initiate handles to browsers. If this were observed, it would likely indicate a system anomaly or corruption rather than credential dumping, which involves other processes reading LSASS memory, not the reverse. This does not represent the standard pattern for known credential theft techniques.

A non-system process requesting PROCESS_QUERY_LIMITED_INFORMATION on lsass.exe.

Why it fails: While many processes query information about LSASS, this specific access right is often legitimate for system monitoring or anti-virus agents. A more definitive indicator would be requests for full memory access rights, such as PROCESS_VM_READ, which are required for dumping sensitive memory contents like password hashes.

Increase in network traffic volume on port 53.

Why it fails: Network traffic on port 53 relates to DNS resolution activity. While DNS tunneling can occur, it is unrelated to credential dumping. Credential dumping is a local host activity focused on memory manipulation and does not inherently rely on or manifest through changes in DNS traffic patterns.

SQL Injection.

Why it fails: SQL Injection involves manipulating database queries through application input. The provided exhibit shows client-side JavaScript injection aimed at the browser, not database command manipulation. The presence of a script tag clearly points to a browser-based vulnerability rather than an interaction with the backend database management system.

Cross-Site Request Forgery (CSRF).

Why it fails: CSRF forces a user to execute unwanted actions on a web application in which they are currently authenticated. While related, the exhibit shows data exfiltration (stealing the cookie) rather than forcing an action on the site. The primary goal shown is credential theft, not unauthorized command execution.

Buffer Overflow.

Why it fails: A buffer overflow occurs when a program writes data beyond the allocated memory limit. The exhibit contains a high-level JavaScript snippet that executes in the browser, not a low-level memory corruption exploit. There is no evidence of stack or heap manipulation, which defines a buffer overflow attack.

Windows Event ID 4688.

Why it fails: Event ID 4688 logs process creation. While it can capture the eventual execution of a malicious startup item, it does not directly log the modification of the registry key itself. Analysts would need to correlate process starts with registry audits to definitively identify the persistence mechanism being used.

The browser cache folder contents.

Why it fails: Browser cache stores temporary web files and does not contain information about system startup persistence. Searching this area would not reveal registry key modifications. Persistence mechanisms operate at the OS level, not within the application data of a web browser, making this an irrelevant source of information.

Network flow logs from the border firewall.

Why it fails: Firewall logs track network traffic, not local host registry modifications. They provide zero visibility into the system's configuration or startup items. Using firewall logs to detect persistence would be unsuccessful, as the persistence mechanism is a local file-system and registry state, not a network communication event.

The file was blocked by AppLocker.

Why it fails: Shimcache entries exist for files that were executed, regardless of their eventual removal. There is no indication within the Shimcache structure whether execution was blocked by AppLocker or allowed. AppLocker events are recorded in separate Event Logs, not the AppCompatCache registry artifact, which only tracks compatibility execution history.

The file was a service that failed to start.

Why it fails: Shimcache tracks execution attempts, not service status. It does not provide information on whether a process was a service or if it failed to initialize correctly. Its primary purpose is recording the metadata of executable files that reached the point of loading into the Windows memory space.

The system was infected by a rootkit.

Why it fails: The presence of a Shimcache entry only confirms execution, not the nature of the software. A rootkit might appear in the Shimcache, but so would a standard application. One cannot conclude the file was a rootkit without further analysis of the binary's behavior, which is no longer available.

The connections utilize TLS 1.2 for all outbound communication.

Why it fails: Using TLS 1.2 is a standard best practice for securing outbound traffic. Many legitimate system processes utilize this protocol to encrypt data sent to Microsoft update servers or telemetry endpoints. Consequently, the use of encryption alone does not serve as an indicator of compromise during forensic investigations.

The connections occur at a consistent, predictable daily interval.

Why it fails: Scheduled tasks and legitimate background services frequently operate on fixed, predictable time intervals. Relying solely on timing provides insufficient evidence of malice, as many system maintenance tasks and network heartbeat signals are designed to trigger at specific times to avoid high-load periods on the workstation.

The external IP address belongs to a cloud service provider.

Why it fails: Legitimate enterprise software and modern operating system components frequently communicate with cloud-hosted infrastructure for updates, licensing, and telemetry. Identifying an IP as belonging to a major cloud provider does not inherently distinguish malicious command-and-control traffic from standard, authorized application behavior in a modern enterprise network environment.

The file is an executable, which is forbidden in the Public folder.

Why it fails: The Windows operating system does not strictly forbid executables in the Public folder. While not best practice for security, the mere presence of an executable is not sufficient proof of malice. The specific file name 'svchost.exe' is the primary indicator of suspicion, not the folder itself.

The Public folder is not indexed by the Windows Search service.

Why it fails: The indexing status of a folder has no bearing on whether a file within it is malicious. Security forensics focuses on file paths, integrity, and behavior, not the performance features of the Windows Search service, which is irrelevant to the determination of whether an executable is potentially harmful.

Windows automatically deletes any binary named svchost.exe found outside System32.

Why it fails: Windows does not perform automatic deletion of binaries based on their name or location. It relies on security features like Windows Defender or user-mode policies to prevent unauthorized code execution. Assuming the OS handles this automatically is a dangerous oversight that leads to missing persistent threats residing in non-standard paths.

The size of the system pagefile.sys.

Why it fails: The pagefile size is a function of system configuration and memory usage, not a record of user activity. While it may contain remnants of executed scripts, it is not a direct artifact of user authentication or command execution and cannot be used to attribute activity to a specific user.

The content of the .bash_history file.

Why it fails: While .bash_history tracks Linux command line activity, it is irrelevant for Windows-based script execution analysis. Forensic analysts must ensure they are examining the correct artifacts for the operating system under investigation to avoid misinterpreting findings or missing critical evidence during the analysis phase of an incident response.

Immediately delete the registry key to stop the persistence.

Why it fails: Deleting the key without forensic analysis destroys evidence. It prevents the analyst from identifying the source, the malware's capabilities, or other indicators of compromise. Proper procedure dictates capturing the state for investigation before remediation, as immediate deletion hampers the ability to understand the full scope of the breach.

Run a full disk scan using a common consumer-grade antivirus tool.

Why it fails: Consumer-grade antivirus tools are not designed for deep forensic analysis. They may miss sophisticated, custom, or fileless malware. Relying solely on these automated scanners is insufficient for a professional forensic investigation, which requires manual validation of binary integrity, origin, and behavior to ensure nothing is overlooked by generic signatures.

Reboot the system to see if the registry entry persists.

Why it fails: Rebooting the system clears volatile memory artifacts and potentially resets the state of the malware, making it harder to track what was running. For forensic investigations, the goal is to observe the system in its current state. Rebooting is an unnecessary risk that can degrade the quality of forensic evidence.

DNS query logs from the domain controller.

Why it fails: DNS logs provide information on name resolution but do not detail the user sessions or service interactions required to prove lateral movement. While they can show communication to suspicious domains, they are not the primary source for identifying user-account-based traversal between internal assets within the corporate network environment.

Application logs for the local web server.

Why it fails: Application logs are limited to the scope of that specific service. They do not capture lateral movement across the network or authentication events for the operating system. Relying on application logs will result in missing the broader activity of an attacker navigating through the domain infrastructure.

DHCP lease logs.

Why it fails: DHCP logs track IP address assignments to MAC addresses. They do not record user authentication, account usage, or service interactions between hosts. These logs are useful for asset identification, but they are not effective for detecting or attributing lateral movement, which occurs at the user and session layer.

The file is a legitimate Windows component that was copied from an installation media, which preserves original timestamps in $STANDARD_INFORMATION but writes new $FILE_NAME timestamps at copy time.

Why it fails: Copying a file generally creates a new file with both $STANDARD_INFORMATION and $FILE_NAME timestamps close to the copy time, unless explicit timestamp preservation tools are used. Legitimate Windows installation does not typically produce a 45-minute discrepancy on lsass.exe, and this explanation ignores the strong timestomping indicator.

The system clock was adjusted backwards after the file was created, so the $STANDARD_INFORMATION timestamps reflect the corrected time.

Why it fails: A backwards clock adjustment would affect timestamps written after the change, but it would not systematically make only the $STANDARD_INFORMATION set earlier than the $FILE_NAME set on a single file. This pattern is not a reliable indicator of clock tampering, and the scenario provides no evidence of a system-wide time change.

The NTFS journal was replayed after an unclean shutdown, which caused $FILE_NAME timestamps to be refreshed while $STANDARD_INFORMATION timestamps remained unchanged.

Why it fails: Journal replay after an unclean shutdown updates metadata for consistency but does not selectively refresh only $FILE_NAME timestamps. Such a process would not create a consistent 45-minute offset, and attributing the discrepancy to journal replay overlooks the known forensic artifact of timestomping, which is far more plausible here.

Security event ID 4624 with Logon Type 3 and the account name of a domain administrator.

Why it fails: Event ID 4624 with Logon Type 3 indicates a network logon, which is common for many legitimate administrative activities, including file shares and remote management. While a DCSync attack may involve network logons, this event alone does not distinguish DCSync from normal administration. It lacks the specific replication rights or directory service access context needed to confirm the attack, so it is not a direct indicator.

Security event ID 5136 with the object class of user and the attribute samAccountName.

Why it fails: Event ID 5136 logs modifications to directory service objects. A change to samAccountName might indicate an account rename or creation, but DCSync does not modify objects; it reads replication data. This event is unrelated to the replication request that characterizes DCSync. It would be relevant for tracking unauthorized account changes, not for detecting credential dumping via replication.

Security event ID 4769 with the service name krbtgt and encryption type 0x17.

Why it fails: Event ID 4769 logs a Kerberos service ticket request. A request for the krbtgt service with RC4 encryption (0x17) can indicate a Kerberoasting or golden ticket attack, but it is not specific to DCSync. DCSync uses directory replication protocols, not Kerberos ticket requests. This event would be more relevant when investigating ticket-based attacks, not replication-based credential dumping.

The presence of a PowerShell script that downloads and executes code from a remote URL.

Why it fails: This describes the action of the scheduled task, not an independent artifact. The scheduled task itself is the persistence mechanism. The remote script execution is a technique, but without the task or another autostart, it would not persist. Thus, this is not a separate persistence artifact.

A new local user account named 'Support' with administrative privileges.

Why it fails: While an unauthorized admin account can be a sign of compromise, it is not a persistence mechanism per se. Attackers may create accounts for access, but persistence typically involves automated execution. The account could be used for lateral movement or privilege escalation, but it does not automatically ensure continued execution after reboots.

A service named 'RemoteSvc' with a binary path pointing to 'C:\Windows\Temp\svc.exe'.

Why it fails: A service with a binary in C:\Windows\Temp is suspicious and could be malicious, but it is not necessarily a persistence mechanism if the service is not set to start automatically. The question asks for persistence mechanisms; services can be persistence if configured to auto-start, but the given information does not specify the start type. The scheduled task and Run key are more definitive.

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Why it fails: User Shell Folders defines where profile directories such as Desktop, Documents, and Startup are located. It does not itself launch programs at logon; it only points to paths. An attacker could redirect the Startup folder here to a writable location as a secondary trick, but the key is not an auto-start entry by itself, so it does not answer the question directly.

HKLM\SYSTEM\CurrentControlSet\Services

Why it fails: The Services key governs kernel and user-mode service startup, which requires administrative rights to modify and is not tied to interactive user logon. While attackers use malicious services for persistence, the stem asks specifically for logon-triggered auto-starts that a non-admin user can create. This key fails the stated requirement of not requiring administrative privileges.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Why it fails: RunOnce executes a command a single time and then removes the entry, so it does not provide recurring logon persistence. It also lives under HKLM and normally requires administrative rights to modify. The stem asks for auto-starts at user logon without administrative rights, and RunOnce fails both the recurrence and privilege conditions.

explorer.exe is legitimately connecting to a Microsoft update server to check for Windows updates.

Why it fails: Windows Update is handled by svchost.exe and other system processes, not explorer.exe. While explorer.exe may make some network connections for features like OneDrive or network discovery, a direct connection to an arbitrary external IP on port 443 is not typical. The IP 203.0.113.5 is not a known Microsoft update server.

The connection is a false positive due to the way Volatility associates network connections with processes.

Why it fails: Volatility's netscan plugin is generally reliable for mapping connections to PIDs, though it can have limitations. However, assuming a false positive without further evidence is not sound. The anomaly of explorer.exe making an external connection warrants investigation as potential malicious activity.

explorer.exe is being used by a legitimate application to download files from the internet.

Why it fails: Legitimate applications typically use their own processes or system services for network communication, not explorer.exe. While explorer.exe can initiate connections for things like downloading files via the shell, an established connection to an arbitrary IP on port 443 is more indicative of malicious injection than normal behavior.

The document was defragmented by the NTFS optimizer during routine maintenance.

Why it fails: Defragmentation moves existing clusters and updates the Master File Table run lists, but it does not generate DATA_TRUNCATION followed by DATA_EXTEND records under the same filename. Maintenance operations also would not coincide with a filename that has vanished from the directory, whereas the observed sequence reflects deliberate content replacement rather than cluster relocation.

The document was overwritten with attacker tooling and then deleted to remove evidence.

Why it fails: Deletion to remove evidence would show a FILE_DELETE record followed by the file's data clusters being freed, not a DATA_TRUNCATION immediately followed by DATA_EXTEND records that build a new, larger file body. The extension phase indicates new content was being written and retained, which is inconsistent with a pure anti-forensic wipe-and-delete operation.

The original document was encrypted in place by ransomware.

Why it fails: Ransomware encryption typically creates a new file with a modified extension and deletes the original, which would produce FILE_CREATE and FILE_DELETE records with a different name, not a truncation followed by extension records under the original filename. The observed pattern shows content being overwritten and then the file being repurposed, not a simple in-place cryptographic transformation of the existing bytes.

The file was moved from another NTFS volume, and the FNA timestamp reflects the original creation time while the SIA timestamp reflects when it was moved to this volume; this is normal NTFS behavior and not indicative of timestomping.

Why it fails: When a file is moved within the same NTFS volume, the FNA timestamp is preserved, but the SIA timestamp is not updated. When moved across volumes, the SIA timestamp is updated to the move time, and the FNA timestamp is also updated to the move time, not the original creation. Therefore, this explanation is incorrect for the observed discrepancy.

The file was downloaded from the internet, and the SIA timestamp reflects when the download completed while the FNA timestamp reflects when the file was first written to disk; this is a normal artifact of browser downloads.

Why it fails: Browser downloads typically create the file with consistent SIA and FNA timestamps. While the SIA modification time might reflect download completion, the creation time is usually set when the file is first created. A later SIA creation than FNA creation is not a standard download artifact and is more indicative of deliberate timestamp manipulation.

The file was copied from another NTFS volume, and the FNA timestamp reflects the original creation time while the SIA timestamp reflects when it was written to this volume; this is a timestomping indicator.

Why it fails: While copying a file between NTFS volumes can cause discrepancies between SIA and FNA timestamps, the FNA typically inherits the original creation time only if the file is moved, not copied. A copy operation usually updates both timestamps. This scenario does not definitively indicate timestomping, as legitimate file operations can produce similar patterns. The location in C:\Windows\Temp adds suspicion but is not conclusive.

The absence of a corresponding event ID 4648 (A logon was attempted using explicit credentials) for the same user

Why it fails: Event ID 4648 is generated when explicit credentials are supplied, such as with runas or a scheduled task. Its absence is common in many legitimate network logons and does not indicate Pass-the-Hash. Attackers using Pass-the-Hash typically do not supply explicit credentials, but neither do many normal service accounts, so this is not a reliable discriminator.

A preceding event ID 4625 (An account failed to log on) from the same source IP

Why it fails: Event ID 4625 indicates a failed logon attempt, which could suggest password guessing or a lockout, but Pass-the-Hash attacks typically succeed on the first attempt because the hash is valid. A preceding failure might indicate a different attack vector, such as brute force, and does not specifically support the use of a stolen NTLM hash.

A corresponding event ID 4672 (Special privileges assigned to new logon) for the same session

Why it fails: Event ID 4672 is logged when a logon is assigned special privileges, such as SeDebugPrivilege. While it often accompanies administrative logons, it does not distinguish a Pass-the-Hash attack from a legitimate administrative logon. It is a generic indicator of elevated privileges and lacks the specificity needed to confirm credential theft via hash reuse.

The Security event log for event ID 4698 (A scheduled task was created)

Why it fails: Event ID 4698 is logged in the Security log when a scheduled task is created and includes the task name, content, and user. However, it may not always be enabled depending on audit policy, and the Task Scheduler operational log is specifically designed for task lifecycle events and is more consistently available. The operational log event 106 is more directly focused on task registration.

The file system timestamps of the task file in C:\Windows\System32\Tasks

Why it fails: The task file's creation timestamp can indicate when the task was created, but it can be modified or the file may be recreated by the system. It does not record which user account created the task. This method lacks the user attribution needed to fully answer the question, making it less reliable than the operational log.

The PowerShell operational log for event ID 4104 (Script block logging) showing the script creation

Why it fails: Event ID 4104 records script block content when PowerShell executes a script, but it does not capture the creation of a scheduled task. It might show the script that the task runs, but not the task registration event or the user who created it. Therefore, it does not provide the creation time or creator of the scheduled task itself.

The Windows Security event log for event ID 4688 with the process name 'WmiPrvSE.exe' and a command line containing 'scrcons.exe'.

Why it fails: Event ID 4688 logs process creation, but WmiPrvSE.exe is the WMI provider host, and scrcons.exe is the script consumer host. While these processes can be involved in WMI activity, their presence alone does not confirm persistence. Moreover, the command line for scrcons.exe may not be logged by default. This artifact is less reliable than the WMI repository for identifying persistence.

The registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WMI\Subscriptions, which stores all WMI event subscriptions.

Why it fails: There is no such registry key that stores WMI event subscriptions. WMI event subscriptions are stored in the WMI repository, not directly in the registry. This registry path does not exist for this purpose. Attackers may use the registry for other persistence, but not for WMI event subscriptions.

The file system artifacts in C:\Windows\System32\wbem\Logs, including the 'wmiprvse.log' and 'scrcons.log' files.

Why it fails: WMI logging is not enabled by default, and even when enabled, the logs in C:\Windows\System32\wbem\Logs are primarily for WMI-Activity operational logs, not detailed event subscription information. These logs may show errors but are not the primary location for persistence artifacts. The WMI repository is the authoritative source for event subscriptions.

An interactive user logged into the local console, triggering default privilege escalation assignments.

Why it fails: Logon Type 3 is a network logon, not an interactive console logon (Type 2), so this interpretation contradicts the event data. It is tempting because 4672 does follow successful logons, but Type 2 would be correct for a user physically at the machine, not a remote subnet source.

A scheduled batch job executed locally using stored credentials without generating network authentication traffic.

Why it fails: Batch jobs utilize Logon Type 4 instead of Logon Type 3. Because network logons require remote connectivity indicators, batch tasks restricted to local execution do not produce the network source IP fields typically logged in Type 3 events.

A service account automatically restarted following a system crash, initiating local service control manager requests.

Why it fails: Service restarts produce Logon Type 5 (service) events, not Type 3 network logons, and 4672 follows interactive or network authentication rather than crash recovery. It is tempting because service accounts do generate 4672, but Type 5 would be correct for a service start, not a remote network source.