Hard Difficulty Questions

Hashcat with mode 1000 and a mask attack targeting eight-character passwords.

Why it fails: Hashcat mode 1000 is for NTLM (the raw hash), not NetNTLMv2. Using the wrong mode will result in failure to crack because the hash format is incompatible. A mask attack targeting eight characters is also inefficient for NetNTLMv2, which requires a challenge and response. The correct mode is 5600, and a wordlist with rules is more effective than a blanket mask attack for typical password policies.

John the Ripper with `--format=netntlmv2` and the `--incremental` mode.

Why it fails: John the Ripper does support NetNTLMv2 via the `netntlmv2` format, but the `--incremental` mode performs a brute-force attack that is extremely slow and unlikely to succeed for complex passwords. For efficiency, a wordlist with rules is preferred. Additionally, Hashcat is generally faster for this hash type due to better GPU optimization. While John can crack NetNTLMv2, it is not the most efficient choice in this scenario.

Use `responder` to relay the hash to another host and gain access without cracking.

Why it fails: Responder is used to capture NetNTLMv2 hashes, not to crack them. Relaying the hash to another host (SMB relay) can yield access without cracking, but the scenario asks specifically to crack the hash offline to recover the plaintext password. Relaying does not recover the password; it only allows authentication to a different service if the conditions are right. Therefore, this does not meet the requirement of offline cracking.

Use the GenericAll permission to perform a targeted Kerberoasting attack by setting an SPN on a user account you control, then request a service ticket.

Why it fails: GenericAll over a computer object does not grant the right to modify user objects. Targeted Kerberoasting requires write permissions over a user account to set an SPN. This option misinterprets the scope of the permission; the GenericAll is on WEB01, not on a user, so this action is not possible with the given access.

Perform a Kerberoasting attack against the machine account of WEB01 to obtain its hash and then crack it offline.

Why it fails: Machine accounts have complex, automatically rotated passwords, making offline cracking infeasible. Kerberoasting targets accounts with Service Principal Names (SPNs) and requests a service ticket, but the resulting hash is for the service account, not the machine account itself. This approach would not yield usable credentials for WEB01 in a reasonable timeframe.

Use the GenericAll permission to perform a resource-based constrained delegation attack by modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

Why it fails: Resource-based constrained delegation (RBCD) is a valid technique, but it requires creating or controlling a computer account and configuring it to impersonate users to WEB01. While GenericAll on WEB01 allows setting the attribute, this is a multi-step process that also requires a controlled account with an SPN. It is less direct than other options.

Input processed by a backend database stored procedure for primary key generation

Why it fails: Database stored procedures generating primary keys never emit their output into HTML, attribute, or script contexts, so injected characters cannot reach a browser parser. It is tempting because stored procedures are a recognised injection surface, but that concerns SQL injection, where parameterised calls and least-privilege execution — not XSS context analysis — are the correct controls.

Input stored as an encrypted binary blob inside the browser local session storage

Why it fails: Data stored as encrypted binary blobs in local storage is treated as static data structures by the client application. It does not get evaluated or parsed as active HTML markup unless explicitly decoded and rendered by the application DOM.

Input utilized as a parameter value inside a server-side JSON response header without content-type sniffing

Why it fails: JSON responses with proper application/json content-type headers are parsed as data objects by modern browsers rather than executed as HTML markup. Without explicit DOM rendering of the JSON values into the page, script execution cannot occur.

Netcat is not capable of receiving reverse shells and a different listener is required.

Why it fails: Netcat is a standard and fully capable listener for reverse TCP shells, so the tool itself is not the limitation. Blaming netcat overlooks the far more common causes such as firewall filtering or an unreachable callback address, and switching listeners would not fix a blocked network path.

The exploit's buffer overflow offset is incorrect, so the payload never reaches the instruction pointer.

Why it fails: An incorrect offset would typically crash the service or produce no success indication at all, because execution would not transfer to the payload. Since the service reports success and the exploit completes, the trigger likely worked; the missing piece is the network callback rather than the memory corruption step.

The exploit was run without administrative privileges on the attacker machine, preventing the listener from binding.

