Linux-hosted web applications and application servers can expose valuable post-exploitation telemetry when audit logging is available. A successful RCE does not necessarily produce a unique malware file or an obvious exploit alert. Instead, it may appear as a web application context suddenly executing shells, download utilities, interpreters, or system discovery commands.
The source defines a behavioral hunt that looks for exactly this type of activity.
What the Detection Looks For
The query searches Linux audit telemetry for commands commonly associated with shell access, reconnaissance, payload delivery, and follow-on execution. These include:
sh,bash,dash, andzsh;curlandwget;nc,ncat, andsocat;python,python3, andperl;chmodandchown;whoami,id, anduname.
The hunt becomes more focused when these commands execute from web or application directories such as /var/www, /srv/www, Tomcat, SAP, webapps, public_html, Node modules, Next.js, or Langflow directories.
The source associates this coverage with RCE affecting SAP NetWeaver, React and Next.js, Langflow, ActiveMQ, cPanel, WordPress, Joomla, Oracle applications, appliances, and other Java, Python, PHP, or Node services.
Detection Query
rule.groups:*audit* and data.audit.command:(*sh* or *bash* or *dash* or *zsh* or *curl* or *wget* or *nc* or *ncat* or *socat* or *python* or *python3* or *perl* or *chmod* or *chown* or *whoami* or *id* or *uname*) and data.audit.cwd:(/var/www* or /srv/www* or /opt/tomcat* or /opt/sap* or /usr/sap* or /opt/*/webapps* or */public_html* or */node_modules* or */next* or */langflow*)
A broader version from the source removes the working-directory condition:
rule.groups:*audit* and data.audit.command:(*sh* or *bash* or *dash* or *zsh* or *curl* or *wget* or *nc* or *ncat* or *socat* or *python* or *python3* or *perl* or *chmod* or *chown* or *whoami* or *id* or *uname*)
The broader hunt produced 3,746 events during the previous 30 days.
Why Working Directory Context Helps
A command such as curl or python3 is common on many Linux systems. The value of the first query comes from combining the command with the execution context.
For example, a shell started from a directory related to a web application is more interesting than the same shell started from a known administrator's home directory. Likewise, whoami, id, or uname executed from a web application directory can be useful reconnaissance indicators when they appear unexpectedly.
The working directory therefore helps reduce the gap between a generic command hunt and application-focused post-exploitation detection.
Investigation Approach
When a match is found, analysts should review:
the executable path;
current working directory;
effective user and original audit user;
parent process;
full command line;
network connections following execution;
files created or modified;
application logs around the same timestamp.
A sequence such as an application context executing whoami, followed by curl, followed by a shell, is considerably more interesting than a single isolated command.
Tuning and Baseline Development
The source result count suggests that the broad command list can create significant noise. Tuning should therefore begin by separating application-specific execution from normal system administration.
Useful allow-list dimensions can include:
known automation accounts;
approved scripts;
maintenance windows;
expected application directories;
known deployment tooling;
known package-management jobs.
The goal is not to remove command-line visibility, but to preserve unusual combinations of command, directory, user, and application context.
Practical Value
This detection is useful because it does not depend on identifying a specific exploit payload. It looks for behavior that can occur after many different web application vulnerabilities.
For Linux servers monitored with Wazuh and audit telemetry, this approach can help identify the transition from vulnerable application to operating-system execution and provide a practical hunting layer across multiple technologies.

