PT0-002 Practice Question: Drag and drop the steps to perform 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.

• ✓

  Gather system information (kernel version, architecture, distribution) -> Search for kernel exploits using searchsploit or similar -> Download or compile the exploit code -> Run the exploit -> Verify privilege escalation (e.g., id command)

  Why this is correct

  This sequence is correct because kernel exploits are tightly coupled to the exact kernel version, CPU architecture, and distribution. You must first run commands like `uname -a` and `cat /etc/os-release` to enumerate this baseline; only then can you query searchsploit or Exploit-DB with precise filters like `--kernel=5.4.0`. After selecting a candidate, you transfer the source or binary, compile it on the target (if needed) to match the ABI, execute it, and finally confirm privilege escalation with `id` or `whoami` to validate that the session now has uid=0.

• ✗

  Search for kernel exploits -> Gather system information -> Download or compile the exploit -> Run the exploit -> Verify privilege escalation

  Why it's wrong here

  This sequence is flawed because it inverts the dependency between reconnaissance and exploit selection. Without first obtaining the kernel version, architecture, and distribution, a search for 'kernel exploits' returns an unmanageable, unfiltered list of results, most of which are irrelevant to the target. You cannot judge which exploit will compile or run, so any download/compile step is guesswork. Proper methodology always enriches target data before querying vulnerability databases, making this premature search both inefficient and practically useless.

• ✗

  Gather system information -> Search for kernel exploits -> Run the exploit -> Verify privilege escalation -> Download or compile the exploit

  Why it's wrong here

  This sequence is logically impossible because an exploit must exist on the filesystem and be executable before you can run it. Attempting `./exploit` before either downloading a prebuilt binary or compiling the C source with `gcc` will fail with 'No such file or directory' or trigger the shell's command-not-found error. Even if the binary were present, it must be granted execute permissions (`chmod +x`) and may need to be recompiled for the target's architecture after downloading the source. Placing execution before preparation breaks the fundamental dependency chain of the attack.

• ✗

  Run the exploit -> Verify privilege escalation -> Gather system information -> Search for kernel exploits -> Download or compile the exploit

  Why it's wrong here

  This sequence is completely reversed: you cannot execute an exploit that has not been acquired, and you cannot craft it without knowing the target's kernel details. Running an arbitrary command in the hope of privilege escalation is not feasible; the exploit payload must be tailored to the target's exact kernel version and distribution to avoid crashing the system. Verifying privilege escalation before even performing the exploitation step is nonsensical because `id` would still show the original unprivileged user, proving no escalation occurred. Proper workflow is enumeration, search, build, execute, then confirm—any other order is invalid.

Go deeper

Related to this question