Why it fails: Binding a high-numbered listener port does not require administrative privileges on the attacker machine, and a failed bind would produce a visible error rather than silence. This explanation misidentifies where the failure occurs, since the listener started successfully and the missing element is the target's outbound connection.

The application is completely immune to Cross-Site Scripting because a Content Security Policy is strictly enforced

Why it fails: The policy includes 'unsafe-inline' in script-src, which permits inline <script> blocks such as the token assignment, so injected inline script executes. A strict policy without 'unsafe-inline' or nonces would block it; here the directive is deliberately weakened, leaving reflected or stored XSS viable.

The server is vulnerable to remote code execution because the nginx version header is explicitly exposed

Why it fails: Exposing the server software version header reveals information for reconnaissance but does not grant remote code execution or relate to client-side CSP configurations. Version disclosure is an informational finding rather than a direct execution vulnerability.

The session token is vulnerable to interception because the response is transmitted over unencrypted HTTP

Why it fails: While the snippet shows HTTP/1.1, the exhibit does not provide transport layer security details, and the core vulnerability highlighted is the CSP directive. The primary security misconfiguration in the exhibit is the allowance of unsafe inline script execution.

The application reflects user input into the HTML body, allowing for XSS.

Why it fails: Reflecting input into the HTML body is the definition of reflected XSS. While this can lead to phishing, it is distinct from an open redirect, which specifically involves manipulating the redirection logic of an application rather than injecting scripts into the document context.

The application fails to set the Secure flag on cookies during redirection.

Why it fails: Failing to set the Secure flag is a session management issue, not an open redirect vulnerability. While session security is critical, it does not involve the redirection logic or the potential for social engineering through deceptive URLs that redirect to external, malicious domains.

The application allows arbitrary file uploads to the server's redirect directory.

Why it fails: Arbitrary file upload is a separate vulnerability that can lead to remote code execution. It is fundamentally different from open redirect, which is a logic flaw in handling URL parameters for redirection. Redirect directories are usually virtual paths controlled by application logic, not physical storage locations.

Modifying the client-side JavaScript validation function in the browser developer tools to allow PHP file extensions before submission

Why it fails: Client-side validation runs entirely within the user's browser and can be completely bypassed by sending HTTP requests directly via a proxy tool, making modifications to the local JavaScript code unnecessary for achieving a successful bypass.

Modifying the Content-Type header in the HTTP request from application/octet-stream to text/plain to satisfy server-side MIME type checks

Why it fails: Altering the Content-Type header alone rarely bypasses robust server-side file type verification, as modern backend applications inspect the actual file magic bytes or binary structure rather than trusting the browser-supplied MIME header.

Disabling JavaScript completely in your browser settings to prevent the upload form from performing any input sanitization

Why it fails: Disabling JavaScript only prevents client-side checks from executing. If the server does not perform independent server-side validation, the upload might succeed, but simply disabling JavaScript does not actively bypass extension blacklists enforced by the backend.

The task must have a trigger set to 'At log on' for any user on the system.

Why it fails: While a 'log on' trigger is a common way for a task to start, it is not a requirement for exploitation. Tasks can be triggered by schedules, system events, or even manually by the user if permissions allow. The trigger only determines when the exploit occurs, not whether the escalation itself is fundamentally possible.

The 'Hidden' attribute must be enabled in the task settings to bypass Windows Defender detection.

Why it fails: The 'Hidden' attribute in a scheduled task merely hides the task from the basic UI view in Task Scheduler; it provides no actual security bypass or privilege escalation capability. Windows Defender and other security tools monitor process execution and file integrity regardless of whether the task is marked as hidden in the interface.

The task must be part of the default Windows installation rather than a third-party application.

Why it fails: Actually, third-party tasks are often more vulnerable because they are frequently installed with weak file permissions or unquoted paths. Default Windows tasks are generally well-secured and their binaries are protected by TrustedInstaller. Most successful escalations during the OSCP exam involve misconfigured third-party software rather than native Windows components.

Supplying a crafted format string as an argument to the binary to overwrite the Global Offset Table and hijack execution flow.

Why it fails: Format string vulnerabilities require explicit vulnerable printf-family functions that accept user-controlled format specifiers. The ltrace output shows a hardcoded string argument passed to system(), which prevents standard format string exploitation.

