Potential Buffer Overflow Attack Detected

ELASTIC detection rule by Elastic · Elastic License v2

Detects potential buffer overflow attacks by querying the "Segfault Detected" pre-built rule signal index, through a threshold rule, with a minimum number of 100 segfault alerts in a short timespan. A large amount of segfaults in a short time interval could indicate application exploitation attempts.

[metadata]
creation_date = "2023/12/11"
maturity = "production"
updated_date = "2025/01/15"

[rule]
author = ["Elastic"]
description = """
Detects potential buffer overflow attacks by querying the "Segfault Detected" pre-built rule signal index, through a
threshold rule, with a minimum number of 100 segfault alerts in a short timespan. A large amount of segfaults in a short
time interval could indicate application exploitation attempts.
"""
from = "now-9m"
index = [".alerts-security.*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential Buffer Overflow Attack Detected"
risk_score = 21
rule_id = "b7c05aaf-78c2-4558-b069-87fa25973489"
setup = """## Setup


This rule leverages alert data from other prebuilt detection rules to function correctly.

### Dependent Elastic Detection Rule Enablement
As a higher-order rule (based on other detections), this rule also requires the following prerequisite Elastic detection rule to be installed and enabled:
- Segfault Detected (5c81fc9d-1eae-437f-ba07-268472967013)
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Initial Access",
    "Use Case: Vulnerability",
    "Rule Type: Higher-Order Rule",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal
'''
note = """## 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 Potential Buffer Overflow Attack Detected

Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known threat tactics.

### Possible investigation steps

- Review the alert details to confirm the presence of a surge in segfault alerts, focusing on the host.os.type:linux field to ensure the affected systems are Linux-based.
- Correlate the timestamps of the segfault alerts to identify any patterns or specific timeframes when the surge occurred, which might indicate the start of an exploitation attempt.
- Investigate the affected host(s) by examining system logs and application logs around the time of the segfault alerts to identify any suspicious activities or anomalies.
- Check for any recent changes or updates to the software running on the affected host(s) that might have introduced vulnerabilities.
- Look for any known vulnerabilities or exploits associated with the software or services running on the affected host(s) that could be targeted by a buffer overflow attack.
- Assess the network traffic to and from the affected host(s) during the time of the alerts to identify any unusual or unauthorized connections that could indicate an attack vector.
- Consult threat intelligence sources to determine if there are any ongoing campaigns or known threat actors targeting similar vulnerabilities or systems.

### False positive analysis

- High-volume legitimate application crashes can trigger false positives, especially during software testing or development phases. Users should identify and exclude these applications from the rule by creating exceptions for specific processes known to cause frequent segfaults without malicious intent.
- System updates or patches may cause temporary spikes in segfault alerts as applications restart or reconfigure. Users can mitigate this by setting a temporary exception during scheduled maintenance windows.
- Custom scripts or automated tasks that interact with system memory in non-standard ways might generate segfaults. Review these scripts and, if verified as safe, exclude them from the rule to prevent false alerts.
- Certain security tools or monitoring software may intentionally cause segfaults as part of their operation. Identify these tools and add them to the exception list to avoid unnecessary alerts.
- Legacy applications with known stability issues might frequently cause segfaults. Consider updating or replacing these applications, or create exceptions if updates are not feasible.

### Response and remediation

- Isolate the affected Linux host immediately to prevent further exploitation and lateral movement within the network.
- Terminate any suspicious processes identified on the affected host that are associated with the segfault alerts to halt potential malicious activity.
- Conduct a thorough analysis of the affected application or service to identify and patch the specific vulnerability being exploited, ensuring all software is updated to the latest secure versions.
- Review and enhance system and application logging to capture detailed information on segfault occurrences and related activities for future analysis and detection.
- Implement additional security controls such as application whitelisting and memory protection mechanisms (e.g., DEP, ASLR) to mitigate the risk of buffer overflow attacks.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Document the incident, including all actions taken and findings, to improve future response efforts and update incident response plans accordingly."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"


[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"


[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[rule.threshold]
field = ["event.kind", "host.id"]
value = 100

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

0cfb5853-d9dc-4827-bd19-762e08b2aec4

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion