PT0-002 Practice Question: A penetration tester gained low-privileged access…

Answer analysis

Option-by-option breakdown

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

• ✗

  Modify the $0 variable during execution

  Why it's wrong here

  In Bash, $0 is a special read-only positional parameter that reflects the argv[0] passed by the kernel or calling process. It is not an environment variable, so an external attacker cannot alter it via env or command-line tricks; attempting to change it inside the script (e.g., with set --) only changes positional parameters $1, $2, etc., not $0. Thus, even if the script uses $(dirname $0), the attacker cannot preconfigure or redirect $0 from outside to point to a malicious directory or value, making this an ineffective escalation technique.

• ✓

  Create a malicious executable named 'dirname' in a directory earlier in the PATH

  Why this is correct

  Since the script uses $(dirname $0) without an absolute path, the system searches PATH for 'dirname'. If the attacker puts a malicious 'dirname' script in a writable directory earlier in PATH, it will be executed as root.

• ✗

  Overwrite /opt/tool/backup.sh with a reverse shell

  Why it's wrong here

  Overwriting /opt/tool/backup.sh with a reverse shell requires write permission on the script file itself or on its containing directory. A low-privileged user typically has no write access to /opt/tool, and the file is likely owned by root with mode 755 or 700, preventing modification. Additionally, this approach is not a subtle command injection; it directly replaces the target script, which would require an existing writable configuration error that is not implied by the scenario. Since the question specifically highlights the use of $(dirname $0), a PATH-based hijack is the intended attack vector, not a file-overwrite escalation.

• ✗

  Exploit a buffer overflow in the Bash interpreter

  Why it's wrong here

  Exploiting a buffer overflow in the Bash interpreter is a memory-corruption attack that would require a specific vulnerable version of Bash, a way to deliver a malicious input to the interpreter's parser, and root privileges on the target process. The script `backup.sh` simply executes `dirname` with a normalized argument (`$0`), which does not overflow any buffer or involve unmarshalling attacker-controlled binary data. Moreover, the flaw described in the question is a logical command-hijacking vulnerability (PATH resolution), not a low-level interpreter bug; memory-safety exploits are irrelevant and anachronistic here. The attack is a straightforward substitution of an executable found via PATH, not a code-execution exploit against the shell binary.

Go deeper

Related to this question