Skip to content
Lesson 6 of 8

Exploitation

9 min read

The Purpose of Exploitation

Exploitation is the phase where you demonstrate that a vulnerability is real by leveraging it to gain access or a controlled effect. Its purpose is not to cause harm, but to prove impact: to turn a theoretical finding into concrete evidence that an attacker could compromise the system. This demonstration is what convinces management to prioritize remediation.

In a professional engagement, exploitation is deliberate and measured. It is not about throwing everything you have at a target, but about selecting tests that demonstrate real risk without compromising the stability or integrity of the systems. A responsible pentester exploits only what is necessary to prove the point and stops there.

It is crucial to stay within scope and the rules of engagement at all times. Some vulnerabilities can be demonstrated safely; others, especially those that can cause denial of service or data corruption, are usually documented without being actively exploited to avoid damage.

Ethical framing: exploitation proves impact, it does not cause harm. It runs only within scope, in a measured and reversible way, and no data is ever extracted beyond the minimum needed to demonstrate access.

Responsible Exploitation

The golden rule of ethical exploitation is: prove impact without causing harm. Before executing any exploit, assess its possible side effects. An exploit that can crash a production service is rarely worth the disruption; in those cases it is enough to document that the vulnerable condition exists and explain the potential impact.

Communication is part of responsible exploitation. If you discover an actively exploitable critical vulnerability, the rules of engagement usually indicate notifying the client immediately rather than waiting for the final report. The same applies if during exploitation you notice that a system is already compromised by a third party: you stop and communicate.

You must also protect data. If exploitation gives you access to sensitive information, you do not extract it beyond what is necessary to prove access. Taking a minimal capture that demonstrates the compromise is enough; copying entire databases exceeds the purpose and may violate privacy regulations.

The Metasploit Framework

Metasploit is the most well-known exploitation framework in the world. It provides an organized collection of modules: exploits that leverage specific vulnerabilities, payloads that run after compromise, encoders, and auxiliary modules for scanning and enumeration. Its msfconsole offers a unified interface to search, configure, and launch these modules.

The typical flow in Metasploit is to search for a module relevant to the identified vulnerability, configure its options (such as the target host and port), select an appropriate payload, and verify that the target is vulnerable before any measured action. The framework manages much of the technical complexity, which lets you focus on the engagement logic.

The following flow is illustrative and conceptual, with generic placeholders and an authorized lab IP. It shows how you navigate the console, not a turnkey attack:

msfconsole                       # opens the framework console
search type:exploit <service>    # searches modules by service/CVE
use <path/to/module>             # selects a module
show options                     # shows required parameters
set RHOSTS 10.0.0.5              # sets the target (authorized lab IP)
set LHOST 10.0.0.10              # sets the listening host
check                            # verifies if the target is vulnerable, without exploiting

The example deliberately stops before running exploit or run. The check step is a non-destructive verification: it confirms whether the target is susceptible without launching the payload. In a real engagement, the final execution happens only within scope, in a measured way, and with full awareness of the side effects. Understanding each step matters more than memorizing commands.

Metasploit also includes Meterpreter, an advanced payload that offers an interactive post-exploitation session. Its educational value is enormous: it lets you understand how exploits work without writing each one from scratch. Even so, understanding the fundamentals behind each module is what distinguishes a pentester from a mere tool operator.

Understanding Payloads

A payload is the code that runs on the target system after an exploit succeeds. Conceptually, the exploit is the key that opens the door and the payload is what you do once inside. Payloads can be as simple as opening a shell or as sophisticated as an interactive session with multiple capabilities.

There are two main connection models. A bind shell opens a port on the target waiting for the attacker to connect, while a reverse shell makes the target connect back to the attacker, which usually bypasses permissive outbound firewalls better. Understanding this difference is key to choosing the right payload for the network topology.

It is also worth distinguishing staged and stageless payloads. A staged payload is delivered in stages: a small initial component (the stager) downloads the rest at runtime, which reduces the initial size. A stageless payload travels complete in a single piece, more robust but heavier. The choice depends on network constraints and the tolerable size.

There is also msfvenom, Metasploit's utility for generating standalone payloads in different formats. Conceptually, it serves to produce the code that would demonstrate execution on the target when the vector does not come from a ready-made module. In this course we mention it as a concept: generating weaponized artifacts is outside the training scope and only makes sense within an authorized engagement.

