File with High Entropy Created by Web Server

Description

This rule detects when a web server process creates a file with high entropy, where the file extension is a web extension. This is a common indicator of an encrypted or encoded payload being uploaded.

Query · eql

file where host.os.type == "linux" and event.action != "deletion" and

/* Entropy threshold chosen to flag likely encoded/encrypted payload uploads while limiting false positives. */
file.Ext.entropy >= 6.0 and

(
  process.name in (
    "nginx", "apache2", "httpd", "caddy", "lighttpd", "httpd.worker", "httpd-worker", "httpd-prefork",
    "php-cgi", "php-fcgi", "php-cgi.cagefs", "frankenphp", "lshttpd", "litespeed", "openlitespeed",
    "fcgiwrap", "uwsgi", "daphne", "uvicorn", "hypercorn", "granian", "waitress-serve", "flask", "puma",
    "unicorn", "unicorn_rails", "thin", "rackup", "mongrel_rails", "starman", "plackup", "twiggy",
    "hypnotoad", "starlet", "unitd", "unitd-debug"
  ) or
  process.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi")
) and
file.extension in~ (
  "php", "phtml", "pht", "php3", "php4", "php5", "php7", "phar",
  "asp", "aspx", "ashx", "asmx", "ascx", "cshtml", "razor",
  "jsp", "jspx", "jsx", "jspf", "tag", "tagx", "war", "ear",
  "js", "mjs", "cjs", "ts", "mts", "cts", "tsx",
  "py", "wsgi", "cgi", "fcgi", "pyc",
  "erb", "ru",
  "psgi",
  "lua", "luac",
  "sh", "elf", "bin"
)

Implementation guide

This rule requires data coming in from Elastic Defend.

Elastic Defend Integration Setup

Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

Prerequisite Requirements:

  • Fleet is required for Elastic Defend.
  • To configure Fleet Server refer to the documentation.

The following steps should be executed in order to add the Elastic Defend integration on a Linux System:

  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
  • Click "Add Elastic Defend".
  • Configure the integration name and optionally add a description.
  • Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
  • Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. Helper guide.
  • We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
  • Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. For more details on Elastic Agent configuration settings, refer to the helper guide.
  • Click "Save and Continue".
  • To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. For more details on Elastic Defend refer to the helper guide.

Elastic Defend integration does not collect advanced file information (such as the different file.Ext.* fields) by default. In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. #### To set up advanced file information capture for an Elastic Agent policy: - Go to “Security → Manage → Policies”. - Select an “Elastic Agent policy”. - Click “Show advanced settings”. - Scroll down or search for “linux.advanced.events.populate_file_data”. - For this rule the linux.advanced.events.populate_file_data variable should be set to "true". - Click “Save”. After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.

Analyst notes

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 File with High Entropy Created by Web Server

This detection identifies a Linux web server process writing a high-entropy file with a web-executable extension, which can signal an encoded or encrypted payload planted through an exposed application. After exploiting a vulnerable upload endpoint, an attacker may save an obfuscated PHP web shell as a .phtml file under the document root, then invoke it over HTTP to establish persistent remote access.

Possible investigation steps

  • Determine the file’s full path, owner, permissions, timestamps, hash, and proximity to document roots, upload directories, temporary locations, or recent authorized deployments.
  • Preserve a copy and inspect its true file type, strings, structure, obfuscation, embedded payloads, and known-malware reputation in a controlled environment without executing it.
  • Correlate the creation time with process ancestry, command lines, service account activity, child processes, and network connections to identify the originating request or exploited application component.
  • Review reverse-proxy, web access, WAF, and application logs for upload attempts, exploit patterns, source addresses, authentication context, and subsequent requests to the created file.
  • Hunt for the same hash, filename, path, source address, or related execution across hosts, and isolate the server while removing the artifact and remediating the vulnerable entry point if malicious activity is confirmed.

False positive analysis

  • An authorized application deployment may cause a web server process to write minified JavaScript or packaged application files with naturally high entropy; verify the creation time, path, hash, and deployment records against the approved release.
  • A Python web application may legitimately generate high-entropy bytecode cache files with a .pyc extension during startup or module import; confirm the files reside in expected cache directories and correlate with a sanctioned restart or code update.

Response and remediation

  • Isolate the affected web server from untrusted networks while preserving the high-entropy file, web logs, process artifacts, and memory for incident-response analysis.
  • Quarantine the malicious file and remove related web shells, unauthorized accounts, scheduled tasks, service changes, startup scripts, SSH keys, and altered application components identified across the environment.
  • Rebuild the server from a known-good image, restore validated application content and configuration, patch the exploited component, and rotate web service, application, database, API, and administrative credentials.
  • Open an incident-response case and escalate to major-incident handling immediately if the file was executed, attacker commands or outbound connections are found, privileged credentials were exposed, or related artifacts appear on other hosts.
  • Block confirmed malicious hashes, source addresses, domains, and request patterns, then hunt for matching files, exploitation attempts, and post-compromise activity across web servers and dependent systems.
  • Prevent recurrence by restricting upload locations from executing code, enforcing extension and content validation, applying least-privilege permissions to web service accounts, and strengthening WAF rules and file-integrity monitoring.
Raw source File with High Entropy Created by Web Server · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2026/09/07"
integration = ["endpoint"]
maturity = "production"
min_stack_version = "9.3.0"
min_stack_comments = "The file.Ext.* fields for file events were introduced in 9.3.0, and are required for this rule to function."
updated_date = "2026/09/07"

[rule]
author = ["Elastic"]
description = """
This rule detects when a web server process creates a file with high entropy, where the file
extension is a web extension. This is a common indicator of an encrypted or encoded payload
being uploaded.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "File with High Entropy Created by Web Server"
note = """## 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 File with High Entropy Created by Web Server

