Windows Privilege Escalation practice questions

Directly modify the kernel memory to escalate the current process.

Why it fails: Modifying kernel memory is an extremely complex and dangerous task that could crash the system. AlwaysInstallElevated is a high-level configuration flaw that does not require kernel-level manipulation to exploit. Using such an approach is unnecessary and significantly increases the risk of detection or system instability.

Delete the HKLM registry key to disable the elevation.

Why it fails: Deleting the registry key would remove the vulnerability, which is the opposite of the goal. The objective of privilege escalation is to leverage existing misconfigurations to gain access, not to perform system remediation or clean up the environment for the target system administrators.

Use the 'runas' command to switch to the SYSTEM user.

Why it fails: The 'runas' command requires knowledge of the target user's password. Since you are performing privilege escalation, you do not have the credentials for the SYSTEM account. AlwaysInstallElevated allows you to run code as SYSTEM without needing a password, rendering the 'runas' command irrelevant for this specific exploitation vector.

Windows Defender

Why it fails: Windows Defender is an anti-malware solution, not a credential storage system. While it monitors system activity, it does not hold user passwords in a way that allows for easy retrieval by a local user for the purpose of privilege escalation.

BitLocker

Why it fails: BitLocker is a disk encryption feature designed to protect data at rest. It does not store user passwords for services or applications in a format that would facilitate privilege escalation for an attacker who has already gained access to the system.

Group Policy

Why it fails: Group Policy is a management framework for configuring Windows settings. While it can be misconfigured to grant privileges, it is not a credential storage feature. It does not provide a mechanism for retrieving user passwords that would lead to immediate privilege escalation in the manner described.

The task is configured to start only when the user logs on.

Why it fails: A task that only runs on user login is less useful for privilege escalation because it depends on a specific user action. Furthermore, it often runs in the context of the logged-in user rather than as SYSTEM, making it a less reliable path for gaining administrative access.

The task's trigger is set to 'OnIdle'.

Why it fails: The trigger type (OnIdle, At, Daily) does not directly affect the security of the task itself. While it dictates when the task runs, it is not an indicator of a privilege escalation vulnerability. The core risk lies in who the task runs as and what it executes.

The service will fail to start.

Why it fails: While an attacker could delete the binary, the risk is not that the service fails to start, but that it starts with malicious code. The primary concern is security, not system availability. Full control allows for complete system compromise, which is much more critical than a service failure.

The service will become visible to all users.

Why it fails: Service visibility in the Windows Service manager is not controlled by folder permissions. While permissions affect the integrity of the files, they do not change how the service is displayed to the users. This is not the primary risk of the described misconfiguration.

Only an administrator can fix this issue.

Why it fails: While administrators are responsible for fixing such issues, any user who identifies this vulnerability can exploit it to become an administrator. The focus for a penetration tester is on the exploitability of the system, not on the remediation capabilities of the administrative staff.

Using 'net user' to list all local users.

Why it fails: The 'net user' command is useful for identifying existing accounts but does not provide information about service configurations. While finding a user with local admin rights is useful, it is not a direct way to gather information about vulnerable services.

Reading the 'C:\Windows\System32\drivers\etc\hosts' file.

Why it fails: The hosts file is used to map hostnames to IP addresses. It has nothing to do with service enumeration or privilege escalation. While it can reveal information about internal network infrastructure, it is irrelevant for identifying misconfigured services or binary vulnerabilities.

Checking the 'C:\Windows\System32\config' folder for SAM files.

Why it fails: Accessing the SAM file directly is not possible without elevated privileges and specific tools. Furthermore, it is not a method for enumerating services. While it might be a goal to extract hashes, it is not a technique for gathering info about vulnerable services.

C:\Windows\System32\service.exe

Why it fails: This path does not contain any spaces. Therefore, the Windows Service Control Manager will correctly identify the executable without ambiguity. Without spaces, the service manager does not need to guess where the executable resides, making it immune to unquoted path exploitation.

C:\"Program Files"\App\service.exe

