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.

• ✗

  Check the exploit's file hash against online databases to confirm it is known.

  Why it's wrong here

  Hash lookups can indicate whether a file is recognized, but a novel or modified exploit will not appear in databases. This does not substitute for understanding the code's behavior, and a known hash does not guarantee the exploit is safe.

• ✗

  Run the exploit in a sandboxed virtual machine first to see if it works.

  Why it's wrong here

  Testing in a sandbox is useful but does not replace code review. A sandbox may not reveal all malicious behavior, especially if the exploit targets external systems or uses delayed execution, and it does not tell you what the exploit is actually doing.

• ✓

  Review the exploit's source code to understand its actions and check for malicious payloads.

  Why this is correct

  Auditing the source code is critical because public exploits from untrusted sources may contain backdoors, additional malicious payloads, or destructive commands. Understanding what the exploit does before execution protects both the client's environment and your own testing platform.

• ✗

  Ask the client for permission to run the exploit on their production system.

  Why it's wrong here

  Authorization is necessary but does not address the security risk of running unreviewed code. Even with permission, executing a malicious exploit could damage the client's systems or compromise your own infrastructure, so code review must come first.