Attacks and Exploits practice questions

John the Ripper

Why it fails: John the Ripper is a dedicated password/hash cracking tool that works offline against captured NTLM or Net-NTLMv2 hashes; it has no built-in capability to authenticate to a remote Windows host or execute commands on the target. While it can break weak passwords, it does not perform pass-the-hash attacks, which require substituting a hash as a credential in an active network authentication session.

Metasploit

Why it fails: Metasploit does contain modules such as exploit/windows/smb/psexec_psh that can authenticate with an NTLM hash, but it is a broad exploitation framework rather than a purpose-built lateral movement utility. Using it for pass-the-hash often requires session management, payload generation, and target-by-target invocation, whereas the attacker in this scenario simply needs to execute commands across multiple hosts quickly; CrackMapExec is more streamlined and is the go-to tool for this exact task.

pth-winexe

Why it fails: pth-winexe is a tool from the Samba suite that can indeed perform pass-the-hash operations by launching winexe to execute commands over SMB using an NTLM hash. However, it is less commonly used in modern penetration testing because it lacks the multi-host automation, protocol diversity (SMB/WMI/WinRM), and built-in post-exploitation helpers that CrackMapExec provides; pth-winexe is also older and not as actively maintained, making CME the more comprehensive and efficient choice for lateral movement.

127.0.0.1

Why it fails: 127.0.0.1 is the IPv4 loopback address, which always points to the local host itself rather than to any external infrastructure. Penetration testers use it to probe services listening on the same machine, such as a database or admin panel, but it is not the cloud provider's instance metadata service. The metadata service uses a distinct link-local address, so an SSRF request targeting 127.0.0.1 would not retrieve IAM credentials or user-data.

192.168.1.254

Why it fails: 192.168.1.254 is a commonly used private IP address for home or small-office router management interfaces, falling within the RFC 1918 192.168.0.0/16 range. It has no special meaning to cloud platforms, and it is not reachable as a metadata service from a public cloud instance. While it could be an internal target in a network scan, choosing it as the metadata endpoint would be based on a false association with typical consumer gateway IP conventions.

10.0.0.1

Why it fails: 10.0.0.1 is a private IPv4 address in the 10.0.0.0/8 RFC 1918 block, frequently used as the default gateway in cloud VPC subnets and corporate networks. It is not a link-local address and is not reserved for metadata services; cloud metadata is only reachable at the 169.254.0.0/16 link-local range. Additionally, many cloud environments have no metadata listener on 10.0.0.1, so a request there would fail or hit an unrelated internal service.

Out-of-band SQL injection

Why it fails: Out-of-band SQL injection uses a separate communication channel (e.g., DNS) to exfiltrate data, which still creates output outside the original query, not fully meeting the requirement.

Error-based SQL injection

Why it fails: Error-based SQL injection relies on database error messages to retrieve data, which is still a form of output from the original query context.

UNION-based SQL injection

Why it fails: UNION-based SQL injection combines results from multiple SELECT statements into the original query output, thereby returning data in the original query, which contradicts the requirement.

Brute-force the secret key

Why it fails: Brute-forcing the JWT secret is conceptually possible only if the signing key is weak or guessable, but it is not the most direct exploitation path here. The server's flaw is that it fails to validate the signature algorithm, meaning an attacker can bypass signature verification entirely without needing the secret. Attempting a brute-force would be inefficient, potentially noise-inducing, and unnecessary when a trivial algorithm substitution achieves immediate token forgery.

KID injection

Why it fails: KID (Key ID) injection exploits how the server uses the `kid` header to select a verification key, often via path traversal or SQL injection to force use of a controllable key. This attack does not target the algorithm validation logic itself, which is the core vulnerability in the scenario. Here the server improperly trusts the `alg` header, so modifying the algorithm to `none` is a simpler and more direct bypass than manipulating key selection via `kid`.

Algorithm confusion attack