Why it fails: This path is correctly quoted. The inclusion of double quotes around the path components instructs the operating system to treat the entire string as the executable location, preventing it from misinterpreting the spaces as delimiters for command-line arguments.

C:\bin\service.exe

Why it fails: This path does not contain spaces. As there are no spaces to be misinterpreted by the service manager as argument delimiters, the service is not vulnerable to the unquoted service path exploit, regardless of the folder structure or binary permissions.

Perform a Kerberoasting attack against the domain controller to request service tickets encrypted with weak keys.

Why it fails: Kerberoasting targets service principal names associated with standard user accounts to crack service tickets offline. It requires valid domain credentials but does not utilize harvested NTLM hashes for direct authentication against administrative services.

Perform a Golden Ticket attack by extracting the krbtgt account NT-hash to forge arbitrary ticket-granting tickets.

Why it fails: Golden Ticket creation requires the specific NTLM hash of the built-in krbtgt service account rather than a standard domain administrator NTLM hash. While both involve harvested hashes, Golden Tickets forge complete Kerberos tickets rather than authenticating via NTLM challenge-response.

Inject the plaintext NTLM hash into the Local Security Authority Subsystem Service memory space to downgrade encryption.

Why it fails: LSASS injection typically involves plaintext passwords or master keys rather than raw NTLM hashes for token manipulation. Attackers inject payloads to spawn new sessions or extract tickets rather than downgrading active directory encryption levels directly.

The local Windows Defender Antivirus service automatically deletes any executable placed inside the System32 directory.

Why it fails: While antivirus solutions may flag malicious payloads, this specific symptom of hanging during startup is caused by protocol communication failures with the Service Control Manager. Antivirus intervention typically results in immediate access denied or file deletion errors rather than startup hangs.

The target machine has strict firewall rules blocking outbound TCP connections on high-numbered ports.

Why it fails: Outbound firewall rules prevent callback connections from reaching your listener, but they do not cause the local Windows service control manager to hang during startup. The service process would still initialize and execute locally regardless of network egress filtering.

monitor.exe

Why it fails: Naming the payload 'monitor.exe' and placing it in 'C:\Program Files\Custom Tools\' would not trigger the unquoted path vulnerability correctly. The service is specifically looking for that file inside the 'Service Monitor' subdirectory. Unless you overwrite the original file, which is a different attack, the service will continue to run the legitimate executable.

Tools.exe

Why it fails: The name 'Tools.exe' does not match any fragment of the provided path. Windows looks for fragments ending in a space, such as 'Program.exe' (from 'Program Files') or 'Service.exe' (from 'Service Monitor'). Since 'Tools' is followed by a backslash rather than a space in this specific path string, it is not a valid interception point.

Program.exe

Why it fails: While 'Program.exe' in the root 'C:\' directory would technically work for an unquoted path starting with 'C:\Program Files', the scenario states the attacker has write access to 'Custom Tools', not the root drive. Most modern Windows installations prevent low-privileged users from writing files directly to the root of the C: drive, making this attempt fail.

JuicyPotato

Why it fails: JuicyPotato abuses SeImpersonatePrivilege by leveraging DCOM and named pipes, but it is largely ineffective on Windows 10 builds after 1809 and Windows Server 2019 due to changes in token impersonation and the introduction of restrictions on the DCOM activation. In this scenario, the Windows 10 host is likely patched, so JuicyPotato would fail. RoguePotato or PrintSpoofer are more reliable alternatives.

PrintSpoofer

Why it fails: PrintSpoofer exploits SeImpersonatePrivilege by abusing the PrinterBug and the Spooler service to coerce SYSTEM authentication, but it requires the Print Spooler service to be running and may not work if the service is disabled. In this scenario, no information about the Spooler service is given, so RoguePotato is a more reliable choice because it does not depend on that service.

SweetPotato

