Endpoint Attack and Pivoting practice questions

Invoke Mimikatz 'sekurlsa::logonpasswords' directly from the command line.

Why it fails: Executing this command directly triggers immediate alerts in modern EDR systems due to the known signature of the Mimikatz binary and the specific API calls used to read LSASS memory. Security teams monitor for these process patterns, making this approach highly likely to result in immediate detection.

Use the 'lsadump::sam' command while running as a standard user.

Why it fails: This command requires local administrator privileges to access the SAM registry hive. Running this as a standard user will fail due to insufficient permissions. Even if attempted, it provides no path to plaintext credentials, and the failed access attempts are easily logged by security monitoring systems.

Inject a malicious DLL into the LSASS process space to capture passwords.

Why it fails: Injecting code into LSASS is an extremely invasive technique that is heavily monitored by endpoint security tools. Process injection into critical system services triggers behavioral alerts because it violates standard integrity boundaries. This method is considered loud and is likely to cause an immediate system crash.

Reset the user's password on the domain controller.

Why it fails: While good for overall security, a password reset does not immediately terminate an existing, established SSH session. If the attacker has already authenticated and built the tunnel, the connection remains active until the process is killed or the network route is physically dropped by a firewall.

Flush the DNS cache on the compromised workstation.

Why it fails: Flushing the DNS cache removes resolved hostnames but has no effect on an already established TCP connection. Since the SSH tunnel is built upon an established socket, clearing DNS entries will not disrupt the attacker's ability to continue using the tunnel for further lateral movement.

Clear the Windows Security Event Logs to remove evidence of the login.

Why it fails: Clearing event logs is a destructive action that hinders forensic investigation. It does not terminate the active attack, and it actually alerts the security team that an attacker is actively attempting to cover their tracks, which is a clear indicator of a compromise in progress.

Presence of a known malicious hash like 'eicar.com'.

Why it fails: The EICAR test file is a benign string used to test antivirus software, not a real-world tool used by attackers. Finding this file is a sign of a misconfiguration or a test, not an indicator of an actual persistent pivot occurring within the enterprise environment.

Normal user browsing the internet using Microsoft Edge.

Why it fails: Web browsing using standard, authorized browsers is an expected behavior for end-users. It does not constitute an indicator of a 'living off the land' attack unless it is associated with anomalous traffic patterns or the execution of unauthorized scripts within the browser context itself.

Enabling Windows Firewall to block all outbound traffic.

Why it fails: Blocking all outbound traffic is often impractical in production environments, as it breaks legitimate services and updates. A more surgical approach, such as using an EDR to monitor PowerShell execution and network connectivity, is preferred over a blanket firewall rule that could disrupt business-critical operations.

Disabling the Guest account on all workstations.

Why it fails: The Guest account is usually disabled by default in modern Windows environments. This does not address the threat posed by an attacker who has already gained user-level access, as the user running the PowerShell command is likely a standard domain user, not the guest account.

Regularly clearing the system audit logs.

Why it fails: Clearing audit logs is a destructive practice that removes forensic artifacts needed for incident response. It does nothing to prevent or mitigate the attack. In fact, such behavior is an indicator of compromise itself, as it is a common tactic for attackers to hide their activity.

Changing the desktop background image.

Why it fails: Changing the desktop wallpaper is a trivial activity that has no impact on the forensic investigation. It does not remove evidence, hide processes, or disrupt logging. While it might be annoying, it is irrelevant to the technical task of tracing an attacker's movement throughout the system.

Renaming a system file to 'temp.exe'.

Why it fails: Renaming a file does not hide its existence or its metadata. A skilled incident responder will easily identify the file during a standard filesystem scan, as the file's hash, creation timestamp, and location will remain consistent regardless of the name assigned to it by the attacker.

Restarting the computer after the attack.

Why it fails: Restarting a computer does not erase most logs, which are written to disk. While it may clear volatile memory (RAM), it does not serve the attacker's goal of deleting forensic artifacts. In many cases, it may actually trigger scripts that re-establish persistence, providing additional evidence for investigators.

Running a local brute-force attack against SSH.

Why it fails: Brute-forcing SSH is a noisy, antiquated technique that is easily detected by modern intrusion detection systems. It is not considered a sophisticated cloud-based lateral movement technique, as it relies on simple password guessing rather than leveraging the legitimate trust relationships inherent in modern cloud APIs and service identities.

