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.

• ✗

  Run the exploit immediately because Exploit-DB entries are verified by OffSec.

  Why it's wrong here

  Exploit-DB entries are community-submitted and not all are verified by OffSec. Running an untrusted exploit against production without review risks unintended damage, data loss, or introducing malware. The responsible approach is to review the code, understand its actions, and test in a controlled environment before touching production.

• ✗

  Ask the client to disable their antivirus so the exploit runs without interference.

  Why it's wrong here

  Requesting AV disablement before understanding the exploit is premature and unprofessional. It also changes the environment in ways that may not reflect real attacker conditions. The immediate next step is to review and lab-test the code. AV evasion, if needed, is a later consideration handled within the rules of engagement.

• ✓

  Review the exploit's source code to understand its actions and test it in a lab environment first.

  Why this is correct

  Public exploits may contain destructive payloads, hardcoded callbacks, or backdoors. Reviewing the source reveals what the code does, and testing in a lab confirms behavior without risking the client's production system. This aligns with professional penetration testing practice and the OSCP emphasis on understanding and validating tools before use.

• ✗

  Submit the exploit to VirusTotal to confirm it is not malicious, then run it.

  Why it's wrong here

  VirusTotal flags many legitimate exploits as malicious because they contain shellcode or reverse-shell logic. A clean or flagged result does not reliably indicate safety or intent. It also uploads the file to a third party, which may violate engagement confidentiality. Source review and lab testing are more informative and safer.