Splunk rules: 3g

name: ASL AWS Credential Access GetPasswordData
id: a79b607a-50cc-4704-bb9d-eff280cb78c2
version: 8
creation_date: '2022-08-10'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic identifiesGetPasswordData API calls in your AWS account. It leverages  CloudTrail logs from Amazon Security Lake to detect this activity by counting the distinct instance IDs accessed. This behavior is significant as it may indicate an attempt to retrieve encrypted administrator passwords for running Windows instances, which is a critical security concern. If confirmed malicious, attackers could gain unauthorized access to administrative credentials, potentially leading to full control over the affected instances and further compromise of the AWS environment.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` api.operation=GetPasswordData
      | spath input=api.request.data
      | 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 instanceId
      | 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_credential_access_getpassworddata_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: Administrator tooling or automated scripts may make these calls but it is highly unlikely to make several calls in a short period of time.
references:
    - https://attack.mitre.org/techniques/T1552/
    - https://stratus-red-team.cloud/attack-techniques/AWS/aws.credential-access.ec2-get-password-data/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: User $user$ is seen to make `GetPasswordData` API calls
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: Cisco Privileged Account Creation with Suspicious SSH Activity
id: 7f8e2b4c-9a3d-4e1f-8c5b-6d7e8f9a0b1c
version: 5
creation_date: '2026-01-12'
modification_date: '2026-05-13'
author: Nasreddine Bencherchali, Splunk
status: production
type: Correlation
description: |
    This analytic detects a correlation between privileged account creation on Cisco IOS devices and subsequent inbound SSH connections to non-standard ports or sshd_operns by correlating risk events
    This correlation identifies when both "Cisco IOS Suspicious Privileged Account Creation" and SSH-related Snort detections ("SSH Connection to sshd_operns" or "SSH Connection to Non-Standard Port") fire for the same network device.
    This behavior is highly indicative of persistence establishment following initial compromise.
data_source: []
search: |
    | tstats `security_content_summariesonly`
      min(_time) as firstTime
      max(_time) as lastTime

      sum(All_Risk.calculated_risk_score) as risk_score
      count(All_Risk.calculated_risk_score) as risk_event_count

      values(All_Risk.annotations.mitre_attack.mitre_tactic_id) as annotations.mitre_attack.mitre_tactic_id
      dc(All_Risk.annotations.mitre_attack.mitre_tactic_id) as mitre_tactic_id_count

      values(All_Risk.annotations.mitre_attack.mitre_technique_id) as annotations.mitre_attack.mitre_technique_id
      dc(All_Risk.annotations.mitre_attack.mitre_technique_id) as mitre_technique_id_count

      values(All_Risk.tag) as tag
      values(source) as source
      dc(source) as source_count

      values(contributing_events_search)

      values(All_Risk.threat_object)

      from datamodel=Risk.All_Risk where

      source IN (
        "*Cisco IOS Suspicious Privileged Account Creation*",
        "*Cisco Secure Firewall - SSH Connection to sshd_operns*",
        "*Cisco Secure Firewall - SSH Connection to Non-Standard Port*"
      )
      by All_Risk.normalized_risk_object
    | `drop_dm_object_name(All_Risk)`
    | eval has_account_creation=if(
                                    match(source, "Cisco IOS Suspicious Privileged Account Creation"),
                                    1, 0
                                  )
    | eval has_ssh_detection=if(
                                  match(source, "SSH Connection to sshd_operns")
                                  OR
                                  match(source, "SSH Connection to Non-Standard Port"),
                                  1, 0
                                )
    | where has_account_creation=1
            AND
            has_ssh_detection=1
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_privileged_account_creation_with_suspicious_ssh_activity_filter`
how_to_implement: |
    This correlation search requires that the following detections are enabled and generating risk events - "Cisco IOS Suspicious Privileged Account Creation", "Cisco Secure Firewall - SSH Connection to sshd_operns", and "Cisco Secure Firewall - SSH Connection to Non-Standard Port". These detections must be configured to generate risk on the same entity field (the network device IP). The search correlates risk events within a 24-hour time window. Ensure that both Cisco IOS logs (sourcetype "cisco:ios") and Cisco Secure Firewall Threat Defense Intrusion Event logs are being ingested and that the underlying detections are properly configured.
known_false_positives: |
    No false positives have been identified yet.
references:
    - https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a
finding:
    title: Cisco Privileged Account Creation with Suspicious SSH Activity - $risk_object$
    entity:
        field: risk_object
        type: other
        score: 0
analytic_story:
    - Cisco Secure Firewall Threat Defense Analytics
    - Salt Typhoon
asset_type: Network
mitre_attack_id:
    - T1021.004
    - T1136
    - T1078
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: network
security_domain: network

