How do you find and safely use a public exploit against a target?

Once enumeration gives you a precise software name and version, the exploitation step is often "find the matching PoC and make it work." The skill being tested is not finding the exploit — it is reading and adapting it responsibly.

Finding the right one

Use searchsploit <product> <version> locally or browse Exploit-DB. Version precision matters: a buffer-overflow exploit built for v1.2 will usually fail or crash the service on v1.3 because offsets differ. If nothing matches exactly, widen to the CVE and look at GitHub PoCs.

Read before you run

Never execute a downloaded exploit blind. Read it end to end and confirm:

• What it actually does — some "exploits" are trolls or backdoors that attack you, phoning home or wiping your box.
• The payload — many PoCs carry hardcoded shellcode for a connect-back that points at the author's old IP, or a bind shell on a fixed port. Regenerate the shellcode (e.g. with msfvenom) for your listener.
• Hardcoded values — target IP, target port, reverse-shell IP/port, return addresses, and offsets all need to match your environment.

Adapt and test

For memory-corruption exploits, verify the architecture, bad characters, and offsets against the actual target version. For web or scripting PoCs, set the URL and parameters correctly. Stand up your listener (nc -lvnp) before firing.

Why the care

A reckless exploit can crash the service (denying you and others access), execute attacker-controlled code on your own machine, or simply waste exam time chasing a payload that connects nowhere.

What interviewers look for

The phrase they want is "I read the exploit before I run it." Mentioning version matching, swapping in your own shellcode, and fixing hardcoded IPs shows you treat downloaded code as untrusted, which is exactly the maturity the OSCP rewards.