This detection identifies a Linux web server process writing a high-entropy file with a web-executable extension, which can signal an encoded or encrypted payload planted through an exposed application. After exploiting a vulnerable upload endpoint, an attacker may save an obfuscated PHP web shell as a .phtml file under the document root, then invoke it over HTTP to establish persistent remote access.

### Possible investigation steps

- Determine the file’s full path, owner, permissions, timestamps, hash, and proximity to document roots, upload directories, temporary locations, or recent authorized deployments.
- Preserve a copy and inspect its true file type, strings, structure, obfuscation, embedded payloads, and known-malware reputation in a controlled environment without executing it.
- Correlate the creation time with process ancestry, command lines, service account activity, child processes, and network connections to identify the originating request or exploited application component.
- Review reverse-proxy, web access, WAF, and application logs for upload attempts, exploit patterns, source addresses, authentication context, and subsequent requests to the created file.
- Hunt for the same hash, filename, path, source address, or related execution across hosts, and isolate the server while removing the artifact and remediating the vulnerable entry point if malicious activity is confirmed.

### False positive analysis

- An authorized application deployment may cause a web server process to write minified JavaScript or packaged application files with naturally high entropy; verify the creation time, path, hash, and deployment records against the approved release.
- A Python web application may legitimately generate high-entropy bytecode cache files with a .pyc extension during startup or module import; confirm the files reside in expected cache directories and correlate with a sanctioned restart or code update.

### Response and remediation

- Isolate the affected web server from untrusted networks while preserving the high-entropy file, web logs, process artifacts, and memory for incident-response analysis.
- Quarantine the malicious file and remove related web shells, unauthorized accounts, scheduled tasks, service changes, startup scripts, SSH keys, and altered application components identified across the environment.
- Rebuild the server from a known-good image, restore validated application content and configuration, patch the exploited component, and rotate web service, application, database, API, and administrative credentials.
- Open an incident-response case and escalate to major-incident handling immediately if the file was executed, attacker commands or outbound connections are found, privileged credentials were exposed, or related artifacts appear on other hosts.
- Block confirmed malicious hashes, source addresses, domains, and request patterns, then hunt for matching files, exploitation attempts, and post-compromise activity across web servers and dependent systems.
- Prevent recurrence by restricting upload locations from executing code, enforcing extension and content validation, applying least-privilege permissions to web service accounts, and strengthening WAF rules and file-integrity monitoring.
"""
risk_score = 73
rule_id = "f2738cad-28ab-4c9e-b7f0-66f3b2775e5f"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

Elastic Defend integration does not collect advanced file information (such as the different file.Ext.* fields) by default.
In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.
 #### To set up advanced file information capture for an Elastic Agent policy:
- Go to “Security → Manage → Policies”.
- Select an “Elastic Agent policy”.
- Click “Show advanced settings”.
- Scroll down or search for “linux.advanced.events.populate_file_data”.
- For this rule the linux.advanced.events.populate_file_data variable should be set to "true".
- Click “Save”.
After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Use Case: Vulnerability",
    "Tactic: Persistence",
    "Tactic: Initial Access",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Rule Type: Event Correlation (EQL)",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action != "deletion" and

/* Entropy threshold chosen to flag likely encoded/encrypted payload uploads while limiting false positives. */
file.Ext.entropy >= 6.0 and

(
  process.name in (
    "nginx", "apache2", "httpd", "caddy", "lighttpd", "httpd.worker", "httpd-worker", "httpd-prefork",
    "php-cgi", "php-fcgi", "php-cgi.cagefs", "frankenphp", "lshttpd", "litespeed", "openlitespeed",
    "fcgiwrap", "uwsgi", "daphne", "uvicorn", "hypercorn", "granian", "waitress-serve", "flask", "puma",
    "unicorn", "unicorn_rails", "thin", "rackup", "mongrel_rails", "starman", "plackup", "twiggy",
    "hypnotoad", "starlet", "unitd", "unitd-debug"
  ) or
  process.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi")
) and
file.extension in~ (
  "php", "phtml", "pht", "php3", "php4", "php5", "php7", "phar",
  "asp", "aspx", "ashx", "asmx", "ascx", "cshtml", "razor",
  "jsp", "jspx", "jsx", "jspf", "tag", "tagx", "war", "ear",
  "js", "mjs", "cjs", "ts", "mts", "cts", "tsx",
  "py", "wsgi", "cgi", "fcgi", "pyc",
  "erb", "ru",
  "psgi",
  "lua", "luac",
  "sh", "elf", "bin"
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

  [rule.threat.tactic]
  name = "Persistence"
  id = "TA0003"
  reference = "https://attack.mitre.org/tactics/TA0003/"

  [[rule.threat.technique]]
  id = "T1505"
  name = "Server Software Component"
  reference = "https://attack.mitre.org/techniques/T1505/"

    [[rule.threat.technique.subtechnique]]
    id = "T1505.003"
    name = "Web Shell"
    reference = "https://attack.mitre.org/techniques/T1505/003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

  [rule.threat.tactic]
  name = "Initial Access"
  id = "TA0001"
  reference = "https://attack.mitre.org/tactics/TA0001/"

  [[rule.threat.technique]]
  name = "Exploit Public-Facing Application"
  id = "T1190"
  reference = "https://attack.mitre.org/techniques/T1190/"

[[rule.threat]]
framework = "MITRE ATT&CK"

  [[rule.threat.technique]]
  id = "T1210"
  name = "Exploitation of Remote Services"
  reference = "https://attack.mitre.org/techniques/T1210/"

  [rule.threat.tactic]
  id = "TA0008"
  name = "Lateral Movement"
  reference = "https://attack.mitre.org/tactics/TA0008/"

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.