name: Cloud Provisioning Activity From Previously Unseen Region
id: 5aba1860-9617-4af9-b19d-aecac16fe4f2
version: 9
creation_date: '2020-10-26'
modification_date: '2026-05-13'
author: Rico Valdez, Bhavin Patel, Splunk
status: production
type: Anomaly
description: The following analytic detects cloud provisioning activities originating from previously unseen regions. It leverages cloud infrastructure logs to identify events where resources are started or created, and cross-references these with a baseline of known regions. This activity is significant as it may indicate unauthorized access or misuse of cloud resources from unfamiliar locations. If confirmed malicious, this could lead to unauthorized resource creation, potential data exfiltration, or further compromise of cloud infrastructure.
data_source:
    - AWS CloudTrail
search: |-
    | tstats earliest(_time) as firstTime, latest(_time) as lastTime FROM datamodel=Change
      WHERE (
            All_Changes.action=started
            OR
            All_Changes.action=created
        )
        All_Changes.status=success
      BY All_Changes.src, All_Changes.user, All_Changes.object,
         All_Changes.command
    | `drop_dm_object_name("All_Changes")`
    | iplocation src
    | where isnotnull(Region)
    | lookup previously_seen_cloud_provisioning_activity_sources Region as Region OUTPUT firstTimeSeen, enough_data
    | eventstats max(enough_data) as enough_data
    | where enough_data=1
    | eval firstTimeSeenRegion=min(firstTimeSeen)
    | where isnull(firstTimeSeenRegion) OR firstTimeSeenRegion > relative_time(now(), `previously_unseen_cloud_provisioning_activity_window`)
    | `security_content_ctime(firstTime)`
    | table firstTime, src, Region, user, object, command
    | `cloud_provisioning_activity_from_previously_unseen_region_filter`