Why it fails: SweetPotato is a collection of various techniques to abuse SeImpersonatePrivilege, but it primarily combines known methods like JuicyPotato and PrintSpoofer. While it can work on some systems, it is not specifically designed for modern Windows 10 versions and may fail if the underlying techniques are blocked. RoguePotato is more targeted for current Windows builds.

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.

Modify the service configuration to run as bob using sc config.

Why it fails: Changing the service account requires administrative privileges. Bob only has low-privileged access and cannot reconfigure the service. Even if he could, changing the account to bob would not escalate privileges; it would just run the service as bob, which is not useful for escalation.

Create a new service with binPath pointing to a malicious executable.

Why it fails: Creating a new service requires administrative privileges, which bob lacks. While a new service could run as SYSTEM, the inability to create one makes this infeasible. The existing weak directory permissions provide a direct path without needing to create a new service.

Use icacls to grant bob Full Control on the service binary.

Why it fails: Bob already has Full Control on the directory via BUILTIN\Users, but icacls requires write permissions to modify ACLs. More importantly, granting additional permissions does not directly lead to code execution as SYSTEM; the key is to replace the binary, not change its ACL.

Mimikatz

Why it fails: Mimikatz is primarily used for credential extraction from memory, such as dumping plaintext passwords and hashes. While it has some token manipulation capabilities, it does not provide an out-of-the-box method to exploit SeImpersonatePrivilege for SYSTEM escalation in the way that a dedicated tool like JuicyPotato does.

winPEAS

Why it fails: winPEAS is an enumeration tool that highlights possible privilege escalation paths, including the presence of SeImpersonatePrivilege. However, it does not exploit the privilege; it only reports it. The scenario asks for a tool to escalate, so winPEAS alone would not achieve SYSTEM access.

PowerUp

Why it fails: PowerUp is a PowerShell script for enumerating common privilege escalation vectors like unquoted service paths and weak service permissions. It does not have a built-in exploit for SeImpersonatePrivilege; it would only identify the privilege, not abuse it. Therefore, it does not directly escalate privileges here.

Leverage the writable folder to plant a malicious `update.exe` and then use `schtasks /run /tn Updater` to trigger the task immediately.

Why it fails: While planting the executable is correct, the command `schtasks /run` typically requires administrative privileges or at least the right to run the task. A low-privileged user may not have permission to start the task manually. The escalation relies on the task running on its own schedule, not on manual triggering.

Use `icacls` to grant yourself Full Control on the scheduled task's XML file and modify the task to run your own command.

Why it fails: Scheduled task definition files are stored in `C:\Windows\System32\Tasks` and are protected by default; a low-privileged user cannot modify them. Even if the task XML were accessible, changing it typically requires administrative rights. The writable folder here does not grant access to task configuration.

Create a new DLL named `update.dll` in the same folder and set the `AppInit_DLLs` registry key to load it.

Why it fails: The `AppInit_DLLs` registry key is located in HKLM and requires administrative privileges to modify. Additionally, it affects all processes loading User32.dll, not just the scheduled task. This approach is not feasible from a low-privileged context and is unrelated to the writable folder.

Create a malicious DLL and place it in a writable directory, then run `msiexec /i malicious.msi`.

Why it fails: While DLL hijacking can be a privilege escalation vector, it is not the direct exploit for AlwaysInstallElevated. The policy allows any MSI to run as SYSTEM, so a malicious DLL is unnecessary. The MSI itself can contain the payload, making this approach overly complex and not guaranteed.

Modify the registry to enable AlwaysInstallElevated for the current user only, then run a malicious MSI.

Why it fails: The AlwaysInstallElevated policy requires both HKLM and HKCU settings to be enabled. If only HKCU is set, the MSI will run with user privileges, not SYSTEM. Therefore, modifying only one hive does not achieve escalation. The scenario already states both are enabled, so this action is redundant and ineffective.

Use `msiexec /a malicious.msi` to perform an administrative installation.

Why it fails: The /a switch performs an administrative installation, which extracts files but does not execute custom actions with elevated privileges. It is not the correct way to trigger the AlwaysInstallElevated behavior. The standard execute (/i) is required to run the MSI with SYSTEM privileges.