Injecting arbitrary shell metacharacters such as semicolons directly into the system log file to break out of the tail command.

Why it fails: The tail command reads the log file rather than interpreting its contents as shell commands. Unless the binary accepts user input and concatenates it directly into the system() argument string, log injection will not trigger execution.

Triggering a buffer overflow by supplying an excessively long filename as an argument to the check_logs binary execution.

Why it fails: Modern Linux systems incorporate stack protection mechanisms and ASLR. Without evidence of vulnerable functions like strcpy or gets parsing unbounded user input, assuming a standard buffer overflow exists is incorrect.

hashcat -a 1 -r rules/combinator.rule wordlist1.txt wordlist2.txt hashes.txt

Why it fails: Attack mode 1 represents the combinator attack, which merges words from two separate files rather than applying rule-based mutations to a single wordlist. Furthermore, combinator.rule is not a standard mutation ruleset designed for single-wordlist transformations.

hashcat -a 3 -r rules/T1048.rule mask.hcmask hashes.txt

Why it fails: Attack mode 3 relies on masks rather than wordlists, making rule files largely redundant or incompatible depending on the exact mask configuration applied. Additionally, T1048 is not a standard rule file distributed natively within the official Hashcat package.

hashcat -a 6 -r rules/leetspeak.rule wordlist.txt mask.hcmask hashes.txt

Why it fails: Attack mode 6 combines hybrid wordlist and mask operations, and while leetspeak transformations exist, they require specific rule syntax rather than arbitrary filenames that may not exist in the default rules directory.

The exploit's payload encoding settings.

Why it fails: Payload encoding affects how data is transmitted to bypass filters, not the initial network connection. If you cannot connect to the port, the payload never reaches the service. You must verify connectivity before worrying about payload-specific issues like encoding or bypassing security controls.

The exploit's memory address offsets.

Why it fails: Memory offsets are only relevant after you have successfully connected to the service and started the exploitation process. A network-level error indicates that the connection has not even been established, making memory address issues irrelevant until the underlying connectivity problem is resolved.

The target's operating system version.

Why it fails: While the OS version is important, it is not the immediate cause of a 'Connection refused' error. This error is specific to network communication. You should first focus on port status and service availability before diving into environmental differences like the specific OS running on the target.

reg copy HKLM\SAM C:\Temp\SAM.hiv and reg copy HKLM\SYSTEM C:\Temp\SYSTEM.hiv; SeBackupPrivilege must be explicitly enabled using whoami /priv before these commands will work.

Why it fails: `reg copy` copies a registry key to another location within the registry, not to a file. It cannot be used to export hives to disk. Additionally, SeBackupPrivilege is enabled by default for accounts that have it, though it may require elevation. The command syntax is entirely wrong for extracting hives. The correct command is `reg save`, which writes the hive to a file.

reg export HKLM\SAM C:\Temp\SAM.reg and reg export HKLM\SYSTEM C:\Temp\SYSTEM.reg; SeBackupPrivilege is not needed because these keys are world-readable.

Why it fails: `reg export` exports keys to a .reg text file, but it does not use the backup privilege and requires the user to have read access to the registry keys. The SAM and SYSTEM hives are not world-readable; by default, only administrators have access. Without SeBackupPrivilege, this command would fail with access denied. Additionally, .reg files are not suitable for direct hash extraction as they are text-based and do not preserve binary data in the same way as hive files.

reg save HKLM\SAM C:\Temp\SAM.hiv and reg save HKLM\SYSTEM C:\Temp\SYSTEM.hiv; SeBackupPrivilege is irrelevant because the reg command always runs with SYSTEM privileges.

Why it fails: The `reg` command runs with the privileges of the calling user, not automatically as SYSTEM. SeBackupPrivilege is exactly what allows a non-administrator to save these hives. Without it, the command would fail with access denied. The statement that reg always runs as SYSTEM is incorrect and could lead an attacker to attempt the command without the necessary privilege, resulting in failure.

Configure a Service Principal Name on the controlled computer object for the target file share service (cifs/target).

