PT0-002 Practice Question: A penetration tester has gained low-privilege…

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a symbolic link from a Python script to a system file like /etc/shadow

  Why it's wrong here

  This fails because the sudo rule executes Python scripts, not arbitrary files. A symlink pointing to /etc/shadow would cause the Python interpreter to attempt to read the shadow file as source code, resulting in a SyntaxError since it contains colon-delimited account data, not valid Python. Even if the file were readable, Python wouldn't execute it as a shell, and the symlink path might fall outside the /opt/scripts/ directory allowed by the sudoers rule.

• ✓

  Write a malicious Python script to /opt/scripts/ that spawns a root shell

  Why this is correct

  Since the user owns /opt/scripts, they can create a Python script that imports os and calls os.system('/bin/bash') or launches a reverse shell with socket and subprocess modules. When the script is run via the configured sudo rule, it executes with root privileges because sudo preserves the target user's (root) permissions. This is a classic and reliable privilege escalation when a sudoers entry permits executing scripts from a user-writable directory without disabling the associated commands.

• ✗

  Exploit a kernel vulnerability to overwrite the sudo binary

  Why it's wrong here

  This approach is unnecessary and risky because kernel exploits require a specific vulnerable kernel version and may crash the system or hang, which can kill the session. Overwriting /usr/bin/sudo would also require write access to a root-owned system binary directory, which the low-privilege user does not have. Since a direct sudo rule exists to run Python scripts as root, exploiting the kernel or modifying sudo adds complexity, violates the principle of least resistance, and can alert defenders or leave the system unstable.

• ✗

  Overwrite an existing Python script in /usr/bin/ with a malicious payload

  Why it's wrong here

  This attempt fails for two reasons: the user almost certainly lacks write permission to /usr/bin/, as that directory is owned by root and typically read-only for non-privileged users, so the overwrite would be denied. Even if the overwrite succeeded, the sudoers rule in question is scoped specifically to /opt/scripts/, not /usr/bin/, so running the modified script with sudo would not be permitted. Additionally, sudo would not execute an arbitrary binary/script from /usr/bin under this rule, making the entire effort futile.

Go deeper

Related to this question