Escalation and Exploitation practice questions

Injecting the cleartext password into the LSASS process memory of the remote database server.

Why it fails: Injecting plaintext credentials into LSASS requires interactive administrative access or specific vulnerable service states which are rarely present remotely without prior session establishment. Furthermore, handling raw cleartext increases memory artifact exposure and triggers aggressive endpoint detection rules.

Generating a golden ticket using the krbtgt hash obtained from a compromised domain controller.

Why it fails: Golden ticket generation requires the long-term secret key of the krbtgt account, which is exclusive to domain controllers. The scenario explicitly describes a compromised workstation service account rather than enterprise administrator access to the domain root.

Requesting a Kerberos service ticket for the target database using the cached NTLM hash.

Why it fails: Kerberos protocol architecture relies on cryptographic keys derived from user passwords, such as AES or RC4 keys, rather than NTLM hashes. Attempting to request a Kerberos ticket directly with an NTLM hash fails because the Key Distribution Center expects pre-authentication data encrypted with proper Kerberos keys.

Use the LFI to read /etc/shadow directly and crack the root password hash offline.

Why it fails: Standard web user privileges typically prevent reading /etc/shadow due to strict file permissions restricted to the root user. Even if successfully read, cracking modern salted hashes offline is computationally intensive and unreliable within assessment timelines.

Overwrite the cron daemon binary directly through the web application upload mechanism.

Why it fails: System binaries such as the cron daemon are protected by strict root ownership and file permissions that prevent modification by standard web application user accounts, making direct binary overwriting impossible without existing root privileges.

Modify the crontab configuration file directly using standard web user privileges.

Why it fails: System-wide crontab files located in /etc/cron.d or /etc/crontab require root privileges to modify. Standard web users cannot alter these protected system configuration files directly without an independent privilege escalation vulnerability.

The ability to read the password hashes of all group members stored in the Active Directory database.

Why it fails: GenericAll grants permission to manage the security group object itself, such as altering its membership or attributes. It does not grant domain-level replication rights like DCSync, which are required to extract password hashes from NTDS.dit.

Automatic inheritance of Domain Admin privileges due to cascading access control list permissions.

Why it fails: Active Directory permissions do not automatically cascade across unrelated security groups unless explicit hierarchical nesting is configured. GenericAll on a specific group only confers control over that specific group object.

The capability to decrypt all Kerberos ticket-granting tickets issued to members of the target group.

Why it fails: Kerberos tickets are encrypted using cryptographic keys derived from account passwords or krbtgt secrets. Modifying group membership via GenericAll does not provide access to the underlying cryptographic key material required for ticket decryption.

Golden Ticket injection

Why it fails: Golden Ticket creation requires the KRBTGT NTLM hash of the domain, not a standard user's cleartext password. While you could technically use the password to crack the KRBTGT hash if you already had it, the cleartext password alone is insufficient for forging an Active Directory Golden Ticket.

Pass-the-Hash via Mimikatz

Why it fails: Pass-the-Hash specifically utilizes the NTLM hash of a user's password rather than the cleartext password itself. While technically possible to derive the hash from the password, the methodology here is technically distinct from the direct utilization of a cleartext password for authentication mechanisms like WinRM.

Overpass-the-Hash

Why it fails: Overpass-the-Hash is a specific technique used to import a user's NTLM hash into memory to request a Kerberos TGT. Since the scenario involves a cleartext password, this is not the most direct or standard terminology for applying those credentials to remote authentication services like SMB.

/etc/shadow

Why it fails: While /etc/shadow contains sensitive password hashes, writing to it does not inherently lead to privilege escalation unless the attacker also controls the authentication mechanism. It is a target for privilege escalation through offline cracking, but not a direct execution vector like modifying system binaries or startup scripts.

/var/log/syslog

Why it fails: Writing to /var/log/syslog might allow an attacker to obfuscate their activities or fill up disk space to cause a denial of service, but it does not directly provide a mechanism for privilege escalation. Log files are generally not executable or interpreted by the system for security policy enforcement.

/usr/bin/ls

Why it fails: Writing to system binaries is generally difficult unless the file system is mounted as read-write. While replacing a binary can lead to escalation, /usr/bin/ls is rarely executed by root in a way that would trigger a privilege escalation, unlike binary files that are executed via cron.

It forces all user applications to run as an administrator.

Why it fails: This setting does not force all applications to run as administrator. It specifically affects the behavior of the Windows Installer service when processing .msi files, allowing them to be installed with elevated privileges regardless of the current user's actual permission level on the system.

It enables the installation of unsigned drivers.

Why it fails: Driver signature enforcement is a different security mechanism managed by Secure Boot and specific code signing policies. AlwaysInstallElevated is strictly related to the MSI installer service and does not affect the system's ability to load or install kernel-mode drivers, which requires different system-wide security settings.