Why it fails: An algorithm confusion attack exploits servers that accept tokens signed with the public key using a symmetric algorithm like HS256, but the stem specifies the server fails to validate the signature algorithm properly, not that it trusts a public key for HMAC verification. This attack is tempting because it is the standard method for forging JWTs when the server uses the same key for both signing and verification without algorithm enforcement, which would be the correct scenario for its use.

use

Why it fails: The 'use' command in Metasploit loads and initializes a specific module (e.g., an exploit, auxiliary, or post-exploitation module) into the active context, allowing you to configure its options and targets. It does not attach to or manage any live shell or Meterpreter sessions that have already been established; rather, it merely prepares a module for execution. Interacting with an existing session requires the 'sessions' command, so 'use' is incorrect here.

exploit

Why it fails: The 'exploit' command executes the currently selected exploit module against a target, delivering a payload in an attempt to establish a new session. It is used to create a session, not to interact with one that already exists; after a successful exploit, you would switch to 'sessions -i' to communicate with the resulting session. Running 'exploit' again would launch a fresh attack rather than attaching to the existing connection, so it is not the correct command for this task.

run

Why it fails: The 'run' command executes a module, typically an auxiliary or post-exploitation module, and is often used after setting module options. While 'run' can be used inside an active Meterpreter session to launch post modules, it does not provide a way to select or interact with a session itself. To interact with an existing session, you must use 'sessions -i', because 'run' lacks the ability to switch the console context to a live session.

SameSite=None

Why it fails: SameSite=None explicitly disables the SameSite mechanism, telling the browser to attach the session cookie to every outgoing request regardless of whether it is same-site or cross-site. This means a malicious page can trigger a POST or GET request to the authenticated application, and the cookie will be included automatically, making the request look legitimate. Even though modern browsers require Secure alongside None, that only enforces HTTPS transport and does nothing to stop the cross-site transmission of the cookie, so CSRF remains entirely possible.

SameSite=Secure

Why it fails: SameSite=Secure has no effect on CSRF because it only tells the browser to send the cookie exclusively over HTTPS connections; it places no restriction on whether those requests are cross-site or same-site. An attacker can still host a malicious form or script that submits to the HTTPS endpoint, and the browser will happily include the Secure cookie in that cross-site request. Its purpose is to prevent cookie exposure over cleartext HTTP, not to mitigate cross-site request forgery, so setting Secure alone leaves the application fully vulnerable.

SameSite=Lax

Why it fails: SameSite=Lax provides only partial CSRF protection by allowing cookies to be included on top-level cross-site navigations that use the GET method, while blocking them on XHR, fetch, iframe, and POST/PUT/DELETE requests. This means an attacker can still craft a simple link or an image tag that triggers a GET request to a state-changing endpoint if the application exposes one, resulting in CSRF. Lax is a pragmatic default that prevents many common attacks using form submissions, but it is not a complete defense against all CSRF vectors, particularly those that rely on top-level GET navigations.

The application validates the Referer header

Why it fails: Referer validation is a CSRF defense that checks the HTTP Referer header to confirm the request originated from the application's own domain. While it can block trivial CSRF attempts, it is not a condition required for exploitation; attackers can bypass weak Referer checks by omitting the header (e.g., via HTTPS-to-HTTP transitions or privacy settings) or using open redirects. Its presence only raises the difficulty of a CSRF attack, rather than enabling it, so it is an incorrect answer when identifying CSRF preconditions.

The application uses SameSite cookies set to Lax or Strict

Why it fails: The SameSite attribute on cookies controls whether the browser sends the cookie with cross-site requests; Lax permits top-level navigation using safe methods (like GET) while Strict blocks all cross-site sending. When cookies are set to Lax or Strict, a CSRF attack originating from another site will not include the session cookie, causing the forged request to fail authentication. This is a protective mechanism against CSRF, not a prerequisite for the vulnerability, so it does not describe a condition that enables CSRF.

The application uses anti-CSRF tokens in forms

Why it fails: Anti-CSRF tokens are random values generated by the server and embedded in forms or requests; the server validates that a submitted request contains the expected token. Because an attacker's site cannot read the victim's token due to the same-origin policy, forged CSRF requests will lack the token and be rejected. This is a defensive mechanism specifically designed to prevent CSRF, so its presence is the opposite of an exploitable condition and thus a wrong answer to what enables the attack.

Performing a DLL hijacking attack

Why it fails: DLL hijacking is a Windows-specific attack that exploits the search order for Dynamic Link Libraries; Linux has no concept of DLLs. On a Linux system, the equivalent technique would be library preloading (LD_PRELOAD) or manipulating RPATH/RUNPATH, but the term 'DLL hijacking' is incorrect in this context. Therefore, this is not a valid enumeration or exploitation step for a SUID binary on a Linux server.

Exploiting a kernel vulnerability

Why it fails: Exploiting a kernel vulnerability is a distinct privilege escalation approach that targets the operating system kernel itself, not the SUID binary's functionality. While kernel exploits can certainly grant root, they require a matching kernel version and often crash the system or are unreliable. In a PenTest+ scenario, SUID binary exploitation is about abusing the binary's own permissions and features, not about kernel-level bugs.

psexec

Why it fails: PsExec is a Windows Sysinternals utility that remotely executes processes over SMB/ADMIN$ shares using valid Windows credentials; its counterpart in Impacket (psexec.py) simply replicates this Windows lateral-movement technique. It does not create routes, forward ports, or tunnel arbitrary TCP traffic, so it cannot pivot an attacker's traffic from a compromised Linux host. Even when run on Linux, it targets a Windows SMB service and is not a pivoting mechanism.

Windows Remote Desktop (RDP)

Why it fails: Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol for interactive graphical access to Windows desktops, not a mechanism for forwarding or tunneling arbitrary network traffic. While it could be used to access a Windows system after moving laterally, it does not provide a route or SOCKS proxy through the Linux host. Therefore, despite being a common remote-access tool, it is not a pivoting technique and is irrelevant when the compromised host is Linux.

sysinfo

Why it fails: sysinfo retrieves operating system version, architecture, domain, and other machine-level details via a remote API call. It is purely an enumeration command that writes to the session's output and never invokes token manipulation, service creation, or privilege-related APIs. As such, it cannot cross a privilege boundary, leaving the session's integrity level exactly where it was before execution.

getuid

Why it fails: getuid queries the current thread token to resolve the username, SID, and domain, then prints them in the console. It performs no write operations, no token adjustments, and no attempt to obtain a higher-privileged context; it merely reports the existing security principal. Even if the Metasploit session is running as a standard user, getuid will simply show that user and return without modifying the access token.

hashdump

Why it fails: hashdump attempts to read the SAM registry hive and, in some configurations, the cached domain credentials, outputting NTLM hashes. To open the SAM hive successfully, the process must already hold SYSTEM or at least elevated local administrative rights; running it from a low-integrity session typically results in an 'Access is denied' error. Because it depends on preexisting high privileges rather than acquiring them, it is a post-escalation credential theft step, not an escalation vector.

ls -la /bin/su

Why it fails: Running ls -la /bin/su merely displays the permission bits and ownership of that single file, giving no visibility into other binaries across the system that may have the SUID bit enabled. An attacker or auditor needs to enumerate all SUID binaries to identify potential privilege escalation paths, which this command cannot do. While it confirms whether /bin/su has setuid, it does not answer the broader question of finding SUID binaries.

find / -perm /2000

Why it fails: The numeric mode /2000 in find's -perm test matches files with the setgid (SGID) bit set, not the setuid (SUID) bit. SGID affects group ownership and can be useful on directories, but it is a different privilege model than SUID's user-based escalation. The correct mode to find SUID binaries is /4000, so this command returns an unrelated set of files and would miss the wanted targets.

find / -type f -perm 0777

Why it fails: Using -type f -perm 0777 locates files that are globally readable, writable, and executable, which are often called world-writable and may be security concerns, but it does not test for the SUID bit at all. The mode 0777 is a full Unix permission mask for user, group, and other, lacking the special setuid bit (4000). Consequently, this command will not reveal binaries with SUID set, and it may also produce many false positives for regular scripts or data files.

