PEN-200 Public 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.

• ✗

  Disable the target firewall with an initial command so the hardcoded callback address becomes reachable.

  Why it's wrong here

  Disabling the firewall does not change the destination IP embedded in the payload, so the callback still travels to the wrong host. It also causes unnecessary configuration changes on the target, which violates the principle of minimal impact and could disrupt other services or alert defenders during the engagement.

• ✓

  Edit the exploit source to replace the hardcoded IP with your attacker IP, then recompile the payload if the exploit includes source.

  Why this is correct

  When source is available, changing the callback address and recompiling produces a payload that is byte-for-byte appropriate for the target and avoids introducing a foreign binary. This is the most transparent adaptation because the tester can review every change, confirm the architecture matches, and verify the callback address before delivery to the target service.

• ✗

  Replace the payload with a bind shell on a common port so no callback address is needed.

  Why it's wrong here

  Switching to a bind shell changes the exploitation model and often fails because the target's firewall blocks inbound connections to the bind port. It also replaces a working reverse-shell mechanism with a different one that may not fit the exploit's delivery constraints, introducing new failure points instead of correcting the hardcoded address.

• ✓

  Use msfvenom to generate a new payload that matches the target architecture and set the LHOST to your tun0 address, then substitute it into the exploit.

  Why this is correct

  Regenerating the payload with msfvenom produces a payload compiled for the target architecture with the correct callback address embedded, which directly solves the hardcoded-IP limitation. Substituting it into the exploit preserves the vulnerability trigger while ensuring the callback returns to the tester's VPN interface, making the adapted exploit functional in the lab environment.

• ✗

  Run the exploit as-is and rely on port forwarding on your router to redirect the callback to your machine.

  Why it's wrong here

  Port forwarding only redirects traffic that arrives at a public address the target can reach; in a lab VPN the target routes to the tun0 subnet, not the tester's home router. The hardcoded third-party address also raises the risk that a real external host receives the callback, leaking engagement activity to an unrelated party.