Splunk rules: 15

name: ASL AWS Multi-Factor Authentication Disabled
id: 4d2df5e0-1092-4817-88a8-79c7fa054668
version: 12
creation_date: '2022-10-04'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects attempts to disable multi-factor authentication (MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations. This activity is significant as disabling MFA can indicate an adversary attempting to weaken account security to maintain persistence using a compromised account. If confirmed malicious, this action could allow attackers to retain access to the AWS environment without detection, potentially leading to unauthorized access to sensitive resources and prolonged compromise.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` (api.operation=DeleteVirtualMFADevice OR api.operation=DeactivateMFADevice)
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor.user.uid api.operation api.service.name
           http_request.user_agent src_endpoint.ip actor.user.account.uid
           cloud.provider cloud.region
      | rename actor.user.uid as user api.operation as action api.service.name as dest http_request.user_agent as user_agent src_endpoint.ip as src actor.user.account.uid as vendor_account cloud.provider as vendor_product cloud.region as vendor_region
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `asl_aws_multi_factor_authentication_disabled_filter`
how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App.
known_false_positives: AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company
references:
    - https://attack.mitre.org/techniques/T1621/
    - https://aws.amazon.com/what-is/mfa/
finding:
    title: User $user$ has disabled Multi-Factor authentication
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS Identity and Access Management Account Takeover
asset_type: AWS Account
mitre_attack_id:
    - T1556.006
    - T1586.003
    - T1621
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: AWS Bedrock Claude excessive use of tokens
id: a839a6f7-aaac-438b-9d99-be0b49481e17
version: 1
creation_date: '2026-07-06'
modification_date: '2026-07-06'
author: Rod Soto
status: production
type: Anomaly
description: Detects identities generating anomalously large model responses relative to their own historical baseline. For each identity, computes the average, maximum, and standard deviation of output token counts across all invocations, then flags any identity whose single largest response exceeds two standard deviations above their own mean. A statistically significant output spike from a single identity may indicate bulk data extraction, successful prompt injection producing verbose output, or a runaway agentic loop hitting context limits.
data_source:
    - AWS Bedrock Claude
search: |-
    `aws_bedrock_claude`
    | spath output="out_tokens" path="output.outputBodyJson.usage.output_tokens"
    | eval user = replace('identity.arn', ".*/", "")
    | stats count           AS invocations,
            avg(out_tokens) AS avg_out,
            max(out_tokens) AS max_out,
            stdev(out_tokens) AS stdev_out
      BY user, identity.arn
    | eval stdev_out  = coalesce(stdev_out, 0)
    | eval threshold  = avg_out + (2 * stdev_out)
    | where max_out > threshold
    | table
        user,
        identity.arn,
        invocations,
        avg_out,
        max_out,
        stdev_out,
        threshold
    | sort -max_out
    | `aws_bedrock_claude_excessive_use_of_tokens_filter`
how_to_implement: You must install and configure the Splunk Add-on for AWS (https://splunkbase.splunk.com/app/1876). Enable Amazon Bedrock model invocation logging in AWS so that Claude request/response payloads are delivered to S3 and/or CloudWatch Logs (see https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html for setup steps), then ingest those logs into Splunk via the AWS TA. Configure the `aws_bedrock_claude` macro to point to the index and sourcetype (`json_no_timestamp`) where these logs land.
known_false_positives: This detection may produce false positives for identities with low invocation history, legitimate large document summarization tasks, or automated pipeline sessions with naturally variable output token counts.
references:
    - https://aws.amazon.com/blogs/apn/unlocking-the-power-of-splunk-with-amazon-bedrock-an-agentic-ai-approach-to-build-customized-splunk-assistants-using-bedrock-agents/
    - https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-infrastructure-monitoring/set-up-ai-infrastructure-monitoring/amazon-bedrock
    - https://research.splunk.com/stories/aws_bedrock_security/
    - https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Identity $user$ generated anomalously high output tokens in AWS Bedrock Claude with max output $max_out$ above threshold $threshold$.
analytic_story:
    - Suspicious AWS Bedrock Claude Activities
asset_type: Web Application
mitre_attack_id:
    - T1055
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: endpoint

name: AWS Bedrock Invoke Model Access Denied
id: c53a8e62-f741-11ee-9f6e-acde48001122
version: 6
creation_date: '2025-03-25'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: TTP
description: The following analytic identifies access denied error when attempting to invoke AWS Bedrock models. It leverages AWS CloudTrail logs to detect when a user or service receives an AccessDenied error when calling the InvokeModel API. This activity is significant as it may indicate an adversary attempting to access Bedrock models with insufficient permissions after compromising credentials. If confirmed malicious, this could suggest reconnaissance activities or privilege escalation attempts targeting generative AI resources, potentially leading to data exfiltration or manipulation of model outputs.
data_source:
    - AWS CloudTrail
search: >-
    `cloudtrail` eventSource=bedrock.amazonaws.com eventName=InvokeModel errorCode=AccessDenied
    | rename user_name as user
    | stats count min(_time) as firstTime max(_time) as lastTime values(requestParameters.modelId) as modelIds by src user user_agent vendor_account vendor_product dest signature vendor_region result result_id
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `aws_bedrock_invoke_model_access_denied_filter`
how_to_implement: The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs with Bedrock service events enabled. You must install and configure the AWS App for Splunk (version 6.0.0 or later) and Splunk Add-on for AWS (version 5.1.0 or later) to collect CloudTrail logs from AWS.
known_false_positives: Legitimate users may encounter access denied errors during permission testing, role transitions, or when service permissions are being reconfigured. Access denials may also happen when automated processes are using outdated credentials or when new Bedrock features are being explored.
references:
    - https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListFoundationModels.html
    - https://trustoncloud.com/blog/exposing-the-weakness-how-we-identified-a-flaw-in-bedrocks-foundation-model-access-control/
    - https://attack.mitre.org/techniques/T1595/
finding:
    title: User $user$ access denied when attempting to invoke AWS Bedrock models from $src$
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS Bedrock Security
asset_type: AWS Account
mitre_attack_id:
    - T1078
    - T1550
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: AWS Defense Evasion Delete Cloudtrail
id: 82092925-9ca1-4e06-98b8-85a2d3889552
version: 12
creation_date: '2022-07-12'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: TTP
description: The following analytic detects the deletion of AWS CloudTrail logs by identifying `DeleteTrail` events within CloudTrail logs. This detection leverages CloudTrail data to monitor for successful `DeleteTrail` actions, excluding those initiated from the AWS console. This activity is significant because adversaries may delete CloudTrail logs to evade detection and operate stealthily within the compromised environment. If confirmed malicious, this action could allow attackers to cover their tracks, making it difficult to trace their activities and potentially leading to prolonged unauthorized access and further exploitation.
data_source:
    - AWS CloudTrail DeleteTrail
search: |-
    `cloudtrail` eventName = DeleteTrail eventSource = cloudtrail.amazonaws.com userAgent !=console.amazonaws.com errorCode = success
      | rename user_name as user
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY signature dest user
           user_agent src vendor_account
           vendor_region vendor_product
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `aws_defense_evasion_delete_cloudtrail_filter`
how_to_implement: You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment.
known_false_positives: While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity.
references:
    - https://attack.mitre.org/techniques/T1562/008/
finding:
    title: User $user$ has delete a CloudTrail logging for account id $vendor_account$ from IP $src$
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS Defense Evasion
asset_type: AWS Account
mitre_attack_id:
    - T1685.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: Cisco Isovalent - Access To Cloud Metadata Service
id: 7f2e1a9a-1e8e-4d2e-8b7c-5f2c3d6a9b21
version: 6
creation_date: '2026-01-05'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: Anomaly
description: The following analytic detects workloads accessing the cloud instance metadata service at 169.254.169.254. This IP is used by AWS, GCP and Azure metadata endpoints and is frequently abused in SSRF or lateral movement scenarios to obtain credentials and sensitive environment details. Monitor unexpected access to this service from application pods or namespaces where such behavior is atypical.
data_source:
    - Cisco Isovalent Process Connect
search: |
    `cisco_isovalent_process_connect` | rename process_connect.parent.binary as binary | `excluded_cloud_binaries`
    | stats count
            min(_time) as firstTime
            max(_time) as lastTime
            values(dest_port) as dest_port
            values(src_ip) as src_ip
        by cluster_name pod_name pod_image_name pod_namespace node_name dest_ip
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_isovalent___access_to_cloud_metadata_service_filter`
how_to_implement: This detection relies on Cisco Isovalent Runtime Security process_connect telemetry. Deploy Isovalent Runtime Security and the Cisco Security Cloud TA to collect these logs via HEC and normalize them. Optionally, a similar variant can be built with process_exec by looking for command-lines that reference 169.254.169.254 (for example curl or wget invocations from within pods). Please update a macro named `excluded_cloud_binaries` that returns true for binaries that are known to access the cloud metadata service.
known_false_positives: Legitimate platform components and node agents may query the metadata service. Validate by namespace, labels and workload identity; suppress expected sources and alert on atypical pods or namespaces.
references:
    - https://attack.mitre.org/techniques/T1552/005/
    - https://hackerone.com/reports/341876
    - https://docs.isovalent.com/user-guide/sec-ops-visibility/lateral-movement/index.html
intermediate_findings:
    entities:
        - field: pod_name
          type: system
          score: 20
          message: Pod [$pod_name$] accessed the cloud metadata service [$dest_ip$] in cluster [$cluster_name$]
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - Cisco Isovalent Suspicious Activity
    - VoidLink Cloud-Native Linux Malware
asset_type: Kubernetes
mitre_attack_id:
    - T1552.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: network

id: '15682.23295'
title: Command Output Redirected to Localhost
description: 'Command output redirection to localhost is a consistent behavior for
  post-exploitation frameworks and is commonly observed in red team engagements. --
  Threat Actor Association: Mustang Panda (aka. Stately Taurus//Earth Preta/BRONZE
  PRESIDENT/TA416/RedDelta)'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR
  "<EventID>4688<" OR Type=Process OR TERM(EventCode=5145) OR "<EventID>5145<") |
  rex field=_raw "''ShareName''?>(?<share_name>[^<]+)" | table _time, host, user signature_id,
  process, process_*, src_nt_host, share_name | bin span=1s | stats values(*) as *
  by _time, host | where match(process, "(?i)cmd(\.exe)?.*\s+/c\s+") and match(src_nt_host,
  "127.0.0.1") '
