Hello! Welcome to the final lesson in our module on Advanced Web Attacks & API Security.
In our last session, you learned how to take a single discovered vulnerability and weaponize it by scripting a proof-of-concept (PoC) in Python. This is a crucial skill, but the true art of hacking often lies in creativity—seeing how individual pieces of a puzzle fit together to create a bigger picture. That's what today's lesson is all about.
This lesson will focus on one of the most impactful concepts in offensive security: vulnerability chaining. We will cover the learning outcome: Chain multiple web vulnerabilities (e.g., SSRF + Command Injection) to achieve a critical impact. You'll learn how to identify and combine multiple, often lower-impact, vulnerabilities into a sequence that results in a significant compromise, such as Remote Code Execution (RCE).
The scripting skills you developed in the previous lesson will be directly relevant here, as complex chains are often difficult or impossible to execute without automation.
1. The Power of Chaining: From "Ping" to RCE
In bug bounties and penetration testing, the impact of a vulnerability directly correlates with the payout or the severity rating. A vulnerability that only reveals a version number is "Informational," while one that allows you to take over a server is "Critical." Vulnerability chaining is the process of combining several lower-impact flaws to climb this severity ladder.
There are several common patterns for vulnerability chaining:
- Creating Conditions: You use one vulnerability (e.g., File Upload) to place a file where a second vulnerability (e.g., Local File Inclusion) can execute it.
- Gaining Access: You use one vulnerability (e.g., Authentication Bypass) to reach an authenticated area of an application where a second vulnerability (e.g., Command Injection) exists.
- Pivoting/Proxying: You use one vulnerability (e.g., SSRF) to send requests from the server itself, allowing you to reach and exploit internal services that are not exposed to the internet.
Today, we'll explore concrete examples of these patterns, with a special focus on Server-Side Request Forgery (SSRF) as a powerful first step in a chain.
2. Case Study 1: SSRF + Command Injection
Let's start with the classic chain mentioned in the learning outcome: combining SSRF with Command Injection. Imagine you find an SSRF, but it's "blind"—the server makes a request to a URL you provide, but you don't see the response. You might only be able to confirm it by getting a pingback to your own server. On its own, this might be rated as a low or medium severity issue. The question is: can we make it do more?
This is where chaining comes in. If the server-side code that handles the URL is not only fetching it but also processing it in some way, we might be able to inject commands.
From a lame Server-Side Request Forgery to Remote Code Execution
The video 'From a lame Server-Side Request Forgery to Remote Code Execution' by thehackerish provides a perfect, real-world example of escalating a blind SSRF to full RCE.
Watch this walkthrough and focus on the attacker's methodology: (02:22 - 04:18): Notice how the SSRF is first identified and confirmed. The presenter correctly assesses its initial impact as low because it doesn't return any data. (04:18 - 05:38): This is the critical chaining step. See how the payload is modified to include a command surrounded by backticks (`whoami`). On Linux systems, backticks are used for command substitution, meaning the whoami command is executed first, and its output replaces the backticked expression in the string. (05:38 - 07:19): Observe how the impact is escalated. The attacker proves arbitrary command execution by first reading /etc/passwd and then writing a file to /tmp. (07:19 - 08:34): Finally, see how full RCE is achieved by writing an SSH public key to the authorized_keys file, granting persistent shell access. This demonstrates maximum impact.
This case study shows how a "lame" SSRF, which many might dismiss, can become a critical RCE by chaining it with a command injection flaw in the same feature.
3. Case Study 2: SSRF to LFI to RCE
Let's look at another common pattern. What if the SSRF vulnerability allows the use of different URL schemes, like file:///? This transforms the SSRF into a Local File Inclusion (LFI) vulnerability, allowing you to read arbitrary files from the server's filesystem.
From SSRF to LFI to RCE! - Gemini Pentest Ep6
This next video, also from thehackerish, 'From SSRF to LFI to RCE!', demonstrates this exact pattern.
As you watch, consider the following points: (00:00 - 03:15): The attacker uses the existing SSRF with a file:/// payload to confirm they can read local files like /etc/passwd and application source code. This is the first link in the chain: SSRF -> LFI. (03:15 - 04:23): Knowing they can read files, they target a high-value file: a user's private SSH key located at /home/user/.ssh/id_rsa. Successfully exfiltrating this key is a critical step. (04:23 - 06:04): The chain is completed. The attacker uses the stolen private key to authenticate to the server via SSH, achieving RCE. The full chain is SSRF -> LFI -> RCE.
Test your understanding!
You have found an SSRF vulnerability. In the first case study, it was escalated via command injection using backticks. In the second, it was escalated by reading local files using file:///.
What fundamental difference in the server-side processing of the URL would lead to these two different escalation paths?
Show answer
The difference lies in what the server does with the user-supplied URL string.
- SSRF + Command Injection: This path is likely possible because the URL string is passed to a system shell command (e.g.,
system("wget " + url)orexec("curl " + url)). The shell interprets the backticks, executes the command within them, and substitutes its output into the command string beforewgetorcurlis even run. - SSRF -> LFI: This path is possible because the server's HTTP client library or function (e.g., in Python, Java, or PHP) is versatile and supports multiple URL schemes, including
file:///. The string is not passed to a system shell, but directly to a library function that can handle file-based URIs, thus reading from the local filesystem.
Understanding this distinction is key to predicting how an SSRF might be escalated.
4. Advanced Chaining: SSRF as a Proxy to Internal Services
Now for a more complex scenario that directly leverages your software engineering background. Sometimes, you'll find an unauthenticated SSRF on a public-facing server, and you'll know (from reconnaissance) that a separate, vulnerable service is running on an internal, firewalled port. Neither vulnerability is exploitable on its own from the outside.
The chain: use the SSRF as a proxy to forward your exploit payloads to the internal service. This requires a deep understanding of the protocols involved and solid scripting skills.
HTB: Backfire | 0xdf hacks stuff
The write-up 'HTB: Backfire' by 0xdf is a masterclass in vulnerability chaining. We will focus on the first exploit chain, which uses an unauthenticated SSRF to exploit an authenticated RCE on an internal service.
This is a detailed article. Follow these steps to understand the chain: Read the 'Shell as ilya' -> 'Strategy' section: This gives you the high-level overview of the chain: SSRF + Authenticated RCE. Read the 'SSRF' section: Understand the first vulnerability, an unauthenticated SSRF in Havoc C2. Note that a PoC script already exists. Read the 'Authenticated RCE' section: Understand the second vulnerability, a command injection flaw that requires authentication and is only accessible on an internal port (blocked by a firewall). Carefully read the 'Create Exploit' section: This is the core of the chain. The author modifies the SSRF exploit script to act as a proxy. Instead of sending a simple HTTP GET request, the script is adapted to: Initiate a WebSocket connection to the internal service through the SSRF. Craft and send raw WebSocket frames (for authentication and the RCE payload) through the established SSRF tunnel. Review the 'Execution' and 'Shell' sections: See the final result of this scripted chain: successful RCE. This is a fantastic example that builds directly on our last lesson. You're not just running a script; you're architecting an exploit by combining two PoCs and making them work together.
This type of chaining, where one vulnerability acts as a communication channel to exploit another, is a hallmark of advanced penetration testing.
5. A Glimpse into Complex, Multi-Stage Chains
In the wild, especially when targeting complex enterprise software, exploit chains can involve even more steps. A notable real-world example is CVE-2025-61882 in Oracle E-Business Suite.
Oracle EBS CVE-2025-61882 Vulnerability
To see what a high-profile, multi-stage chain looks like, let's briefly review the Picus Security blog post on an Oracle EBS vulnerability.
You don't need to dive deep, but read the 'Oracle EBS CVE-2025-61882 Exploit Chain' section. Notice the sequence of flaws required for RCE: SSRF: To initiate a request to an arbitrary host. CRLF Injection: To manipulate the HTTP request sent via the SSRF, turning a GET into a POST and injecting headers. Authentication Bypass: Using the crafted request to hit an internal endpoint and use path traversal to access a restricted page. RCE via Unsafe XSLT Processing: Forcing the internal page to load and execute a malicious XSL stylesheet. This shows how four distinct vulnerabilities were woven together to achieve a critical impact.
This example serves to illustrate the creative and complex nature of vulnerability research at the highest levels.
Conclusion
Today you've moved beyond single vulnerabilities and into the mindset of an advanced attacker who sees a system not as a set of isolated features, but as an interconnected web of potential opportunities. Vulnerability chaining is a creative process that turns seemingly minor issues into critical security breaches.
Key Takeaways:
- Impact is Everything: Chaining is the primary method for escalating the impact of lower-severity vulnerabilities.
- SSRF is a Gateway: Server-Side Request Forgery is one of the most powerful starting points for a chain, enabling command injection, LFI, or access to internal networks.
- Methodology is Key: A systematic approach—find a foothold, analyze what it gives you, and look for the next link in the chain—is essential.
- Scripting is Your Superpower: As chains become more complex, scripting becomes non-negotiable. The skills from our previous lesson are the tools you'll use to build these complex exploits.
Next Lesson Preview:
With this lesson, you've completed the module on web and API attacks. You now have the skills to find, exploit, and chain vulnerabilities to gain initial access to a target system. But what happens after you get that first shell?
In our next module, "Privilege Escalation & Post-Exploitation," we will answer that question. You will learn how to take your initial low-privilege access and escalate it to the highest level on both Linux and Windows systems—gaining root or NT AUTHORITY\SYSTEM—and how to maintain your presence on the compromised host.