Registry Run keys

Why it fails: Registry Run keys are a Windows-specific persistence mechanism that stores startup programs under HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE. The Linux operating system has no central registry; instead, startup and autostart files are plain-text configuration files like /etc/rc.local, systemd unit files, or shell profile scripts. Since the target is a Linux server, this technique is entirely inapplicable and cannot be used to maintain access.

WMI subscriptions

Why it fails: WMI (Windows Management Instrumentation) is a Windows framework for system management and monitoring. Permanent WMI event subscriptions, such as creating a filter and a consumer, allow attackers to execute code when a specific event occurs, making it a well-known persistence vector on Windows. Linux does not implement WMI; equivalent Linux mechanisms would be tools like inotify or systemd path units, so this option is irrelevant on a compromised Linux server.

Creating a new service

Why it fails: Creating a new service requires root privileges and systemd integration, which the compromised shell may lack if the initial foothold was gained through a low-privilege vector such as a web application vulnerability. This method is tempting because services are the standard mechanism for running persistent daemons on Linux, and would be correct if the tester had already escalated to root and needed a reliable, restartable back-end process.

The service account password must be weak

Why it fails: The strength of the service account password is irrelevant to whether Kerberoasting can be performed; the attack succeeds whenever a TGS ticket encrypted with the account's hash can be obtained. A weak password only increases the chance that offline cracking will recover the plaintext, but even a strong password can be subjected to the same offline attack. Thus, weak password is not a precondition for the attack.

The domain must be using NTLM authentication

Why it fails: Kerberoasting is a Kerberos-based attack, not an NTLM attack. The attacker requests TGS tickets from the domain controller using a valid Kerberos TGT, and the service ticket is encrypted with the service account's long-term key derived from its password. NTLM is a separate challenge-response protocol that does not issue or carry service tickets, so requiring NTLM would be both incorrect and irrelevant to the attack's success.

The attacker must have domain admin privileges

Why it fails: Kerberoasting requires no elevated privileges like domain admin. Any authenticated domain user can request TGS tickets for any SPN because the ticket is encrypted with the service account's password hash, not the requester's. This is a core reason Kerberoasting is a common privilege-escalation vector: it starts with unprivileged access and can yield hashes that, once cracked, grant access to service accounts.

John the Ripper

Why it fails: John the Ripper is an offline password cracking utility that takes captured NTLM hashes and attempts to recover the original plaintext via dictionary, brute force, or rule-based attacks. It operates solely on a local copy of the hash file and never sends the hash to a remote service, so it cannot be used to impersonate a user over the network. Even if John eventually cracks the hash, that is a password-recovery process, not pass-the-hash, making it the wrong choice for directly authenticating to a Windows target.

CrackMapExec

Why it fails: CrackMapExec (CME) is a post-exploitation framework that does support pass-the-hash, allowing you to authenticate with an NTLM hash over SMB or WinRM and execute commands across multiple hosts. However, it is a general-purpose Swiss Army knife for lateral movement, network enumeration, and vulnerability checking, not a dedicated pass-the-hash utility. pth-winexe, in contrast, is a single-purpose Impacket tool built specifically to use a hash with the Windows SMB and service control manager interfaces, making it the more exact and therefore correct answer.

Hashcat

Why it fails: Hashcat is a GPU-accelerated password recovery tool that cracks hashes by testing millions of candidate passwords per second against the captured NTLM hash, but it performs only offline cryptanalysis. It cannot initiate an SMB connection, send a challenge/response, or otherwise use the hash to authenticate to a remote system. Like John the Ripper, its purpose is to recover plaintext passwords, not to perform pass-the-hash, so it is incorrect for this scenario.

Time-based blind SQL injection

Why it fails: Time-based blind SQL injection is a separate blind technique that triggers a database delay function (such as SLEEP() in MySQL, WAITFOR DELAY in SQL Server, or pg_sleep in PostgreSQL) when an injected condition is true, and the attacker measures the response latency to infer the answer. Unlike boolean-based methods, it does not rely on any observable difference in the returned page content, only on the timing delay, which can be problematic over unreliable networks or when query caching affects latency. It is often used when boolean-based tests produce identical responses regardless of the condition, for example when the application masks differences with generic error pages.