how_to_implement: You must be ingesting your cloud infrastructure logs from your cloud provider.  You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_region_filter` macro.
known_false_positives: "This is a strictly behavioral search, so we define \"false positive\" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no \"false positives\" in a traditional sense, there is definitely lots of noise.\nThis search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you."
references: []
intermediate_findings:
    entities:
        - field: object
          type: system
          score: 20
          message: User $user$ is starting or creating an instance $object$ for the first time in region $Region$ from IP address $src$
        - field: user
          type: user
          score: 20
          message: User $user$ is starting or creating an instance $object$ for the first time in region $Region$ from IP address $src$
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - Suspicious Cloud Provisioning Activities
asset_type: AWS Instance
mitre_attack_id:
    - T1078
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat
baselines:
    - Previously Seen Cloud Provisioning Activity Sources - Initial
    - Previously Seen Cloud Provisioning Activity Sources - Update

id: '1036.1048'
title: Command-Line Interface Execution
description: 'Detects when a Command-Line Interface executes on a host. -- Threat
  Actor Association: APT29/Nobelium/Cozy Bear, APT31, APT35/Phosphorus/Magic Hound,
  APT36, APT37, APT41, Carbanak, FamousSparrow, FIN6, FIN7, FIN8, Kimsuky, MalKamak,
  MuddyWater, Night Spider, TA,505, TA551, Prophet Spider, Wizard Spider, WIRTE --
  Software Association: Astaroth, BadHatch, Bazar, Conti, Cring, Emotet, GhostShell,
  Hafnium, Hancitor, Harvester, Hive, IcedID, MINEBRIDGE, MirrorBlast, MysterySnail,
  Nefilim, PowerShortShell, Prometheus / Spook, QakBot, Ransom Cartel, RATDispenser,
  Remcos, Ryuk, Sodinokibi/REvil, SquirrelWaffle, Trickbot, XingLocker, Zloader, Zumkong'
logic_format: Splunk
logic: ' `get_endpoint_data` `get_endpoint_data_sysmon` EventCode=1 AND ("powershell.exe"
  OR "cmd.exe") | table _time, host, user dest, direction, client, event_id, eventtype,
  hashes, host, index, parent_process, parent_process_id, parent_process_name, parent_process_path,
  process, process_current_directory, process_id, process_name, process_path, signature_id,
  source, sourcetype, tag, user, user_id | bin span=60s | stats values(*) as * by
  _time, host | where match(process_name,"(?i)powershell\.exe") OR match(process_name,"(i?)cmd\.exe") '
techniques:
- execution:command and scripting interpreter:powershell
- execution:command and scripting interpreter:windows command shell
technique_id:
- T1059.001
- T1059.003
data_category:
- Windows Sysmon
references:
- https://securityintelligence.com/an-increase-in-powershell-attacks-observations-from-ibm-x-force-iris/
- https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/tracking-detecting-and-thwarting-powershell-based-malware-and-attacks

name: Detect Regasm Spawning a Process
id: 72170ec5-f7d2-42f5-aefb-2b8be6aad15f
version: 17
creation_date: '2021-02-12'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic detects regasm.exe spawning a child process. This behavior is identified using data from Endpoint Detection and Response (EDR) agents, focusing on process creation events where regasm.exe is the parent process. This activity is significant because regasm.exe spawning a process is rare and can indicate an attempt to bypass application control mechanisms. If confirmed malicious, this could allow an attacker to execute arbitrary code, potentially leading to privilege escalation or persistent access within the environment. Immediate investigation is recommended to determine the legitimacy of the spawned process and any associated activities.
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.parent_process_name=regasm.exe NOT (Processes.process_name IN ("conhost.exe"))
      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_regasm_spawning_a_process_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: Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
references:
    - https://attack.mitre.org/techniques/T1218/009/
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1218.009/T1218.009.md
    - https://lolbas-project.github.io/lolbas/Binaries/Regsvcs/
    - https://lolbas-project.github.io/lolbas/Binaries/Regasm/
finding:
    title: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ spawning a child process, typically not normal behavior for $parent_process_name$.
    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$ spawning a child process, typically not normal behavior for $parent_process_name$.
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
analytic_story:
    - Suspicious Regsvcs Regasm Activity
    - Living Off The Land
    - Handala Wiper
    - Compromised Windows Host
    - DarkGate Malware
    - Snake Keylogger
    - Void Manticore
asset_type: Endpoint
mitre_attack_id:
    - T1218.009
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Linux Change File Owner To Root
id: c1400ea2-6257-11ec-ad49-acde48001122
version: 11
creation_date: '2022-01-05'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects the use of the 'chown' command to change a file owner to 'root' on a Linux system. It leverages Endpoint Detection and Response (EDR) telemetry, specifically monitoring command-line executions and process details. This activity is significant as it may indicate an attempt to escalate privileges by adversaries, malware, or red teamers. If confirmed malicious, this action could allow an attacker to gain root-level access, leading to full control over the compromised host and potential persistence within the environment.
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 = chown
            OR
            Processes.process = "*chown *"
        )
        AND Processes.process = "* root *"
      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_change_file_owner_to_root_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://unix.stackexchange.com/questions/101073/how-to-change-permissions-from-root-user-to-all-users
    - https://askubuntu.com/questions/617850/changing-from-user-to-superuser
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A commandline $process$ that may change ownership to root on $dest$
analytic_story:
    - Linux Privilege Escalation
    - Linux Persistence Techniques
    - Linux Living Off The Land
asset_type: Endpoint
mitre_attack_id:
    - T1222.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Linux Suspicious Staging of Alternate System Files
id: 250fd1b5-e62a-4515-baff-3010b52b4c12
version: 1
creation_date: '2026-07-08'
modification_date: '2026-07-08'
author: Raven Tait, Splunk
status: production
type: Anomaly
description: |-
    The following analytic detects the creation of sensitive system files such as nsswitch.conf, passwd, shadow, sudoers, and NSS shared libraries outside of their canonical /etc or /var/lib/docker paths.
    This technique is associated with CVE-2025-32463 (chwoot), where an attacker stages a fake root directory containing spoofed system configuration files and NSS libraries to manipulate how privileged processes such as sudo resolve name services, enabling local privilege escalation by hijacking library loading without modifying the real /etc directory.
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/group",
        "*/etc/nsswitch.conf",
        "*/etc/pam.conf",
        "*/etc/passwd",
        "*/etc/shadow",
        "*/etc/sudo.conf",
        "*/etc/sudoers",
        "*/libnss_*"
    )
    NOT Filesystem.file_path IN (
        "/etc/*",
        "/var/lib/docker/*"
    )

    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.process_guid
       Filesystem.process_id Filesystem.user Filesystem.vendor_product

    | `drop_dm_object_name(Filesystem)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `linux_suspicious_staging_of_alternate_system_files_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 file creation events including the file path and user context. 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 `Filesystem` 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: |-
    Developers or system administrators may stage alternate system files for legitimate testing or containerized environments. Filter based on known development or testing systems.
references:
    - https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-linux-sudo-flaw-exploited-in-attacks/
    - https://github.com/pr0v3rbs/CVE-2025-32463_chwoot
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: Suspicious Staging of Alternate System File - [$file_name$] observed on [$dest$].
threat_objects:
    - field: file_name
      type: file_name
analytic_story:
    - Linux Privilege Escalation
    - Linux Post-Exploitation
    - Linux Persistence Techniques
asset_type: Endpoint
mitre_attack_id:
    - T1036
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: MCP Prompt Injection
id: 49779398-b738-4d64-bb3f-ead6eb97fe53
version: 5
creation_date: '2026-02-17'
modification_date: '2026-05-13'
author: Rod Soto
status: production
type: TTP
description: This detection identifies potential prompt injection attempts within MCP (Model Context Protocol) communications by monitoring for known malicious phrases and patterns commonly used to manipulate AI assistants. Prompt injection is a critical vulnerability where adversaries embed hidden instructions in content processed by AI tools, attempting to override system prompts, bypass security controls, or hijack the AI's behavior. The search monitors JSON-RPC traffic for phrases such as "IGNORE PREVIOUS INSTRUCTIONS," "SYSTEM PROMPT OVERRIDE," and "ignore all security" which indicate attempts to subvert the AI's intended behavior and potentially execute unauthorized actions through the MCP toolchain.
data_source:
    - MCP Server
search: |
    `mcp_server` direction=inbound ( "IGNORE PREVIOUS INSTRUCTIONS" OR "AI_INSTRUCTION" OR "SYSTEM PROMPT OVERRIDE" OR "[SYSTEM]:" OR "ignore all security" OR "New directive" OR "ignore security policies" )
    | eval dest=host
    | eval injection_payload=coalesce('params.content_preview', 'params.result_preview')
    | eval target_path='params.path'
    | eval sql_query='params.query'
    | stats count min(_time) as firstTime max(_time) as lastTime values(method) as method values(target_path) as target_path values(sql_query) as sql_query values(injection_payload) as injection_payload by dest, source
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | table dest firstTime lastTime count source method target_path sql_query injection_payload
    | `mcp_prompt_injection_filter`
how_to_implement: This detection requires the MCP Technology Add-on (TA) for Splunk configured to ingest JSON-RPC formatted logs from MCP-enabled AI assistants and agents into the appropiate index with sourcetype mcp:jsonrpc. Ensure the TA parses multivalue fields including params.content_preview, params.result_preview, params.path, and params.query to capture tool inputs and outputs where injection payloads may appear. The macro mcp_prompt_injection_filter should be created to allow environment-specific tuning and whitelisting of known benign patterns.
known_false_positives: Known false positives include security research and testing activities where red teams or developers intentionally test prompt injection defenses, as well as educational content where documentation, tutorials, or training materials discussing prompt injection techniques are legitimately processed by the AI assistant. Additionally, security tool development involving code reviews or development of prompt injection detection mechanisms may contain these patterns, and quoted references in conversations where users discuss or report prompt injection attempts they encountered elsewhere could trigger this detection.
references:
    - https://splunkbase.splunk.com/app/8377
    - https://www.tenable.com/blog/mcp-prompt-injection-not-just-for-evil
    - https://www.splunk.com/en_us/blog/security/securing-ai-agents-model-context-protocol.html
finding:
    title: 'A prompt injection attempt was detected on $dest$ via MCP server. An attacker attempted to override AI instructions using phrases like IGNORE PREVIOUS INSTRUCTIONS or SYSTEM PROMPT OVERRIDE. This technique (AML.T0051) attempts to manipulate the LLM into bypassing security controls or executing unauthorized actions. Payload detected: $injection_payload$'
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Suspicious MCP Activities
asset_type: Web Application
mitre_attack_id:
    - T1059
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: endpoint

name: O365 Safe Links Detection
id: 711d9e8c-2cb0-45cf-8813-5f191ecb9b26
version: 11
creation_date: '2024-04-07'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic detects when any Microsoft Safe Links alerting is triggered. This behavior may indicate when user has interacted with a phishing or otherwise malicious link within the Microsoft Office ecosystem.
data_source:
    - Office 365 Universal Audit Log
search: |-
    `o365_management_activity` Name="*a potentially malicious URL*" Operation=AlertEntityGenerated
      | fromjson Data
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime values(ObjectId) as url values(od) as desc
        BY AlertId, trc, Name,
           ot, dest, vendor_account,
           vendor_product, src
      | rename Name as signature, AlertId as signature_id, trc as user, ot as action
      | eval action = CASE(action == "Allowed", "allowed", action=="BlockPageOverride", "allowed", true(),"blocked")
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `o365_safe_links_detection_filter`
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. The Safe Links capability must be configured and is typically only available to E3/E5 level customers.
known_false_positives: Based on Safe Links policies, may vary.
references:
    - https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/safe-links-about?view=o365-worldwide
    - https://attack.mitre.org/techniques/T1566/
finding:
    title: $user$ triggered a Microsoft Safe Links detection.
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Office 365 Account Takeover
    - Spearphishing Attachments
asset_type: O365 Tenant
mitre_attack_id:
    - T1566.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: O365 SharePoint Malware Detection
id: 583c5de3-7709-44cb-abfc-0e828d301b59
version: 12
creation_date: '2024-04-07'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic identifies when a malicious file is detected within the SharePoint Online ecosystem. Attackers may stage and execute malicious files from within the Microsoft Office 365 ecosystem. 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` Operation=FileMalwareDetected
      | rename UserId as user, Id as signature_id
      | stats values(Workload) as category, values(SourceFileName) as file_name values(ObjectId) as file_path, values(VirusInfo) as signature, count, min(_time) as firstTime, max(_time) as lastTime
        BY signature_id, user, dest,
           src, vendor_account, vendor_product
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `o365_sharepoint_malware_detection_filter`
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
known_false_positives: No false positives have been identified at this time.
references:
    - https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-malware-protection-for-spo-odfb-teams-about?view=o365-worldwide
