Splunk rules: 0t

name: AWS Credential Access Failed Login
id: a19b354d-0d7f-47f3-8ea6-1a7c36434968
version: 11
creation_date: '2022-08-07'
modification_date: '2026-05-13'
author: Gowthamaraj Rajendran, Bhavin Patel, Splunk
status: production
type: TTP
description: The following analytic identifies unsuccessful login attempts to the AWS Management Console using a specific user identity. It leverages AWS CloudTrail logs to detect failed authentication events associated with the AWS ConsoleLogin action. This activity is significant for a SOC because repeated failed login attempts may indicate a brute force attack or unauthorized access attempts. If confirmed malicious, an attacker could potentially gain access to AWS account services and resources, leading to data breaches, resource manipulation, or further exploitation within the AWS environment.
data_source:
    - AWS CloudTrail ConsoleLogin
search: |-
    `cloudtrail` eventName = ConsoleLogin errorMessage="Failed authentication"
      | 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_credential_access_failed_login_filter`
how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
known_false_positives: Users may genuinely mistype or forget the password.
references:
    - https://attack.mitre.org/techniques/T1110/001/
finding:
    title: User $user$ has a login failure from IP $src$
    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:
    - T1110.001
    - T1586.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: AWS Excessive Security Scanning
id: 1fdd164a-def8-4762-83a9-9ffe24e74d5a
version: 10
creation_date: '2021-04-13'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic identifies excessive security scanning activities in AWS by detecting a high number of Describe, List, or Get API calls from a single user. It leverages AWS CloudTrail logs to count distinct event names and flags users with more than 50 such events. This behavior is significant as it may indicate reconnaissance activities by an attacker attempting to map out your AWS environment. If confirmed malicious, this could lead to unauthorized access, data exfiltration, or further exploitation of your cloud infrastructure.
data_source:
    - AWS CloudTrail
search: |-
    `cloudtrail` eventName=Describe* OR eventName=List* OR eventName=Get*
      | fillnull
      | rename user_name as user
      | stats dc(signature) as dc_events min(_time) as firstTime max(_time) as lastTime values(signature) as signature values(dest) as dest values(user_agent) as user_agent values(src) as src values(vendor_account) as vendor_account values(vendor_region) as vendor_region
        BY user
      | where dc_events > 50
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `aws_excessive_security_scanning_filter`
how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
known_false_positives: While this search has no known false positives.
references:
    - https://github.com/aquasecurity/cloudsploit
finding:
    title: User $user$ has excessive number of api calls $dc_events$ from these IP addresses $src$, violating the threshold of 50, using the following actions $signature$.
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS User Monitoring
asset_type: AWS Account
mitre_attack_id:
    - T1526
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

name: BITS Job Persistence
id: e97a5ffe-90bf-11eb-928a-acde48001122
version: 13
creation_date: '2021-03-30'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic detects the use of `bitsadmin.exe` to schedule a BITS job for persistence on an endpoint. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific command-line parameters such as `create`, `addfile`, and `resume`. This activity is significant because BITS jobs can be used by attackers to maintain persistence, download malicious payloads, or exfiltrate data. If confirmed malicious, this could allow an attacker to persist in the environment, execute arbitrary code, or transfer sensitive information, necessitating further investigation and potential remediation.
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 `process_bitsadmin` Processes.process IN (*create*, *addfile*, *setnotifyflags*, *setnotifycmdline*, *setminretrydelay*, *setcustomheaders*, *resume* )
      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)`
    | `bits_job_persistence_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: Limited false positives will be present. Typically, applications will use `BitsAdmin.exe`. Any filtering should be done based on command-line arguments (legitimate applications) or parent process.
references:
    - https://attack.mitre.org/techniques/T1197/
    - https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1197/T1197.md#atomic-test-3---persist-download--execute
    - https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/
finding:
    title: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting to persist using BITS.
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting to persist using BITS.
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
analytic_story:
    - BITS Jobs
    - Living Off The Land
asset_type: Endpoint
mitre_attack_id:
    - T1197
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Cisco Secure Firewall - Connection to File Sharing Domain
id: f7e5e792-d907-46c1-a58e-4ff974dc462a
version: 10
creation_date: '2025-04-03'
modification_date: '2026-05-13'
author: Nasreddine Bencherchali, Splunk
status: production
type: Anomaly
description: |
    The following analytic detects outbound connections to commonly abused file sharing and pastebin-style hosting domains. It leverages Cisco Secure Firewall Threat Defense logs and focuses on allowed connections (action=Allow) where the url field matches a list of known data hosting or temporary storage services. While many of these platforms serve legitimate purposes, they are frequently leveraged by adversaries for malware delivery, data exfiltration, command and control (C2) beacons, or staging of encoded payloads. This analytic is valuable for identifying potential abuse of legitimate infrastructure as part of an attacker's kill chain. If confirmed malicious, this activity may indicate tool staging, credential dumping, or outbound data leaks over HTTP(S).
data_source:
    - Cisco Secure Firewall Threat Defense Connection Event
search: |
    `cisco_secure_firewall` action IN ("Trust", "Allow", "allowed") EventType=ConnectionEvent url IN ("*//objects.githubusercontent.com*", "*anonfiles.com*", "*cdn.discordapp.com*", "*ddns.net*", "*dl.dropboxusercontent.com*", "*ghostbin.co*", "*glitch.me*", "*gofile.io*", "*hastebin.com*", "*mediafire.com*", "*mega.nz*", "*onrender.com*", "*pages.dev*", "*paste.ee*", "*pastebin.com*", "*pastebin.pl*", "*pastetext.net*", "*privatlab.com*", "*privatlab.net*", "*send.exploit.in*", "*sendspace.com*", "*storage.googleapis.com*", "*storjshare.io*", "*supabase.co*", "*temp.sh*", "*transfer.sh*", "*trycloudflare.com*", "*ufile.io*", "*w3spaces.com*", "*workers.dev*")
    | stats count min(_time) as firstTime max(_time) as lastTime
      Values(src_port) as src_port
      Values(dest) as dest
      Values(dest_port) as dest_port
      Values(rule) as rule
      Values(url) as url
      Values(EVE_Process) as EVE_Process
      by src, transport, action
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_secure_firewall___connection_to_file_sharing_domain_filter`
how_to_implement: |
    This search requires Cisco Secure Firewall Threat Defense Logs, which
    includes the ConnectionEvent EventType. This search uses an input macro named `cisco_secure_firewall`.
    We strongly recommend that you specify your environment-specific configurations
    (index, source, sourcetype, etc.) for Cisco Secure Firewall Threat Defense 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.
    The logs are to be ingested using the Splunk Add-on for Cisco Security Cloud (https://splunkbase.splunk.com/app/7404).
    The access policy must also enable logging.
known_false_positives: |
    Legitimate users and applications may use these domains for benign purposes such as file transfers, collaborative development, or storing public content.
    Developer tools, browser extensions, or open-source software may connect to githubusercontent.com or cdn.discordapp.com as part of normal operation.
    It is recommended to review the associated process (`EVE_Process`), user behavior, and frequency of access before classifying the activity as suspicious.
references:
    - https://www.cisco.com/c/en/us/td/docs/security/firepower/741/api/FQE/secure_firewall_estreamer_fqe_guide_740.pdf
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: The host $src$ initiated a connection to the file sharing or pastebin domain $url$.
threat_objects:
    - field: url
      type: url
analytic_story:
    - Cisco Secure Firewall Threat Defense Analytics
    - Scattered Lapsus$ Hunters
asset_type: Network
mitre_attack_id:
    - T1071.001
    - T1090.002
    - T1105
    - T1567.002
    - T1588.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: network
security_domain: network

name: Detect attackers scanning for vulnerable JBoss servers
id: 104658f4-afdc-499e-9719-17243f982681
version: 8
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: experimental
type: TTP
description: The following analytic identifies specific GET or HEAD requests to web servers that indicate reconnaissance attempts to find vulnerable JBoss servers. It leverages data from the Web data model, focusing on HTTP methods and URLs associated with JBoss management interfaces. This activity is significant because it often precedes exploitation attempts using tools like JexBoss, which can compromise the server. If confirmed malicious, attackers could gain unauthorized access, execute arbitrary code, or escalate privileges, leading to potential data breaches and system compromise.
data_source: []
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Web
      WHERE (
            Web.http_method="GET"
            OR
            Web.http_method="HEAD"
        )
        AND (Web.url="*/web-console/ServerInfo.jsp*" OR Web.url="*web-console*" OR Web.url="*jmx-console*" OR Web.url = "*invoker*")
      BY Web.http_method, Web.url, Web.src,
         Web.dest
    | `drop_dm_object_name("Web")`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `detect_attackers_scanning_for_vulnerable_jboss_servers_filter`
how_to_implement: You must be ingesting data from the web server or network traffic that contains web specific information, and populating the Web data model.
known_false_positives: It's possible for legitimate HTTP requests to be made to URLs containing the suspicious paths.
references: []
finding:
    title: Potential Scanning for Vulnerable JBoss Servers - $dest$
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - JBoss Vulnerability
    - SamSam Ransomware
asset_type: Web Server
mitre_attack_id:
    - T1082
    - T1133
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: web
security_domain: network

name: Detect Certify Command Line Arguments
id: e6d2dc61-a8b9-4b03-906c-da0ca75d71b8
version: 12
creation_date: '2023-07-28'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic detects the use of Certify or Certipy tools to enumerate Active Directory Certificate Services (AD CS) environments. It leverages Endpoint Detection and Response (EDR) data, focusing on specific command-line arguments associated with these tools. This activity is significant because it indicates potential reconnaissance or exploitation attempts targeting AD CS, which could lead to unauthorized access or privilege escalation. If confirmed malicious, attackers could gain insights into the AD CS infrastructure, potentially compromising sensitive certificates and escalating their privileges within the network.
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 IN ("* find *","* auth *","* request *","* req *","* download *",)
        AND
        Processes.process IN ("* /vulnerable*","* /enrolleeSuppliesSubject *","* /json /outfile*","* /ca*", "* -username *","* -u *")
      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)`
    | `detect_certify_command_line_arguments_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://github.com/GhostPack/Certify
    - https://github.com/ly4k/Certipy
    - https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
