Free Offensive Security Linux Privilege Escalation Practice Test 2026

Master Linux Privilege Escalation with free offensive security practice questions covering escalating privileges on Linux via SUID binaries, sudo misconfigurations, cron jobs, capabilities, and kernel exploits. 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 Linux Privilege Escalation Topics

Free Linux 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 — 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 2 — 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 3 — Linux Privilege Escalation

You have a low-privilege shell as user `www-data` on an Ubuntu 20.04 web server. During enumeration, you run `sudo -l` and get: User www-data may run the following commands on web01: (root) NOPASSWD: /usr/bin/find /var/backups -type f -mtime -1 -exec /bin/tar -czf /var/backups/daily.tar.gz {} + You confirm that `sudo` is allowed without a password: www-data@web01:/var/www/html$ sudo -n -l Matching Defaults entries for www-data on web01: env_reset, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin User www-data may run the following commands on web01: (root) NOPASSWD: /usr/bin/find /var/backups -type f -mtime -1 -exec /bin/tar -czf /var/backups/daily.tar.gz {} + You cannot modify `/usr/bin/find` or `/bin/tar`, and `/var/backups` is writable by `www-data`. Which is the most reliable way to escalate to root using this configuration?

  1. A. Create a malicious file in `/var/backups` named `--checkpoint-action=exec=/bin/sh` so that when `find` runs with `tar`, it triggers a root shell.
  2. B. Abuse `find`'s `-exec` by replacing `/bin/tar` with a symlink to `/bin/bash` in `/var/backups`, then run the sudo command to spawn a root shell.
  3. C. Leverage `tar`'s `--checkpoint-action` feature by creating a file in `/var/backups` whose name is interpreted as additional `tar` options when passed via `find -exec`, causing `tar` (run as root) to execute `/bin/sh`. (Correct answer)
  4. D. Exploit a race condition by deleting all files in `/var/backups` and quickly creating a SUID-root copy of `/bin/bash` before `find` completes, so the SUID bit is preserved.

Correct answer: C

Explanation: The key is that `www-data` can run a specific `find` command as root without a password. The command is fixed except for the files in `/var/backups`, which `www-data` can control. The `find` command: `/usr/bin/find /var/backups -type f -mtime -1 -exec /bin/tar -czf /var/backups/daily.tar.gz {} +` means that any file names in `/var/backups` that match `-type f -mtime -1` will be passed as arguments to `/bin/tar`. If we can craft a filename that starts with a dash (`-`), `tar` will interpret it as an option rather than a normal file. `tar` has a known privesc pattern using `--checkpoint` and `--checkpoint-action=exec=/bin/sh`. When `tar` encounters these options, it will execute the specified command. Because `tar` is being run as root via `sudo`, this command will execute as root. The attack chain for option C is: 1. Create malicious filenames in `/var/backups`: ```bash cd /var/backups touch "--checkpoint=1" touch "--checkpoint-action=exec=/bin/sh" ``` 2. Run the allowed sudo command: ```bash sudo /usr/bin/find /var/backups -type f -mtime -1 -exec /bin/tar -czf /var/backups/daily.tar.gz {} + ``` 3. `find` will pass the files (including those starting with `--checkpoint` and `--checkpoint-action=...`) to `tar`. 4. `tar`, running as root, interprets them as options and executes `/bin/sh` as root, giving you a root shell. This is a realistic Linux privesc pattern that relies on understanding how argument parsing works and abusing a legitimate backup command. Why the other options are wrong: - **A:** Simply creating a file named `--checkpoint-action=exec=/bin/sh` is not enough by itself; you also need a `--checkpoint` option for `tar` to trigger the action. Moreover, the answer does not mention the full chain or the need for both options. In practice, you need both `--checkpoint=1` and `--checkpoint-action=exec=/bin/sh` as separate filenames so `tar` processes them as options. Option C correctly captures this technique. - **B:** You cannot influence the path to `/bin/tar` in the `find -exec` clause. The command explicitly calls `/bin/tar`, not `tar` via `$PATH`, so creating a symlink in `/var/backups` will not affect which binary is executed. Also, you cannot replace `/bin/tar` because you lack permissions. - **D:** There is no inherent race condition here that would cause a SUID bit to be set or preserved. `tar` is just creating an archive; it is not restoring files with altered permissions. Creating a SUID-root copy of `/bin/bash` would require root privileges in the first place. The described race condition is not realistic in this context. Therefore, **C** is the correct and practical escalation method: abusing `tar`'s `--checkpoint-action` via controlled filenames passed through the sudo-allowed `find` command.

