Simple HTTP Web Server Connection

This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/12/17"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/10/13"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may
 11create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell
 12payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when
 13an attacker requests the server to execute a command or script via a potential backdoor.
 14"""
 15from = "now-9m"
 16index = ["logs-endpoint.events.process*", "logs-endpoint.events.network*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Simple HTTP Web Server Connection"
 20risk_score = 21
 21rule_id = "183f3cd2-4cc6-44c0-917c-c5d29ecdcf74"
 22setup = """## Setup
 23
 24This rule requires data coming in from Elastic Defend.
 25
 26### Elastic Defend Integration Setup
 27Elastic 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.
 28
 29#### Prerequisite Requirements:
 30- Fleet is required for Elastic Defend.
 31- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 32
 33#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 34- Go to the Kibana home page and click "Add integrations".
 35- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 36- Click "Add Elastic Defend".
 37- Configure the integration name and optionally add a description.
 38- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 39- 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).
 40- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 41- 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.
 42For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 43- Click "Save and Continue".
 44- 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.
 45For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 46"""
 47severity = "low"
 48tags = [
 49    "Domain: Endpoint",
 50    "OS: Linux",
 51    "Use Case: Threat Detection",
 52    "Tactic: Persistence",
 53    "Tactic: Execution",
 54    "Tactic: Command and Control",
 55    "Data Source: Elastic Defend",
 56    "Resources: Investigation Guide",
 57]
 58timestamp_override = "event.ingested"
 59type = "eql"
 60query = '''
 61sequence by process.entity_id with maxspan=1m
 62[process where host.os.type == "linux" and event.type == "start" and 
 63 (
 64  (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.command_line like "*-S*") or
 65  (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*"))
 66 )]
 67[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted"]
 68'''
 69note = """## Triage and analysis
 70
 71> **Disclaimer**:
 72> 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.
 73
 74### Investigating Simple HTTP Web Server Connection
 75
 76Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation.
 77
 78### Possible investigation steps
 79
 80- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields.
 81- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections.
 82- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
 83- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies.
 84- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload.
 85- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign.
 86
 87### False positive analysis
 88
 89- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule.
 90- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list.
 91- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities.
 92- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts.
 93- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration.
 94
 95### Response and remediation
 96
 97- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
 98- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity.
 99- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded.
100- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access.
101- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.
102- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments.
103- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107
108  [rule.threat.tactic]
109  name = "Persistence"
110  id = "TA0003"
111  reference = "https://attack.mitre.org/tactics/TA0003/"
112
113    [[rule.threat.technique]]
114    id = "T1505"
115    name = "Server Software Component"
116    reference = "https://attack.mitre.org/techniques/T1505/"
117
118      [[rule.threat.technique.subtechnique]]
119      id = "T1505.003"
120      name = "Web Shell"
121      reference = "https://attack.mitre.org/techniques/T1505/003/"
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125
126  [rule.threat.tactic]
127  name = "Execution"
128  id = "TA0002"
129  reference = "https://attack.mitre.org/tactics/TA0002/"
130
131    [[rule.threat.technique]]
132    id = "T1059"
133    name = "Command and Scripting Interpreter"
134    reference = "https://attack.mitre.org/techniques/T1059/"
135
136      [[rule.threat.technique.subtechnique]]
137      name = "Unix Shell"
138      id = "T1059.004"
139      reference = "https://attack.mitre.org/techniques/T1059/004/"
140
141[[rule.threat]]
142framework = "MITRE ATT&CK"
143
144  [rule.threat.tactic]
145  name = "Command and Control"
146  id = "TA0011"
147  reference = "https://attack.mitre.org/tactics/TA0011/"
148
149    [[rule.threat.technique]]
150    name = "Application Layer Protocol"
151    id = "T1071"
152    reference = "https://attack.mitre.org/techniques/T1071/"

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 Simple HTTP Web Server Connection

Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation.

Possible investigation steps

  • Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields.
  • Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections.
  • Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
  • Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies.
  • Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload.
  • Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign.

False positive analysis

  • Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule.
  • Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list.
  • Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities.
  • Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts.
  • Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
  • Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity.
  • Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded.
  • Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access.
  • Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.
  • Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments.
  • Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.

Related rules

to-top