finding:
    title: Certify/Certipy arguments detected on $dest$.
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: process_name
      type: process_name
    - field: process_name
      type: process_name
analytic_story:
    - Compromised Windows Host
    - Windows Certificate Services
    - Ingress Tool Transfer
asset_type: Endpoint
mitre_attack_id:
    - T1649
    - T1105
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Detect Outlook exe writing a zip file
id: a51bfe1a-94f0-4822-b1e4-16ae10145893
version: 18
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: Anomaly
description: |
    The following analytic identifies the execution of `outlook.exe` writing a `.zip` file to the disk.
    It leverages data from the Endpoint data model, specifically monitoring process and filesystem activities.
    This behavior can be significant as it may indicate the use of Outlook to deliver malicious payloads or exfiltrate data via compressed files.
    If confirmed malicious, this activity could lead to unauthorized data access, data exfiltration, or the delivery of malware, potentially compromising the security of the affected system and network.
data_source:
    - Sysmon EventID 1 AND Sysmon EventID 11
search: |
    | tstats `security_content_summariesonly`
      min(_time) as firstTime
      max(_time) as lastTime

    FROM datamodel=Endpoint.Processes where

    Processes.process_name=outlook.exe

    by _time span=5m
      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)`

    | rename process_guid as malicious_id
    | rename parent_process_id as outlook_id

    | join malicious_id type=inner
      [
        | tstats `security_content_summariesonly`
          count values(Filesystem.file_path) as file_path
                values(Filesystem.file_name) as file_name
          FROM datamodel=Endpoint.Filesystem where

          Filesystem.file_path=*.zip
          Filesystem.file_path IN ("*:\\Users*", "*\\AppData\\Local\\Temp*")
          Filesystem.action=created

          by _time span=5m
             Filesystem.process_guid Filesystem.process_id
             Filesystem.file_hash Filesystem.dest Filesystem.dvc
             Filesystem.signature Filesystem.signature_id

        | `drop_dm_object_name(Filesystem)`
        | `security_content_ctime(firstTime)`
        | `security_content_ctime(lastTime)`

        | rename process_guid as malicious_id

        | fields malicious_id outlook_id dest
                 file_path file_name
                 file_hash count file_id
      ]
    | table firstTime lastTime user malicious_id outlook_id
            process_name parent_process_name file_name file_path
            dest action original_file_name parent_process
            parent_process_name parent_process_exec parent_process_guid
            parent_process_id parent_process_path process_exec
            process_guid process_hash process_id process_integrity_level
            process_name process_path user user_id vendor_product

    | where file_name != ""
    | `detect_outlook_exe_writing_a_zip_file_filter`
how_to_implement: |
    You must be ingesting data that records filesystem and process activity
    from your hosts to populate the Endpoint data model. This is typically populated
    via endpoint detection-and-response product, such as Carbon Black, or endpoint data
    sources, such as Sysmon.
known_false_positives: It is not uncommon for outlook to write legitimate zip files to the disk.
references:
    - https://www.paubox.com/news/hackers-exploit-corrupted-zip-and-office-files-to-bypass-email-security
    - https://docs.datadoghq.com/security/default_rules/def-000-14w/
    - https://theweborion.com/blog/zip-files/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: ZIP file - [$file_name$] located in [$file_path$] written by outlook.exe on destination host - [$dest$] by user - [$user$]
        - field: dest
          type: system
          score: 20
          message: ZIP file - [$file_name$] located in [$file_path$] written by outlook.exe on destination host - [$dest$] by user - [$user$]
threat_objects:
    - field: file_name
      type: file_name
    - field: file_path
      type: file_path
analytic_story:
    - Amadey
    - APT37 Rustonotto and FadeStealer
    - Meduza Stealer
    - PXA Stealer
    - Remcos
    - Spearphishing Attachments
asset_type: Endpoint
mitre_attack_id:
    - T1566.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Hide User Account From Sign-In Screen
id: 834ba832-ad89-11eb-937d-acde48001122
version: 16
creation_date: '2021-05-07'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk, Steven Dick
status: production
type: TTP
description: The following analytic detects a suspicious registry modification that hides a user account from the Windows Login screen. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\Windows NT\\CurrentVersion\\Winlogon\\SpecialAccounts\\Userlist*" with a value of "0x00000000". This activity is significant as it may indicate an adversary attempting to create a hidden admin account to avoid detection and maintain persistence on the compromised machine. If confirmed malicious, this could allow the attacker to maintain undetected access and control over the system, posing a severe security risk.
data_source:
    - Sysmon EventID 13
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path="*\\Windows NT\\CurrentVersion\\Winlogon\\SpecialAccounts\\Userlist*" AND Registry.registry_value_data = "0x00000000") by Registry.action Registry.dest Registry.process_guid Registry.process_id Registry.registry_hive Registry.registry_path Registry.registry_key_name Registry.registry_value_data Registry.registry_value_name Registry.registry_value_type Registry.status Registry.user Registry.vendor_product | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `hide_user_account_from_sign_in_screen_filter`'
how_to_implement: To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the official Sysmon TA. https://splunkbase.splunk.com/app/5709
known_false_positives: No false positives have been identified at this time.
references:
    - https://thedfirreport.com/2020/04/20/sqlserver-or-the-miner-in-the-basement/
finding:
    title: Suspicious registry modification ($registry_value_name$) which is used go hide a user account on the Windows Login screen detected on $dest$ executed by $user$
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: Suspicious registry modification ($registry_value_name$) which is used go hide a user account on the Windows Login screen detected on $dest$ executed by $user$
threat_objects:
    - field: registry_value_name
      type: registry_value_name
analytic_story:
    - XMRig
    - Windows Registry Abuse
    - Azorult
    - Warzone RAT
asset_type: Endpoint
mitre_attack_id:
    - T1685
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Kubernetes DaemonSet Deployed
id: bf39c3a3-b191-4d42-8738-9d9797bd0c3a
version: 10
creation_date: '2023-12-20'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. This behavior is identified by monitoring Kubernetes Audit logs for the creation event of a DaemonSet. DaemonSets ensure a specific pod runs on every node, making them a potential vector for persistent access. This activity is significant for a SOC as it could indicate an attempt to maintain persistent access to the Kubernetes infrastructure. If confirmed malicious, it could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information.
data_source:
    - Kubernetes Audit
search: |-
    `kube_audit` "objectRef.resource"=daemonsets verb=create
      | fillnull
      | stats count values(user.groups{}) as user_groups
        BY kind objectRef.name objectRef.namespace
           objectRef.resource requestObject.kind responseStatus.code
           sourceIPs{} stage user.username
           userAgent verb
      | rename sourceIPs{} as src_ip, user.username as user
      | `kubernetes_daemonset_deployed_filter`
how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
known_false_positives: No false positives have been identified at this time.
references:
    - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: DaemonSet deployed to Kubernetes by user $user$
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - Kubernetes Security
asset_type: Kubernetes
mitre_attack_id:
    - T1204
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

name: Linux At Allow Config File Creation
id: 977b3082-5f3d-11ec-b954-acde48001122
version: 11
creation_date: '2021-12-21'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects the creation of the /etc/at.allow or /etc/at.deny configuration files in Linux. It leverages file creation events from the Endpoint datamodel to identify when these files are created. This activity is significant as these files control user permissions for the "at" scheduling application and can be abused by attackers to establish persistence. If confirmed malicious, this could allow unauthorized execution of malicious code, leading to potential data theft or further system compromise. Analysts should review the file path, creation time, and associated processes to assess the threat.
data_source:
    - Sysmon for Linux EventID 11
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Filesystem
      WHERE Filesystem.file_path IN ("*/etc/at.allow", "*/etc/at.deny")
      BY Filesystem.action Filesystem.dest Filesystem.file_access_time
         Filesystem.file_create_time Filesystem.file_hash Filesystem.file_modify_time
         Filesystem.file_name Filesystem.file_path Filesystem.file_acl
         Filesystem.file_size Filesystem.process_guid Filesystem.process_id
         Filesystem.user Filesystem.vendor_product
    | `drop_dm_object_name(Filesystem)`
    | `security_content_ctime(lastTime)`
    | `security_content_ctime(firstTime)`
    | `linux_at_allow_config_file_creation_filter`
how_to_implement: To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints into the Endpoint datamodel. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
known_false_positives: Administrator or network operator can create this file for automation purposes. Please update the filter macros to remove false positives.
references:
    - https://linuxize.com/post/at-command-in-linux/
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A file $file_name$ is created in $file_path$ on $dest$
analytic_story:
    - Linux Privilege Escalation
    - Linux Persistence Techniques
    - Linux Living Off The Land
    - Scheduled Tasks
asset_type: Endpoint
mitre_attack_id:
    - T1053.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Linux Suspicious Child Process of PostgreSQL
id: 6488b83f-8e76-43c3-91ee-c90a6d9e8d62
version: 1
creation_date: '2026-07-17'
modification_date: '2026-07-17'
author: Raven Tait, Splunk
status: production
type: TTP
description: |-
    The following analytic detects PostgreSQL spawning a shell, interpreter, or network utility as a child process.
    When an attacker exploits a remote code execution vulnerability in PostgreSQL (such as via malicious COPY TO/FROM PROGRAM, CVE-2019-9193, or an insecurely configured extension), the database process itself becomes the parent of attacker-controlled commands.
    Legitimate PostgreSQL processes do not normally fork shells or download tools, making this a high-fidelity signal for post-exploitation activity.
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.parent_process_name IN (
            "postgres",
            "postmaster",
            "pg_ctl"
        )
        OR
        Processes.parent_process_path = "*/bin/postgres"
        OR
        Processes.process_current_directory="*/var/lib/postgresql/*/main*"
    )
    Processes.process_name IN (
        "awk", "bash", "curl", "dash", "env", "gawk", "id", "ifconfig",
        "ksh", "lua", "nc", "ncat", "netcat", "nmap", "openssl", "perl",
        "php", "python", "python2", "python3", "ruby", "sh", "socat",
        "tcpdump", "wget", "whoami", "zsh"
    )

    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_current_directory 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_suspicious_child_process_of_postgresql_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: |-
    Custom PostgreSQL extensions or wrapper scripts that legitimately invoke shell utilities may trigger this detection. Baseline the environment and use the filter macro to suppress known-good parent/child combinations. Recommend throttling by dest and process_name before enabling broadly.
references:
    - https://www.horizon3.ai/cve-2023-27524-insecure-default-configuration-in-apache-superset-leads-to-remote-code-execution/
    - https://www.postgresql.org/docs/current/sql-copy.html
    - https://nvd.nist.gov/vuln/detail/CVE-2019-9193
finding:
    title: Suspicious Child Process of [$parent_process_path$] identified on [$dest$] via [$process_name$] with the Command Line [$process$]
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
    - field: process
      type: process
analytic_story:
    - Linux Post-Exploitation
    - Linux Privilege Escalation
    - Linux Persistence Techniques
    - Compromised Linux Host
    - SQL Injection
asset_type: Endpoint
mitre_attack_id:
    - T1190
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '5030.5084'
title: New Linux Service Started_Enabled
description: 'Looks for new services being started or configured to start on boot.
  This could be used for persistence - Threat Actor Association: TeamTNT'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_unix` type IN("EXECVE", "proctitle")
  ((TERM(systemctl) (TERM(start) OR TERM(enable))) OR ("/etc/init.d/" TERM(start))
  OR (TERM(chkconfig) TERM(on)) OR (TERM(service) TERM(start))) | rex field=_raw "(?i)proctitle=(\")?(?<proc>.+")|
  eval process=mvappend(proc, process)| rex field=process "(?i)(enable|start|\Q/etc/init.d\E|\Q/sbin/service\E)(\s)?(\/)?(?<service>[A-Za-z0-9\-\.\_\x5c]+")
  | table _time, host, user, process, process_*, service | bin span=1s | stats values(*)
  as * by _time, host, process '