Sample Question 4 — Linux Privilege Escalation

During an internal penetration test, you compromise a Debian-based file server as user `backup`. While enumerating for privilege escalation, you find the following in `/etc/crontab`: ```bash # m h dom mon dow user command */5 * * * * root /usr/local/bin/backup.sh ``` You inspect `/usr/local/bin/backup.sh`: ```bash #!/bin/bash SRC_DIR="/home" DEST_DIR="/mnt/backup" cd $SRC_DIR for d in *; do if [ -d "$d" ]; then tar -czf "$DEST_DIR/$d.tar.gz" $d fi done ``` Permissions: ```bash backup@filesrv:~$ ls -l /usr/local/bin/backup.sh -rwxrwxr-x 1 root backup 347 Jun 1 10:22 /usr/local/bin/backup.sh backup@filesrv:~$ ls -ld /usr/local/bin drwxr-xr-x 2 root root 4096 Jun 1 09:00 /usr/local/bin ``` You also confirm that `/home/backup` is writable by the `backup` user and that `tar` is the standard system binary (`/bin/tar`). Which is the most reliable way to escalate to root using this cron job?

  1. A. Edit `/usr/local/bin/backup.sh` to append `chmod u+s /bin/bash` at the end of the script so that when cron runs it as root, `/bin/bash` becomes SUID-root.
  2. B. Create a directory `/home/backup;chmod u+s /bin/bash;#` so that when `tar` runs, the shell metacharacters are interpreted and set the SUID bit on `/bin/bash`.
  3. C. Modify `/usr/local/bin/backup.sh` to replace `tar -czf "$DEST_DIR/$d.tar.gz" $d` with `tar -czf "$DEST_DIR/$d.tar.gz" $d; /bin/bash -p` so that cron spawns a root shell. (Correct answer)
  4. D. Exploit PATH hijacking by creating a malicious `tar` binary in `/home/backup` that spawns a root shell, since the script runs `tar` without an absolute path and cron jobs often have a minimal PATH.

Correct answer: C

Explanation: The cron job runs `/usr/local/bin/backup.sh` as root every 5 minutes. The key observations: - The script is owned by root but is group-writable by the `backup` group, and the `backup` user is in that group (inferred from permissions `-rwxrwxr-x 1 root backup`). - `/usr/local/bin` itself is not writable, but the file `backup.sh` is, so `backup` can edit the script content. - The script is executed by cron as root, so any commands added to it will run with root privileges. The most straightforward and reliable escalation is to directly modify the script to execute a root shell when cron runs it. Option C does exactly that: ```bash # as backup user nano /usr/local/bin/backup.sh # or use echo >>, vim, etc. ``` Change the line: ```bash tar -czf "$DEST_DIR/$d.tar.gz" $d ``` to: ```bash tar -czf "$DEST_DIR/$d.tar.gz" $d; /bin/bash -p ``` `/bin/bash -p` preserves the effective UID (root) when running setuid or from cron, giving you a root shell the next time the cron job executes. You can redirect this shell to a reverse shell or write a SUID binary, depending on your access method. Why the other options are wrong or less appropriate: - **A:** Appending `chmod u+s /bin/bash` will likely work in many cases, but it is noisier and more intrusive than just spawning a root shell. Also, some hardened systems may have protections or monitoring around SUID changes. While technically viable, exam-style questions usually expect the more direct and controlled method of getting a shell, which is what C describes. - **B:** The script uses `tar` with arguments passed as plain strings; it does not invoke a shell to interpret metacharacters. The `for d in *` loop and `tar -czf "$DEST_DIR/$d.tar.gz" $d` will treat the directory name literally. Shell metacharacters like `;` and `#` in directory names are not executed; they are just part of the filename. So this will not result in command execution. - **D:** While the script calls `tar` without an absolute path, PATH hijacking here is unreliable and likely ineffective: - Cron typically sets a minimal PATH like `/usr/bin:/bin`, not including `/home/backup`. - You cannot modify root's PATH from the `backup` user in a way that affects cron. - There is no evidence that `/home/backup` is in the PATH for this cron job. Even if you create `/home/backup/tar`, it will not be used unless PATH is manipulated, which you cannot do here. Therefore, **C** is the most reliable and realistic escalation path: directly modifying the root-executed cron script you can write to, and injecting a root shell command.

Sample Question 5 — Linux Privilege Escalation

On a Red Hat-based application server, you obtain a shell as user `appuser`. While enumerating for privilege escalation, you find the following SUID binary: ```bash appuser@appsrv:~$ ls -l /usr/local/bin/diag -rwsr-xr-x 1 root root 18432 Jun 1 09:12 /usr/local/bin/diag appuser@appsrv:~$ file /usr/local/bin/diag /usr/local/bin/diag: ELF 64-bit LSB pie executable, x86-64, dynamically linked, for GNU/Linux 3.2.0, stripped ``` Running the binary: ```bash appuser@appsrv:~$ /usr/local/bin/diag [+] Running system diagnostics... [+] Collecting network info... [+] Collecting disk usage... [+] Done. Report saved to /tmp/diag.log ``` You use `strings` and see: ```bash appuser@appsrv:~$ strings /usr/local/bin/diag | grep -E 'ifconfig|df|sh' /bin/sh ifconfig /bin/df /tmp/diag.log ``` You then run `strace`: ```bash appuser@appsrv:~$ strace -f -e execve /usr/local/bin/diag 2>&1 | grep -E 'ifconfig|df' execve("/usr/local/bin/diag", ["/usr/local/bin/diag"], 0x7ffc...) = 0 execve("/usr/bin/ifconfig", ["ifconfig"], 0x7ffc...) = -1 ENOENT (No such file or directory) execve("/bin/ifconfig", ["ifconfig"], 0x7ffc...) = -1 ENOENT (No such file or directory) execve("/bin/df", ["df"], 0x7ffc...) = 0 ``` You confirm that `/usr/bin` is writable by `appuser` (misconfiguration): ```bash appuser@appsrv:~$ ls -ld /usr/bin drwxrwxr-x 2 root appgroup 4096 Jun 1 08:00 /usr/bin ``` Which is the most appropriate way to escalate to root using this SUID binary?

  1. A. Create a malicious `/usr/bin/ifconfig` script that spawns a root shell, make it executable, and then run `/usr/local/bin/diag` to have it executed as root. (Correct answer)
  2. B. Overwrite `/bin/df` with a malicious binary that spawns a root shell, since `diag` successfully executes `/bin/df` as seen in `strace`.
  3. C. Use `LD_PRELOAD` to load a malicious shared library when running `/usr/local/bin/diag`, intercepting calls to `ifconfig` and executing a root shell.
  4. D. Exploit PATH hijacking by creating a malicious `df` binary in `/tmp` and setting `PATH=/tmp:$PATH` before running `/usr/local/bin/diag`.

Correct answer: A

Explanation: The SUID binary `/usr/local/bin/diag` runs as root (due to the SUID bit) and attempts to execute `ifconfig` and `df`. From `strace`: ```bash execve("/usr/bin/ifconfig", ["ifconfig"], ...) = -1 ENOENT execve("/bin/ifconfig", ["ifconfig"], ...) = -1 ENOENT execve("/bin/df", ["df"], ...) = 0 ``` This shows: - It tries `/usr/bin/ifconfig` and `/bin/ifconfig` but both are missing. - It successfully runs `/bin/df`. Crucially, `/usr/bin` is writable by `appuser` (a serious misconfiguration): ```bash ls -ld /usr/bin drwxrwxr-x 2 root appgroup ... /usr/bin ``` So you can create `/usr/bin/ifconfig`. When `diag` runs as root, it will attempt to execute `/usr/bin/ifconfig`. If you place a malicious script or binary there, it will run with root privileges. Attack chain for option A: 1. Create a malicious `ifconfig` in `/usr/bin`: ```bash appuser@appsrv:~$ cat << 'EOF' > /usr/bin/ifconfig #!/bin/bash /bin/bash -p EOF appuser@appsrv:~$ chmod +x /usr/bin/ifconfig ``` 2. Run the SUID binary: ```bash appuser@appsrv:~$ /usr/local/bin/diag [+] Running system diagnostics... # you now have a root shell from /bin/bash -p ``` Because `/usr/local/bin/diag` is SUID-root, it will execute `/usr/bin/ifconfig` as root, and `/bin/bash -p` will preserve the effective UID, giving you a root shell. Why the other options are wrong or less appropriate: - **B:** Overwriting `/bin/df` is technically possible if `/bin` were writable, but we have no evidence that `/bin` is writable; only `/usr/bin` is confirmed writable. On a typical system, `/bin` is root-owned and not writable by normal users. Attempting to overwrite `/bin/df` would fail with permission denied. Also, modifying core system binaries is noisy and more likely to break the system. - **C:** SUID binaries ignore `LD_PRELOAD` and most environment-based dynamic linker tricks by default for security reasons. The dynamic loader will not honor `LD_PRELOAD` for setuid/setgid programs unless very specific and rare conditions are met. Therefore, relying on `LD_PRELOAD` for a SUID-root binary is generally ineffective and not a realistic privesc path here. - **D:** PATH hijacking would require the SUID binary to call `df` without an absolute path and to respect the untrusted user's `PATH`. However, `strace` shows that `diag` calls `/bin/df` explicitly, not just `df`. That means changing `PATH` or placing a `df` in `/tmp` will not affect which binary is executed. The absolute path `/bin/df` is used, so PATH hijacking is not applicable. Therefore, **A** is the correct and realistic escalation method: abuse the writable `/usr/bin` directory to place a malicious `/usr/bin/ifconfig` that is executed by the SUID-root `diag` binary.