It bypasses User Account Control (UAC) for all tasks.

Why it fails: UAC is a broader feature that prompts for consent when administrative actions are taken. While AlwaysInstallElevated bypasses the need for authorization during MSI installs, it does not globally disable UAC for other system tasks, files, or processes that are not related to the Microsoft Installer service.

The service binary is located in a protected directory.

Why it fails: If the binary is in a protected directory, the attacker likely lacks write permissions to the path segments, making exploitation difficult. The vulnerability depends on the attacker's ability to write to the path segment, which is usually only possible in less secure directory structures.

The service uses a remote network share.

Why it fails: Services running from remote network shares are a different configuration issue involving network security and credentials, not an unquoted service path vulnerability. This setup is generally discouraged for performance and security reasons but does not lead to this specific type of local privilege escalation.

The payload uses staged delivery, where a small stager downloads the full Meterpreter DLL into memory after connecting back.

Why it fails: Staged delivery reduces the initial payload size and loads the main Meterpreter DLL in memory, which helps evade some detection and size limits. It does not, however, provide persistence across reboots or automatic reconnection after network loss. The requirement here is resilience and encrypted control, so staged versus stageless delivery is not the deciding characteristic.

The payload executes a single command and exits immediately, returning only the command output to the tester.

Why it fails: A single-command payload that exits provides no interactive session, no encryption layer, and no reconnection logic. It is useful for quick, one-shot execution but cannot sustain command and control across an unstable link. This directly contradicts the requirement for a reliable, encrypted channel that survives intermittent connectivity.

The payload is a bind shell that listens on a chosen port and accepts a single inbound connection from the tester.

Why it fails: A bind shell waits for the tester to connect inbound, which is fragile behind NAT and firewalls and typically accepts only one connection. When that connection drops, the listener may be gone and no automatic reconnection occurs. It also lacks the encrypted transport and process migration that make Meterpreter sessions resilient.

Modify the service's registry key to point to a malicious executable and restart the service.

Why it fails: Modifying the service's registry key requires administrative privileges, which you do not have as webuser. The service configuration is stored in HKLM\SYSTEM\CurrentControlSet\Services, which is protected. Without write access to that registry hive, you cannot change the binary path. This method would require prior privilege escalation, making it unsuitable for this scenario.

Create a new service with the same name using sc.exe create.

Why it fails: Creating a new service with the same name is not possible because a service with that name already exists. The sc.exe create command would fail with an error indicating the service already exists. Even if you could, you would need administrative privileges to create a service, which you do not have. This approach does not leverage the existing misconfiguration and is not a viable escalation path.

Use the unquoted service path vulnerability by placing a malicious executable in C:\Program Files\Apache Group\Apache2\bin.

Why it fails: The service path is properly quoted as 'C:\Program Files\Apache Group\Apache2\bin\httpd.exe', so the unquoted service path vulnerability does not apply. Windows will correctly resolve the full path and not search for alternative executables. Placing a file in the bin directory would not cause it to be executed because the path is unambiguous. This technique is ineffective here.

Load a vulnerable signed driver to execute kernel code and disable token checks

Why it fails: Loading a kernel driver requires administrative rights and typically test-signing or a vulnerable driver already present, and it does not rely on SeImpersonatePrivilege. This is a separate BYOVD escalation class. It is not a valid use of the impersonation privilege described and would generally fail without prior elevation.

Enable the built-in Administrator account by writing to the SAM registry hive directly from the service context

Why it fails: Writing to the SAM hive requires administrative rights or backup privileges that bypass ACLs; SeImpersonatePrivilege alone does not grant registry write access to protected hives. Attempting this from a service account will be denied. The privilege is about impersonating tokens, not modifying account databases, so this is not a valid path here.

Invoke a named pipe impersonation attack against the LSASS process to duplicate its token

Why it fails: Named pipe impersonation is the mechanism underlying the Potato family, but directly targeting LSASS requires SeDebugPrivilege to open the process. A service account with only SeImpersonatePrivilege cannot open LSASS. The valid techniques coerce a privileged service to connect to the attacker's pipe rather than opening a protected process directly.

Use the Sweet Potato exploit to combine Juicy Potato and PrintSpoofer techniques.

Why it fails: Sweet Potato is a variant that combines techniques, but it is not a standard term in the same way as Rotten Potato. The question expects knowledge of the primary exploit associated with SeImpersonatePrivilege. Rotten Potato is the foundational exploit. Sweet Potato is less commonly referenced and may not be the expected answer. This option is less precise and not the most direct technique.

Use the Juicy Potato exploit to relay NTLM authentication to an external server.