techniques:
- persistence:create or modify system process:systemd service
- privilege-escalation:create or modify system process:systemd service
technique_id:
- T1543.002
data_category:
- Process command-line parameters
- Linux audit logs
references: null

name: Okta IDP Lifecycle Modifications
id: e0be2c83-5526-4219-a14f-c3db2e763d15
version: 9
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: Anomaly
description: The following analytic identifies modifications to Okta Identity Provider (IDP) lifecycle events, including creation, activation, deactivation, and deletion of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms. Unauthorized or anomalous changes could indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could manipulate authentication processes, potentially gaining unauthorized access or disrupting identity management systems.
data_source:
    - Okta
search: |-
    `okta` eventType IN ("system.idp.lifecycle.activate","system.idp.lifecycle.create","system.idp.lifecycle.delete","system.idp.lifecycle.deactivate")
      | stats count  min(_time) as firstTime max(_time) as lastTime values(target{}.id) as target_id values(target{}.type) as target_modified
        BY src dest src_user_id
           user user_agent command
           description
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `okta_idp_lifecycle_modifications_filter`
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It's possible for legitimate administrative actions or automated processes to trigger this detection, especially if there are bulk modifications to Okta IDP lifecycle events. Review the context of the modification, such as the user making the change and the specific lifecycle event modified, to determine if it aligns with expected behavior.
references:
    - https://www.obsidiansecurity.com/blog/behind-the-breach-cross-tenant-impersonation-in-okta/
    - https://splunkbase.splunk.com/app/6553
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: A user [$user$] is attempting IDP lifecycle modification - [$description$] from IP Address - [$src$]"
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - Suspicious Okta Activity
asset_type: Okta Tenant
mitre_attack_id:
    - T1087.004
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: identity