Modifying the local 'hosts' file for DNS spoofing.

Why it fails: DNS spoofing via the hosts file is an on-premises technique used to redirect traffic on a local network. It is not a cloud API-based technique for lateral movement. While it can be used for pivoting, it does not leverage cloud service APIs or the cloud control plane.

Downloading the entire contents of a public bucket.

Why it fails: Accessing public buckets is a reconnaissance activity, not lateral movement. Lateral movement requires the attacker to actively pivot into a more privileged or internal position within the infrastructure. Simply accessing a public resource does not represent a move from one controlled system to another within the enterprise.

ss -tulpn

Why it fails: The ss utility is indeed a modern and faster replacement for netstat, displaying sockets with similar flags. However, while it provides excellent socket details, investigators frequently default to legacy netstat syntax under high-stress incident response timelines, making familiarity with both essential for accurate forensics.

ps -ef --forest

Why it fails: Process tree listings show hierarchical relationships and command-line arguments but fail to provide active socket binding states, local and remote endpoint IPs, or port numbers actively utilized by the forwarding tunnel on the operating system network stack.

lsof -i -P -n

Why it fails: Listing open files and network connections with lsof is highly effective for identifying network sockets, but it does not directly configure or test listening protocols in the precise tabular format traditionally inspected during rapid triage workflows.

PowerShell Script Block Logging Event ID 4104 showing interactive console inputs

Why it fails: PsExec is a compiled native Windows binary executed from the command line or via administrative shares, meaning it does not generate PowerShell script block logs or interact with the managed PowerShell execution engine.

DNS query logs for external command and control domain resolution requests

Why it fails: PsExec is an internal lateral movement tool operating over SMB and named pipes within the local network, so it typically does not generate external DNS queries unless the target itself attempts external resolution.

DHCP lease allocation logs showing dynamic IP address reassignments

Why it fails: DHCP lease logs track IP address assignments to network interfaces over time, which has no direct correlation to internal service creation, SMB authentication, or native administrative tool execution on a target endpoint.

Use a reverse shell from the database server to the workstation.

Why it fails: A reverse shell from the database server would require the database server to initiate a connection to the workstation. However, the database server is the target, not yet compromised, and it only allows connections from the workstation's IP. A reverse shell would not help the attacker connect to the database service.

Use ARP spoofing to redirect database traffic through the workstation.

Why it fails: ARP spoofing can intercept traffic but does not provide a proxy mechanism to initiate connections to the database server. It is a man-in-the-middle technique, not a pivot that allows the attacker to interact with the database as if from the workstation.

Use a SOCKS proxy server on the workstation and configure the attacker's tools to use it.

Why it fails: A SOCKS proxy on the workstation would allow the attacker to route traffic through it, but the database server only allows connections from the workstation's IP. A SOCKS proxy would still originate connections from the workstation, but it is not listed as a correct answer because the two most direct and commonly used techniques are netsh portproxy and SSH local port forwarding. SOCKS is also valid, but the question asks for two, and the other two are more specific to the scenario.

netsh portproxy add v4tov4 listenport=8080 connectport=3389 connectaddress=10.10.10.5

Why it fails: The correct syntax requires the 'interface portproxy' context. Omitting 'interface' results in an invalid command. Additionally, the listenaddress parameter is missing; while it can default to 0.0.0.0, the command as written would fail because 'netsh portproxy' is not a valid context. This option is a syntax error.

netsh interface portproxy add v4tov4 listenport=8080 listenaddress=127.0.0.1 connectport=3389 connectaddress=10.10.10.5

Why it fails: This command binds the listener to 127.0.0.1, meaning it only accepts connections from localhost. The attacker needs to accept connections from remote systems to pivot, so binding to the loopback address would prevent external access. The listenaddress should be 0.0.0.0 or a specific reachable IP.

netsh interface portproxy add v4tov4 listenport=3389 listenaddress=0.0.0.0 connectport=8080 connectaddress=10.10.10.5

Why it fails: This command reverses the ports: it listens on 3389 and forwards to 8080 on the target. The scenario requires listening on 8080 and forwarding to 3389. Although the syntax is correct, the port mapping is wrong, so the pivot would not work as intended. It would attempt to connect to RDP on the wrong port.

Security event log entries for process creation with event ID 4688

