Finding & Running Exploits

You exit vulnerability analysis with a confirmed weakness pinned to a version and a CVE — for example, Apache 2.4.49 — CVE-2021-41773, a path-traversal flaw that can lead to remote code execution. That identifier is the handle everything else hangs on: it is how databases index the bug, how exploit authors title their code, and how you will search for the one thing you still lack — the working exploit that converts the vulnerability into a shell.

The temptation is to grab the first script that mentions your CVE and fire it at the target. Resist it. A public exploit is untrusted code written by a stranger, aimed at a system you were paid to protect. The professional workflow has three distinct steps, and skipping any one of them is how engagements go wrong: find a candidate exploit, vet it so you understand exactly what it does, and only then run it — in a lab first, against the client second.

Public exploit code is scattered across the internet, but a handful of sources do the heavy lifting. The one you reach for first is the Exploit Database at exploit-db.com — OffSec's large, curated, CVE-tagged archive of public exploits and proof-of-concept code. It is searchable by product, version, or CVE, every entry links back to the original advisory, and its sheer breadth makes it the default starting point for almost any known-vulnerability lookup.

Different sources suit different moments. Exploit-DB and searchsploit are where you start for an established CVE; Metasploit's module search is where you go when you want a polished, repeatable exploit; GitHub is where the newest proofs-of-concept appear before anything else has caught up. Whatever the source, treat every download as unverified until you have read it — the next sections cover running both kinds of exploit you will find.

When a matching Metasploit module exists, it is usually the cleanest path to access — the author has already handled the fiddly parts, and the framework gives you a consistent loop for every exploit. That loop is worth memorizing, because you will run it hundreds of times:

• search — find the module by CVE or product, e.g. search cve:2021-41773.
• use — select it by name or index, which loads its options into the console.
• set — configure the required options: RHOSTS and RPORT for the target, LHOST for your listener, and a payload to deliver.
• check — when the module supports it, a safe test that confirms whether the target is actually vulnerable without firing the exploit.
• exploit — launch it.

How do you know it worked? Two signals. The clearest is a session opening — Metasploit reports a new Meterpreter or command shell, and you now have interactive access to the target. The other is expected command output: the module runs and returns the file contents, the version banner, or the response that only a successful exploit could produce. If neither appears, the target may be patched, the wrong version, or behind a control you have not accounted for — go back to check and your option values before you assume the exploit is broken.

Plenty of vulnerabilities have no Metasploit module. Many Exploit-DB entries are standalone scripts — a Python, C, or Ruby file you download, read, adjust, and run yourself. The shape is always similar: open the file, find the variables at the top (the target IP and port, sometimes a memory offset or a payload string), set them to your environment, compile if it is C, and execute it against the target.

The friction is real and it is the point. A standalone exploit may need a specific interpreter version, may be written for a slightly different target build, or may expect you to understand what an offset is doing before it will work. Reading the code is not optional housekeeping — it is how you make the exploit fit your target at all.

Treat the lab as a mandatory waypoint, not a nicety. You read the exploit, you run it against a disposable copy of the target, you confirm it behaves the way you expect — and only then do you point a known-good, fully understood exploit at the real engagement. The cost of that discipline is a few minutes; the cost of skipping it is a destroyed client system and a finished career.

Not all exploits are equally safe to run, and the framework tells you so. Metasploit modules carry a reliability ranking — from excellent down to low — that estimates how likely the exploit is to work without harming the target. A high-ranked module typically lands cleanly; a low-ranked one may corrupt memory, hang a process, or knock the service over entirely. When two modules hit the same vulnerability, prefer the more reliable one.

That matters because some exploits can crash the target service, and a crash is a denial of service. Denial of service is almost always out of scope unless the engagement explicitly authorizes it — taking a client's production system offline is a real outage with real consequences, not a successful test. The same discipline applies to standalone scripts, which carry no ranking at all and demand that you judge the risk yourself from the code.

• Use check where possible — confirm vulnerability before you ever fire the exploit.
• Prefer reliable modules — reach for the higher-ranked option, and treat low-rank or crash-prone exploits as a last resort.
• Stay strictly inside scope — if an exploit risks a denial of service and the rules of engagement do not allow it, you do not run it, full stop.

Finding and running exploits is where reconnaissance and analysis finally pay off — but it is also where a careless action does the most damage. With the workflow in hand — find, vet, run, stay in scope — the next lesson puts it to work against the most common target of all: unpatched services running known-vulnerable software in the wild.