Exploitation and Metasploit

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: An exploit is the bridge between “this system has a weakness” and “I now have access.” Page 2.10 established that vulnerabilities are often publicly documented; this page is about what it means to actually use one. Understanding exploitation is essential for offense — and just as essential for defense, because you cannot grasp why patching matters until you’ve seen a known vulnerability turn into a shell.

Part 1: The Problem

You’ve found weak services (3.2) and you know that services can have known vulnerabilities (2.10, 3.1). But there’s a gap between knowing a vulnerability exists and gaining access through it. Closing that gap is exploitation.

This page demystifies it. Exploitation has an aura — it sounds like the “real hacking.” In reality, for the vast majority of practical work, it is a understood, structured process, often using existing tools. The mystique is unhelpful; the understanding is essential. And critically: understanding exploitation is what makes a defender take patching seriously — abstract “vulnerability” becomes concrete “this is how they get in.”

Part 2: The Concept — What an Exploit Actually Is

Precise definitions, building on 1.1:

• A vulnerability is a weakness (1.1) — a flaw in a service, an application, or a configuration.
• An exploit is a piece of code or a technique that takes advantage of a specific vulnerability to make the system do something it shouldn’t.
• A payload is what the exploit delivers — the code that actually runs on the target once the exploit succeeds. The exploit is the way in; the payload is what you do once in.

   EXPLOIT  =  the method that breaks through a specific weakness
   PAYLOAD  =  the code that runs on the target after it breaks through

   Analogy:
   exploit  = the technique that gets the door open
   payload  = what you do once you're through the door

A very common payload goal is a shell — command-line access to the target machine, letting the attacker run commands on it. A widely used, more capable payload type provides a richer interactive session for working with the compromised machine.

Two terms you’ll hear: a 0-day (zero-day) is a vulnerability not yet publicly known and not yet patched — rare, valuable, and not what everyday practical work uses. Far more common is exploiting known/N-day vulnerabilities — publicly documented ones (CVEs, 2.10) where the issue is simply that the target hasn’t patched. Most real-world compromise, by attackers and testers alike, uses known vulnerabilities against unpatched systems. That fact is the entire argument for patching.

Part 3: The Concept — Where Exploits Come From

When a vulnerability is publicly disclosed (the CVE process from 2.10), exploit code is often developed and published too — for legitimate reasons: defenders need it to test their systems, and security professionals need it for authorized assessments.

This means a practitioner usually does not write exploits from scratch. They:

• Find existing exploit code in public exploit databases and repositories, matched to a specific CVE and version.
• Use exploitation frameworks (Part 4) that package many exploits in one consistent tool.
• Occasionally adapt an existing exploit to a particular target — which is where the Phase 0.6 skill of reading code pays off directly.

Writing original exploits — and the deep, low-level skills behind it (memory corruption, and so on) — is a genuine specialization (it sits in Phase 5’s advanced and research-oriented directions). It is not a prerequisite for being a competent, employable security practitioner. Most pentesters and bug bounty hunters are highly effective using existing exploits skillfully and understanding them deeply.

⚠️ Public exploit code is dangerous in two directions. It can damage the target — exploits can crash services, corrupt data, destabilize systems (some are unreliable; some are meant to crash things). And it can be malicious to you — recall 0.6: some published “exploits” actually attack whoever runs them. So: read exploit code before running it (0.6), run it only against authorized targets, and understand that exploitation carries real risk of disruption — which is why engagement rules often restrict it.

Part 4: The Concept — The Metasploit Framework

Metasploit is the best-known exploitation framework: a single tool that brings together a large library of exploits, payloads, and supporting modules under one consistent interface. It’s pre-installed in Kali and is a standard part of the field — add it to your Tools & Reference Cheatsheet.

What a framework like Metasploit gives you, conceptually:

• Exploit modules — a large, organized library of exploits for known vulnerabilities.
• Payloads — a selection of payloads (shells, richer sessions) to pair with an exploit.
• A consistent workflow — instead of every exploit being a different script with different usage, the framework gives one repeatable pattern: choose an exploit, set its options (which target, which port), choose a payload, run it.
• Auxiliary modules — supporting tools for scanning, enumeration, and more.
• Post-exploitation modules — tools for working with a machine after compromise.

The conceptual workflow:

   1. SEARCH   — find an exploit module for the target's
                 known vulnerability (matched by service + version)
   2. SELECT   — choose that exploit module
   3. CONFIGURE— set options: target address, port, etc.
   4. PAYLOAD  — choose what to deliver (e.g. a shell)
   5. RUN      — launch the exploit
   6. RESULT   — on success, you get a session on the target

A crucial caveat — a framework is a convenience, not a replacement for understanding. Metasploit makes running an exploit straightforward; it does not teach you what the exploit does, why it works, or why it sometimes fails. Treat it as a power tool wielded by someone who understands the underlying work — never as a substitute for that understanding. A person who only knows “run Metasploit” is lost the moment it doesn’t just work.

Part 5: The Exploitation Workflow in Context

Exploitation doesn’t stand alone — it slots into the Phase 3 chain. Pulling the pieces together:

   3.1  SCAN          → service X, exact version identified
            │
            ▼
   2.10 RESEARCH      → that version has a known CVE
            │
            ▼
   3.3  FIND EXPLOIT  → existing exploit code / a Metasploit module
            │            exists for that CVE
            ▼
   3.3  EXPLOIT       → run it (authorized target) → a session/shell
            │
            ▼
        FOOTHOLD      → access on the machine — usually LOW-privileged
            │
            ▼
   3.4  PRIVILEGE ESCALATION → low-privileged → admin/root
            │
            ▼
   3.5  go from one machine → the whole network