Error-based SQL injection

Why it fails: Error-based SQL injection exploits the database's verbose error messages to extract information directly in the response. For instance, in MySQL an attacker can use functions like UPDATEXML() or EXTRACTVALUE() with a malformed XPath expression that concatenates the query result into the error text, while in SQL Server a CONVERT() with an invalid data type can force data into the error output. The key distinction is that the attacker observes the crafted error message itself as the output channel, not just a true/false page difference. This method is considered non-blind because it returns actual data values through errors, requiring immediate error display in the application.

UNION-based SQL injection

Why it fails: UNION-based SQL injection leverages the UNION operator to append a second SELECT statement's results directly into the original query's result set, thereby displaying database content in the normal application page. To succeed, the attacker must match the number and data types of columns in the original query, typically by guessing or using ORDER BY techniques, and then the extracted data (such as credentials) appears alongside legitimate output. Since the data is returned directly in the HTTP response, it is fundamentally different from blind SQL injection, which only reveals a binary true/false outcome.

Writable script in cron

Why it fails: This is incorrect because a writable script in cron requires a scheduled task that executes a script an attacker can modify, allowing code execution at the time the cron job runs. However, the scenario involves a Linux binary that is misconfigured to look for executables via PATH, not a cron job. There is no indication of a cron entry, so this vector does not apply to the discovered vulnerability.

Kernel exploit

Why it fails: This is wrong because a kernel exploit targets a vulnerability in the kernel itself, such as a race condition or memory corruption, to gain root. In this case, no kernel bug is present; the root cause is a misconfiguration in how the binary calls external programs. Exploiting a misconfiguration is simpler and does not require the risk of crashing the system or matching kernel versions, so kernel exploitation is unnecessary.

SUID binary exploitation using GTFOBins

Why it fails: This is wrong because GTFOBins provides a curated list of standard Linux binaries (like find, vim, or nft) that can be abused for privilege escalation when they have the SUID bit set or are used in certain ways. The discovered binary, however, is likely a custom or non-standard binary that relies on PATH manipulation, not a known GTFOBins entry. GTFOBins would not list this custom 'cp' substitution path, so it does not apply here.

Perform SQL injection on the database

Why it fails: Performing SQL injection on the database is not a direct consequence of SSRF. SSRF is an HTTP request forgery vulnerability where the attacker controls the URL that the server requests, not the SQL queries sent to a database. SQL injection relies on flaws in the application's query construction, typically through input fields that are interpolated into SQL statements. Even if an SSRF target service itself is vulnerable to SQLi, exploiting that requires a separate series of crafted requests and SQL payloads; the SSRF primitive alone does not execute or enable SQL injection.

Upload files to the server

Why it fails: Uploading files to the server is not an inherent capability of SSRF. SSRF lets the attacker make the vulnerable server initiate outbound HTTP(S) requests, but it does not provide a mechanism to push files onto the server's filesystem. Some SSRF implementations may allow an attacker to send a POST body or use protocols like gopher, but that still only sends data to another service, not a file upload to the vulnerable server itself. The server that is tricked into making the request is acting as a client, not as a file-upload endpoint.

Read local files using file:// protocol

Why it fails: Reading local files via file:// protocol is only possible in certain SSRF variants where the application's URL parser and network stack allow non-HTTP schemes. Many production systems explicitly whitelist http and https, so the file:// scheme is blocked, making this the exception rather than the rule. Even when file:// is allowed, it is a distinct exploitation path (often called a local file inclusion via SSRF) that requires the server's native URL handlers to support it. Meanwhile, the primary and most common SSRF scenario is to probe internal services over HTTP, not to read files from the server's disk.

Perform DLL hijacking on a system service

