Detection rules › Splunk

Splunk XSS Privilege Escalation via Custom Urls in Dashboard

Status
production
Group by
_time, host, index, sourcetype
Author
Rod Soto, Chase Franklin
Source
github.com/splunk/security_content

This is a composed hunting search that looks for POST requests to splunk_internal_metrics/data/ui/views which can be used to elevate privileges on the Splunk server via custom urls. The way to find privilege escalation is by looking at created users with high privielges after payload has been executed. This search looks at POST request and then looks at created users privileges.

Known false positives

  • This is a hunting search and requires operator to search for specific indicators of user creation in proximity to POST requests against vulnerable endpoint. It is not possible to detect payload during runtime.

MITRE ATT&CK coverage

TacticTechniques
Initial Access

Rule body

name: Splunk XSS Privilege Escalation via Custom Urls in Dashboard
id: 01e1e386-7656-4f36-a55a-52fe39b04a96
version: 7
creation_date: '2024-07-01'
modification_date: '2026-05-14'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
description: This is a composed hunting search that looks for POST requests to splunk_internal_metrics/data/ui/views which can be used to elevate privileges on the Splunk server via custom urls. The way to find privilege escalation is by looking at created users with high privielges after payload has been executed. This search looks at POST request and then looks at created users privileges.
data_source:
    - Splunk
search: '`splunkd_ui` method=POST /*/data/ui/views* | stats values(method) as method by _time index, sourcetype, host | eval event="post_request" | append [| search `audittrail` action="edit_user" operation="create" | rex field=_raw "object=\"(?<newUser>.*)\"" | stats count values(operation) as operation values(splunk_server) as splunk_server values(user) as user by _time index, sourcetype, host, newUser | eval event="create_user"] | sort - _time | transaction host startswith=event="post_request" endswith=event="create_user" maxspan=10m | table _time index, sourcetype, host, method, user, splunk_server, operation, event, newUser eventcount | `splunk_xss_privilege_escalation_via_custom_urls_in_dashboard_filter`'
how_to_implement: Requires access to internal indexes _audit and _internal.
known_false_positives: This is a hunting search and requires operator to search for specific indicators of user creation in proximity to POST requests against vulnerable endpoint. It is not possible to detect payload during runtime.
references:
    - https://advisory.splunk.com/
analytic_story:
    - Splunk Vulnerabilities
asset_type: Splunk Server
cve:
    - CVE-2024-36992
mitre_attack_id:
    - T1189
product:
    - Splunk Enterprise
    - Splunk Cloud
    - Splunk Enterprise Security
category: application
security_domain: endpoint

Stages and Predicates

Stage 1: search

`splunkd_ui` method=POST /*/data/ui/views*

Stage 2: stats

| stats values(method) as method by _time index, sourcetype, host

Stage 3: eval

| eval event="post_request"

Stage 4: append

| append [| search `audittrail` action="edit_user" operation="create" | rex field=_raw "object=\"(?<newUser>.*)\"" | stats count values(operation) as operation values(splunk_server) as splunk_server values(user) as user by _time index, sourcetype, host, newUser | eval event="create_user"]

Stage 5: sort

| sort - _time

Stage 6: macro (not parsed)

| transaction host startswith=event="post_request" endswith=event="create_user" maxspan=10m

Stage 7: table

| table _time index, sourcetype, host, method, user, splunk_server, operation, event, newUser eventcount

Stage 8: search

| `splunk_xss_privilege_escalation_via_custom_urls_in_dashboard_filter`

Indicators

These rows show field, operator, and value matches.

Search terms

These SPL tokens match against raw event text.

StageTerm
1/*/data/ui/views*