name: Ollama Possible API Endpoint Scan Reconnaissance
id: ad3f352a-0347-48ee-86b9-670b5025a548
version: 5
creation_date: '2025-10-13'
modification_date: '2026-05-13'
author: Rod Soto
status: experimental
type: Anomaly
description: Detects API reconnaissance and endpoint scanning activity against Ollama servers by identifying sources probing multiple API endpoints within short timeframes, particularly when using HEAD requests or accessing diverse endpoint paths, which indicates systematic enumeration to map the API surface, discover hidden endpoints, or identify vulnerabilities before launching targeted attacks.
data_source:
    - Ollama Server
search: |-
    `ollama_server` "[GIN]"
      | bin _time span=5m
      | stats count as total_requests, values(dest) as dest, values(http_method) as methods, values(status) as status_codes
        BY _time, src, host
      | where total_requests > 120
      | eval severity="medium"
      | eval attack_type="API Activity Surge"
      | stats count
        BY _time, host, src,
           total_requests, dest, methods,
           status_codes, severity, attack_type
      | `ollama_possible_api_endpoint_scan_reconnaissance_filter`
how_to_implement: 'Ingest Ollama logs via Splunk TA-ollama add-on by configuring file monitoring inputs pointed to your Ollama server log directories (sourcetype: ollama:server), or enable HTTP Event Collector (HEC) for real-time API telemetry and prompt analytics (sourcetypes: ollama:api, ollama:prompts). CIM compatibility using the Web datamodel for standardized security detections.'
known_false_positives: Legitimate web application clients or mobile apps that access multiple API endpoints as part of normal functionality, monitoring and health check systems probing various endpoints for availability, load balancers performing health checks across different paths, API testing frameworks during development and QA processes, or users navigating through web interfaces that trigger multiple API calls may generate similar patterns during normal operations.
references:
    - https://github.com/rosplk/ta-ollama
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: API reconnaissance activity detected from $src$ on $host$ with $total_requests$ requests across different endpoints using methods $methods$ and receiving status codes $status_codes$, indicating systematic endpoint enumeration to map API attack surface and identify potential vulnerabilities.
analytic_story:
    - Suspicious Ollama Activities
