Simple HTTP Web Server Creation

  1[metadata]
  2creation_date = "2024/12/17"
  3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the creation of a simple HTTP web server using PHP or Python built-in modules. Adversaries may create
 13simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload
 14to the server web root, allowing them to regain remote access to the system if lost.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Simple HTTP Web Server Creation"
 21risk_score = 21
 22rule_id = "907a26f5-3eb6-4338-a70e-6c375c1cde8a"
 23setup = """## Setup
 24
 25This rule requires data coming in from Elastic Defend.
 26
 27### Elastic Defend Integration Setup
 28Elastic 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.
 29
 30#### Prerequisite Requirements:
 31- Fleet is required for Elastic Defend.
 32- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 33
 34#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 35- Go to the Kibana home page and click "Add integrations".
 36- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 37- Click "Add Elastic Defend".
 38- Configure the integration name and optionally add a description.
 39- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 40- 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).
 41- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 42- 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.
 43For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 44- Click "Save and Continue".
 45- 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.
 46For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 47"""
 48severity = "low"
 49tags = [
 50    "Domain: Endpoint",
 51    "OS: Linux",
 52    "Use Case: Threat Detection",
 53    "Tactic: Persistence",
 54    "Tactic: Execution",
 55    "Tactic: Command and Control",
 56    "Data Source: Elastic Defend",
 57    "Data Source: Crowdstrike",
 58    "Data Source: SentinelOne",
 59    "Data Source: Elastic Endgame",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "eql"
 64query = '''
 65process where host.os.type == "linux" and event.type == "start" and
 66  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 67  (
 68    (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.args == "-S") or
 69    (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer"))
 70  )
 71'''
 72note = """## Triage and analysis
 73
 74> **Disclaimer**:
 75> 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.
 76
 77### Investigating Simple HTTP Web Server Creation
 78
 79Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised Linux systems. By deploying a web server, they can upload malicious payloads, such as reverse shells, to maintain remote access. The detection rule identifies suspicious server creation by monitoring process executions that match specific patterns, such as PHP or Python commands indicative of server setup, thereby alerting analysts to potential threats.
 80
 81### Possible investigation steps
 82
 83- Review the process execution details to confirm the presence of PHP or Python commands with arguments matching the patterns specified in the query, such as PHP with the "-S" argument or Python with "--cgi" or "CGIHTTPServer".
 84- Identify the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
 85- Examine the network activity associated with the process to identify any unusual connections or data transfers that could suggest malicious intent or data exfiltration.
 86- Check the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads, such as reverse shells.
 87- Investigate the parent process of the suspicious server creation to understand how the process was initiated and whether it was triggered by another potentially malicious activity.
 88- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
 89
 90### False positive analysis
 91
 92- Development and testing environments often use simple HTTP servers for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development directories or user accounts frequently involved in these activities.
 93- Automated scripts or cron jobs may start simple HTTP servers for routine tasks like file distribution or internal data sharing. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts.
 94- Educational or training sessions might involve setting up simple HTTP servers as part of learning exercises. Exclude specific IP ranges or user groups associated with training environments to prevent false positives.
 95- System administrators might use simple HTTP servers for quick troubleshooting or system maintenance tasks. Document these activities and create exceptions based on the administrator's user accounts or specific server names.
 96- Continuous integration and deployment pipelines may temporarily start HTTP servers during build or deployment processes. Identify these pipelines and exclude their associated processes or execution contexts from the detection rule.
 97
 98### Response and remediation
 99
100- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
101- Terminate any suspicious PHP or Python processes identified by the detection rule to halt the operation of the unauthorized web server.
102- Conduct a thorough examination of the web server's root directory to identify and remove any malicious payloads, such as reverse shells or unauthorized scripts.
103- Review system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary.
104- Restore the system from a known good backup if any critical system files or configurations have been altered by the adversary.
105- Implement stricter access controls and monitoring on the affected system to prevent similar unauthorized server setups in the future.
106- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110
111  [rule.threat.tactic]
112  name = "Persistence"
113  id = "TA0003"
114  reference = "https://attack.mitre.org/tactics/TA0003/"
115
116    [[rule.threat.technique]]
117    id = "T1505"
118    name = "Server Software Component"
119    reference = "https://attack.mitre.org/techniques/T1505/"
120
121      [[rule.threat.technique.subtechnique]]
122      id = "T1505.003"
123      name = "Web Shell"
124      reference = "https://attack.mitre.org/techniques/T1505/003/"
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128
129  [rule.threat.tactic]
130  name = "Execution"
131  id = "TA0002"
132  reference = "https://attack.mitre.org/tactics/TA0002/"
133
134    [[rule.threat.technique]]
135    id = "T1059"
136    name = "Command and Scripting Interpreter"
137    reference = "https://attack.mitre.org/techniques/T1059/"
138
139      [[rule.threat.technique.subtechnique]]
140      name = "Unix Shell"
141      id = "T1059.004"
142      reference = "https://attack.mitre.org/techniques/T1059/004/"
143
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146
147  [rule.threat.tactic]
148  name = "Command and Control"
149  id = "TA0011"
150  reference = "https://attack.mitre.org/tactics/TA0011/"
151
152    [[rule.threat.technique]]
153    name = "Application Layer Protocol"
154    id = "T1071"
155    reference = "https://attack.mitre.org/techniques/T1071/"