Unusual File Creation via Web Server

This rule leverages the "new_terms" rule type to detect unusual file creations originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical file creations. As file creations from web server processes are common, the "new_terms" rule type approach helps to identify deviations from normal behavior.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/24"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/08/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule leverages the "new_terms" rule type to detect unusual file creations originating from web server
 11processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system,
 12often resulting in atypical file creations. As file creations from web server processes are common, the
 13"new_terms" rule type approach helps to identify deviations from normal behavior.
 14"""
 15from = "now-9m"
 16index = ["logs-endpoint.events.file*"]
 17language = "kuery"
 18license = "Elastic License v2"
 19name = "Unusual File Creation via Web Server"
 20note = """ ## Triage and analysis
 21
 22> **Disclaimer**:
 23> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 24
 25### Investigating Unusual File Creation via Web Server
 26
 27This alert flags a Linux web server process creating or renaming a file in web content or application directories that it does not normally touch, which can reveal a compromised service writing attacker-controlled content. That matters because web-facing processes rarely need to drop new executable or template files outside normal deployment activity. A common pattern is an intruder exploiting a vulnerable upload handler or plugin to place a web shell, JSP, PHP, or script-backed page under the site root for persistent remote access.
 28
 29### Possible investigation steps
 30
 31- Determine whether the file aligns with an approved deployment, plugin or theme update, package installation, or administrator change in the same time window by reviewing change records and system update history.
 32- Inspect the file contents, hash, ownership, permissions, and timestamps for signs of a web shell, dropped payload, hidden redirect, or script stager, and compare it with known-good application files from the same host or image.
 33- Review the web service’s parent and child activity around the event for spawned shells, interpreters, archive extraction, or permission changes that would indicate exploitation followed by payload execution or persistence setup.
 34- Correlate nearby web access, reverse-proxy, and application log events to identify suspicious upload, template-edit, admin-panel, deserialization, or remote-code-execution requests immediately before the file appeared and any follow-up requests to the new file.
 35- Scope the compromise by searching the host and peer web servers for similarly named files, unexpected cron or systemd persistence, modified startup scripts, or outbound connections made by the web service account after the creation event.
 36
 37### False positive analysis
 38
 39- Approved application deployment, patching, or first-run initialization can cause the web server or application server to create new files in the web root, so verify the event time against authorized change activity and confirm the file path, owner, and hash match the expected release contents.
 40- Legitimate web application features such as user uploads or automatic generation of images, media, attachments, or cache files can create new content under upload-facing directories, so review nearby web or application requests and confirm the file extension, location, and contents are consistent with normal business use.
 41
 42### Response and remediation
 43
 44- Isolate the affected web server from the internet and internal network, remove it from the load balancer, and temporarily disable the compromised site or virtual host while keeping only secured management access for containment.
 45- Eradicate attacker persistence by deleting the malicious web shell or dropped script, removing any unauthorized cron jobs, systemd units, startup scripts, SSH keys, or writable symlinks created by the web service account, and disabling any backdoored application user or admin account.
 46- Restore the service to a known-good state by rebuilding the host from a trusted image or redeploying the application from clean source, recovering web content and configuration from a verified backup taken before the file appeared, and validating expected ownership and permissions across the web root.
 47- Rotate all secrets exposed to the host, including web application credentials, API tokens, database passwords, and TLS private keys, and invalidate active sessions or cookies if the malicious file could have intercepted user or administrator access.
 48- Escalate to incident response immediately if you find the same malicious file on multiple web servers, observe the web process spawning a shell or making outbound command-and-control connections, or confirm access to databases, payment data, or domain credentials.
 49- Harden the environment by patching the exploited CMS, plugin, framework, or server component, restricting the web service account to only required write paths, disabling script execution in upload directories, and adding detections for new executable or template files under the web root.
 50"""
 51risk_score = 21
 52rule_id = "9ab15ca6-be79-4718-bae6-5978a3ac6a46"
 53severity = "low"
 54tags = [
 55  "Domain: Endpoint",
 56  "Domain: Web",
 57  "OS: Linux",
 58  "Use Case: Threat Detection",
 59  "Tactic: Persistence",
 60  "Tactic: Execution",
 61  "Tactic: Command and Control",
 62  "Tactic: Initial Access",
 63  "Data Source: Elastic Defend",
 64  "Resources: Investigation Guide"
 65]
 66timestamp_override = "event.ingested"
 67type = "new_terms"
 68query = '''
 69event.category:file and host.os.type:linux and event.action:(creation or rename) and (
 70  process.name: (
 71    "nginx" or "apache2" or "httpd" or "caddy" or "lighttpd" or "httpd.worker" or "httpd-worker" or "httpd-prefork" or
 72    "php-cgi" or "php-fcgi" or "php-cgi.cagefs" or "frankenphp" or "lshttpd" or "litespeed" or "openlitespeed" or
 73    "fcgiwrap" or "uwsgi" or "daphne" or "uvicorn" or "hypercorn" or "granian" or "waitress-serve" or "flask" or
 74    "puma" or "unicorn" or "unicorn_rails" or "thin" or "rackup" or "mongrel_rails" or "starman" or "plackup" or
 75    "twiggy" or "hypnotoad" or "starlet" or "unitd" or "unitd-debug" or php-fpm* or lsphp* or gunicorn* or
 76    "nginx3" or "apache" or *.cgi or *.fcgi
 77  ) or
 78  (process.name: "java" and file.extension: ("jsp" or "jspx" or "jspf" or "tag" or "tagx" or "war" or "ear")) or
 79  (process.name: ("node" or "nodejs") and file.extension: ("js" or "mjs" or "cjs" or "ts" or "mts" or "cts")) or
 80  (process.name: "dotnet" and file.extension: ("cshtml" or "razor")) or
 81  (process.name: (mono* or xsp* or mod-mono-server* or fastcgi-mono-server*) and file.extension: ("asp" or "aspx" or "ashx" or "asmx" or "ascx" or "cshtml")) or
 82  (process.name: python* and file.extension: ("wsgi" or "cgi" or "fcgi")) or
 83  (process.name: ruby* and file.extension: ("erb" or "ru")) or
 84  (process.name: perl* and file.extension: ("cgi" or "fcgi" or "psgi")) or
 85  (process.name: lua* and file.extension: ("lua" or "luac"))
 86) and
 87file.path:(
 88  /home/*/* or /var/www/* or /srv/www/* or /srv/http/* or /usr/share/nginx/* or /var/lib/nginx/* or
 89  /usr/share/caddy/* or /usr/local/lsws/* or /opt/bitnami/* or */sites/*/files/* or /opt/easyengine/* or
 90  */wp-content/* or */httpdocs/* or */httpsdocs/* or */htdocs/* or */wwwroot/* or */webroot/* or */cgi-bin/* or
 91  */upload/* or */uploads/* or */images/* or */media/* or */userfiles/* or */attachments/* or
 92  /usr/share/webapps/* or /usr/share/zabbix/* or /usr/share/phpmyadmin/* or /usr/share/phpMyAdmin/* or
 93  /var/lib/roundcube/* or /usr/share/cacti/* or /usr/share/nagios* or /var/lib/tomcat* or /usr/share/tomcat* or
 94  /usr/local/tomcat/* or /opt/tomcat* or /var/lib/jetty* or /usr/share/jetty* or
 95  /usr/local/cpanel/* or /usr/local/psa* or /opt/psa/admin/* or /usr/share/webmin/* or
 96  /usr/libexec/webmin/* or /usr/local/nginx/* or /usr/local/apache* or /usr/sap/* or /opt/rh/* or
 97  */public_html/* or */private_html/* or */public/* or */private/* or */deployments/* or */autodeploy/* or
 98  */dropins/* or */installedApps/* or /srv/caddy/* or /usr/local/openresty/* or */fileadmin/* or */custom_apps/* or
 99  */vhost* or /opt/apache-tomcat* or /opt/jetty* or /usr/local/jetty* or */wildfly*/* or */jboss*/* or */glassfish/* or
100  */user_projects/domains/* or */resin*/webapps/* or */installedApps/*
101)
102'''
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106
107[[rule.threat.technique]]
108id = "T1505"
109name = "Server Software Component"
110reference = "https://attack.mitre.org/techniques/T1505/"
111
112[[rule.threat.technique.subtechnique]]
113id = "T1505.003"
114name = "Web Shell"
115reference = "https://attack.mitre.org/techniques/T1505/003/"
116
117[rule.threat.tactic]
118id = "TA0003"
119name = "Persistence"
120reference = "https://attack.mitre.org/tactics/TA0003/"
121
122[[rule.threat]]
123framework = "MITRE ATT&CK"
124
125[[rule.threat.technique]]
126id = "T1059"
127name = "Command and Scripting Interpreter"
128reference = "https://attack.mitre.org/techniques/T1059/"
129
130[[rule.threat.technique.subtechnique]]
131id = "T1059.004"
132name = "Unix Shell"
133reference = "https://attack.mitre.org/techniques/T1059/004/"
134
135[rule.threat.tactic]
136id = "TA0002"
137name = "Execution"
138reference = "https://attack.mitre.org/tactics/TA0002/"
139
140[[rule.threat]]
141framework = "MITRE ATT&CK"
142
143[[rule.threat.technique]]
144id = "T1071"
145name = "Application Layer Protocol"
146reference = "https://attack.mitre.org/techniques/T1071/"
147
148[rule.threat.tactic]
149id = "TA0011"
150name = "Command and Control"
151reference = "https://attack.mitre.org/tactics/TA0011/"
152
153[[rule.threat]]
154framework = "MITRE ATT&CK"
155
156[[rule.threat.technique]]
157id = "T1190"
158name = "Exploit Public-Facing Application"
159reference = "https://attack.mitre.org/techniques/T1190/"
160
161[rule.threat.tactic]
162id = "TA0001"
163name = "Initial Access"
164reference = "https://attack.mitre.org/tactics/TA0001/"
165
166[rule.new_terms]
167field = "new_terms_fields"
168value = ["file.path", "host.id", "process.executable"]
169
170[[rule.new_terms.history_window_start]]
171field = "history_window_start"
172value = "now-7d"

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Unusual File Creation via Web Server

This alert flags a Linux web server process creating or renaming a file in web content or application directories that it does not normally touch, which can reveal a compromised service writing attacker-controlled content. That matters because web-facing processes rarely need to drop new executable or template files outside normal deployment activity. A common pattern is an intruder exploiting a vulnerable upload handler or plugin to place a web shell, JSP, PHP, or script-backed page under the site root for persistent remote access.

Possible investigation steps

  • Determine whether the file aligns with an approved deployment, plugin or theme update, package installation, or administrator change in the same time window by reviewing change records and system update history.
  • Inspect the file contents, hash, ownership, permissions, and timestamps for signs of a web shell, dropped payload, hidden redirect, or script stager, and compare it with known-good application files from the same host or image.
  • Review the web service’s parent and child activity around the event for spawned shells, interpreters, archive extraction, or permission changes that would indicate exploitation followed by payload execution or persistence setup.
  • Correlate nearby web access, reverse-proxy, and application log events to identify suspicious upload, template-edit, admin-panel, deserialization, or remote-code-execution requests immediately before the file appeared and any follow-up requests to the new file.
  • Scope the compromise by searching the host and peer web servers for similarly named files, unexpected cron or systemd persistence, modified startup scripts, or outbound connections made by the web service account after the creation event.

False positive analysis

  • Approved application deployment, patching, or first-run initialization can cause the web server or application server to create new files in the web root, so verify the event time against authorized change activity and confirm the file path, owner, and hash match the expected release contents.
  • Legitimate web application features such as user uploads or automatic generation of images, media, attachments, or cache files can create new content under upload-facing directories, so review nearby web or application requests and confirm the file extension, location, and contents are consistent with normal business use.

Response and remediation

  • Isolate the affected web server from the internet and internal network, remove it from the load balancer, and temporarily disable the compromised site or virtual host while keeping only secured management access for containment.
  • Eradicate attacker persistence by deleting the malicious web shell or dropped script, removing any unauthorized cron jobs, systemd units, startup scripts, SSH keys, or writable symlinks created by the web service account, and disabling any backdoored application user or admin account.
  • Restore the service to a known-good state by rebuilding the host from a trusted image or redeploying the application from clean source, recovering web content and configuration from a verified backup taken before the file appeared, and validating expected ownership and permissions across the web root.
  • Rotate all secrets exposed to the host, including web application credentials, API tokens, database passwords, and TLS private keys, and invalidate active sessions or cookies if the malicious file could have intercepted user or administrator access.
  • Escalate to incident response immediately if you find the same malicious file on multiple web servers, observe the web process spawning a shell or making outbound command-and-control connections, or confirm access to databases, payment data, or domain credentials.
  • Harden the environment by patching the exploited CMS, plugin, framework, or server component, restricting the web service account to only required write paths, disabling script execution in upload directories, and adding detections for new executable or template files under the web root.

Related rules

to-top