finding:
    title: SharePoint detected a potentially malicious file $file_name$
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: file_name
      type: file_name
analytic_story:
    - Azure Active Directory Persistence
    - Office 365 Account Takeover
    - Ransomware Cloud
asset_type: O365 Tenant
mitre_attack_id:
    - T1204.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: Okta Phishing Detection with FastPass Origin Check
id: f4ca0057-cbf3-44f8-82ea-4e330ee901d3
version: 9
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Okta, Inc, Michael Haag, Splunk
status: experimental
type: TTP
description: The following analytic identifies failed user authentication attempts in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically looking for events where multi-factor authentication (MFA) fails with the reason "FastPass declined phishing attempt." This activity is significant as it indicates that attackers are targeting users with real-time phishing proxies, attempting to capture credentials. If confirmed malicious, this could lead to unauthorized access to user accounts, potentially compromising sensitive information and furthering lateral movement within the organization.
data_source:
    - Okta
search: |-
    `okta` eventType="user.authentication.auth_via_mfa" AND result="FAILURE" AND outcome.reason="FastPass declined phishing attempt"
      | stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage)
        BY user eventType client.userAgent.rawUserAgent
           client.userAgent.browser outcome.reason
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `okta_phishing_detection_with_fastpass_origin_check_filter`
how_to_implement: This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment.
known_false_positives: Fidelity of this is high as Okta is specifying malicious infrastructure. Filter and modify as needed.
references:
    - https://sec.okta.com/fastpassphishingdetection
