---
title: Shell spawned by web process
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: Docs > Datadog Security > OOTB Rules > Shell spawned by web process
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Shell spawned by web process
Classification:attackTactic:[TA0003-persistence](https://attack.mitre.org/tactics/TA0003)Technique:[T1505-server-software-component](https://attack.mitre.org/techniques/T1505) 
## Goal{% #goal %}

Detects a shell or HTTP download utility executed by a web server or PHP process on a Linux host.

## Strategy{% #strategy %}

This rule monitors auditd `SYSCALL` records for the `execve` syscall where `@exe` is a shell, `curl`, `wget`, or `lwp-download`, and the process runs in a web server context. The rule identifies that context when `@UID` or `@EUID` is a web service account (`www-data`, `apache`, `nginx`, `http`, `wwwrun`, `lighttpd`, `php-fpm`, or `php`), or when the SELinux context in `@subj` is `httpd_t` or `httpd_sys_script_t`. PHP-FPM pools and Apache `mod_php` run PHP code as the web server account, so commands launched by a web shell or a remote code execution exploit inherit that account. A shell raises a Medium severity signal, and an HTTP download utility raises a Low severity signal. This rule requires an audit rule that logs `execve` for web service accounts, for example `-a always,exit -F arch=b64 -S execve -F euid=33 -k detect_execve_www`. Audit rules that only log interactive users (`auid>=1000`) do not record these executions.

## Triage and response{% #triage-and-response %}

- Identify the executed binary in `{{@exe}}` and the account in `{{@UID}}` on `{{host}}`.
- Retrieve the matching `EXECVE` record with the same `@event_id` to see the full command line that the web server ran.
- Review web server access logs on `{{host}}` around the signal time for requests to unusual scripts, file uploads, or exploit payloads.
- Check the web root for recently created or modified script files that could be a web shell.
- Look for follow-on activity from the same session, such as outbound connections, downloads, or access to credential files.
- Determine whether the web application is expected to run system commands, such as for image processing or scheduled maintenance.