Why it fails: Event ID 4688 records process creation, including the account that started the process. However, the scenario states the attacker cleared the Security event log, which would remove these entries. While 4688 could have provided the account and process name, its deletion makes it unavailable. The question asks for an artifact that would still contain evidence despite the clearing, so this is not the best choice.

Prefetch file for the malicious binary

Why it fails: Prefetch files record the execution of an executable, including the last run time and loaded modules, but they do not store the user account that ran the process. The attacker deleted the binary, which may also affect Prefetch if the file was removed, though Prefetch can sometimes remain. Even if present, Prefetch would not reveal the cached domain administrator account used with `runas /savecred`, so it does not satisfy the requirement.

Amcache.hve entries for the malicious binary

Why it fails: Amcache.hve tracks the presence and execution of executables, storing metadata such as file path, SHA1 hash, and timestamps. It does not record the user account that executed the binary. Since the attacker deleted the binary, Amcache may still show its previous existence, but it cannot provide the account used. This artifact fails to answer the specific need to identify the account used for execution.

The Windows Firewall log for inbound connections on port 5985.

Why it fails: While WinRM uses port 5985 for HTTP, firewall logs may show allowed connections but often lack detailed application-layer information. They can indicate attempted connections but not the commands executed. The more specific WinRM and PowerShell logs provide richer context for analysis.

The Security event log for event ID 4624 with logon type 3.

Why it fails: Event ID 4624 with logon type 3 indicates a network logon, which could be part of WinRM but is not specific to it. Many services use network logons, so this alone does not confirm WinRM usage. It may be a supporting indicator but lacks the specificity of WinRM operational logs.

The presence of a service named 'WinRM' running on the server.

Why it fails: The WinRM service is installed by default on modern Windows Server versions and may be running legitimately. Its mere presence does not indicate malicious activity. The responder should focus on logs and configuration changes rather than the service's existence, as it is a normal component.

The service has already been deleted by the system.

Why it fails: The error 1060 specifically indicates that the Service Control Manager cannot locate the service in the registry. It does not imply that a service was deleted; rather, it indicates that the command provided was inappropriate for the intended action of creating a new persistent service entry.

The 'sc' command does not support the 'binPath' argument.

Why it fails: The 'sc create' command does indeed support the 'binPath' argument to define the executable path. The issue is that 'sc query' does not take a 'binPath' argument, as it only accepts a service name to identify a service that is already registered within the OS configuration.

The user lacks sufficient privileges to query services.

Why it fails: Querying services is a low-privilege operation that does not require administrative rights. The failure to find the service is due to the incorrect command structure rather than a lack of permissions. Administrative privileges are only required when attempting to create, delete, or modify service configurations.

Win32_Service, StartService

Why it fails: While Win32_Service can be used to start services, it is not the most common method for direct, ephemeral remote command execution. Attackers typically prefer Win32_Process for immediate execution of payloads without the overhead of creating, starting, and deleting a service object on the remote host.

Win32_StartupCommand, Create

Why it fails: This class is used to manage startup items that run when a user logs in. It is generally used for persistence rather than lateral movement, as it requires a user to log out and log back in to trigger the execution, which is not ideal for real-time pivoting.

Win32_ScheduledJob, Create

Why it fails: While Win32_ScheduledJob can be used for remote execution, it is an older, deprecated method that is often blocked or restricted in modern Windows environments. Most attackers prefer the more reliable and modern Win32_Process Create method for rapid lateral movement across a compromised network.

The creation of a temporary file named 'psexec.exe' in the root directory.

Why it fails: PsExec does not necessarily leave a file named 'psexec.exe' on the target. Instead, it creates a temporary service component that manages the execution. While it does upload a service binary, the filename can be randomized or transient, making the service name a more reliable indicator.

An entry in the 'Run' registry key for persistence.

Why it fails: PsExec is typically used for immediate, transient remote execution rather than long-term persistence. It does not automatically add entries to the Run registry keys. If an attacker wants persistence, they must perform additional steps to modify registry keys after the initial access is established via PsExec.

A specific user-mode process named 'psexec_agent'.

Why it fails: PsExec does not use a process named 'psexec_agent' for its operations. It executes commands through the service framework, which spawns processes under the context of the service account. The process name will simply reflect the command being executed by the attacker, not a fixed PsExec agent name.

Netcat