finding:
    title: Okta FastPass has prevented $user$ from authenticating to a malicious site.
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Okta Account Takeover
asset_type: Infrastructure
mitre_attack_id:
    - T1078.001
    - T1556
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: access

name: Ollama Suspicious Prompt Injection Jailbreak
id: aac5df6f-9151-4da6-bdb2-5691aa6e376f
version: 4
creation_date: '2025-10-13'
modification_date: '2026-05-13'
author: Rod Soto
status: experimental
type: Anomaly
description: Detects potential prompt injection or jailbreak attempts against Ollama API endpoints by identifying requests with abnormally long response times. Attackers often craft complex, layered prompts designed to bypass AI safety controls, which typically result in extended processing times as the model attempts to parse and respond to these malicious inputs. This detection monitors /api/generate and /api/chat endpoints for requests exceeding 30 seconds, which may indicate sophisticated jailbreak techniques, multi-stage prompt injections, or attempts to extract sensitive information from the model.
data_source:
    - Ollama Server
search: '`ollama_server` "GIN" ("*/api/generate*" OR "*/v1/chat/completions*") | rex field=_raw "\|\s+(?<status_code>\d+)\s+\|\s+(?<response_time>[\d\.]+[a-z]+)\s+\|\s+(?<src_ip>[\:\da-f\.]+)\s+\|\s+(?<http_method>\w+)\s+\"(?<uri_path>[^\"]+)\"" | rex field=response_time "^(?:(?<minutes>\d+)m)?(?<seconds>[\d\.]+)s$" | eval response_time_seconds=if(isnotnull(minutes), tonumber(minutes)*60+tonumber(seconds), tonumber(seconds)) | eval src=src_ip | where response_time_seconds > 30 | bin _time span=10m | stats count as long_request_count, avg(response_time_seconds) as avg_response_time, max(response_time_seconds) as max_response_time, values(uri_path) as uri_path, values(status_code) as status_codes by _time, src, host | where long_request_count > 170 | eval avg_response_time=round(avg_response_time, 2) | eval max_response_time=round(max_response_time, 2) | eval severity=case( long_request_count > 50 OR max_response_time > 55, "critical", long_request_count > 20 OR max_response_time > 40, "high", 1=1, "medium" ) | eval attack_type="Potential Prompt Injection / Jailbreak" | table _time, host, src, uri_path, long_request_count, avg_response_time, max_response_time, status_codes, severity, attack_type | `ollama_suspicious_prompt_injection_jailbreak_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 complex queries requiring extensive model reasoning, large context windows processing substantial amounts of text, batch processing operations, or resource-constrained systems experiencing performance degradation may trigger this detection during normal operations.
references:
    - https://github.com/rosplk/ta-ollama
    - https://github.com/OWASP/www-project-ai-testing-guide
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: Potential prompt injection or jailbreak attempt detected from $src$ with $long_request_count$ requests averaging $avg_response_time$ seconds, indicating possible attempts to bypass AI safety controls or extract sensitive information from the Ollama model.
analytic_story:
    - Suspicious Ollama Activities