Why it fails: Juicy Potato is an evolution of Rotten Potato that allows specifying a CLSID to abuse DCOM, but it still requires SeImpersonatePrivilege. However, relaying NTLM authentication to an external server is not the primary purpose; it's about local token impersonation. The description of relaying to an external server is inaccurate for Juicy Potato. This option misrepresents the technique.

Use the PrintSpoofer exploit to abuse the SeImpersonatePrivilege by coercing the Print Spooler service.

Why it fails: PrintSpoofer is a technique that also abuses SeImpersonatePrivilege, specifically by coercing the Print Spooler service to authenticate and then impersonating its token. While it is a valid method, it is not the only one. The question asks for a technique, and Rotten Potato is a classic and widely recognized method. However, PrintSpoofer is also correct in principle, but in the context of multiple choice, Rotten Potato is the most direct and well-known answer. The option is not the best answer because it specifies a particular service, whereas Rotten Potato is more general.

Add the current user to /etc/sudoers using a writable /etc/sudoers.d drop-in file.

Why it fails: This would work only if /etc/sudoers or a drop-in directory were writable by the low-privileged user, which is not stated. NOPASSWD entries are a separate escalation path, and the scenario supplies docker group membership instead. Suggesting sudoers modification invents a precondition and misidentifies the actual attack surface presented.

Inspect /var/run/docker.sock permissions and, if world-writable, use curl to pull a privileged image.

Why it fails: The socket permission check is a valid enumeration step, but the question states the user already belongs to the docker group, so access to docker.sock is already granted. Recommending a conditional check and image pull does not describe the escalation primitive of mounting the host filesystem, and it adds unnecessary verification that the scenario already resolves.

Exploit a known kernel vulnerability in the host's Linux kernel version to obtain a root shell.

Why it fails: Kernel exploitation is possible but is not the most direct method here, and it risks crashing the host. The docker group already provides a documented, reliable escalation path that does not depend on an unpatched CVE. Choosing kernel exploitation ignores the simpler intended weakness and unnecessarily raises the operational risk of the engagement.

Abuse the SeBackupPrivilege to read the SAM and SYSTEM registry hives and extract local account hashes.

Why it fails: SeBackupPrivilege is not the privilege stated in the scenario, and its abuse yields copied registry hives for offline hash extraction rather than an interactive SYSTEM shell. Even where it exists, it is a different primitive and does not leverage SeImpersonatePrivilege. Selecting it misreads the enumerated privilege and targets a different escalation objective.

Deploy PrintSpoofer against the Spooler service to capture a SYSTEM token over a named pipe.

Why it fails: PrintSpoofer also abuses SeImpersonatePrivilege, but it specifically requires the Print Spooler service to be running and reachable. On a hardened Server 2019 host the Spooler may be disabled, and the scenario does not confirm it. Because the stem asks for the most appropriate techniques given only the privilege and build, relying on an unverified service is a weaker choice.

Use the SeTcbPrivilege to add your account to the local Administrators group directly.

Why it fails: SeTcbPrivilege, known as Act as part of the operating system, is not the assigned privilege, and it does not by itself grant the ability to modify group membership. Claiming it enables direct Administrators addition misstates the privilege semantics. The scenario provides SeImpersonatePrivilege, so options built on a different token privilege are inapplicable here.

Point the parameter at /proc/self/environ and inject code through the User-Agent header.

Why it fails: The /proc/self/environ technique depends on the web server process environment being readable and on the injected header being reflected into it, which is uncommon on modern hardened servers. It also frequently fails due to permissions or process ownership. Because it is environment-dependent and widely mitigated, it is a less dependable conversion than a filter chain.

Set the parameter to a data:// URI containing the PHP payload.

Why it fails: The data:// wrapper requires allow_url_include to be enabled, and many production PHP configurations disable it by default. When that setting is off, the include() call rejects the wrapper and no code executes. Because the scenario does not confirm the configuration, relying on data:// is less reliable than a technique that does not depend on that directive.

Use php://input to supply the payload in the request body.

Why it fails: php://input reads the raw request body, but include() will only treat it as PHP source when allow_url_include is enabled, the same dependency that undermines data://. It also fails for POST-less requests and cannot reference files. Choosing it assumes a configuration the scenario does not establish, so it is not the most reliable path.

Querying the root certificate store via PowerShell to check for untrusted root certification authorities.

Why it fails: The root certificate store holds trusted CAs, not file ACLs or service path strings, so it cannot reveal privilege escalation vectors. It is tempting because certificate enumeration is a legitimate hardening check, but it addresses trust configuration rather than the insecure permissions or unquoted service paths the task requires.

Inspecting the local security policy database using the auditpol utility to check account lockout thresholds.

