Splunk External Alerts

ELASTIC detection rule by Elastic · Elastic License v2

Generates a detection alert for each Splunk alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Splunk alerts in the app.

[metadata]
creation_date = "2025/07/31"
integration = ["splunk"]
maturity = "production"
promotion = true
updated_date = "2025/10/17"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert for each Splunk alert written to the configured indices. Enabling this rule allows you to
immediately begin investigating Splunk alerts in the app.
"""
from = "now-2m"
index = ["logs-splunk.alert-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Splunk External Alerts"
note = """## Triage and analysis

### Investigating Splunk External Alerts

Splunk monitors and analyzes data, often used in security environments to track and respond to potential threats. The rule identifies such manipulations by flagging alerts enabling timely investigation and response.

### Possible investigation steps

- Examine the specific indices where the alert was written to identify any unusual or unauthorized activity.
- Cross-reference the alert with recent changes or activities in the Splunk environment to determine if the alert could be a result of legitimate administrative actions.
- Investigate the source and context of the alert to identify any patterns or anomalies that could indicate manipulation or false positives.
- Check for any related alerts or logs that might provide additional context or evidence of adversarial behavior.
- Consult the Splunk investigation guide and resources tagged in the alert for specific guidance on handling similar threats.

### False positive analysis

- Alerts triggered by routine Splunk maintenance activities can be false positives. To manage these, identify and document regular maintenance schedules and create exceptions for alerts generated during these times.
- Frequent alerts from specific indices that are known to contain non-threatening data can be excluded by adjusting the rule to ignore these indices, ensuring only relevant alerts are investigated.
- Alerts generated by automated scripts or tools that interact with Splunk for legitimate purposes can be false positives. Review and whitelist these scripts or tools to prevent unnecessary alerts.
- If certain user actions consistently trigger alerts but are verified as non-malicious, consider creating user-specific exceptions to reduce noise and focus on genuine threats.
- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently exclude new or evolving threats.

### Response and remediation

- Immediately isolate affected systems to prevent further manipulation of Splunk alerts and potential spread of malicious activity.
- Review and validate the integrity of the Splunk alert indices to ensure no unauthorized changes have been made.
- Restore any compromised Splunk alert configurations from a known good backup to ensure accurate monitoring and alerting.
- Conduct a thorough audit of user access and permissions within Splunk to identify and revoke any unauthorized access.
- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems or data have been affected.
- Implement enhanced monitoring on Splunk indices to detect any future unauthorized changes or suspicious activities.
- Document the incident details and response actions taken for future reference and to improve incident response procedures.
"""
references = ["https://docs.elastic.co/en/integrations/splunk"]
risk_score = 47
rule_id = "d3b6222f-537e-4b84-956a-3ebae2dcf811"
rule_name_override = "splunk.alert.source"
setup = """## Setup

### Splunk Alert Integration
This rule is designed to capture alert events generated by the Splunk integration and promote them as Elastic detection alerts.

To capture Splunk alerts, install and configure the Splunk integration to ingest alert events into the `logs-splunk.alert-*` index pattern.

If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Splunk events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:splunk.alert to avoid receiving duplicate alerts.

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "medium"
tags = [
    "Data Source: Splunk",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Promotion: External Alerts",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind: alert and data_stream.dataset: splunk.alert
'''


[[rule.risk_score_mapping]]
field = "event.risk_score"
operator = "equals"
value = ""

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "low"
value = "21"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "medium"
value = "47"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "high"
value = "73"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "critical"
value = "99"

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

8807d523-fac3-4c46-bbbc-a89c6d2afddb

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