asset_type: Web Application
mitre_attack_id:
    - T1190
    - T1059
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: endpoint

name: Ping Sleep Batch Command
id: ce058d6c-79f2-11ec-b476-acde48001122
version: 17
creation_date: '2022-01-20'
modification_date: '2026-08-11'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: |-
    The following analytic identifies the use of ping commands as a delay or sleep mechanism within batch-style command execution.
    It leverages process creation telemetry from Endpoint Detection and Response (EDR) agents and examines process and parent process command-line fields for ping commands that specify a count and are chained with additional commands using command separators or redirection operators.
    While execution of the command may generate individual process creation events, such as a separate ping.exe process, this analytic specifically focuses on the original command string passed to a command interpreter, such as cmd.exe /c, that combines the ping-based delay with subsequent command execution.
    Adversaries may use ping as an alternative to explicit sleep or timeout commands to introduce execution delays, potentially evading automated analysis, sandboxing, or behavior-based detection.
    Because ping is commonly used for legitimate network troubleshooting, findings should be reviewed in the context of the complete command line, parent process, user, and commands executed before or after the delay.
data_source:
    - Sysmon EventID 1
    - CrowdStrike ProcessRollup2
search: |-
    | tstats `security_content_summariesonly`
      count min(_time) as firstTime
            max(_time) as lastTime

    FROM datamodel=Endpoint.Processes WHERE
    (
        Processes.parent_process= "*ping*"
        Processes.parent_process IN (
            "*-n*",
            "*/n*"
        )
        Processes.parent_process IN (
            "*& *",
            "*&*",
            "*&C:*",
            "*>*",
            "*>*",
            "*||*"
        )
    )
    OR
    (
        (
            Processes.process_name= "ping.exe"
            OR
            Processes.original_file_name= "ping.exe"
        )
        Processes.process IN (
            "*-n*",
            "*/n*"
        )
        Processes.process IN (
            "*& *",
            "*&*",
            "*&C:*",
            "*>*",
            "*>*",
            "*||*"
        )
    )

    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)`
    | `ping_sleep_batch_command_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, network operators, scripts, and software installers may legitimately use ping commands as a simple delay mechanism between commands or operations.
    Review the full command line, parent process, user context, and surrounding activity to determine whether the execution is expected.
    Update the filter macro to exclude known legitimate command patterns or processes in your environment.
references:
    - https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Potential ping-based execution delay detected on [$dest$] by [$user$] via [$process$]
        - field: dest
          type: system
          score: 20
          message: Potential ping-based execution delay detected on [$dest$] by [$user$] via [$process$]
threat_objects:
    - field: process
      type: process
    - field: parent_process
      type: parent_process
analytic_story:
    - Warzone RAT
    - Quasar RAT
    - Data Destruction
    - Meduza Stealer
    - WhisperGate
    - BlackByte Ransomware
    - Void Manticore
    - Gh0st RAT
asset_type: Endpoint
mitre_attack_id:
    - T1497.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '40834.75130'
title: Potential CVE-2024-49113 - LDAPNightmare
description: SafeBreach Labs revealed a PoC for CVE-2024-49113, codenamed LDAPNightmare.
  The PoC is designed to crash any unpatched Windows Server with no prerequisites
  except that the DNS server of the victim domain controller has internet connectivity.
  This use case detects potential Windows LDAP Denial of Service Vulnerability events
  involving lsass.exe and the WLDAP32.dll module in application errors. Windows Application
  event 1000 is required for detection.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=1000) OR
  "<EventID>1000<") "lsass.exe" "WLDAP32.dll" | table _time, host, user user, process,
  process_*, parent_* | bin span=1s | stats values(*) as * by _time, host '
techniques:
- impact:endpoint denial of service
technique_id: 
- T1499
data_category:
- Windows event logs
references:
- https://github.com/SafeBreach-Labs/CVE-2024-49112?tab=readme-ov-file
- https://www.safebreach.com/blog/ldapnightmare-safebreach-labs-publishes-first-proof-of-concept-exploit-for-cve-2024-49112
- https://gist.github.com/travisbgreen/82b68bac499edbe0b17dcbfa0c5c71b7
- https://github.com/SigmaHQ/sigma/pull/5155/files

name: Potential password in username
id: 5ced34b4-ab32-4bb0-8f22-3b8f186f0a38
version: 8
creation_date: '2022-05-27'
modification_date: '2026-05-13'
author: Mikael Bjerkeland, Splunk
status: production
type: Hunting
description: The following analytic identifies instances where users may have mistakenly entered their passwords in the username field during authentication attempts. It detects this by analyzing failed authentication events with usernames longer than 7 characters and high Shannon entropy, followed by a successful authentication from the same source to the same destination. This activity is significant as it can indicate potential security risks, such as password exposure. If confirmed malicious, attackers could exploit this to gain unauthorized access, leading to potential data breaches or further compromise of the system.
data_source:
    - Linux Secure
search: |-
    | tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) AS endtime latest(sourcetype) AS sourcetype values(Authentication.src) AS src values(Authentication.dest) AS dest count FROM datamodel=Authentication
      WHERE nodename=Authentication.Failed_Authentication
      BY "Authentication.user"
    | `drop_dm_object_name(Authentication)`
    | lookup ut_shannon_lookup word AS user
    | where ut_shannon>3 AND len(user)>=8 AND mvcount(src) == 1
    | sort count, - ut_shannon
    | eval incorrect_cred=user
    | eval endtime=endtime+1000
    | map maxsearches=70 search="
    | tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) AS endtime latest(sourcetype) AS sourcetype values(Authentication.src) AS src values(Authentication.dest) AS dest count FROM datamodel=Authentication
      WHERE nodename=Authentication.Successful_Authentication Authentication.src=\"$src$\" Authentication.dest=\"$dest$\" sourcetype IN (\"$sourcetype$\") earliest=\"$starttime$\" latest=\"$endtime$\" BY \"Authentication.user\"
    | `drop_dm_object_name(\"Authentication\")`
    | `potential_password_in_username_false_positive_reduction`
    | eval incorrect_cred=\"$incorrect_cred$\"
    | eval ut_shannon=\"$ut_shannon$\"
    | sort count"
    | where user!=incorrect_cred
    | outlier action=RM count
    | `potential_password_in_username_filter`
how_to_implement: To successfully implement this search, you need to have relevant authentication logs mapped to the Authentication data model. You also need to have the Splunk TA URL Toolbox (https://splunkbase.splunk.com/app/2734/) installed. The detection must run with a time interval shorter than endtime+1000.
known_false_positives: Valid usernames with high entropy or source/destination system pairs with multiple authenticating users will make it difficult to identify the real user authenticating.
references:
    - https://medium.com/@markmotig/search-for-passwords-accidentally-typed-into-the-username-field-975f1a389928
analytic_story:
    - Credential Dumping
    - Insider Threat
asset_type: Endpoint
mitre_attack_id:
    - T1078.003
    - T1552.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: access

id: '39125.70661'
title: PowerShell Hidden Window
description: 'Threat actors may attempt to conceal their activity involving PowerShell
  windows by setting the WindowStyle parameter to hidden. While legitimate administrative
  tasks may use hidden windows to perform maintainence tasks in the background, this
  technique can be used by threat actors to evade user suspicion and reduce the likelihood
  of detection. This use case detects PowerShell executions involving hidden window
  commands. PowerShell logging is recommended for detection; process creation logs
  will only detect this activity if the command is executed in a manner that creates
  a new process, such as powershell -c. Atomic Test T1564.003 - Test #1'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_powershell` (TERM(EventCode=4104) OR
  "<EventID>4104<" OR TERM(EventCode=4103) OR "<EventID>4103<") ("-WindowStyle" OR
  "-w") "hidden" | regex process="(?i)-w(indowStyle)?\s+hidden" | table _time, host,
  user, process, parent_process_name | bin span=1s | stats values(*) as * by _time,
  host '
techniques:
- defense-evasion:hide artifacts:hidden window
- execution:command and scripting interpreter
- defense-evasion:hide artifacts
technique_id:
- T1564.003
- T1059
- T1564
data_category:
- PowerShell logs
references:
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1564.003/T1564.003.md#atomic-test-1---hidden-window
- https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/

