PT0-002 Attacks and Exploits Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  DLL hijacking

  Why it's wrong here

  DLL hijacking is a Windows-specific exploitation vector that abuses the DLL search order to load a malicious library in place of a legitimate one. Since the target is a Linux system running an ELF binary, there are no DLLs; Linux uses shared objects (.so) and the dynamic linker with mechanisms like LD_PRELOAD. Even if an equivalent shared-object attack existed, it would not be called DLL hijacking, and the scenario provides no evidence of such a component. Therefore, this option is incorrect for a Linux SUID binary.

• ✗

  Kernel exploit

  Why it's wrong here

  A kernel exploit targets a specific vulnerability in the operating system kernel, such as a race condition or missing permission check, to elevate privileges. In this scenario, the only disclosed detail is a SUID binary; there is no indication of an unpatched kernel, vulnerable module, or relevant CVE. Choosing a kernel exploit would require reconnaissance to confirm a kernel flaw, which the question does not provide. Thus, this is not the correct technique for the described situation.

• ✗

  Token impersonation

  Why it's wrong here

  Token impersonation is a Windows-only privilege escalation technique that leverages access tokens, particularly the SeImpersonatePrivilege, to assume the identity of another user (often SYSTEM). Linux security is based on Unix user IDs, group IDs, and capabilities, not on Windows tokens, so this technique has no direct equivalent in a Linux environment. The presence of a SUID binary does not create any token-based attack surface. Consequently, token impersonation is not a valid answer for a Linux system.

• ✓

  PATH manipulation

  Why this is correct

  When a SUID binary executes an external command using a relative path, such as calling system('ls') or execvp('ls', ...), it relies on the PATH environment variable set by the invoking user. An attacker can prepend a custom directory to PATH containing a malicious executable with the name of the expected command; since the SUID binary runs with root privileges, the malicious executable executes with root privileges, granting privilege escalation. The exploit succeeds only if the binary does not sanitize the environment (e.g., via secure_getenv) and uses a relative path instead of an absolute path. This is precisely the described scenario, making PATH manipulation the correct answer.

Go deeper

Related to this question