Sample Question 6 — Linux Privilege Escalation

You have a low-privilege shell as user `www-data` on a Ubuntu 20.04 server. During enumeration, you run `sudo -l` and get: User www-data may run the following commands on web01: (root) NOPASSWD: /usr/bin/find /tmp -name * Which of the following is the most reliable way to escalate to a root shell using this configuration?

  1. A. Create a SUID copy of `/bin/bash` in `/tmp` and execute it via the allowed `find` command.
  2. B. Abuse `find`'s `-exec` option to execute `/bin/bash` as root: `sudo /usr/bin/find /tmp -name x -exec /bin/bash \;`. (Correct answer)
  3. C. Use `find` to read `/etc/shadow` via `sudo /usr/bin/find /tmp -name x -exec cat /etc/shadow \;` and crack the root hash offline.
  4. D. Use `find`'s `-delete` option with sudo to remove `/etc/sudoers` and then re-add yourself to the sudoers file.

Correct answer: B

Explanation: The sudoers entry allows `www-data` to run `/usr/bin/find /tmp -name *` as root without a password. The key is that `find` supports `-exec` to execute arbitrary commands on matched files. When run via sudo, those commands execute with root privileges. Correct answer (B): - `sudo /usr/bin/find /tmp -name x -exec /bin/bash \;` - Even though the sudoers rule shows `/usr/bin/find /tmp -name *`, sudo does not, by default, restrict additional arguments unless explicitly configured with `NOPASSWD: /usr/bin/find /tmp -name \*` and `NOEXEC` or `COMMAND` tags. In most real-world misconfigurations, you can append `-exec`. - This command runs `find` as root, searching `/tmp` for files named `x`. For each match, it executes `/bin/bash`. The spawned bash inherits root's privileges, giving you a root shell. - This is a classic GTFOBins-style sudo misconfiguration exploit. Why the others are wrong: - (A) "Create a SUID copy of `/bin/bash` in `/tmp` and execute it via the allowed `find` command." - You cannot set the SUID bit as `www-data` on a file you own and expect it to run as root; SUID only elevates to the file owner. You would need root to set the owner to root. - Also, the sudoers rule does not allow you to run `chmod` or `chown` as root, only `find`. - (C) "Use `find` to read `/etc/shadow` via `sudo /usr/bin/find /tmp -name x -exec cat /etc/shadow \;` and crack the root hash offline." - While this might work to read `/etc/shadow` and is a valid data exfiltration step, it is not the most direct or reliable privilege escalation path in an exam context. - Cracking the root hash may be time-consuming or infeasible if the password is strong. - (D) "Use `find`'s `-delete` option with sudo to remove `/etc/sudoers` and then re-add yourself to the sudoers file." - `find` is restricted to the `/tmp` directory in the sudoers rule; it cannot operate on `/etc/sudoers`. - Deleting `/etc/sudoers` is dangerous and can lock you out of sudo entirely; recreating it correctly requires root access you don't yet have. Relevant technique: - Linux privilege escalation via sudo misconfiguration + GTFOBins. - Typical workflow: `sudo -l` → identify misconfigured binary → check GTFOBins (e.g., `find`) → craft `sudo` command with `-exec` to spawn a root shell.

Offensive Security Prep Pack Overview

Other Offensive Security Domains

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