id: '1015.1018'
title: 'PowerShell: SMBExec Script'
description: 'This PowerShell script (SMBExec.ps1) performs SMBExec style command
  execution with NTLMv2 pass the hash authentication. Invoke-SMBExec supports SMB1
  and SMB2 with and without SMB signing. Threat Actor Association: FIN12'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_powershell` EventCode=4103 AND ("[Char][System.Convert]::ToInt16($_,16)"
  OR "System.Net.Sockets.TCPClient" OR "System.Security.Cryptography.HMACMD5" OR "successfully
  authenticated on" OR "failed to authenticate on" OR "Invoke-SMBExec.ps1") | table
  _time, host, user dvc, dvc_nt_host, event_id, eventtype, host, index, parameters,
  process, process_name, process_path, shell, signature_id, source, sourcetype, tag,
  user, user_id | transaction dvc maxspan=1m| fields - _raw closed_txn duration eventcount
  field_match_sum linecount | stats values(*) as * by dvc _time | where like(process,"%Invoke-SMBExec%")
  OR(like(process,"%[Char][System.Convert]::ToInt16($_,16)%") ANDlike(process,"%System.Net.Sockets.TCPClient%")
  ANDlike(process,"%System.Security.Cryptography.HMACMD5%") AND(like(process,"%successfully
  authenticated on%") OR like(process,"%failed to authenticate on%"))) '
techniques:
- execution:command and scripting interpreter:powershell
- defense-evasion:indirect command execution
- execution:system services:service execution
- lateral-movement:remote services:smb/windows admin shares
- lateral-movement:exploitation of remote services
technique_id:
- T1059.001
- T1202
- T1021.002
- T1569.002
- T1210
data_category:
- PowerShell logs
- Process command-line parameters
references:
- https://github.com/EmpireProject/Empire/blob/master/data/module_source/lateral_movement/Invoke-SMBExec.ps1

name: Remote System Discovery with Adsisearcher
id: 70803451-0047-4e12-9d63-77fa7eb8649c
version: 12
creation_date: '2021-09-01'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects the use of the `[Adsisearcher]` type accelerator in PowerShell scripts to query Active Directory for domain computers. It leverages PowerShell Script Block Logging (EventCode=4104) to identify specific script blocks containing `adsisearcher` and `objectcategory=computer` with methods like `findAll()` or `findOne()`. This activity is significant as it may indicate an attempt by adversaries or Red Teams to perform Active Directory discovery and gain situational awareness. If confirmed malicious, this could lead to further reconnaissance and potential lateral movement within the network.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell` EventCode=4104 ScriptBlockText = "*adsisearcher*" AND ScriptBlockText = "*objectcategory=computer*" AND ScriptBlockText IN ("*findAll()*","*findOne()*")
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY dest signature signature_id
           user_id vendor_product EventID
           Guid Opcode Name
           Path ProcessID ScriptBlockId
           ScriptBlockText
      | `security_content_ctime(firstTime)`
      | `remote_system_discovery_with_adsisearcher_filter`
how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://help.splunk.com/en/security-offerings/splunk-user-behavior-analytics/get-data-in/5.4.1/add-other-data-to-splunk-uba/configure-powershell-logging-to-see-powershell-anomalies-in-splunk-uba.
known_false_positives: Administrators or power users may use Adsisearcher for troubleshooting.
references:
    - https://attack.mitre.org/techniques/T1018/
    - https://devblogs.microsoft.com/scripting/use-the-powershell-adsisearcher-type-accelerator-to-search-active-directory/
finding:
    title: Remote system discovery enumeration with adsisearcher on $dest$ by $user_id$
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Active Directory Discovery
asset_type: Endpoint
mitre_attack_id:
    - T1018
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Schtasks used for forcing a reboot
id: 1297fb80-f42a-4b4a-9c8a-88c066437cf6
version: 15
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: TTP
description: The following analytic detects the use of 'schtasks.exe' to schedule forced system reboots using the 'shutdown' and '/create' flags. It leverages endpoint process data to identify instances where these specific command-line arguments are used. This activity is significant because it may indicate an adversary attempting to disrupt operations or force a reboot to execute further malicious actions. If confirmed malicious, this could lead to system downtime, potential data loss, and provide an attacker with an opportunity to execute additional payloads or evade detection.
data_source:
    - Sysmon EventID 1
    - Windows Event Log Security 4688
    - CrowdStrike ProcessRollup2
search: |-
    | tstats `security_content_summariesonly` values(Processes.process) as process min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes
      WHERE Processes.process_name=schtasks.exe Processes.process="*shutdown*" Processes.process="*/create *"
      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)`
    | `schtasks_used_for_forcing_a_reboot_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: This analytic may also capture legitimate administrative activities such as system updates or maintenance tasks, which can be classified as false positives. Filter as needed.
references: []
finding:
    title: A schedule task process $process_name$ with force reboot commandline $process$ in host $dest$
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: A schedule task process $process_name$ with force reboot commandline $process$ in host $dest$
analytic_story:
    - Windows Persistence Techniques
    - Ransomware
    - Scheduled Tasks
asset_type: Endpoint
mitre_attack_id:
    - T1053.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint