PT0-002 Practice Question: During an internal penetration test, a tester…

Answer analysis

Option-by-option breakdown

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

• ✗

  Injecting shellcode directly onto the stack and overwriting the return address to jump to it

  Why it's wrong here

  Directly injecting shellcode onto the stack and redirecting execution to it fails because DEP marks the stack as non-executable. With the NX bit set, the CPU refuses to fetch instructions from stack pages, and any attempt to jump to the injected shellcode triggers an access violation (0xC0000005). Even with a precise overwrite of the saved return address, the exploit cannot gain code execution without first disabling DEP or using an indirect technique.

• ✗

  Using a return-to-libc attack to call system() with a command string

  Why it's wrong here

  A return-to-libc attack is ineffective here because Windows servers do not utilise the `libc` library or its `system()` function in the same manner as Unix-like systems. Windows relies on its native API, such as `kernel32.dll`, for system calls. This technique is tempting as it is a classic method for bypassing Data Execution Prevention by executing existing code. It would be highly effective on a Linux system with DEP enabled and Address Space Layout Randomisation disabled, where `system()` is predictably located.

• ✓

  Constructing a ROP chain using gadgets from loaded DLLs to simulate shellcode execution

  Why this is correct

  A ROP chain reuses sequences of existing instructions (gadgets) terminated by a ret, all located in executable modules such as loaded DLLs or system libraries. Because these gadgets reside in executable memory, DEP does not block them; chaining them lets the attacker simulate arbitrary logic or call functions like VirtualProtect to change memory permissions and then execute shellcode. With ASLR disabled, gadget addresses are fixed and predictable, making this a reliable bypass of DEP on Windows.

• ✗

  Enabling the execute bit on the stack via a memory corruption primitive

  Why it's wrong here

  Altering the execute permission of the stack typically requires modifying page-table entries or invoking a privileged API like VirtualProtect, which itself demands code execution. A memory corruption primitive alone only gives the attacker read/write access to process memory, not the ability to change hardware-enforced memory protection; doing so would require an additional vulnerability, such as an arbitrary write to kernel structures. This approach is neither standard nor practical, as it introduces extra attack surface and is far more complex than a straightforward ROP chain.

Go deeper

Related to this question