PT0-002 Attacks and Exploits Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Token impersonation

  Why it's wrong here

  Token impersonation attacks leverage privileges such as SeImpersonatePrivilege to duplicate or impersonate another user's access token, often using tools like JuicyPotato or RoguePotato to escalate from a service account to SYSTEM. This technique abuses Windows token-management logic and named pipe or COM servers, rather than manipulating how the Service Control Manager resolves an unquoted executable path. It is a distinct escalation vector that requires either a vulnerable service token or specific privilege configuration, not a service path misconfiguration.

• ✗

  AlwaysInstallElevated

  Why it's wrong here

  The AlwaysInstallElevated registry policy, when enabled in both HKLM\Software\Policies\Microsoft\Windows\Installer and HKCU\Software\Policies\Microsoft\Windows\Installer, permits unprivileged users to run MSI packages with SYSTEM privileges. Attackers exploit this by generating a malicious .msi payload (e.g., with msfvenom) and executing it, achieving code execution without any reference to service binary paths. This is an installer policy flaw, distinct from unquoted service path attacks because the malicious payload is delivered via Windows Installer, not via the service executable lookup process.

• ✓

  Unquoted service path

  Why this is correct

  When the ImagePath value of a Windows service is an unquoted string containing spaces, the Service Control Manager (or CreateProcess) interprets each space as a potential path separator and tries successive prefixes as executable candidates. For example, 'C:\Program Files\MyApp\Service.exe' leads Windows to attempt 'C:\Program.exe' and 'C:\Program Files\MyApp\Service.exe' in order. If an attacker can write to a directory earlier in the path, they can place a malicious binary named to match a truncated component, such as 'My.exe' or 'Program.exe', which then executes with the service's privilege level when the service starts. This is the exact privilege escalation mechanism caused by an unquoted service path.

• ✗

  DLL hijacking

  Why it's wrong here

  DLL hijacking (or DLL preloading) exploits the Windows DLL search order by placing a malicious DLL in a directory that an application searches before the intended system location, often the application's current working directory or a user-writable path. In the context of a service, the service executable runs normally from a properly quoted path, but when it loads a library, Windows may walk the search order and load the attacker's DLL instead of the legitimate one. This is a different mechanism from unquoted service path because the flaw lies in the DLL loading behavior, not in the parsing of the service binary's path, and it requires the attacker to control a DLL name loaded by the service.

Go deeper

Related to this question