techniques:
- collection:data staged
- execution:command and scripting interpreter
technique_id: 
- T1074
- T1059
data_category:
- Windows event logs
- Process command-line parameters
references:
- https://resource.redcanary.com/rs/003-YRU-314/images/2021-Threat-Detection-Report.pdf

name: Create Remote Thread into LSASS
id: 67d4dbef-9564-4699-8da8-03a151529edc
version: 15
creation_date: '2019-12-11'
modification_date: '2026-06-29'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: |-
    The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS).
    This behavior is identified using Sysmon EventID 8 logs, focusing on processes that create remote threads in lsass.exe.
    This activity is significant because it is commonly associated with credential dumping, a tactic used by adversaries to steal user authentication credentials.
    If confirmed malicious, this could allow attackers to gain unauthorized access to sensitive information, leading to potential compromise of the entire network.
    Analysts should investigate to differentiate between legitimate tools and potential threats.
data_source:
    - Sysmon EventID 8
search: |-
    `sysmon`
    EventID=8
    TargetImage="*\\lsass.exe"
    | stats count min(_time) as firstTime
                  max(_time) as lastTime
                  values(NewThreadId) as "NewThreadId"
                  values(StartAddress) as "StartAddress"
      by dest signature_id signature
         SourceProcessGuid SourceProcessId SourceImage
         TargetProcessGuid TargetProcessId TargetImage
         StartModule StartFunction vendor_product
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `create_remote_thread_into_lsass_filter`
how_to_implement: This search needs Sysmon Logs with a Sysmon configuration, which includes EventCode 8 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
known_false_positives: Other tools can access LSASS for legitimate reasons and generate an event. In these cases, tweaking the search may help eliminate noise.
references:
    - https://2017.zeronights.org/wp-content/uploads/materials/ZN17_Kheirkhabarov_Hunting_for_Credentials_Dumping_in_Windows_Environment.pdf
finding:
    title: A process has created a remote thread into $TargetImage$ on $dest$. This behavior is indicative of credential dumping and should be investigated.
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: TargetImage
      type: process_name
analytic_story:
    - Credential Dumping
    - BlackSuit Ransomware
    - Lokibot
asset_type: Windows
mitre_attack_id:
    - T1003.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '31402.56383'
title: Defender Registry Values Modified
description: Adversaries may interact with the Windows Registry to disable security
  tools to avoid possible detection of their malware/tools and activities. They may
  interact directly with the registry via command line interpreters or they may abuse
  system utilities to achieve the same goals, such as SystemSettingsAdminFlows.exe.
  This use case detects commands for registry modifications targeting Windows Defender
  capabilities.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_powershell` (TERM(EventCode=4103) OR
  "<EventID>4103<") OR (TERM(EventCode=4104) OR "<EventID>4104<") "Defender" (("DisableEnhancedNotifications"
  OR "RTP") "1") OR (("SubmitSamplesConsent" OR "SpynetReporting") "0") OR (("Set-ItemProperty"
  OR "sp " OR "ADD ") ("SOFTWARE\\Microsoft\\Windows Defender\\Reporting" OR "SOFTWARE\\Microsoft\\Windows
  Defender\\Spynet" OR "SOFTWARE\\Microsoft\\Windows Defender\\Real-Time Protection")))
  | table _time, host, user, process | bin span=1s | stats values(*) as * by _time,
  host '
techniques:
- defense-evasion:modify registry
- defense-evasion:impair defenses:disable or modify tools
technique_id:
- T1112
- T1562.001
data_category:
- PowerShell logs
references:
- https://attack.mitre.org/techniques/T1562/001/
- https://attack.mitre.org/techniques/T1112/
- https://www.huntress.com/blog/lolbin-to-inc-ransomware

name: Detect AWS Console Login by New User
id: bc91a8cd-35e7-4bb2-6140-e756cc46fd71
version: 11
creation_date: '2020-10-26'
modification_date: '2026-05-13'
author: Rico Valdez, Splunk
status: production
type: Hunting
description: The following analytic detects AWS console login events by new users. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen users based on ARN values. This detection is significant because a new user logging into the AWS console could indicate the creation of new accounts or potential unauthorized access. If confirmed malicious, this activity could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment.
data_source:
    - AWS CloudTrail
search: |-
    | tstats earliest(_time) as firstTime latest(_time) as lastTime FROM datamodel=Authentication
      WHERE Authentication.signature=ConsoleLogin
      BY Authentication.user
    | `drop_dm_object_name(Authentication)`
    | join user type=outer [
    | inputlookup previously_seen_users_console_logins
    | stats min(firstTime) as earliestseen
      BY user]
    | eval userStatus=if(earliestseen >= relative_time(now(), "-24h@h") OR isnull(earliestseen), "First Time Logging into AWS Console", "Previously Seen User")
    | where userStatus="First Time Logging into AWS Console"
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `detect_aws_console_login_by_new_user_filter`
how_to_implement: You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines.
known_false_positives: When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
references: []
analytic_story:
    - Suspicious Cloud Authentication Activities
    - AWS Identity and Access Management Account Takeover
asset_type: AWS Instance
mitre_attack_id:
    - T1552
    - T1586.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat
baselines:
    - Previously Seen Users in CloudTrail - Initial
    - Previously Seen Users In CloudTrail - Update

name: Execute Javascript With Jscript COM CLSID
id: dc64d064-d346-11eb-8588-acde48001122
version: 13
creation_date: '2021-06-23'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic detects the execution of JavaScript using the JScript.Encode CLSID (COM Object) by cscript.exe. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, command-line executions, and parent processes. This activity is significant as it is a known technique used by ransomware, such as Reddot, to execute malicious scripts and potentially disable AMSI (Antimalware Scan Interface). If confirmed malicious, this behavior could allow attackers to execute arbitrary code, evade detection, and maintain persistence within the environment.
data_source:
    - Sysmon EventID 1
    - Windows Event Log Security 4688
    - CrowdStrike ProcessRollup2
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes
      WHERE Processes.process_name = "cscript.exe" Processes.process="*-e:{F414C262-6AC0-11CF-B6D1-00AA00BBBB58}*"
      BY Processes.action Processes.dest Processes.original_file_name
         Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid
         Processes.parent_process_id Processes.parent_process_name Processes.parent_process_path
         Processes.process Processes.process_exec Processes.process_guid
         Processes.process_hash Processes.process_id Processes.process_integrity_level
         Processes.process_name Processes.process_path Processes.user
         Processes.user_id Processes.vendor_product
    | `drop_dm_object_name(Processes)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `execute_javascript_with_jscript_com_clsid_filter`
