First Occurrence of a Web Server Segmentation Fault

  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 segmentation fault, SIGSEGV, signal 11 termination, or Windows access-violation status
 11observed in web-server error logs for a host during the configured history window. An unexpected web-server crash can
 12indicate attempted exploitation of a memory-safety vulnerability, including attempts that fail before code execution,
 13although software defects and resource problems can produce the same behavior.
 14"""
 15false_positives = [
 16    """
 17    Web-server, runtime, module, extension, or application defects can legitimately crash a worker after an upgrade,
 18    configuration change, or unusual request.
 19    """,
 20    """
 21    Stress tests, fault-injection exercises, fuzzing, and authorized vulnerability testing may intentionally trigger
 22    segmentation faults or access violations.
 23    """,
 24]
 25from = "now-9m"
 26index = [
 27    "logs-apache.error-*",
 28    "logs-apache_tomcat.catalina-*",
 29    "logs-apache_tomcat.localhost-*",
 30    "logs-nginx.error-*",
 31]
 32language = "kuery"
 33license = "Elastic License v2"
 34name = "First Occurrence of a Web Server Segmentation Fault"
 35note = """## Triage and analysis
 36
 37### Investigating First Occurrence of a Web Server Segmentation Fault
 38
 39A segmentation fault is a memory-access violation that terminates a process or worker. A first-seen crash in an
 40internet-facing service deserves prompt review because memory-corruption exploit attempts frequently terminate workers
 41even when exploitation fails. This alert does not prove exploitation or successful code execution.
 42
 43### Possible investigation steps
 44
 45- Identify the affected `host.id`, process or worker identifier, signal or exception value, web-server module, and complete
 46  error text. Determine whether one worker or the entire service terminated.
 47- Review requests immediately preceding the crash, including `source.ip`, URL, method, status, content type, body size,
 48  cookies, and user agent. Recover the original client from trusted edge logs when a proxy or container bridge is present.
 49- Correlate the crash with fatal PHP errors, malformed multipart requests, repeated HTTP 500 responses, worker churn, and
 50  known vulnerability signatures such as the PHP2Shell memory-exhaustion pattern.
 51- Review endpoint telemetry for a core dump, unexpected child processes, file writes, outbound connections, privilege
 52  changes, or persistence after the crash.
 53- Determine whether a recent deployment, package upgrade, native extension, security test, or resource-pressure event can
 54  explain the fault. Preserve a core dump and relevant binaries when available.
 55
 56### False positive analysis
 57
 58- Native modules, language runtimes, drivers, and third-party extensions can contain non-security defects that crash a
 59  web worker. Recurrent crashes with the same stack after an approved change may be operational rather than adversarial.
 60- Do not broadly exclude a host solely because it has a known stability issue; use a narrow exception for the understood
 61  message, module, version, or maintenance window.
 62
 63### Response and remediation
 64
 65- Remove a repeatedly crashing or potentially exploited server from public traffic and preserve volatile and on-disk
 66  evidence before restarting or rebuilding it.
 67- Patch the web server, runtime, application, and native extensions. If exploitation cannot be ruled out, rebuild from a
 68  trusted image and rotate credentials and secrets accessible to the service account.
 69- Block confirmed malicious origins at the edge and hunt for the same crash signature and follow-on behavior on peer hosts.
 70"""
 71risk_score = 47
 72rule_id = "98dd5283-970b-40a9-bc12-61661b25b514"
 73severity = "medium"
 74tags = [
 75    "Domain: Web",
 76    "Use Case: Threat Detection",
 77    "Tactic: Initial Access",
 78    "Tactic: Impact",
 79    "Data Source: Nginx",
 80    "Data Source: Apache",
 81    "Data Source: Apache Tomcat",
 82    "Resources: Investigation Guide",
 83    "Rule Type: New Terms",
 84    "Service: Nginx",
 85    "Service: Apache Tomcat",
 86    "Service: Apache HTTP Server",
 87]
 88timestamp_override = "event.ingested"
 89type = "new_terms"
 90
 91query = '''
 92agent.id:* and
 93event.dataset:("apache.error" or "nginx.error" or "apache_tomcat.catalina" or "apache_tomcat.localhost") and
 94message:(
 95  segfault or SIGSEGV or (Segmentation and fault) or (signal and 11) or "0xc0000005" or "c0000005" or "3221225477"
 96)
 97'''
 98
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102[[rule.threat.technique]]
103id = "T1499"
104name = "Endpoint Denial of Service"
105reference = "https://attack.mitre.org/techniques/T1499/"
106[[rule.threat.technique.subtechnique]]
107id = "T1499.004"
108name = "Application or System Exploitation"
109reference = "https://attack.mitre.org/techniques/T1499/004/"
110
111
112
113[rule.threat.tactic]
114id = "TA0040"
115name = "Impact"
116reference = "https://attack.mitre.org/tactics/TA0040/"
117[[rule.threat]]
118framework = "MITRE ATT&CK"
119[[rule.threat.technique]]
120id = "T1190"
121name = "Exploit Public-Facing Application"
122reference = "https://attack.mitre.org/techniques/T1190/"
123
124
125[rule.threat.tactic]
126id = "TA0001"
127name = "Initial Access"
128reference = "https://attack.mitre.org/tactics/TA0001/"
129
130[rule.investigation_fields]
131field_names = [
132    "@timestamp",
133    "host.id",
134    "host.name",
135    "host.ip",
136    "source.ip",
137    "process.pid",
138    "process.thread.id",
139    "event.dataset",
140    "log.file.path",
141    "message",
142]
143
144[rule.new_terms]
145field = "new_terms_fields"
146value = ["agent.id"]
147[[rule.new_terms.history_window_start]]
148field = "history_window_start"
149value = "now-7d"