asset_type: Web Application
mitre_attack_id:
    - T1595
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: endpoint

name: Regsvr32 Silent and Install Param Dll Loading
id: f421c250-24e7-11ec-bc43-acde48001122
version: 15
creation_date: '2021-10-04'
modification_date: '2026-06-09'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects the loading of a DLL using the regsvr32 application with the silent parameter and DLLInstall execution. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process command-line arguments and parent process details. This activity is significant as it is commonly used by RAT malware like Remcos and njRAT to load malicious DLLs on compromised machines. If confirmed malicious, this technique could allow attackers to execute arbitrary code, maintain persistence, and further compromise the system.
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

    `process_regsvr32`
    Processes.process  IN ("*/i*", "*-i*")
    Processes.process  IN ("*/s*", "*-s*")
    NOT Processes.process="*Microsoft\\TeamsMeetingAddin*"

    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)`
    | `regsvr32_silent_and_install_param_dll_loading_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: |
    Other third part application may used this parameter.
    One identified use case is Microsoft Teams. Apply the necessary filters before using this rule in production.
references:
    - https://app.any.run/tasks/dc93ee63-050c-4ff8-b07e-8277af9ab939/
    - https://attack.mitre.org/techniques/T1218/010/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting to load a DLL using the silent and dllinstall parameter.
        - field: dest
          type: system
          score: 20
          message: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting to load a DLL using the silent and dllinstall parameter.
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
analytic_story:
    - AsyncRAT
    - Hermetic Wiper
    - Living Off The Land
    - Data Destruction
    - Remcos
    - Suspicious Regsvr32 Activity