In an ethical context, payloads are used to demonstrate access, not to install persistent malware or cause harm. The distinction is fundamental: the same techniques an attacker would use to maintain prolonged control, the pentester uses in a bounded and reversible way, removing any trace at the end and documenting everything performed.

Web Applications and Other Surfaces

Not all exploitation goes through Metasploit. In web applications, Burp Suite is the central tool: its proxy lets you intercept and manipulate requests to test SQL injection, cross-site scripting, access control flaws, and more. Burp Repeater lets you resend a single manually adjusted request, and Intruder automates controlled variations over a parameter until impact is confirmed.

Each surface has its toolkit. The following commands are illustrative (no real targets), to show the invocation form, not to copy against a system:

hydra -l <user> -P <list> <service>://<authorized-host>   # authorized brute force
hashcat -m <mode> <hashes.txt> <wordlist>                 # assess strength of captured hashes
john --wordlist=<wordlist> <hashes.txt>                   # alternative to hashcat

Hydra tests credential combinations against services, always with explicit authorization. For hashes legitimately captured during the engagement, Hashcat or John the Ripper help assess the strength of the organization's passwords. The choice of tool depends on the vulnerability and the objective: what matters is understanding what each one does and why, instead of running commands blindly. A mature pentester reasons about the impact before acting.

Classes of Exploitable Vulnerabilities

Understanding what type of flaw you are leveraging clarifies why an exploit works and how it is remediated. At a high level, the most common classes are:

  • Injection: the system interprets user-controlled data as code or commands (SQL, command, LDAP injection). The root cause is mixing data and control without strict separation.
  • Memory corruption: buffer overflows and memory-management errors in native software that allow altering the execution flow. They are technically complex and very sensitive to the exact version.
  • Authentication and access-control flaws: weak credentials, poorly managed sessions, or authorization that does not correctly validate the user's privilege level.
  • Insecure configurations: services exposed with default values, lax permissions, or debug features enabled in production.
  • Insecure deserialization: processing serialized objects from untrusted sources, which can lead to code execution.

Recognizing the class helps you reason about the real impact and, above all, write a remediation recommendation that attacks the root cause and not just the symptom. A pentester who understands the class of the flaw communicates risk better than one who only knows that "the exploit worked".

MITRE ATT&CK Mapping

It helps to place exploitation within a recognized framework. MITRE ATT&CK catalogs adversary tactics and techniques observed in the real world. Exploitation touches two tactics directly: Initial Access (TA0001), the set of techniques for gaining the first foothold in the network, and Execution (TA0002), the techniques for running attacker-controlled code on a system.

Mapping your findings to these tactics makes the report clearer and more actionable: the client understands not only what you found, but how it fits into real adversary behavior and which defensive controls correspond to each stage.

Mini-Scenario: Measured Exploitation

Imagine you confirm a vulnerable service in the authorized lab. You run check and the target responds as susceptible. Before proceeding, you assess the side effect: the module is known to potentially crash the service if the version does not match exactly. There the responsible decision is not to actively exploit: you document the condition, the detected version, and the potential impact, and mark it as confirmed by non-destructive verification.

Conversely, if the exploit is stable and reversible, you obtain a session, take a minimal capture that proves access (for example, the process user identifier), and close the session. You do not copy data, you leave no artifacts, and you record every step. The criterion is always the same: when the risk of harm outweighs the value of the demonstration, document instead of exploit.

After Gaining Access

Gaining access is a milestone, but the work does not end there. Each compromise must be documented meticulously: which vulnerability was exploited, with which tool, what access was obtained, and what evidence supports it. This documentation feeds both the post-exploitation phase and the final report.

Successful exploitation also opens the door to the next phase: post-exploitation, where you assess how far an attacker could really go. But before moving on, make sure you have recorded the state of the system and that you can restore any changes you made. Reversibility and cleanup are responsibilities of the ethical pentester, not options.

Responsible Exploitation Checklist

  • Prior verification: use check or another non-destructive test before exploiting; confirm the target is within the authorized scope.
  • Risk assessment: if there is a risk of DoS or data corruption, document instead of actively exploiting.
  • Data minimization: extract only the minimal evidence that demonstrates access; never copy entire databases.
  • Reversibility: leave the system as you found it; remove sessions, artifacts, and any changes made.
  • Documentation: record the vulnerability, tool, payload, access obtained, and evidence, mapped to MITRE ATT&CK.
  • Critical notification: faced with an actively exploitable critical vulnerability or an already-compromised system, stop and notify the client immediately.