dir /s /b "C:\Program Files"

Why it fails: `dir /s /b` recursively lists files and directories, which can reveal installed applications by their folder names, but it does not provide structured information like product names and versions. It is not designed for software inventory and would require manual interpretation, making it inefficient and unreliable for this task.

Get-WmiObject -Class Win32_Product

Why it fails: `Get-WmiObject -Class Win32_Product` is a PowerShell equivalent of the `wmic product` command and does list installed software. However, it is not a command-line tool in the same sense as `wmic`, and it can trigger a consistency check that may cause performance issues. The question asks for a command-line tool, and `wmic` is more directly a command-line utility.

systeminfo

Why it fails: `systeminfo` displays operating system configuration, hotfixes, and hardware details, but it does not list installed applications. While it can show some installed updates, it is not intended for software enumeration. Therefore, it does not fulfill the requirement of identifying installed applications and their versions.

Modify the service's registry key to point to a malicious binary in a writable location.

Why it fails: Modifying the service's registry key requires administrative privileges. The service configuration is stored in HKLM\SYSTEM\CurrentControlSet\Services\CustomSvc, which is not writable by standard users. Therefore, this attack is not possible without prior elevation, making it irrelevant to the unquoted path vulnerability.

Place a malicious 'Program.exe' in C:\ and restart the service.

Why it fails: The unquoted path 'C:\Program Files\CustomSvc\svc.exe' would cause Windows to search for 'C:\Program.exe' first if the path is interpreted as unquoted. However, the root of C:\ typically does not allow standard users to write files. Thus, a low-privileged user cannot place Program.exe there, making this attack infeasible unless the root is writable, which is not indicated.

Place a malicious 'svc.exe' in C:\Program Files\CustomSvc\ and restart the service.

Why it fails: The directory 'C:\Program Files\CustomSvc' has default permissions where Users only have Read & Execute, not Write. Therefore, a low-privileged user cannot create or overwrite files in that directory. This attack would fail due to insufficient permissions, despite the unquoted path vulnerability.

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 'sc query state= all' to list all services and their current status.

Why it fails: The 'sc query state= all' command lists all services and their states, but does not reveal permissions. It only shows whether services are running or stopped. Without permission information, it cannot identify weak service permissions. Therefore, it is not an effective technique for discovering privilege escalation vectors via service permissions.

Run 'wmic service get name,displayname,pathname,startmode' to list service paths and start modes.

Why it fails: While 'wmic service get' lists service paths and start modes, it does not show permission settings. It can help identify unquoted service paths, but not weak permissions on service binaries or directories. Thus, it is not directly effective for discovering weak service permissions, though it is useful for other checks.

Use 'Get-Service | Get-Acl' in PowerShell to inspect service permissions.

Why it fails: The 'Get-Acl' cmdlet retrieves the access control list for a service, but it requires administrative privileges to read service ACLs for many services. A low-privileged user may not have sufficient rights to query all service permissions. Therefore, this method is not reliably effective for enumeration from a low-privileged context.

Restart the service immediately to trigger a buffer overflow.

Why it fails: Restarting a service does not inherently trigger a buffer overflow. Buffer overflows require sending malformed data to an application that lacks proper bounds checking. Unquoted path vulnerabilities rely on the search order of the Windows Service Control Manager, not memory corruption or application crash scenarios.

Overwrite the existing service executable with your payload.

Why it fails: Overwriting the original binary typically requires administrative permissions that the user currently lacks. The vulnerability exists because you can place a file in a parent directory of the path, not because you have write access to the binary itself. This approach would likely fail due to insufficient file permissions.

Modify the Windows Registry to point the service to a new location.

Why it fails: Modifying registry keys related to service configuration usually requires elevated privileges that a low-privileged user does not possess. The unquoted service path vulnerability is exploited by leveraging existing file system permissions, not by changing the underlying configuration of the service itself through registry manipulation.