asset_type: Endpoint
mitre_attack_id:
    - T1218.010
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: WBAdmin Delete System Backups
id: cd5aed7e-5cea-11eb-ae93-0242ac130002
version: 14
creation_date: '2021-01-11'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic detects the execution of wbadmin.exe with flags that delete backup files, specifically targeting catalog or system state backups. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. This activity is significant because it is commonly used by ransomware to prevent recovery by deleting system backups. If confirmed malicious, this action could severely hinder recovery efforts, leading to prolonged downtime and potential data loss.
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=wbadmin.exe
            OR
            Processes.original_file_name=WBADMIN.EXE
        )
        Processes.process="*delete*" ( Processes.process="*catalog*" OR Processes.process="*backup*" )
      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)`
    | `wbadmin_delete_system_backups_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: Administrators may modify the boot configuration.
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1490/T1490.md
    - https://thedfirreport.com/2020/10/08/ryuks-return/
    - https://attack.mitre.org/techniques/T1490/
    - https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin
    - https://www.welivesecurity.com/2019/04/30/buhtrap-backdoor-ransomware-advertising-platform/
finding:
    title: System backups deletion on $dest$
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Ryuk Ransomware
    - Ransomware
    - Prestige Ransomware
    - Chaos Ransomware
    - Storm-2460 CLFS Zero Day Exploitation
    - Storm-0501 Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1490
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Web or Application Server Spawning a Shell
id: 8fdb41ad-091c-4d7a-af1d-9123fe94b539
version: 5
creation_date: '2021-12-13'
modification_date: '2026-05-13'
author: Michael Haag, Nasreddine Bencherchali, Splunk
status: production
type: TTP
description: |
    The following analytic detects instances where Java, or Tomcat
    processes spawn a Linux shell, which may indicate exploitation attempts, such as
    those related to CVE-2021-44228 (Log4Shell). This detection leverages Endpoint Detection
    and Response (EDR) telemetry, focusing on process names and parent-child process
    relationships. This activity is significant as it can signify a compromised Java
    application, potentially leading to unauthorized shell access. If confirmed malicious,
    attackers could execute arbitrary commands, escalate privileges, or maintain persistent
    access, posing a severe threat to the environment.