Why it fails: SPNs are used for Kerberoasting and for constrained delegation targeting, not for unconstrained delegation. Setting an SPN on the controlled computer does not cause the DC to forward TGTs to it. This step is irrelevant to enabling unconstrained delegation and would not contribute to capturing a privileged user's credentials.

Modify the msDS-AllowedToDelegateTo attribute on the controlled computer to include the target server's CIFS service.

Why it fails: msDS-AllowedToDelegateTo is used for constrained delegation, which restricts delegation to specific services. Unconstrained delegation does not use this attribute; it relies on the TRUSTED_FOR_DELEGATION flag. Configuring this attribute would set up a different delegation model and does not enable the TGT capture that unconstrained delegation provides.

Add the controlled computer to the Protected Users group to ensure delegation tokens are cached securely.

Why it fails: The Protected Users group prevents delegation and blocks caching of credentials that would otherwise be exposed. Adding a computer to this group would actively hinder the attack by preventing TGT caching. It is a security control, not a step in enabling or exploiting unconstrained delegation.

The compromised host will listen on port 9001 and forward connections to attacker.com.

Why it fails: This reverses the direction. In remote port forwarding (-R), the listening socket is created on the SSH server side (attacker.com), not on the SSH client side (compromised host). The compromised host initiates the SSH connection and forwards traffic from the server to the target, but it does not listen on port 9001.

This setup requires the attacker to run a separate listener on port 9001.

Why it fails: No separate listener is needed because the SSH server itself creates the listening socket on port 9001 as part of the remote forward. The attacker simply connects to localhost:9001 after the SSH connection is established. Running an additional listener would conflict with the SSH-created socket and cause a bind error.

The compromised host must have a public IP address for this to work.

Why it fails: The compromised host does not need a public IP; it only needs outbound SSH connectivity to attacker.com. The SSH connection is initiated from the compromised host, so NAT and firewalls on the compromised network typically allow it. The public IP requirement applies to the SSH server if it is to be reachable, but not to the client.

ssh -L 1080:10.0.0.5:22 user@192.168.1.100

Why it fails: This command creates a local port forward from local port 1080 to the internal server's SSH port. It only allows access to that single service, not a full SOCKS proxy. While it could be used to SSH to the internal server via localhost:1080, it does not provide a generic proxy for scanning multiple hosts or ports, which is the requirement here.

ssh -D 1080 user@10.0.0.5

Why it fails: This attempts to connect directly to the internal server at 10.0.0.5, which is not reachable from your attacking machine without a pivot. The dynamic forward would be established on the internal server, but you cannot reach it to initiate the connection. The correct target for the SSH connection is the compromised dual-homed host, not the internal server.

ssh -R 1080 user@192.168.1.100

Why it fails: The -R flag sets up a remote port forward, which would forward a port on the remote host back to your local machine. That is the opposite of what is needed; you want to create a proxy on your local machine to reach the internal network. Additionally, the syntax is incomplete as it lacks a destination address and port.

Add the /DYNAMICBASE:NO linker flag so the loader's base address does not change between runs.

Why it fails: Disabling ASLR changes where the loader itself is mapped, but it does not affect whether ntdll.dll is hooked. The EDR hooks are placed in ntdll regardless of the loader's base address, and the loader still calls the hooked functions. This flag is sometimes used for exploit reliability, but it has no bearing on bypassing user-mode API hooks, so the block would still occur.

Replace the calls to VirtualAllocEx and CreateRemoteThread with their NtAllocateVirtualMemory and NtCreateThreadEx equivalents from ntdll.dll.

Why it fails: The Nt-prefixed functions in ntdll.dll are precisely where user-mode EDR hooks are placed. Switching from the kernel32 wrappers to the ntdll versions does not bypass the hooks because the hook resides in ntdll itself. The EDR intercepts the call before it reaches the kernel, so the block still occurs. The tester must avoid the hooked ntdll code path entirely, not just call a lower-level wrapper.

Call VirtualProtect on the ntdll.dll .text section to restore the original bytes before invoking the API.

Why it fails: Restoring ntdll's original bytes would unhook the API, but it requires writing to a protected system DLL region, which EDR products monitor closely and often block outright. It also affects all processes sharing that image, creating side effects. While the concept of unhooking is valid, the described method is fragile and likely to be flagged; the cleaner approach is to avoid the hooked code path entirely rather than tamper with a system DLL.