Why it fails: Netcat is a versatile networking utility, but it does not natively support SOCKS proxying. While it can be used for simple port forwarding, it lacks the sophistication required for dynamic SOCKS pivoting, which allows attackers to route any traffic through the compromised host without manual reconfiguration.

Tcpdump

Why it fails: Tcpdump is a packet analysis and sniffing tool, not a proxy or tunneling utility. It is used by both defenders for troubleshooting and attackers for reconnaissance, but it does not facilitate the creation of network tunnels required for pivoting between isolated segments within a network.

Wget

Why it fails: Wget is a command-line utility for downloading files from the internet. It does not provide any capability for proxying or tunneling. Using Wget for pivoting would be impossible, as it is designed for single-direction file retrieval, not for establishing bidirectional network connectivity for lateral movement.

Because they force a password reset on the target.

Why it fails: PtH does not involve resetting or changing passwords. It is an authentication bypass technique that uses existing credential material. If it triggered a password reset, it would be highly visible to users and administrators, making it a failed, noisy attack rather than a successful stealthy pivot.

Because they only work on Linux-based domain controllers.

Why it fails: Pass-the-Hash is a Windows-centric attack specifically targeting the NTLM authentication mechanism. It is not designed for Linux-based systems, which typically use different authentication protocols like Kerberos or SSH keys. The vulnerability exists within the Windows OS architecture, not in Linux domain controller environments.

Because the hash is always encrypted with AES-256.

Why it fails: NTLM hashes are not encrypted with AES-256; they are derived using the MD4 algorithm. The effectiveness of PtH does not depend on the strength of the encryption used to store the hash, but rather on the design of the NTLM protocol which accepts the hash as authentication material.

Encrypting files on the network share.

Why it fails: Encrypting files is the objective of ransomware, not a pivoting technique. SMB Relay is about intercepting and relaying authentication requests to impersonate a user. It does not involve mass encryption of data, which would be an extremely loud action that would trigger immediate detection by security teams.

Sending flood packets to crash the SMB service.

Why it fails: Sending flood packets is a Denial of Service (DoS) technique, not an attack for lateral movement or pivoting. The goal of an attacker during lateral movement is to maintain access and control, not to destroy service availability, which would only draw unwanted attention to their activities.

Replacing the SMB.exe binary with a malicious version.

Why it fails: SMB is a protocol implemented within the kernel and system services; there is no single binary named 'SMB.exe'. Replacing system-level protocol handlers is extremely difficult due to file integrity protections. SMB Relay is a network-layer attack, not a file replacement attack, making this option technically incorrect.

To hide files in a hidden directory.

Why it fails: Token manipulation has nothing to do with file storage or filesystem obfuscation. It is strictly about process identity and authentication. Hiding files is a separate persistence or exfiltration technique that does not involve interacting with the Windows security subsystem or impersonating other user contexts on the host.

To bypass user authentication prompts.

Why it fails: While it allows an attacker to act as another user, it does not 'bypass' authentication prompts in the way a password bypass would. It works by stealing an existing session token that has already been authenticated, effectively 'inheriting' the rights of that user session without requiring an interactive login.

To encrypt the memory of a running process.

Why it fails: Encrypting process memory is not a standard technique for pivoting. Attackers generally want to read or inject into process memory to steal information or code, not encrypt it. Encrypting memory would crash the process and trigger stability alerts, failing the attacker's objective of stealth and persistence.

Reimage the compromised workstation immediately to ensure all hidden artifacts and registry hooks are completely removed from the operating system.

Why it fails: Reimagining is a drastic containment measure that destroys volatile evidence needed for forensic analysis. While effective for total eradication, targeted artifact removal and process termination should be evaluated first when maintaining operational availability is a high priority during early triage.

Delete the legitimate signed Microsoft binary that loaded the malicious payload to prevent any further execution attempts by the operating system.

Why it fails: Deleting a legitimate signed Microsoft binary compromises operating system integrity and system file checkers. The malicious actor exploited the legitimate binary's search behavior, meaning the target for remediation is the rogue DLL, not the signed executable itself.

Modify the Windows Registry to disable the DLL loading subsystem entirely across the domain to prevent all future instances of search order hijacking.

Why it fails: Disabling the core Windows DLL loading subsystem would instantly crash the operating system and render all installed applications completely inoperable. Security teams must never apply global architectural changes that break fundamental OS operations as a remediation strategy.