Why it fails: DLL hijacking exploits insecure DLL search order in a service executable, requiring write access to a directory in its search path to plant a malicious DLL and then trigger a service restart. In the AlwaysInstallElevated scenario, no such writable directory or service restart is needed—the misconfiguration already grants SYSTEM code execution via Windows Installer. Thus, it's an unrelated detour, not the direct exploitation of the policy, and it would complicate rather than simplify the escalation.

Exploit a kernel vulnerability

Why it fails: Exploiting a kernel vulnerability is a completely separate escalation path that relies on an unpatched flaw in the OS kernel, not on a policy misconfiguration. It requires a stable and reliable exploit—which is often noisy, system-specific, and risks a Blue Screen of Death—and would be overkill here. Since the AlwaysInstallElevated policy already provides a trivial and low-risk path to SYSTEM, using a kernel exploit would be both unnecessary and counterproductive for the engagement.

Modify the registry key to disable the policy

Why it fails: The AlwaysInstallElevated policy is controlled by registry keys in both HKLM\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated and HKCU\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated. To modify or disable these keys, a standard user needs write access to HKLM, which is precisely what we lack before escalation—and even if we could modify HKCU, the system-wide HKLM key would still remain. Moreover, the goal of a privilege escalation attempt is to leverage the policy to gain SYSTEM, not to remediate the misconfiguration.

Kernel exploit

Why it fails: Kernel exploits target vulnerabilities in the operating system kernel to gain elevated privileges, such as local privilege escalation via CVE-affected kernel code. However, this scenario involves a user-controlled binary with the SUID bit set and PATH environment manipulation, which are application-level weaknesses. Exploiting a kernel flaw would not depend on the presence or behavior of a specific SUID binary. Therefore, this option misidentifies the privilege escalation vector, as the evidence points to a setuid root binary, not a kernel bug.

Capability abuse

Why it fails: Linux capabilities partition root privileges into small, distinct units (e.g., CAP_SYS_ADMIN, CAP_SETUID) that can be assigned to executables via setcap. While misusing file capabilities is a valid privilege escalation technique, the scenario specifically describes a binary with the SUID bit set and PATH manipulation to hijack subprocess calls. Capability abuse would typically involve a binary with file capabilities (shown by a '+' in getcap), not the setuid root model described here. Thus, the attack path is SUID-based, not capability-based.

Cron job abuse

Why it fails: Cron job abuse occurs when an attacker can write to or modify a script or binary that is executed on a schedule by root via cron, often by exploiting writable directories or insecure PATH in the crontab. In this scenario, the tester discovered an SUID binary that invokes other programs using an unqualified path, and the attack leverages PATH manipulation at the moment the binary runs — not by tampering with cron's scheduled tasks. There is no indication of cron configuration or a scheduled job being involved. Therefore, this option describes a different persistence/privilege-escalation mechanism.

UNION-based SQLi; sqlmap

Why it fails: UNION-based SQLi returns rows from a crafted SELECT directly in the HTTP response, allowing immediate data exfiltration without any need to compare boolean or true/false application responses. The observed behavior of differing content based on injected conditions, without returned data or error messages, points to a blind form of injection. While sqlmap is capable of automating UNION-based attacks, the vulnerability type here is not UNION-based because the tester is not seeing in-band data, only conditional responses.

Time-based blind SQLi; nmap

Why it fails: Time-based blind SQLi induces deliberate database delays (e.g., SLEEP) to infer information from response latency, not from true/false content changes. nmap is a network and port scanner designed for host discovery and service enumeration, not for crafting SQL injection payloads or interpreting database responses. The scenario's 'true/false response' indicates a boolean-based blind condition, and the exploitation tool should be sqlmap, not nmap.

Error-based SQLi; Burp Suite

Why it fails: Error-based SQLi forces the database to emit verbose error messages, which the attacker then parses to extract schema or data details; it does not rely on the application responding to injected conditions with different true/false pages. Burp Suite is a general-purpose web security proxy that can intercept and manipulate requests, but it does not automatically identify or exploit SQLi without manual configuration or extensions. Because the login response varies based on a boolean condition rather than error content, this is blind SQLi, not error-based, and Burp Suite would only be an auxiliary tool.