PEN-200 Public Exploits Practice Question
You are adapting a public exploit whose payload is a reverse shell. The exploit runs and the service reports success, but your netcat listener never receives a connection. Which cause is most likely?
⚠ Common exam trap
The trap here is assuming the exploit failed at the memory-corruption stage when the service already reported success, pointing instead to the callback network path.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The target's outbound firewall blocks the callback port, or the payload is calling back to an address the target cannot route to.
When exploitation succeeds but no callback arrives, the network path from target to listener is the prime suspect. Outbound firewall rules or a payload addressed to an unroutable interface stop the reverse shell even though the vulnerability was triggered. Offset errors would crash the service, netcat is a valid listener, and high-port binding needs no elevated privileges.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Netcat is not capable of receiving reverse shells and a different listener is required.
Why it's wrong here
Netcat is a standard and fully capable listener for reverse TCP shells, so the tool itself is not the limitation. Blaming netcat overlooks the far more common causes such as firewall filtering or an unreachable callback address, and switching listeners would not fix a blocked network path.
- ✓
The target's outbound firewall blocks the callback port, or the payload is calling back to an address the target cannot route to.
Why this is correct
A successful exploit trigger with no callback almost always means the payload executed but its network path failed. Outbound filtering on the target or a payload pointing at an unreachable address prevents the reverse connection even though the vulnerability was exploited, which matches the observed success-without-shell behavior exactly.
- ✗
The exploit's buffer overflow offset is incorrect, so the payload never reaches the instruction pointer.
Why it's wrong here
An incorrect offset would typically crash the service or produce no success indication at all, because execution would not transfer to the payload. Since the service reports success and the exploit completes, the trigger likely worked; the missing piece is the network callback rather than the memory corruption step.
- ✗
The exploit was run without administrative privileges on the attacker machine, preventing the listener from binding.
Why it's wrong here
Binding a high-numbered listener port does not require administrative privileges on the attacker machine, and a failed bind would produce a visible error rather than silence. This explanation misidentifies where the failure occurs, since the listener started successfully and the missing element is the target's outbound connection.
About these practice questions
One of 285 original PEN-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official OffSec exam blueprint
This PEN-200 practice question is part of Courseiva's free OffSec certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PEN-200 exam.