Why it fails: Auditpol configures audit policy and account lockout thresholds, which govern logging and authentication behaviour, not filesystem ACLs or service binary paths. It is tempting as a local security enumeration step, but it would be the right choice for auditing policy compliance, not for finding privilege escalation vectors.

Reviewing the Active Directory group policy object inheritance tree using the Resultant Set of Policy tool.

Why it fails: Group Policy inheritance determines domain-wide settings, not the local file ACLs or unquoted service paths on this workstation. It is tempting because RSoP reveals security configuration, but it would be correct when troubleshooting domain policy application, not enumerating local privilege escalation vectors.

Overflow the buffer of the binary.

Why it fails: Buffer overflows are a complex exploit vector that requires finding a vulnerability in the source code of the binary. While possible, it is significantly more difficult and time-consuming than leveraging an insecure PATH dependency, which is a design flaw that is easily exploited by changing environmental variables.

Use LD_PRELOAD to inject a shared object.

Why it fails: LD_PRELOAD is a technique for library injection, but most modern SUID binaries are designed to ignore environmental variables like LD_PRELOAD for security reasons. Relying on this is unreliable on patched systems, whereas PATH manipulation targets the logic of the application rather than the dynamic linker settings.

Inject arguments into the binary.

Why it fails: Injecting arguments into a binary only works if the binary is poorly written and passes the input to a shell without sanitization. While this is an injection vulnerability, it is distinct from the PATH dependency issue, which is specifically concerned with how binaries resolve the location of commands.

Database backup functionality

Why it fails: Backups are useful for exfiltration of data, but they do not provide a direct vector for command execution. While one could theoretically restore a malicious backup to overwrite files, this is not the standard or most efficient method for achieving RCE during an active penetration test engagement.

Database triggers on update

Why it fails: Triggers can be used for persistence or modifying data upon events, but they do not inherently provide the ability to execute OS commands. They run within the database context, meaning they are limited to SQL operations and cannot escape the database engine to interact with the OS.

Database user enumeration

Why it fails: Enumerating database users is a reconnaissance activity that provides information about the environment, but it is not a mechanism for achieving code execution. It helps in understanding the level of access but does not inherently grant the ability to execute arbitrary commands on the host server.

To document all vulnerabilities found.

Why it fails: Documentation is a critical phase of the report generation, but it is not the primary activity during exploitation. While you should record your findings, the exploitation phase focuses on the technical demonstration of control over the target system or data, which is distinct from the reporting process.

To scan the entire network for open ports.

Why it fails: Scanning for open ports is part of the reconnaissance or vulnerability assessment phase. It provides the necessary data to identify potential targets, but it is not the exploitation phase itself. Exploitation happens after you have identified a target and chosen a specific exploit to attempt.

To patch the vulnerabilities identified.

Why it fails: Patching is the responsibility of the client's IT department after the penetration test is complete. A penetration tester should never attempt to patch or alter system configurations in a way that could cause instability or disrupt production services, unless explicitly authorized in the Rules of Engagement.

Immediately drop a reverse shell.

Why it fails: Dropping a reverse shell as SYSTEM immediately could trigger defensive alerts and potentially crash the service if not carefully crafted. Safe penetration testing requires verifying the vulnerability with a non-disruptive payload first, ensuring that the service remains operational for the client throughout the testing engagement.

Reboot the server to force the service to restart.

Why it fails: Rebooting a server during a penetration test is highly disruptive and violates most Rules of Engagement. Testers should aim to test vulnerabilities in a way that minimizes impact on system availability. You should wait for a natural restart or use service control commands if permitted.

Modify the Windows Registry to disable the service.

Why it fails: Disabling a service is a destructive action that negatively impacts system availability. As a penetration tester, your goal is to assess security, not to cause denial-of-service conditions. You must always prioritize system stability and follow the Rules of Engagement regarding the impact of your testing activities.

It requires the user to have administrative credentials.

Why it fails: Kernel exploits are specifically used to obtain administrative or SYSTEM privileges from a low-privileged state. If you already had administrative credentials, you would not need a kernel exploit to escalate your privileges. The exploit itself targets vulnerabilities in kernel-mode drivers or the operating system kernel.

It is easily detected by standard antivirus software.

Why it fails: While kernel exploits are often detected by modern EDRs, the primary risk is not detection, but system instability. Antivirus detection is a concern for any exploit, but the unique danger of kernel-level testing is the potential for unplanned downtime that cannot be easily reversed without a reboot.

It can only be executed on outdated operating systems.

Why it fails: While kernel exploits are more common on legacy systems, they are still found in modern OS kernels. The difficulty of writing them does not change the fact that they are inherently risky. Regardless of the system's age, the impact of a crash remains a critical concern for testers.