Exploitation & Getting a Shell

You've scanned, you've enumerated, and you have a list of services with specific versions and misconfigurations. Now comes the question every new security practitioner finds intimidating: how do you actually turn "Apache 2.4.38" into a shell? This lesson covers the professional workflow for finding, evaluating, and safely executing exploits - and what to do the moment you land one.

The Exploitation Mindset

Before you run anything, ask three questions:

1. Is this target vulnerable? Version matches the affected range, and the configuration is exploitable.
2. Is this exploit safe to run here? Does it cause service disruption? Does it corrupt data? In production environments, even authorized tests require selecting low-impact exploits.
3. Will it demonstrate the finding clearly? A shell is convincing evidence. A crash is not - it proves a DoS, but doesn't demonstrate what an attacker could actually do with the access.

Experienced testers test exploits in a local lab replica before running them against client systems. This is especially important for buffer overflow exploits, which can crash processes if the offset is slightly wrong.

Finding Exploits: searchsploit and Exploit-DB

Exploit-DB (exploit-db.com) is the largest public database of exploits and vulnerable software proof-of-concepts, maintained by Offensive Security. searchsploit is the offline CLI tool that queries a local copy of the database.

When evaluating an exploit from searchsploit or Exploit-DB:

• Read the code before running it. Understand what it does. Malicious exploit code exists - even in public databases. Read the file.
• Check the affected version range. The exploit title may say "Apache 2.4.49" but your target runs 2.4.38. Confirm the CVE affects your specific version.
• Check the proof-of-concept vs weaponized distinction. Many PoCs demonstrate that a vulnerability exists without providing a working exploit. Metasploit modules are typically more reliable.
• Look up the CVE independently. NVD (nvd.nist.gov), CVEdetails.com, and vendor advisories give you CVSS scores and detailed description of what the vulnerability actually is.

Metasploit: The Framework

Metasploit is an open-source penetration testing framework. Its power is in organization: hundreds of exploits, payloads, and auxiliary modules - all with a consistent interface, reliable payload generation, and built-in handler management.

msfconsole Workflow

The msfconsole workflow is always: search → use → show options → set → run (or exploit). Almost every module follows this pattern.

Meterpreter: The Smart Shell

When a Metasploit exploit succeeds, the default payload is often Meterpreter - an in-memory agent with extensive post-exploitation capabilities.

Meterpreter runs entirely in memory - no file is written to disk. This makes it harder for antivirus to detect, but also means it disappears if the process crashes or the system reboots.

Reverse Shells vs Bind Shells

Understanding shell direction is fundamental.

Reverse shell: The target machine connects back to your machine.

Attacker machine (listening) ← Target machine (initiates connection)

A reverse shell works through NAT and most firewalls because the connection is outbound from the target. The attacker starts a listener (nc -lvnp 4444), and the exploit triggers the target to connect back.

Bind shell: The target machine opens a listening port; you connect to it.

Attacker machine (initiates connection) → Target machine (listening)

Bind shells require the attacker to reach the target's listening port directly. This fails if the target is behind NAT or if egress filtering blocks the connection. Bind shells are less common in external engagements.

In almost all modern pentests: use reverse shells.

Starting a Netcat Listener

msfvenom: Payload Generation

msfvenom generates standalone payloads - EXE files, PHP webshells, Python scripts, DLLs - that you can deploy without using Metasploit's exploit modules. This is useful when you have a file upload vulnerability or need to drop a payload manually.

After generating a payload, start the corresponding Metasploit handler:

Stabilizing a Shell

Raw netcat shells are fragile. Pressing Ctrl+C kills the connection instead of interrupting a command. Tab completion doesn't work. Terminal size is wrong. The first thing you do after landing a raw shell is stabilize it.

Python TTY Upgrade

After these steps you have a fully interactive shell: Ctrl+C works, tab completion works, nano and vim work, and the terminal size is correct.

rlwrap for Instant Improvement

Web Exploitation: A Brief Map

For web targets, exploitation often doesn't require a full exploit framework. Common entry points:

Command injection: Input fields that pass data to OS commands - tested with ;id, | whoami, and similar. If the response contains command output, you have execution.

File upload bypasses: Upload a PHP webshell disguised as an image. Common bypasses: change MIME type in the request, use double extensions (shell.php.jpg), exploit client-side-only validation.

SQL injection to RCE: In MySQL, INTO OUTFILE can write files if the web server path is known and MySQL has write permissions. Combined with a PHP webshell: database query to RCE.

Deserialization: Sending crafted serialized objects to applications that deserialize them without validation. Java (ysoserial), PHP (phpggc), .NET - complex but devastating.

Each of these is a lesson in its own right. The common thread: find an input that reaches an execution context, craft input that executes your code, catch the callback.

What Happens Right After Exploitation

The instant you land a shell, stop and document. Screenshot the shell prompt, whoami output, and hostname. This is your primary evidence for the finding.

Then do the minimum needed to establish your position:

This tells you: what user you are, what machine you're on, its network position, what other users exist, and the kernel version. Everything you need to plan your next step - privilege escalation, lateral movement, or stopping here to document if this is sufficient evidence.

Key Takeaways

• Read the exploit before running it. Understand what it does. Malicious or poorly-written exploit code is a real risk.
• The msfconsole workflow is: search → use → show options → set → run.
• Reverse shells connect back to your listener; they work through NAT and firewalls. Bind shells require direct inbound access to the target.
• msfvenom generates standalone payloads for scenarios where you can't use Metasploit's exploit modules.
• Always stabilize a raw shell immediately - Python PTY upgrade or rlwrap makes it usable for real work.
• The first five commands after landing a shell establish situational awareness and produce the evidence you need for your report.
• Never go beyond what's necessary to demonstrate the finding. The goal is evidence, not maximum access.