Uncommon Destination Port Connection by Web Server
This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/03/05"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/04/07"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule identifies unusual destination port network activity originating from a web server process. The
11rule is designed to detect potential web shell activity or unauthorized communication from a web server
12process to external systems.
13"""
14from = "now-9m"
15index = ["logs-endpoint.events.network*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Uncommon Destination Port Connection by Web Server"
19note = """ ## Triage and analysis
20
21> **Disclaimer**:
22> 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.
23
24### Investigating Uncommon Destination Port Connection by Web Server
25
26Web servers, crucial for hosting applications, typically communicate over standard ports like 80 and 443. Adversaries may exploit web server processes to establish unauthorized connections to unusual ports, potentially indicating web shell activity or data exfiltration. This detection rule identifies such anomalies by monitoring egress connections from web server processes to non-standard ports, excluding common local IP ranges, thus highlighting potential threats.
27
28### Possible investigation steps
29
30- Review the process name and user associated with the alert to determine if the connection attempt was made by a legitimate web server process or user, as specified in the query fields (e.g., process.name or user.name).
31- Examine the destination IP address to assess whether it is known or suspicious, and check if it falls outside the excluded local IP ranges.
32- Investigate the destination port to understand why the connection was attempted on a non-standard port, and determine if this port is associated with any known services or threats.
33- Check historical logs for any previous connection attempts from the same process or user to the same or similar destination IPs and ports to identify patterns or repeated behavior.
34- Analyze any related network traffic or logs to identify additional context or anomalies that may indicate unauthorized activity or data exfiltration.
35- Correlate the alert with other security events or alerts to determine if it is part of a larger attack pattern or campaign.
36
37### False positive analysis
38
39- Routine administrative tasks or maintenance scripts may trigger alerts if they involve web server processes connecting to non-standard ports. To manage this, identify and document these tasks, then create exceptions for the specific processes and ports involved.
40- Internal monitoring or management tools that use non-standard ports for legitimate purposes can cause false positives. Review the tools in use and exclude their known IP addresses and ports from the rule.
41- Development or testing environments often use non-standard ports for web server processes. Ensure these environments are well-documented and consider excluding their IP ranges or specific ports from the rule.
42- Load balancers or reverse proxies might redirect traffic to non-standard ports as part of their normal operation. Verify the configuration of these devices and exclude their IP addresses and ports if necessary.
43- Custom applications running on web servers may require communication over non-standard ports. Work with application owners to understand these requirements and adjust the rule to exclude these specific cases.
44
45### Response and remediation
46
47- Immediately isolate the affected web server from the network to prevent further unauthorized access or data exfiltration.
48- Conduct a thorough review of the web server's logs and processes to identify any unauthorized changes or suspicious activities, focusing on the processes and user accounts mentioned in the detection rule.
49- Terminate any suspicious processes identified during the investigation that are not part of the standard operation of the web server.
50- Change passwords and review permissions for the user accounts associated with the web server processes to ensure they have not been compromised.
51- Restore the web server from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise.
52- Implement network segmentation to limit the web server's access to critical systems and data, reducing the potential impact of future incidents.
53- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected, ensuring comprehensive threat containment and remediation.
54"""
55risk_score = 21
56rule_id = "00546494-5bb0-49d6-9220-5f3b4c12f26a"
57setup = """## Setup
58
59This rule requires data coming in from Elastic Defend.
60
61### Elastic Defend Integration Setup
62Elastic 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.
63
64#### Prerequisite Requirements:
65- Fleet is required for Elastic Defend.
66- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
67
68#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
69- Go to the Kibana home page and click "Add integrations".
70- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
71- Click "Add Elastic Defend".
72- Configure the integration name and optionally add a description.
73- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
74- 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).
75- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
76- 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.
77For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
78- Click "Save and Continue".
79- 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.
80For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
81"""
82severity = "low"
83tags = [
84 "Domain: Endpoint",
85 "OS: Linux",
86 "Use Case: Threat Detection",
87 "Tactic: Persistence",
88 "Tactic: Execution",
89 "Tactic: Command and Control",
90 "Data Source: Elastic Defend",
91 "Resources: Investigation Guide",
92]
93timestamp_override = "event.ingested"
94type = "eql"
95query = '''
96network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and (
97 user.name in (
98 "apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd"
99 ) or
100 user.id in ("99", "33", "498", "48")
101 ) and (
102 process.name in (
103 "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "node", "mongrel_rails", "java", "gunicorn",
104 "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn",
105 "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel"
106 ) or
107 process.name like ("php-*", "python*", "ruby*", "perl*")
108) and
109network.direction == "egress" and destination.ip != null and
110not destination.port in (80, 443, 8080, 8443, 8000, 8888, 3128, 3306) and
111not cidrmatch(destination.ip, "127.0.0.0/8", "::1","FE80::/10", "FF00::/8")
112
113/*
114This rule does not exclude local IP ranges by default. To exclude these, use the following exclusion statement:
115cidrmatch(destination.ip, "10.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32",
116"192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24",
117"224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4")
118*/
119'''
120
121[[rule.threat]]
122framework = "MITRE ATT&CK"
123
124[rule.threat.tactic]
125name = "Persistence"
126id = "TA0003"
127reference = "https://attack.mitre.org/tactics/TA0003/"
128
129[[rule.threat.technique]]
130id = "T1505"
131name = "Server Software Component"
132reference = "https://attack.mitre.org/techniques/T1505/"
133
134[[rule.threat.technique.subtechnique]]
135id = "T1505.003"
136name = "Web Shell"
137reference = "https://attack.mitre.org/techniques/T1505/003/"
138
139[[rule.threat]]
140framework = "MITRE ATT&CK"
141
142[rule.threat.tactic]
143name = "Execution"
144id = "TA0002"
145reference = "https://attack.mitre.org/tactics/TA0002/"
146
147[[rule.threat.technique]]
148id = "T1059"
149name = "Command and Scripting Interpreter"
150reference = "https://attack.mitre.org/techniques/T1059/"
151
152[[rule.threat.technique.subtechnique]]
153id = "T1059.004"
154name = "Unix Shell"
155reference = "https://attack.mitre.org/techniques/T1059/004/"
156
157[[rule.threat]]
158framework = "MITRE ATT&CK"
159
160[rule.threat.tactic]
161name = "Command and Control"
162id = "TA0011"
163reference = "https://attack.mitre.org/tactics/TA0011/"
164
165[[rule.threat.technique]]
166name = "Application Layer Protocol"
167id = "T1071"
168reference = "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 Uncommon Destination Port Connection by Web Server
Web servers, crucial for hosting applications, typically communicate over standard ports like 80 and 443. Adversaries may exploit web server processes to establish unauthorized connections to unusual ports, potentially indicating web shell activity or data exfiltration. This detection rule identifies such anomalies by monitoring egress connections from web server processes to non-standard ports, excluding common local IP ranges, thus highlighting potential threats.
Possible investigation steps
- Review the process name and user associated with the alert to determine if the connection attempt was made by a legitimate web server process or user, as specified in the query fields (e.g., process.name or user.name).
- Examine the destination IP address to assess whether it is known or suspicious, and check if it falls outside the excluded local IP ranges.
- Investigate the destination port to understand why the connection was attempted on a non-standard port, and determine if this port is associated with any known services or threats.
- Check historical logs for any previous connection attempts from the same process or user to the same or similar destination IPs and ports to identify patterns or repeated behavior.
- Analyze any related network traffic or logs to identify additional context or anomalies that may indicate unauthorized activity or data exfiltration.
- Correlate the alert with other security events or alerts to determine if it is part of a larger attack pattern or campaign.
False positive analysis
- Routine administrative tasks or maintenance scripts may trigger alerts if they involve web server processes connecting to non-standard ports. To manage this, identify and document these tasks, then create exceptions for the specific processes and ports involved.
- Internal monitoring or management tools that use non-standard ports for legitimate purposes can cause false positives. Review the tools in use and exclude their known IP addresses and ports from the rule.
- Development or testing environments often use non-standard ports for web server processes. Ensure these environments are well-documented and consider excluding their IP ranges or specific ports from the rule.
- Load balancers or reverse proxies might redirect traffic to non-standard ports as part of their normal operation. Verify the configuration of these devices and exclude their IP addresses and ports if necessary.
- Custom applications running on web servers may require communication over non-standard ports. Work with application owners to understand these requirements and adjust the rule to exclude these specific cases.
Response and remediation
- Immediately isolate the affected web server from the network to prevent further unauthorized access or data exfiltration.
- Conduct a thorough review of the web server's logs and processes to identify any unauthorized changes or suspicious activities, focusing on the processes and user accounts mentioned in the detection rule.
- Terminate any suspicious processes identified during the investigation that are not part of the standard operation of the web server.
- Change passwords and review permissions for the user accounts associated with the web server processes to ensure they have not been compromised.
- Restore the web server from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise.
- Implement network segmentation to limit the web server's access to critical systems and data, reducing the potential impact of future incidents.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected, ensuring comprehensive threat containment and remediation.
Related rules
- Unusual Command Execution from Web Server Parent
- Unusual Process Spawned from Web Server Parent
- Simple HTTP Web Server Creation
- Simple HTTP Web Server Connection
- File Creation in /var/log via Suspicious Process