This is the same picture as 3.2’s foothold diagram, with exploitation as the alternative route in: 3.2 got a foothold via misconfiguration (weak/default/anonymous access); 3.3 gets a foothold via a vulnerability in the service itself. Real engagements use whichever works — often both.

After a successful exploit comes post-exploitation: understanding what you have access to, what the machine is, what’s reachable from it. Two important sub-ideas you’ll develop in 3.4–3.5:

• Pivoting — using a compromised machine as a stepping-stone to reach other machines that weren’t reachable from outside (conceptually related to SSRF in 2.8 — a foothold becomes a relay deeper into the network).
• Persistence — establishing a way to retain access. In authorized testing, persistence is used carefully and always cleaned up afterward; it’s a thing real attackers do, and testers must both understand it and handle it responsibly.

Part 6: The Defense — A Preview of Phase 4

The offense/defense mirror, and arguably the most important “why” of this page. Defending against exploitation is built across Phase 4 — hardening (4.4), monitoring and detection (4.6), incident response (4.7), and vulnerability management (4.8). The shape:

• Patch — promptly and systematically. Since most real exploitation uses known vulnerabilities against unpatched systems (Part 2), timely patching defeats most of it outright. Vulnerability management (4.8) is the organized process of finding, prioritizing, and patching known vulnerabilities — and it is one of the highest-value defensive functions precisely because of what this page shows.
• Reduce attack surface — fewer exposed services means fewer exploitable targets (0.4, 4.4). An exploit needs a reachable vulnerable service.
• Defense in depth — so a single exploited service doesn’t mean total compromise. Segmentation limits how far a foothold reaches (1.1, 4.3, 4.4); least privilege limits what an exploited process can do.
• Detection and monitoring — exploitation and post-exploitation generate signals: unusual processes, unexpected connections, new sessions. Monitoring (4.6) is how a defender notices an attacker who got in.
• Incident response — assuming breach (1.1), have a plan for when an exploit succeeds: contain, investigate, recover (4.7).

🔑 The deep lesson — and the reason exploitation is on the curriculum even for someone who wants to be defensive: once you have seen a known, patched-years-ago vulnerability turn into a shell on a machine in seconds, “keep your systems patched” stops being a platitude and becomes an obvious, urgent priority. Understanding the attack is what makes the defense feel real.

📓 Key Terms

🧪 Hands-On Lab

Exploitation runs only against your own lab VMs (Phase 0.5) or authorized practice platforms. Exploits can crash and damage systems — never run them against anything you don’t own or aren’t explicitly authorized (and scoped) to exploit. Read any exploit code before running it (0.6).

Task 1 — Pick a known-vulnerable target. Use a deliberately vulnerable VM in your lab (e.g. Metasploitable, set up in 0.5) — these intentionally run services with well-known vulnerabilities, expressly for this practice.

Task 2 — Identify a vulnerability. From your 3.1 infrastructure map, take a service and version on the target. Research it: find a known CVE for that version in a public vulnerability database (the 2.10 skill).

Task 3 — Explore Metasploit. Launch Metasploit in Kali. Search for an exploit module matching the CVE / service from Task 2. Read the module’s description and options. Understand what it targets before running anything.

Task 4 — Run an exploit (your lab only). Follow the framework workflow from Part 4: select the exploit module, configure its options for your victim VM, choose a payload (a shell), and run it. On success, you have a session on the machine.

Task 5 — Read an exploit’s code. Find the standalone exploit code for one CVE in a public exploit database. Read it (don’t necessarily run it) — apply the 0.6 skill. What vulnerability does it target? What does it send? What would the payload do?

Task 6 — Explore post-exploitation. With your session from Task 4, look around the compromised machine: who are you (which user?), what is this machine, what’s on it. Note your privilege level — this is the starting point for 3.4.

Task 7 — Reflect as a defender. Write a short note: that exploit used a known, long-patched vulnerability. How quickly did known-vuln + unpatched-service become a shell? What single defensive action (Part 6) would have stopped it? This reflection is the bridge to Phase 4.

⚠️ Common Mistakes

• Running exploits on unauthorized targets. Exploits are active attacks that can crash and damage systems. Your lab and explicitly-scoped authorized targets only.
• Running exploit code without reading it. Public exploits can be unreliable, destructive, or malicious to you (0.6). Read before you run.
• Treating Metasploit as a substitute for understanding. A framework runs exploits; it doesn’t teach what they do or why they fail. Understand the underlying work — tool-only operators are lost when the tool doesn’t just work.
• Chasing 0-days. Practical work overwhelmingly uses known vulnerabilities against unpatched systems. Original exploit development is a specialization, not a prerequisite.
• Forgetting exploitation can break things. Some exploits crash services by design or by unreliability. This is exactly why engagement rules restrict exploitation — respect that.
• Stopping at the foothold. The exploit is a means; a foothold is usually low-privileged. 3.4 and 3.5 are where it leads.

✅ Recap & What’s Next

• An exploit takes advantage of a specific vulnerability; a payload is what runs on the target afterward — commonly a shell. Most real compromise uses known vulnerabilities against unpatched systems, not 0-days.
• Practitioners mostly use and understand existing exploits — via public exploit code and frameworks like Metasploit — rather than writing them; a framework is a power tool, never a substitute for understanding.
• Defense (Phase 4) is patching and vulnerability management above all, plus attack surface reduction, defense in depth, detection, and incident response — and seeing exploitation firsthand is what makes those priorities feel real.

Next (3.4): Your exploit or service attack gave you a foothold — but as a low-privileged user. Page 3.4 covers privilege escalation: the art of climbing from limited access to full administrative control of a machine.