data_source:
    - Sysmon for Linux EventID 1
    - Sysmon EventID 1
search: |
    | tstats `security_content_summariesonly`
      count min(_time) as firstTime
            max(_time) as lastTime

    from datamodel=Endpoint.Processes where

    (
      Processes.parent_process_name IN ("java", "tomcat*", "httpd", "lighttpd", "apache2", "nginx", "node", "caddy")
      `linux_shells`
    )
    OR
    (
      Processes.parent_process_name IN ("httpd.exe", "nginx.exe", "php*.exe", "php-cgi.exe", "tomcat*.exe", "caddy.exe", "UMWorkerProcess.exe", "w3wp.exe", "ws_TomcatService.exe", "node.exe", "java.exe")
      `windows_shells`
    )

    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)`
    | `web_or_application_server_spawning_a_shell_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: |
    Filtering may be required on internal developer build systems or classify assets as web facing and restrict the analytic based on asset type.
references:
    - https://blog.netlab.360.com/ten-families-of-malicious-samples-are-spreading-using-the-log4j2-vulnerability-now/
    - https://gist.github.com/olafhartong/916ebc673ba066537740164f7e7e1d72
finding:
    title: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ spawning a Linux shell, potentially indicative of exploitation.
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
analytic_story:
    - BlackByte Ransomware
    - CISA AA22-257A
    - CISA AA22-264A
    - Cleo File Transfer Software
    - Data Destruction
    - Flax Typhoon
    - GhostRedirector IIS Module and Rungan Backdoor
    - HAFNIUM Group
    - Hermetic Wiper
    - Log4Shell CVE-2021-44228
    - Microsoft SharePoint Vulnerabilities
    - Microsoft WSUS CVE-2025-59287
    - PHP-CGI RCE Attack on Japanese Organizations
    - ProxyNotShell
    - ProxyShell
    - SAP NetWeaver Exploitation
    - Spring4Shell CVE-2022-22965
    - SysAid On-Prem Software CVE-2023-47246 Vulnerability
    - WS FTP Server Critical Vulnerabilities