Metasploit's psexec module with SMBPass set to the hash

Why it fails: Metasploit's psexec module can use pass-the-hash, but it requires setting both SMBUser and SMBPass, where SMBPass is the hash. However, the module often expects the hash in a specific format and may require additional configuration. It is possible, but not as straightforward as the other tools. In the context of this question, the most direct and commonly used tools are Impacket and CrackMapExec. Thus, this option is less correct than the others.

Hydra with the -p option

Why it fails: Hydra is a password cracking tool that performs online brute-force attacks. It does not support pass-the-hash authentication. The -p option is used to specify a password or a list of passwords, not a hash. Hydra cannot use NTLM hashes for authentication. Therefore, this option is incorrect.

Nmap with the smb-psexec script

Why it fails: Nmap's smb-psexec script is used for executing commands via SMB but does not support pass-the-hash authentication. It typically requires plaintext credentials or a valid session. It cannot use an NTLM hash directly. Therefore, this option is incorrect.

Disable Windows Defender real-time protection by modifying the registry before executing the payload.

Why it fails: Modifying Defender registry keys requires elevated privileges and generates high-severity alerts in most EDR deployments, often triggering immediate response before the payload ever runs. The scenario specifies an EDR that is separate from Defender and performs behavioral monitoring, so tampering with Defender settings does not address the EDR at all. This approach increases visibility rather than reducing it.

Rename the payload executable to svchost.exe and place it in the user's temp directory.

Why it fails: Renaming a file does not change its contents, so static scanning still matches the payload bytes on disk. The behavioral layer also observes the actual behavior of the process regardless of its filename; invoking a binary named svchost.exe from a temp directory is itself a suspicious indicator that EDR products flag. This technique neither defeats static scanning nor reduces behavioral detection, making it ineffective here.

Compress the payload with UPX and deliver it as a self-extracting archive.

Why it fails: UPX is a well-known packer, and EDR and antivirus engines routinely unpack UPX-compressed binaries before scanning, so the original payload bytes are still analyzed. Self-extracting archives add another executable stage that behavioral monitoring can flag. Compression does not remove the static signature and does not change the runtime behavior that the EDR observes, so it does not address either control described in the scenario.

copy C:\Windows\System32\config\SAM C:\Temp\sam.hiv

Why it fails: The SAM file is locked by the operating system and cannot be copied directly with standard copy even with SeBackupPrivilege, because the privilege is not automatically applied to file copy operations. You need a tool that uses backup semantics, like reg save or robocopy with /b.

robocopy /b C:\Windows\System32\config C:\Temp SAM

Why it fails: robocopy with /b uses backup mode, which can copy locked files if you have SeBackupPrivilege. However, the syntax here is incorrect: it would copy the entire config folder, and the destination would be a directory, not a file. Also, robocopy may not handle registry hives perfectly for later parsing.

esentutl /y C:\Windows\System32\config\SAM /d C:\Temp\sam.hiv

Why it fails: esentutl is used for ESE database files, not registry hives. While it can copy locked files, it is not the correct tool for SAM extraction. The /y and /d switches are not valid for this purpose. Using reg save is the standard method.

Use a malicious .lnk file that executes a PowerShell one-liner when double-clicked.

Why it fails: A .lnk file is not a document that Office opens; it requires the user to double-click a shortcut, which is a different attack vector. The scenario specifies opening a weaponized document, implying an Office file. While .lnk attacks are effective, they do not fit the context of macro-disabled Office documents.

Use a malicious Excel 4.0 (XLM) macro embedded in a .xlsm file.

Why it fails: Excel 4.0 macros are also blocked by the same Group Policy that disables VBA macros in Office 2016, because the policy applies to macro execution broadly. While XLM macros can sometimes bypass older defenses, modern Group Policy settings and Office updates specifically address them. This technique is unlikely to succeed under the stated restrictions.

Deliver a malicious .docm file with a VBA macro that uses AutoOpen().

Why it fails: The AutoOpen() macro is a VBA macro, and the Group Policy explicitly disables macro execution. Even if the user enables content, the policy prevents the macro from running. This approach directly violates the stated restriction and will fail.