how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
known_false_positives: No false positives have been identified at this time.
references:
    - https://app.any.run/tasks/c0f98850-af65-4352-9746-fbebadee4f05/
finding:
    title: Suspicious process of cscript.exe with a parent process $parent_process_name$ where it tries to execute javascript using jscript.encode CLSID (COM OBJ), detected on $dest$ by $user$
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: Suspicious process of cscript.exe with a parent process $parent_process_name$ where it tries to execute javascript using jscript.encode CLSID (COM OBJ), detected on $dest$ by $user$
threat_objects:
    - field: parent_process_name
      type: parent_process_name
analytic_story:
    - Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1059.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Get WMIObject Group Discovery
id: 5434f670-155d-11ec-8cca-acde48001122
version: 9
creation_date: '2021-09-14'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Hunting
description: The following analytic detects the use of the `Get-WMIObject Win32_Group` command executed via PowerShell to enumerate local groups on an endpoint. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. Identifying local groups can be a precursor to privilege escalation or lateral movement. If confirmed malicious, this activity could allow an attacker to map out group memberships, aiding in further exploitation or unauthorized access to sensitive resources.
data_source:
    - Sysmon EventID 1
    - Windows Event Log Security 4688
    - CrowdStrike ProcessRollup2
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes
      WHERE (
            Processes.process_name=powershell.exe
            OR
            processes.process_name=cmd.exe
        )
        (Processes.process="*Get-WMIObject*" AND Processes.process="*Win32_Group*")
      BY Processes.action Processes.dest Processes.original_file_name
         Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid
         Processes.parent_process_id Processes.parent_process_name Processes.parent_process_path
         Processes.process Processes.process_exec Processes.process_guid
         Processes.process_hash Processes.process_id Processes.process_integrity_level
         Processes.process_name Processes.process_path Processes.user
         Processes.user_id Processes.vendor_product
    | `drop_dm_object_name(Processes)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `get_wmiobject_group_discovery_filter`
how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
known_false_positives: False positives may be present. Tune as needed.
references:
    - https://attack.mitre.org/techniques/T1069/001/
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1069.001/T1069.001.md
analytic_story:
    - Active Directory Discovery
asset_type: Endpoint
mitre_attack_id:
    - T1069.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '32248.57375'
title: Group Policy Editor Execution
description: Adversaries may abuse mmc.exe to proxy execution of malicious .msc files.
  Microsoft Management Console (MMC) is a binary that may be signed by Microsoft and
  is used in several ways in either its GUI or in a command prompt. MMC can be used
  to create, open, and save custom consoles that contain administrative tools created
  by Microsoft, called snap-ins. These snap-ins may be used to manage Windows systems
  locally or remotely. MMC can also be used to open Microsoft created .msc files to
  manage system configuration. For example, mmc gpedit.msc, will open the Group Policy
  Editor application window. This use case detects gpedit.msc executions.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR
  "<EventID>4688<" OR Type=Process) TERM(gpedit) "mmc.exe" | table _time, host, user,
  process | bin span=1s | stats values(*) as * by _time, host '
techniques:
- defense-evasion:system binary proxy execution:mmc
technique_id:
- T1218.014
data_category:
- Process command-line parameters
- Windows event logs
references:
- https://attack.mitre.org/techniques/T1218/014/
- https://www.itechtics.com/enable-gpedit-windows-10-home/

name: Kerberos TGT Request Using RC4 Encryption
id: 18916468-9c04-11ec-bdc6-acde48001122
version: 12
creation_date: '2022-03-08'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects a Kerberos Ticket Granting Ticket (TGT) request using RC4-HMAC encryption (type 0x17) by leveraging Event 4768. This encryption type is outdated and its presence may indicate an OverPass The Hash attack. Monitoring this activity is crucial as it can signify credential theft, allowing adversaries to authenticate to the Kerberos Distribution Center (KDC) using a stolen NTLM hash. If confirmed malicious, this could enable unauthorized access to systems and resources, potentially leading to lateral movement and further compromise within the network.
data_source:
    - Windows Event Log Security 4768
search: |-
    `wineventlog_security` EventCode=4768 TicketEncryptionType=0x17 ServiceName!=*$
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY ServiceName src_ip dest
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `kerberos_tgt_request_using_rc4_encryption_filter`
how_to_implement: To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
known_false_positives: Based on Microsoft documentation, legacy systems or applications will use RC4-HMAC as the default encryption for TGT requests. Specifically, systems before Windows Server 2008 and Windows Vista. Newer systems will use AES128 or AES256.
references:
    - https://stealthbits.com/blog/how-to-detect-overpass-the-hash-attacks/
    - https://www.thehacker.recipes/ad/movement/kerberos/ptk
    - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768
finding:
    title: A Kerberos TGT request with RC4 encryption was requested for $ServiceName$ from $src_ip$
    entity:
        field: src_ip
        type: system
        score: 50
analytic_story:
    - Active Directory Kerberos Attacks
    - Scattered Lapsus$ Hunters
asset_type: Endpoint
mitre_attack_id:
    - T1550
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Linux Install Kernel Module Using Modprobe Utility
id: 387b278a-6326-11ec-aa2c-acde48001122
version: 13
creation_date: '2022-01-05'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects the installation of a Linux kernel module using the modprobe utility. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line executions. This activity is significant because installing a kernel module can indicate an attempt to deploy a rootkit or other malicious kernel-level code, potentially leading to elevated privileges and bypassing security detections. If confirmed malicious, this could allow an attacker to gain persistent, high-level access to the system, compromising its integrity and security.
data_source:
    - Sysmon for Linux EventID 1
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes
      WHERE Processes.process_name IN("kmod", "sudo")
        AND
        Processes.process = *modprobe*
      BY Processes.action Processes.dest Processes.original_file_name
         Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid
         Processes.parent_process_id Processes.parent_process_name Processes.parent_process_path
         Processes.process Processes.process_exec Processes.process_guid
         Processes.process_hash Processes.process_id Processes.process_integrity_level
         Processes.process_name Processes.process_path Processes.user
         Processes.user_id Processes.vendor_product
    | `drop_dm_object_name(Processes)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `linux_install_kernel_module_using_modprobe_utility_filter`
how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
known_false_positives: Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
references:
    - https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/
    - https://security.stackexchange.com/questions/175953/how-to-load-a-malicious-lkm-at-startup
    - https://0x00sec.org/t/kernel-rootkits-getting-your-hands-dirty/1485
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A commandline $process$ that may install kernel module on $dest$
analytic_story:
    - Linux Privilege Escalation
    - Linux Persistence Techniques
    - Linux Rootkit
    - China-Nexus Threat Activity
    - VoidLink Cloud-Native Linux Malware
asset_type: Endpoint
mitre_attack_id:
    - T1547.006
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Monitor Email For Brand Abuse
id: b2ea1f38-3a3e-4b8a-9cf1-82760d86a6b8
version: 11
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: David Dorsey, Splunk
status: experimental
type: TTP
description: The following analytic identifies emails claiming to be sent from a domain similar to one you are monitoring for potential abuse. It leverages email header data, specifically the sender's address, and cross-references it with a lookup table of known domain permutations generated by the "ESCU - DNSTwist Domain Names" search. This activity is significant as it can indicate phishing attempts or brand impersonation, which are common tactics used in social engineering attacks. If confirmed malicious, this could lead to unauthorized access, data theft, or reputational damage.
data_source: []
search: |-
    | tstats `security_content_summariesonly` values(All_Email.recipient) as recipients, min(_time) as firstTime, max(_time) as lastTime FROM datamodel=Email
      BY All_Email.src_user, All_Email.message_id
    | `drop_dm_object_name("All_Email")`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | eval temp=split(src_user, "@")
    | eval email_domain=mvindex(temp, 1)
    | lookup update=true brandMonitoring_lookup domain as email_domain OUTPUT domain_abuse
    | search domain_abuse=true
    | table message_id, src_user, email_domain, recipients, firstTime, lastTime
    | `monitor_email_for_brand_abuse_filter`
how_to_implement: You need to ingest email header data. Specifically the sender's address (src_user) must be populated.  You also need to have run the search "ESCU - DNSTwist Domain Names", which creates the permutations of the domain that will be checked for.
known_false_positives: No false positives have been identified at this time.
references: []
finding:
    title: Possible Brand Abuse from $email_domain$
    entity:
        field: src_user
        type: user
        score: 50
analytic_story:
    - Brand Monitoring
    - Suspicious Emails
    - Scattered Lapsus$ Hunters
asset_type: Endpoint
mitre_attack_id: []
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: network
baselines:
    - DNSTwist Domain Names

name: MSI Module Loaded by Non-System Binary
id: ccb98a66-5851-11ec-b91c-acde48001122
version: 10
creation_date: '2021-12-08'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Hunting
description: The following analytic detects the loading of `msi.dll` by a binary not located in `system32`, `syswow64`, `winsxs`, or `windows` directories. This is identified using Sysmon EventCode 7, which logs DLL loads, and filters out legitimate system paths. This activity is significant as it may indicate exploitation of CVE-2021-41379 or DLL side-loading attacks, both of which can lead to unauthorized system modifications. If confirmed malicious, this could allow an attacker to execute arbitrary code, escalate privileges, or persist within the environment.
data_source:
    - Sysmon EventID 7
search: '`sysmon` EventCode=7 ImageLoaded="*\\msi.dll" NOT (Image IN ("*\\System32\\*","*\\syswow64\\*","*\\windows\\*", "*\\winsxs\\*")) | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by Image ImageLoaded dest loaded_file loaded_file_path original_file_name process_exec process_guid process_hash process_id process_name process_path service_dll_signature_exists service_dll_signature_verified signature signature_id user_id vendor_product | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `msi_module_loaded_by_non_system_binary_filter`'
how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
known_false_positives: It is possible some Administrative utilities will load msi.dll outside of normal system paths, filter as needed.
references:
    - https://attackerkb.com/topics/7LstI2clmF/cve-2021-41379/rapid7-analysis
    - https://github.com/AlexandrVIvanov/InstallerFileTakeOver
    - https://github.com/mandiant/red_team_tool_countermeasures/blob/master/rules/PGF/supplemental/hxioc/msi.dll%20Hijack%20(Methodology).ioc
analytic_story:
    - Data Destruction
    - Hermetic Wiper
    - Windows Privilege Escalation
asset_type: Endpoint
cve:
    - CVE-2021-41379
mitre_attack_id:
    - T1574.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: O365 Email Suspicious Behavior Alert
id: 85c7555a-05af-4322-81aa-76b4ddf52baa
version: 11
creation_date: '2024-04-07'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic identifies when one of O365 the built-in security detections for suspicious email behaviors are triggered.  These alerts often indicate that an attacker may have compromised a mailbox within the environment. Any detections from built-in Office 365 capabilities should be monitored and responded to appropriately. Certain premium Office 365 capabilities further enhance these detection and response functions.
data_source:
    - Office 365 Universal Audit Log
search: |-
    `o365_management_activity` Workload=SecurityComplianceCenter Operation=AlertEntityGenerated Name IN ("Suspicious email sending patterns detected","User restricted from sending email","Suspicious Email Forwarding Activity","Email sending limit exceeded")
      | fromjson Data
      | rename Name as signature, AlertId as signature_id, ObjectId as user
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY dest user src
           vendor_account vendor_product signature
           signature_id
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `o365_email_suspicious_behavior_alert_filter`
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. The alerts must be enabled in the o365 security portal.
known_false_positives: Users emailing for legitimate business purposes that appear suspicious.
references:
    - https://learn.microsoft.com/en-us/purview/alert-policies
finding:
    title: The user $user$ triggered the O365 security alert [$signature$]
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Suspicious Emails
    - Office 365 Collection Techniques
    - Office 365 Account Takeover
asset_type: O365 Tenant
mitre_attack_id:
    - T1114.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: O365 Privileged Role Assigned To Service Principal
id: 80f3fc1b-705f-4080-bf08-f61bf013b900
version: 11
creation_date: '2024-04-13'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals. This detection leverages the O365 Universal Audit Log data source.
data_source:
    - Office 365 Universal Audit Log
search: "`o365_management_activity` Workload=AzureActiveDirectory Operation IN (\"Add member to role.\",\"Add eligible member to role.\") | eval user = ObjectId, src_user = case(match(mvindex('Actor{}.ID',-1),\"User\"),mvindex('Actor{}.ID',0),match(mvindex('Actor{}.ID',-1),\"ServicePrincipal\"),mvindex('Actor{}.ID',3),true(),mvindex('Actor{}.ID',0)), object_name = mvindex('ModifiedProperties{}.NewValue', mvfind('ModifiedProperties{}.Name',\"Role\\.DisplayName\")), object_id = mvindex('ModifiedProperties{}.NewValue', mvfind('ModifiedProperties{}.Name',\"Role\\.TemplateId\")), signature = Operation, result = ResultStatus, category = mvindex('Target{}.ID',2) | fillnull | stats count, min(_time) as firstTime, max(_time) as lastTime by src_user, src, user, category, result, object_name, object_id, signature,vendor_account, vendor_product, dest | lookup privileged_azure_ad_roles azuretemplateid as object_id OUTPUT isprvilegedadrole | search isprvilegedadrole=\"TRUE\" category!=\"User\" | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_privileged_role_assigned_to_service_principal_filter`"
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
known_false_positives: Administrators may legitimately assign the privileged roles to Service Principals as part of administrative tasks. Filter as needed.
references:
    - https://attack.mitre.org/techniques/T1098/003/
    - https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference
    - https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-exchange-online-admin-role?view=o365-worldwide
    - https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5
finding:
    title: A privileged Azure AD role [$object_name$] was assigned to the Service Principal $user$ initiated by $src_user$
    entity:
        field: src_user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 50
          message: A privileged Azure AD role [$object_name$] was assigned to the Service Principal $user$ initiated by $src_user$
analytic_story:
    - Azure Active Directory Privilege Escalation
    - Scattered Lapsus$ Hunters
asset_type: O365 Tenant
mitre_attack_id:
    - T1098.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: identity

name: PingID New MFA Method Registered For User
id: 892dfeaf-461d-4a78-aac8-b07e185c9bce
version: 8
creation_date: '2023-12-20'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic detects the registration of a new Multi-Factor Authentication (MFA) method for a PingID (PingOne) account. It leverages JSON logs from PingID, specifically looking for successful device pairing events. This activity is significant as adversaries who gain unauthorized access to a user account may register a new MFA method to maintain persistence. If confirmed malicious, this could allow attackers to bypass existing security measures, maintain long-term access, and potentially escalate their privileges within the compromised environment.
data_source:
    - PingID
search: "`pingid` \"result.message\"=\"Device Paired*\" result.status=\"SUCCESS\"   | rex field=result.message \"Device (Unp)?(P)?aired (?<device_extract>.+)\" | eval src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user = upper('actors{}.name'), reason = 'result.message' | eval object=CASE(ISNOTNULL('resources{}.devicemodel'),'resources{}.devicemodel',true(),device_extract) | eval action=CASE(match('result.message',\"Device Paired*\"),\"created\",match('result.message', \"Device Unpaired*\"),\"deleted\") | stats count min(_time) as firstTime, max(_time) as lastTime by src,user,object,action,reason | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `pingid_new_mfa_method_registered_for_user_filter`"
how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
known_false_positives: False positives may be generated by normal provisioning workflows for user device registration.
references:
    - https://twitter.com/jhencinski/status/1618660062352007174
    - https://attack.mitre.org/techniques/T1098/005/
    - https://attack.mitre.org/techniques/T1556/006/
    - https://docs.pingidentity.com/r/en-us/pingoneforenterprise/p14e_subscriptions?tocId=3xhnxjX3VzKNs3SXigWnQA
finding:
    title: An MFA configuration change was detected for [$user$], the device [$object$] was $action$.
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 50
          message: An MFA configuration change was detected for [$user$], the device [$object$] was $action$.
analytic_story:
    - Compromised User Account
asset_type: Identity
mitre_attack_id:
    - T1621
    - T1556.006
    - T1098.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: access

name: Rundll32 Process Creating Exe Dll Files
id: 6338266a-ee2a-11eb-bf68-acde48001122
version: 14
creation_date: '2021-08-03'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic detects a rundll32 process creating executable (.exe) or dynamic link library (.dll) files. It leverages Sysmon EventCode 11 to identify instances where rundll32.exe generates these file types. This activity is significant because rundll32 is often exploited by malware, such as IcedID, to drop malicious payloads in directories like Temp, AppData, or ProgramData. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, establish persistence, or escalate privileges within the environment.
data_source:
    - Sysmon EventID 11
search: |-
    `sysmon` EventCode=11 Image="*rundll32.exe" TargetFilename IN ("*.exe", "*.dll")
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY action dest file_name
           file_path process_guid process_id
           user_id vendor_product
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `rundll32_process_creating_exe_dll_files_filter`
how_to_implement: To successfully implement this search, you need to be ingesting logs with the process name, TargetFilename, and eventcode 11 executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
known_false_positives: No false positives have been identified at this time.
references:
    - https://any.run/malware-trends/icedid
finding:
    title: rundll32 process drops a file $file_name$ on host $dest$
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: file_name
      type: file_name
analytic_story:
    - IcedID
    - Living Off The Land
    - Gh0st RAT
asset_type: Endpoint
mitre_attack_id:
    - T1218.011
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '13454.20044'
title: System Owner_User Discovery - Windows
description: 'Adversaries may attempt to identify the primary user, currently logged
  in user, set of users that commonly uses a system, or whether a user is actively
  using the system. Adversaries may use the information during automated discovery
  to direct follow-on behaviors, including whether or not the adversary fully infects
  the target and/or attempts specific actions. This use case detects when reconnaissance
  commands specifically targeting discovery of system owners and users are executed
  in a short period of time. -- Threat Actor Association: Alloy Taurus/Gallium, APT28/Fancy
  Bear, FIN8 - Software Association: Play, Rhysida -- Atomics T1033 Test #1'
logic_format: Splunk
logic: ' `get_endpoint_data` `get_endpoint_data_powershell` ("<EventID>4104<" OR "<EventID>4103<"
  OR "EventCode=4104" OR "EventCode=4103") ("GetCurrent" OR "UserName") | table _time,
  host, user process, process_*, signature_id, user | bin span=60s | stats values(*)
  as * by _time, host | where match(process, "(?i)((GetCurrent)|(\[System\.Environment\]::UserName))") '
techniques:
- discovery:system owner/user discovery
technique_id: 
- T1033
data_category:
- PowerShell logs
- Process command-line parameters
references:
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1033/T1033.md#atomic-test-1---system-owneruser-discovery

name: Tomcat Session File Upload Attempt
id: a1d8f5c3-9b7e-4f2d-8c51-3bca5e672410
version: 6
creation_date: '2025-03-25'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Anomaly
description: This detection identifies potential exploitation of CVE-2025-24813 in Apache Tomcat through the initial stage of the attack. This first phase occurs when an attacker attempts to upload a malicious serialized Java object with a .session file extension via an HTTP PUT request. When successful, these uploads typically result in HTTP status codes 201 (Created) or 409 (Conflict) and create the foundation for subsequent deserialization attacks by placing malicious content in a location where Tomcat's session management can access it.
data_source:
    - Nginx Access
search: |-
    | tstats count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Web
      WHERE Web.http_method=PUT
        AND
        Web.uri_path="*.session"
        AND
        (Web.status=201
        OR
        Web.status=409)
      BY Web.src, Web.dest, Web.http_user_agent,
         Web.uri_path, Web.status
    | `drop_dm_object_name("Web")`
    | rex field=uri_path "/(?<filename>[^/]+)\.session$"
    | eval severity="High"
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `tomcat_session_file_upload_attempt_filter`
how_to_implement: To successfully implement this search, you need to be ingesting logs from your web servers, proxies, or WAFs that process web traffic to Tomcat instances. The data must be mapped to the Web datamodel in the Web node. Ensure your web servers are logging HTTP PUT requests, including status codes and URI paths. This detection specifically looks for PUT requests targeting files with a .session extension that result in HTTP status codes 201 or 409, which indicate successful creation of files - a pattern consistent with the first stage of CVE-2025-24813 exploitation.
known_false_positives: Some legitimate applications might use PUT requests to create .session files, especially in custom implementations that leverage Tomcat's session persistence mechanism. Verify if the detected activity is part of a normal application flow or if it correlates with other suspicious behavior, such as subsequent GET requests with manipulated JSESSIONID cookies.
references:
    - https://lists.apache.org/thread/j5fkjv2k477os90nczf2v9l61fb0kkgq
    - https://nvd.nist.gov/vuln/detail/CVE-2025-24813
    - https://github.com/vulhub/vulhub/tree/master/tomcat/CVE-2025-24813
    - https://www.rapid7.com/db/vulnerabilities/apache-tomcat-cve-2025-24813/
    - https://gist.github.com/MHaggis/e106367f6649fbb09ab27e7b4a01cf73
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A Tomcat session file upload attempt has been detected from IP $src$ targeting $dest$ with a suspicious .session file. This could indicate the first stage of CVE-2025-24813 exploitation.
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - Apache Tomcat Session Deserialization Attacks
asset_type: Web Application
cve:
    - CVE-2025-24813
mitre_attack_id:
    - T1190
    - T1505.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: web
security_domain: network