asset_type: Endpoint
mitre_attack_id:
    - T1190
    - T1133
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Windows AD DSRM Account Changes
id: 08cb291e-ea77-48e8-a95a-0799319bf056
version: 12
creation_date: '2022-09-08'
modification_date: '2026-05-13'
author: Dean Luxton
status: production
type: TTP
description: The following analytic identifies changes to the Directory Services Restore Mode (DSRM) account behavior via registry modifications. It detects alterations in the registry path "*\\System\\CurrentControlSet\\Control\\Lsa\\DSRMAdminLogonBehavior" with specific values indicating potential misuse. This activity is significant because the DSRM account, if misconfigured, can be exploited to persist within a domain, similar to a local administrator account. If confirmed malicious, an attacker could gain persistent administrative access to a Domain Controller, leading to potential domain-wide compromise and unauthorized access to sensitive information.
data_source:
    - Sysmon EventID 13
search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_path= "*\\System\\CurrentControlSet\\Control\\Lsa\\DSRMAdminLogonBehavior" Registry.registry_value_data IN ("*1","*2") by Registry.action Registry.dest Registry.process_guid Registry.process_id Registry.registry_hive Registry.registry_path Registry.registry_key_name Registry.registry_value_data Registry.registry_value_name Registry.registry_value_type Registry.status Registry.user Registry.vendor_product | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_ad_dsrm_account_changes_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: Disaster recovery events.
references:
    - https://adsecurity.org/?p=1714
finding:
    title: DSRM Account Changes Initiated on $dest$ by $user$
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: DSRM Account Changes Initiated on $dest$ by $user$
analytic_story:
    - Sneaky Active Directory Persistence Tricks
    - Windows Registry Abuse
    - Windows Persistence Techniques
    - Scattered Lapsus$ Hunters
asset_type: Endpoint
mitre_attack_id:
    - T1098
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint