First Occurrence of a PHP Fatal Error on a Web Server
This rule identifies the first PHP fatal error observed on a web server during the configured history window. PHP fatal errors are not inherently malicious, but a newly observed fatal condition can indicate exploitation of a previously unseen application or PHP engine failure. The rule is intentionally generic so it can identify both known and novel exploit attempts that terminate PHP request processing.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/10/22"
3integration = ["nginx", "apache", "apache_tomcat"]
4maturity = "production"
5updated_date = "2026/10/22"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule identifies the first PHP fatal error observed on a web server during the configured history window. PHP fatal
11errors are not inherently malicious, but a newly observed fatal condition can indicate exploitation of a previously
12unseen application or PHP engine failure. The rule is intentionally generic so it can identify both known and novel
13exploit attempts that terminate PHP request processing.
14"""
15false_positives = [
16 """
17 New deployments, application defects, dependency changes, resource exhaustion, and configuration errors can
18 legitimately produce a first-seen PHP fatal error.
19 """,
20 "Development, staging, and quality-assurance systems may generate frequent novel fatal errors during testing.",
21]
22from = "now-9m"
23index = [
24 "logs-apache.error-*",
25 "logs-apache_tomcat.catalina-*",
26 "logs-apache_tomcat.localhost-*",
27 "logs-nginx.error-*",
28]
29language = "kuery"
30license = "Elastic License v2"
31name = "First Occurrence of a PHP Fatal Error on a Web Server"
32note = """## Triage and analysis
33
34### Investigating First Occurrence of a PHP Fatal Error on a Web Server
35
36This rule establishes first-seen state by `host.id`, so it alerts when a host with no matching event in the history window
37produces a PHP fatal error. The alert does not establish malicious activity; it prioritizes a previously unseen condition
38for investigation and can provide generic coverage for exploitation paths that intentionally trigger fatal PHP states.
39
40### Possible investigation steps
41
42- Review the complete error text and identify the affected host, virtual host, PHP script, application, and PHP version.
43- Examine `source.ip` when present. It represents the immediate requester seen by the web server and may be a proxy,
44 load balancer, CDN node, NAT gateway, or container bridge rather than the original external client.
45- Correlate access logs for the same host and time with request methods, URLs, response codes, multipart bodies, session
46 activity, and unusual cookies. Determine whether many hosts or requests produced the same error.
47- Review endpoint telemetry for web-server or PHP-worker crashes, unusual child processes, file writes, and outbound
48 connections after the fatal error.
49- Compare the error with recent deployments, configuration changes, memory-limit changes, and application test activity.
50
51### False positive analysis
52
53- Fatal errors commonly result from application bugs, missing dependencies, incompatible upgrades, and resource limits.
54 Validate the stack trace and deployment history before treating the alert as exploitation.
55- Consider excluding tightly scoped, well-understood development hosts or known error strings rather than disabling the
56 rule across production PHP servers.
57
58### Response and remediation
59
60- Patch or roll back the affected application or PHP runtime after preserving relevant logs and process telemetry.
61- If the request or surrounding host behavior is suspicious, isolate the server, block the confirmed origin at the edge,
62 rotate exposed secrets, and scope similar errors across the environment.
63"""
64risk_score = 47
65rule_id = "0d173166-95b8-4813-bfb9-a6276813ca2a"
66severity = "medium"
67tags = [
68 "Domain: Web",
69 "Use Case: Threat Detection",
70 "Tactic: Initial Access",
71 "Data Source: Nginx",
72 "Data Source: Apache",
73 "Data Source: Apache Tomcat",
74 "Resources: Investigation Guide",
75 "Rule Type: New Terms",
76 "Service: Nginx",
77 "Service: Apache Tomcat",
78 "Service: Apache HTTP Server",
79]
80timestamp_override = "event.ingested"
81type = "new_terms"
82
83query = '''
84agent.id:* and
85event.dataset:(
86 "apache.error" or "nginx.error" or "apache_tomcat.catalina" or "apache_tomcat.localhost"
87) and (
88 message:(PHP and Fatal and error)
89)
90'''
91
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95[[rule.threat.technique]]
96id = "T1190"
97name = "Exploit Public-Facing Application"
98reference = "https://attack.mitre.org/techniques/T1190/"
99
100
101[rule.threat.tactic]
102id = "TA0001"
103name = "Initial Access"
104reference = "https://attack.mitre.org/tactics/TA0001/"
105
106[rule.investigation_fields]
107field_names = [
108 "@timestamp",
109 "host.id",
110 "host.name",
111 "host.ip",
112 "source.ip",
113 "event.dataset",
114 "log.file.path",
115 "message",
116]
117
118[rule.new_terms]
119field = "new_terms_fields"
120value = ["agent.id"]
121[[rule.new_terms.history_window_start]]
122field = "history_window_start"
123value = "now-7d"
Triage and analysis
Investigating First Occurrence of a PHP Fatal Error on a Web Server
This rule establishes first-seen state by host.id, so it alerts when a host with no matching event in the history window
produces a PHP fatal error. The alert does not establish malicious activity; it prioritizes a previously unseen condition
for investigation and can provide generic coverage for exploitation paths that intentionally trigger fatal PHP states.
Possible investigation steps
- Review the complete error text and identify the affected host, virtual host, PHP script, application, and PHP version.
- Examine
source.ipwhen present. It represents the immediate requester seen by the web server and may be a proxy, load balancer, CDN node, NAT gateway, or container bridge rather than the original external client. - Correlate access logs for the same host and time with request methods, URLs, response codes, multipart bodies, session activity, and unusual cookies. Determine whether many hosts or requests produced the same error.
- Review endpoint telemetry for web-server or PHP-worker crashes, unusual child processes, file writes, and outbound connections after the fatal error.
- Compare the error with recent deployments, configuration changes, memory-limit changes, and application test activity.
False positive analysis
- Fatal errors commonly result from application bugs, missing dependencies, incompatible upgrades, and resource limits. Validate the stack trace and deployment history before treating the alert as exploitation.
- Consider excluding tightly scoped, well-understood development hosts or known error strings rather than disabling the rule across production PHP servers.
Response and remediation
- Patch or roll back the affected application or PHP runtime after preserving relevant logs and process telemetry.
- If the request or surrounding host behavior is suspicious, isolate the server, block the confirmed origin at the edge, rotate exposed secrets, and scope similar errors across the environment.
Related rules
- First Occurrence of a Web Server Segmentation Fault
- Potential HTTP Downgrade Attack
- Web Server Cloud Metadata SSRF Request
- Potential Spike in Web Server Error Logs
- Web Server Discovery or Fuzzing Activity