Detection rules › Splunk

Splunk rules: 3h

.msc Executed from Unusual Location (Sysmon)

#
Group by
_time, host
Source
github.com/anvilogic-forge/armory

Threat actors may abuse mmc.exe to proxy execution of malicious .msc files. Microsoft Management Console (MMC) is a binary that may be signed by Microsoft and is used in several ways in either its GUI or in a command prompt. MMC can be used to create, open, and save custom consoles that contain administrative tools created by Microsoft, called snap-ins. These snap-ins may be used to manage Windows systems locally or remotely. MMC can also be used to open Microsoft created .msc files to manage system configuration. This use case detects mmc.exe executions referencing .msc files outside of C:\Windows\system32 or C:\Windows\SysWOW64.

MITRE ATT&CK Coverage

References

Telemetry Coverage

ProviderRecord / event type
SysmonEvent ID 1: Process creation

Rule Body

id: '32363.57558'
title: .msc Executed from Unusual Location
description: 'Threat actors may abuse mmc.exe to proxy execution of malicious .msc
  files. Microsoft Management Console (MMC) is a binary that may be signed by Microsoft
  and is used in several ways in either its GUI or in a command prompt. MMC can be
  used to create, open, and save custom consoles that contain administrative tools
  created by Microsoft, called snap-ins. These snap-ins may be used to manage Windows
  systems locally or remotely. MMC can also be used to open Microsoft created .msc
  files to manage system configuration. This use case detects mmc.exe executions referencing
  .msc files outside of C:\Windows\system32 or C:\Windows\SysWOW64. '
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("mmc.exe" OR "Microsoft Management Console") ".msc" | regex process="(?i)\.msc"|
  regex process!="(?i)C:\x5cWindows\x5c(system32|syswow64)\x5c\w+\.msc" | table _time,
  host, user, process | bin span=1s | stats values(*) as * by _time, host '
techniques:
- defense-evasion:system binary proxy execution:mmc
technique_id:
- T1218.014
data_category:
- Windows Sysmon
references:
- https://www.itechtics.com/enable-gpedit-windows-10-home/

Stages and Predicates

Stage 1: search

`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<") ("mmc.exe" OR "Microsoft Management Console") ".msc"

Stage 2: regex

| regex process="(?i)\.msc"

Stage 3: regex

| regex process!="(?i)C:\x5cWindows\x5c(system32|syswow64)\x5c\w+\.msc"

Stage 4: table

| table _time, host, user, process

Stage 5: bucket

| bin span=1s

Stage 6: stats

| stats values(*) as * by _time, host

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 1 corpus 226 (splunk 226)
field:"EventID" kind:eq value:"1"
processregex_match
  • (?i).msc corpus 2 (splunk 2)
field:"CommandLine" kind:regex_match value:"(?i).msc"

Exclusions

The rule actively suppresses these predicates.

FieldKindExcluded valuesSearch
processregex_match(?i)C:\x5cWindows\x5c(system32|syswow64)\x5c\w+.mscexcludes:process field:"process" value:"(?i)C:\x5cWindows\x5c(system32|syswow64)\x5c\w+.msc"

Search Terms

These SPL tokens match against raw event text.

StageTerm
1"<EventID>1<"
1"mmc.exe"
1"Microsoft Management Console"
1".msc"

Abuse EQNEDT32.EXE (Windows Event Log)

#
Group by
_time, host
Source
github.com/anvilogic-forge/armory

Detects potential malicious Microsoft Office payload (CVE-2017-11882 or CVE-2018-0798) on host. Equation Editor

MITRE ATT&CK Coverage

References

Telemetry Coverage

Rule Body

id: '1074.1113'
title: Abuse EQNEDT32.EXE
description: 'Detects potential malicious Microsoft Office payload (CVE-2017-11882
  or CVE-2018-0798) on host. Equation Editor. -- Threat Actor Association: Bitter
  APT, Lotus Blossom, SideWinder, TA428, Tonto Team - Software Association: Soul'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR
  "<EventID>4688<") "EQNEDT32.EXE"| table _time, host, user _time, host, session_id,
  process, signature_id, parent_process_name, process_name, user| bin span=300s |
  stats values(*) as * by _time, host | where match(parent_process_name, "(?i)EQNEDT32.EXE")
  | table _time, host, user _time, host, session_id, process, signature_id, parent_process_name,
  user `hec_collect`'
techniques:
- execution:exploitation for client execution
technique_id: 
- T1203
data_category:
- Windows event logs
references:
- https://www.fireeye.com/blog/threat-research/2017/12/targeted-attack-in-middle-east-by-apt34.html

Stages and Predicates

Stage 1: search

`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR "<EventID>4688<") "EQNEDT32.EXE"

Stage 2: table

| table _time, host, user _time, host, session_id, process, signature_id, parent_process_name,
    process_name, user

Stage 3: bucket

| bin span=300s

Stage 4: stats

| stats values(*) as * by _time, host

Stage 5: where

| where match(parent_process_name, "(?i)EQNEDT32.EXE")

Stage 6: table

| table _time, host, user _time, host, session_id, process, signature_id, parent_process_name, user
    `hec_collect`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 4688 corpus 284 (splunk 283, elastic 1)
field:"EventID" kind:eq value:"4688"
parent_process_nameregex_match
  • (?i)EQNEDT32.EXE corpus 2 (splunk 2)
field:"parent_process_name" kind:regex_match value:"(?i)EQNEDT32.EXE"

Search Terms

These SPL tokens match against raw event text.

StageTerm
1"<EventID>4688<"
1"EQNEDT32.EXE"

Add DefaultUser And Password In Registry

#
Status
production
Severity
low
Group by
TargetObject, computer_name, details, event_type, process_guid, process_id, registry_hive, registry_path, registry_status, registry_value_name, registry_value_type, user, vendor_product
Author
Teoderick Contreras, Splunk, Steven Dick
Source
github.com/splunk/security_content

The following analytic detects suspicious registry modifications that implement auto admin logon by adding DefaultUserName and DefaultPassword values. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" registry path. This activity is significant because it is associated with BlackMatter ransomware, which uses this technique to automatically log on to compromised hosts and continue encryption after a safe mode boot. If confirmed malicious, this could allow attackers to maintain persistence and further encrypt the network, leading to significant data loss and operational disruption.

Known False Positives

  • No false positives have been identified at this time.

MITRE ATT&CK Coverage

Telemetry Coverage

Rule Body

name: Add DefaultUser And Password In Registry
id: d4a3eb62-0f1e-11ec-a971-acde48001122
version: 15
creation_date: '2021-09-06'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk, Steven Dick
status: production
type: Anomaly
description: The following analytic detects suspicious registry modifications that implement auto admin logon by adding DefaultUserName and DefaultPassword values. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" registry path. This activity is significant because it is associated with BlackMatter ransomware, which uses this technique to automatically log on to compromised hosts and continue encryption after a safe mode boot. If confirmed malicious, this could allow attackers to maintain persistence and further encrypt the network, leading to significant data loss and operational disruption.
data_source:
    - Sysmon EventID 12
    - 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= "*SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon*" AND Registry.registry_value_name= DefaultPassword OR Registry.registry_value_name= DefaultUserName) 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)` | `add_defaultuser_and_password_in_registry_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://news.sophos.com/en-us/2021/08/09/blackmatter-ransomware-emerges-from-the-shadow-of-darkside/
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: modified registry key $registry_key_name$ with registry value $registry_value_name$ to prepare autoadminlogon
analytic_story:
    - BlackMatter Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1552.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
    count
    min(_time) as firstTime
    max(_time) as lastTime
  FROM datamodel=Endpoint.Registry
  WHERE (
      Registry.registry_path= "*SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon*"
      AND Registry.registry_value_name= DefaultPassword
      OR Registry.registry_value_name= DefaultUserName
  )
  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

Stage 2: search

| `drop_dm_object_name(Registry)`

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `add_defaultuser_and_password_in_registry_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
Registry.registry_patheq
  • *SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon* corpus 2 (splunk 2)
field:"registry_path" kind:eq value:"*SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon*"
Registry.registry_value_nameeq
  • DefaultPassword
  • DefaultUserName
field:"registry_value_name" kind:eq

ASL AWS IAM Assume Role Policy Brute Force

#
Status
production
Severity
medium
Group by
"actor.user.uid", _time
Author
Patrick Bareiss, Splunk
Source
github.com/splunk/security_content

The following analytic detects multiple failed attempts to assume an AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail logs to identify MalformedPolicyDocumentException errors with a status of failure and filters out legitimate AWS services. This activity is significant as repeated failures to assume roles can indicate an adversary attempting to guess role names, which is a precursor to unauthorized access. If confirmed malicious, this could lead to unauthorized access to AWS resources, potentially compromising sensitive data and services.

Known False Positives

  • This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users.

MITRE ATT&CK Coverage

TacticTechniques
Credential Access
Discovery

Telemetry Coverage

Rules Detecting the Same Action

These rules filter on the same operation.

Rule Body

name: ASL AWS IAM Assume Role Policy Brute Force
id: 726959fe-316d-445c-a584-fa187d64e295
version: 8
creation_date: '2022-10-04'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects multiple failed attempts to assume an AWS IAM role, indicating a potential brute force attack. It leverages AWS CloudTrail logs to identify `MalformedPolicyDocumentException` errors with a status of `failure` and filters out legitimate AWS services. This activity is significant as repeated failures to assume roles can indicate an adversary attempting to guess role names, which is a precursor to unauthorized access. If confirmed malicious, this could lead to unauthorized access to AWS resources, potentially compromising sensitive data and services.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` api.operation="AssumeRole" "api.response.error"=AccessDenied
      | bucket _time span=1h
      | stats count as failures min(_time) as firstTime max(_time) as lastTime values(api.operation) as api.operation values(api.service.name) as api.service.name values(http_request.user_agent) as http_request.user_agent values(src_endpoint.ip) as src_ip values(actor.user.account.uid) as actor.user.account.uid values(cloud.provider) as cloud.provider values(cloud.region) as cloud.region
        BY _time actor.user.uid
      | where failures >= 3
      | 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_iam_assume_role_policy_brute_force_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: This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users.
references:
    - https://www.praetorian.com/blog/aws-iam-assume-role-vulnerabilities/
    - https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/
    - https://www.elastic.co/guide/en/security/current/aws-iam-brute-force-of-assume-role-policy.html
finding:
    title: User $user$ has caused multiple failures with errorCode AccessDenied, which potentially means adversary is attempting to identify a role name.
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - AWS IAM Privilege Escalation
    - Scattered Lapsus$ Hunters
asset_type: AWS Account
mitre_attack_id:
    - T1580
    - T1110
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: access

Stages and Predicates

Stage 1: search

`amazon_security_lake` api.operation="AssumeRole" "api.response.error"=AccessDenied

Stage 2: bucket

| bucket _time span=1h

Stage 3: stats

| stats
    count as failures
    min(_time) as firstTime
    max(_time) as lastTime
    values(api.operation) as api.operation
    values(api.service.name) as api.service.name
    values(http_request.user_agent) as http_request.user_agent
    values(src_endpoint.ip) as src_ip
    values(actor.user.account.uid) as actor.user.account.uid
    values(cloud.provider) as cloud.provider
    values(cloud.region) as cloud.region
  BY _time actor.user.uid

Stage 4: where

| where failures >= 3

Stage 5: rename

| 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

Stage 6: search

| `security_content_ctime(firstTime)`

Stage 7: search

| `security_content_ctime(lastTime)`

Stage 8: search

| `asl_aws_iam_assume_role_policy_brute_force_filter`

Indicators

These rows show field, operator, and value matches.

Certutil De-Obfuscate_Decode Files (Sysmon)

#
Group by
_time, host
Source
github.com/anvilogic-forge/armory

Detects the decoding of PE files inside a certificate (used by MenuPass) - (T1140)

MITRE ATT&CK Coverage

References

Telemetry Coverage

ProviderRecord / event type
SysmonEvent ID 1: Process creation

Rule Body

id: '1031.1036'
title: Certutil De-Obfuscate_Decode Files
description: 'Detects the decoding of PE files inside a certificate (used by MenuPass)
  - (T1140). -- Threat Actor Association: FIN13, Kimsuky, Revil, TA551, Volt Typhoon
  -- Software Association: Astaroth, MINEBRIDGE, Mispadu, VawTrack -- Atomics T1140
  Test #1 Atomics T1140 Test #2'
logic_format: Splunk
logic: ' `get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("certutil" (TERM(-decode) OR TERM(-decodehex))) OR (TERM(-decode) OR TERM(-decodehex))
  | table _time, host, user event_id, parent_process, parent_process_id, parent_process_name,
  parent_process_path, process, process_current_directory, process_hash, process_id,
  process_name, process_path, signature_id, user_id | bin span=1s | stats values(*)
  as * by _time, host | where match(process, "(?i)-decode") '
techniques:
- defense-evasion:deobfuscate/decode files or information
technique_id: 
- T1140
data_category:
- Windows Sysmon
references:
- https://www.sentinelone.com/blog/malware-living-off-land-with-certutil/

Stages and Predicates

Stage 1: search

`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<") ("certutil" (TERM(-decode) OR TERM(-decodehex))) OR (TERM(-decode) OR TERM(-decodehex))

Stage 2: table

| table _time, host, user event_id, parent_process, parent_process_id, parent_process_name,
    parent_process_path, process, process_current_directory, process_hash, process_id, process_name,
    process_path, signature_id, user_id

Stage 3: bucket

| bin span=1s

Stage 4: stats

| stats values(*) as * by _time, host

Stage 5: where

| where match(process, "(?i)-decode")

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 1 corpus 226 (splunk 226)
field:"EventID" kind:eq value:"1"
processregex_match
  • (?i)-decode corpus 2 (splunk 2)
field:"CommandLine" kind:regex_match value:"(?i)-decode"

Search Terms

These SPL tokens match against raw event text.

StageTerm
1"<EventID>1<"
1"certutil"
1"-decode"
1"-decodehex"
1"-decode"
1"-decodehex"

Cisco Duo Policy Allow Tampered Devices

#
Status
production
Severity
medium
Group by
action, actionlabel, admin_email, description, user
Author
Patrick Bareiss, Splunk
Source
github.com/splunk/security_content

The following analytic detects when a Duo policy is created or updated to allow tampered or rooted devices, such as jailbroken smartphones, to access protected resources. It identifies this behavior by searching Duo administrator activity logs for policy changes where the allow_rooted_devices setting is enabled. This is accomplished by filtering for policy creation or update actions and parsing the policy description for the relevant configuration. Allowing tampered devices poses a significant security risk, as these devices may bypass built-in security controls, run unauthorized software, or be more susceptible to compromise. For a Security Operations Center (SOC), identifying such policy changes is critical because it may indicate either a misconfiguration or a malicious attempt to weaken authentication requirements, potentially enabling attackers to access sensitive systems with compromised devices. The impact of this attack can include unauthorized access, data breaches, and lateral movement within the environment, making prompt detection and response essential to maintaining organizational security.

Known False Positives

  • No false positives have been identified at this time.

MITRE ATT&CK Coverage

Rule Body

name: Cisco Duo Policy Allow Tampered Devices
id: 6b813efd-8859-406f-b677-719458387fac
version: 6
creation_date: '2025-07-10'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: |
    The following analytic detects when a Duo policy is created or updated to allow tampered or rooted devices, such as jailbroken smartphones,
    to access protected resources. It identifies this behavior by searching Duo administrator activity logs for policy changes where the allow_rooted_devices
    setting is enabled. This is accomplished by filtering for policy creation or update actions and parsing the policy description for the relevant configuration.
    Allowing tampered devices poses a significant security risk, as these devices may bypass built-in security controls, run unauthorized software, or be more
    susceptible to compromise. For a Security Operations Center (SOC), identifying such policy changes is critical because it may indicate either a
    misconfiguration or a malicious attempt to weaken authentication requirements, potentially enabling attackers to access sensitive systems with
    compromised devices. The impact of this attack can include unauthorized access, data breaches, and lateral movement within the environment,
    making prompt detection and response essential to maintaining organizational security.
data_source:
    - Cisco Duo Administrator
search: |-
    `cisco_duo_administrator` action=policy_update OR action=policy_create
      | spath input=description
      | search allow_rooted_devices=true
      | rename object as user
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY action actionlabel description
           user admin_email
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `cisco_duo_policy_allow_tampered_devices_filter`
how_to_implement: The analytic leverages Duo activity logs to be ingested using the Cisco Security Cloud App (https://splunkbase.splunk.com/app/7404).
known_false_positives: No false positives have been identified at this time.
references:
    - https://splunkbase.splunk.com/app/7404
finding:
    title: A policy has been created or updated to allow tampered devices by user $user$ with email $admin_email$
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Cisco Duo Suspicious Activity
asset_type: Identity
mitre_attack_id:
    - T1556
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: identity

Stages and Predicates

Stage 1: search

`cisco_duo_administrator` action=policy_update OR action=policy_create

Stage 2: spath

| spath input=description

Stage 3: search

| search allow_rooted_devices=true

Stage 4: rename

| rename object as user

Stage 5: stats

| stats count min(_time) as firstTime max(_time) as lastTime
    BY action actionlabel description
       user admin_email

Stage 6: search

| `security_content_ctime(firstTime)`

Stage 7: search

| `security_content_ctime(lastTime)`

Stage 8: search

| `cisco_duo_policy_allow_tampered_devices_filter`

Indicators

These rows show field, operator, and value matches.

Cisco Secure Firewall - Possibly Compromised Host

#
Status
experimental
Severity
low
Group by
Impact, InlineResult, InlineResultReason, MitreAttackGroups, app, class_desc, dest, destination_port, impact_desc, src, transport
Author
Nasreddine Bencherchali, Splunk
Source
github.com/splunk/security_content

The following analytic highlights high-impact intrusion events assigned by Cisco Secure Firewall. This detection leverages Cisco Secure Firewall Threat Defense logs and specifically the IntrusionEvent event type and Impact field assigned by Cisco Secure Firewall looking for an impact score of 1 or 2. If confirmed malicious this may indicate a potential compromised host.

Known False Positives

  • False positives are directly related to their snort rules triggering and the firewall scoring. Apply additional filters if the rules are too noisy by disabling them or simply ignoring certain IP ranges that trigger it.

MITRE ATT&CK Coverage

Rule Body

name: Cisco Secure Firewall - Possibly Compromised Host
id: 244a77bb-3b2a-46f1-bf2c-b4f7cd29276d
version: 8
creation_date: '2025-04-16'
modification_date: '2026-05-13'
author: Nasreddine Bencherchali, Splunk
status: experimental
type: Anomaly
description: |
    The following analytic highlights high-impact intrusion events assigned by Cisco Secure Firewall.
    This detection leverages Cisco Secure Firewall Threat Defense logs and specifically the IntrusionEvent event type and `Impact` field assigned by Cisco Secure Firewall looking for an impact score of 1 or 2. If confirmed malicious this may indicate a potential compromised host.
data_source:
    - Cisco Secure Firewall Threat Defense Intrusion Event
search: |
    `cisco_secure_firewall` EventType=IntrusionEvent Impact IN (1,2)
    | stats count as TotalDetections values(signature_id) as signature_id
            values(signature) as signature
            values(rule) as rule
            min(_time) as firstTime max(_time) as lastTime
            by src dest dest_port transport Impact app impact_desc class_desc MitreAttackGroups InlineResult InlineResultReason
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_secure_firewall___possibly_compromised_host_filter`
how_to_implement: |
    This search requires Cisco Secure Firewall Threat Defense Logs, which
    includes the IntrusionEvent 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 intrusion access policy must also be configured.
known_false_positives: False positives are directly related to their snort rules triggering and the firewall scoring. Apply additional filters if the rules are too noisy by disabling them or simply ignoring certain IP ranges that trigger it.
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: A high impact IntrusionEvent was detected from $src$ to $dest$.
threat_objects:
    - field: signature
      type: signature
analytic_story:
    - Cisco Secure Firewall Threat Defense Analytics
asset_type: Network
mitre_attack_id:
    - T1203
    - T1059
    - T1587.001
product:
    - Splunk Enterprise
    - Splunk Cloud
    - Splunk Enterprise Security
category: network
security_domain: network

Stages and Predicates

Stage 1: search

`cisco_secure_firewall` EventType=IntrusionEvent Impact IN (1,2)

Stage 2: stats

| stats
    count as TotalDetections
    values(signature_id) as signature_id
    values(signature) as signature
    values(rule) as rule
    min(_time) as firstTime
    max(_time) as lastTime
  by
    src
    dest
    dest_port
    transport
    Impact
    app
    impact_desc
    class_desc
    MitreAttackGroups
    InlineResult
    InlineResultReason

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `cisco_secure_firewall___possibly_compromised_host_filter`

Indicators

These rows show field, operator, and value matches.

Clop Common Exec Parameter

#
Status
production
Severity
medium
Group by
IntegrityLevel, command_line, computer_name, event_action, original_file_name, parent_command_line, parent_process_basename, parent_process_guid, parent_process_id, parent_process_name, process_basename, process_guid, process_hash, process_id, process_name, user, user_id, vendor_product
Author
Teoderick Contreras, Splunk
Source
github.com/splunk/security_content

The following analytic identifies the execution of CLOP ransomware variants using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it indicates potential ransomware behavior, which can lead to file encryption on network shares or local machines. If confirmed malicious, this activity could result in significant data loss and operational disruption due to encrypted files, highlighting the need for immediate investigation and response.

Known False Positives

  • Operators can execute third party tools using these parameters.

MITRE ATT&CK Coverage

TacticTechniques
Execution

Telemetry Coverage

Rule Body

name: Clop Common Exec Parameter
id: 5a8a2a72-8322-11eb-9ee9-acde48001122
version: 14
creation_date: '2021-03-17'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic identifies the execution of CLOP ransomware variants using specific arguments ("runrun" or "temp.dat") to trigger their malicious activities. This detection leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names and command-line arguments. Monitoring this activity is crucial as it indicates potential ransomware behavior, which can lead to file encryption on network shares or local machines. If confirmed malicious, this activity could result in significant data loss and operational disruption due to encrypted files, highlighting the need for immediate investigation and response.
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 != "*temp.dat*" Processes.process = "*runrun*"
        OR
        Processes.process = "*temp.dat*"
      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)`
    | `clop_common_exec_parameter_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: Operators can execute third party tools using these parameters.
references:
    - https://www.mandiant.com/resources/fin11-email-campaigns-precursor-for-ransomware-data-theft
    - https://blog.virustotal.com/2020/11/keep-your-friends-close-keep-ransomware.html
finding:
    title: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting using arguments to execute its main code or feature of its code related to Clop ransomware.
    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 using arguments to execute its main code or feature of its code related to Clop ransomware.
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
analytic_story:
    - Compromised Windows Host
    - Clop Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1204
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
    count
    min(_time) as firstTime
    max(_time) as lastTime
  FROM datamodel=Endpoint.Processes
  WHERE Processes.process_name != "*temp.dat*" Processes.process = "*runrun*"
    OR
    Processes.process = "*temp.dat*"
  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

Stage 2: search

| `drop_dm_object_name(Processes)`

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `clop_common_exec_parameter_filter`

Indicators

These rows show field, operator, and value matches.

Cloud Compute Instance Created With Previously Unseen Instance Type

#
Status
production
Severity
low
Group by
All_Changes.Instance_Changes.instance_type, All_Changes.user
Author
David Dorsey, Splunk
Source
github.com/splunk/security_content

The following analytic detects the creation of EC2 instances with previously unseen instance types. It leverages Splunk's tstats command to analyze data from the Change data model, identifying instance types that have not been previously recorded. This activity is significant for a SOC because it may indicate unauthorized or suspicious activity, such as an attacker attempting to create instances for malicious purposes. If confirmed malicious, this could lead to unauthorized access, data exfiltration, system compromise, or service disruption. Immediate investigation is required to determine the legitimacy of the instance creation.

Known False Positives

  • It is possible that an admin will create a new system using a new instance type that has never been used before. Verify with the creator that they intended to create the system with the new instance type.

MITRE ATT&CK Coverage

Rule Body

name: Cloud Compute Instance Created With Previously Unseen Instance Type
id: c6ddbf53-9715-49f3-bb4c-fb2e8a309cda
version: 11
creation_date: '2019-10-16'
modification_date: '2026-05-13'
author: David Dorsey, Splunk
status: production
type: Anomaly
description: |-
    The following analytic detects the creation of EC2 instances with previously unseen instance types.
    It leverages Splunk's tstats command to analyze data from the Change data model, identifying instance types that have not been previously recorded.
    This activity is significant for a SOC because it may indicate unauthorized or suspicious activity, such as an attacker attempting to create instances for malicious purposes.
    If confirmed malicious, this could lead to unauthorized access, data exfiltration, system compromise, or service disruption. Immediate investigation is required to determine the legitimacy of the instance creation.
data_source:
    - AWS CloudTrail
search: |-
    | tstats count earliest(_time) as firstTime
                   latest(_time) as lastTime
                   values(All_Changes.object_id) as dest
    FROM datamodel=Change WHERE

    All_Changes.action=created

    BY All_Changes.Instance_Changes.instance_type All_Changes.user

    | `drop_dm_object_name("All_Changes")`
    | `drop_dm_object_name("Instance_Changes")`
    | where instance_type != "unknown"
    | lookup previously_seen_cloud_compute_instance_types instance_type as instance_type OUTPUTNEW firstTimeSeen, enough_data
    | eventstats max(enough_data) as enough_data
    | where enough_data=1
    | eval firstTimeSeenInstanceType=min(firstTimeSeen)
    | where isnull(firstTimeSeenInstanceType) OR firstTimeSeenInstanceType > relative_time(now(), "-24h@h")
    | table firstTime, user, dest, count, instance_type
    | `security_content_ctime(firstTime)`
    | `cloud_compute_instance_created_with_previously_unseen_instance_type_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 Compute Instance Types - Initial` to build the initial table of instance types observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Instance Types - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_instance_type_filter` macro.
known_false_positives: |-
    It is possible that an admin will create a new system using a new instance type that has never been used before. Verify with the creator that they intended to create the system with the new instance type.
references: []
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: User $user$ is creating an instance $dest$ with an instance type $instance_type$ that has not been previously seen.
        - field: user
          type: user
          score: 20
          message: User $user$ is creating an instance $dest$ with an instance type $instance_type$ that has not been previously seen.
analytic_story:
    - Cloud Cryptomining
asset_type: Cloud Compute Instance
mitre_attack_id:
    - T1578.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat
baselines:
    - Previously Seen Cloud Compute Instance Types - Update
    - Previously Seen Cloud Compute Instance Types - Initial

Stages and Predicates

Stage 1: tstats

| tstats count earliest(_time) as firstTime
               latest(_time) as lastTime
               values(All_Changes.object_id) as dest
FROM datamodel=Change WHERE

All_Changes.action=created

BY All_Changes.Instance_Changes.instance_type All_Changes.user

Stage 2: search

| `drop_dm_object_name("All_Changes")`

Stage 3: search

| `drop_dm_object_name("Instance_Changes")`

Stage 4: where

| where instance_type != "unknown"

Stage 5: lookup

| lookup previously_seen_cloud_compute_instance_types instance_type as instance_type OUTPUTNEW
    firstTimeSeen, enough_data
Lookup table
previously_seen_cloud_compute_instance_types
Key field
instance_type
Output columns
['firstTimeSeen', 'firstTimeSeen'], ['enough_data', 'enough_data']

Stage 6: eventstats

| eventstats max(enough_data) as enough_data

Stage 7: where

| where enough_data=1

Stage 8: eval

| eval firstTimeSeenInstanceType=min(firstTimeSeen)

Stage 9: where

| where isnull(firstTimeSeenInstanceType)
    OR firstTimeSeenInstanceType > relative_time(now(), "-24h@h")

Stage 10: table

| table firstTime, user, dest, count, instance_type

Stage 11: search

| `security_content_ctime(firstTime)`

Stage 12: search

| `cloud_compute_instance_created_with_previously_unseen_instance_type_filter`

Indicators

These rows show field, operator, and value matches.

DLL Execution from Uncommon Process (Windows Event Log)

#
Group by
_time, host
Source
github.com/anvilogic-forge/armory

During an attack using Ursnif malware, threat actors were observed executing DLLs with a renamed rundll32 binary. This use case detects execution of the DLL functions DllRegisterServer, DllMain, DllUnregisterServer, DllInstall, or DllCanUnloadNow from processes other than rundll32.exe

MITRE ATT&CK Coverage

References

Telemetry Coverage

Rule Body

id: '27341.49802'
title: DLL Execution from Uncommon Process
description: During an attack using Ursnif malware, threat actors were observed executing
  DLLs with a renamed rundll32 binary. This use case detects execution of the DLL
  functions DllRegisterServer, DllMain, DllUnregisterServer, DllInstall, or DllCanUnloadNow
  from processes other than rundll32.exe. Living Off the Land Binary and Scripts (LOLBAS)
  (LOLBIN)
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR
  "<EventID>4688<" OR Type=Process) ",DllRegisterServer" OR ",DllMain" OR ",DllUnregisterServer"
  OR ",DllInstall" OR ",DllCanUnloadNow" | rex field=process ",(?<dll_function>\S+)"|
  where not match(process_name, "(?i)rundll32\.exe") | table _time, host, user, process,
  process_*, parent_process*, dll_function | bin span=1s | stats values(*) as * by
  _time, host '
techniques:
- defense-evasion:system binary proxy execution:rundll32
technique_id:
- T1218.011
data_category:
- Process command-line parameters
- Windows event logs
references:
- https://thedfirreport.com/2023/01/09/unwrapping-ursnifs-gifts/

Stages and Predicates

Stage 1: search

`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR "<EventID>4688<" OR Type=Process) ",DllRegisterServer" OR ",DllMain" OR ",DllUnregisterServer" OR ",DllInstall" OR ",DllCanUnloadNow"

Stage 2: rex

| rex field=process ",(?<dll_function>\S+)"

Stage 3: where

| where not match(process_name, "(?i)rundll32\.exe")

Stage 4: table

| table _time, host, user, process, process_*, parent_process*, dll_function

Stage 5: bucket

| bin span=1s

Stage 6: stats

| stats values(*) as * by _time, host

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 4688 corpus 284 (splunk 283, elastic 1)
field:"EventID" kind:eq value:"4688"

Exclusions

The rule actively suppresses these predicates.

FieldKindExcluded valuesSearch
process_nameregex_match(?i)rundll32.exeexcludes:process_name field:"process_name" value:"(?i)rundll32.exe"

Search Terms

These SPL tokens match against raw event text.

StageTerm
1"<EventID>4688<"
1",DllRegisterServer"
1",DllMain"
1",DllUnregisterServer"
1",DllInstall"
1",DllCanUnloadNow"

Powershell Fileless Script Contains Base64 Encoded Content

#
Status
production
Severity
medium
Group by
Guid, Name, Opcode, Path, ScriptBlockId, ScriptBlockText, dest, process_id, signature, signature_id, user_id, vendor_product
Author
Michael Haag, Splunk
Source
github.com/splunk/security_content

The following analytic detects the execution of PowerShell scripts containing Base64 encoded content, specifically identifying the use of FromBase64String. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command sent to PowerShell. This activity is significant as Base64 encoding is often used by attackers to obfuscate malicious payloads, making it harder to detect. If confirmed malicious, this could lead to code execution, allowing attackers to run arbitrary commands and potentially compromise the system.

Known False Positives

  • False positives should be limited. Filter as needed.

MITRE ATT&CK Coverage

Telemetry Coverage

Rule Body

name: Powershell Fileless Script Contains Base64 Encoded Content
id: 8acbc04c-c882-11eb-b060-acde48001122
version: 22
creation_date: '2021-06-09'
modification_date: '2026-06-25'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic detects the execution of PowerShell scripts containing Base64 encoded content, specifically identifying the use of `FromBase64String`. It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command sent to PowerShell. This activity is significant as Base64 encoding is often used by attackers to obfuscate malicious payloads, making it harder to detect. If confirmed malicious, this could lead to code execution, allowing attackers to run arbitrary commands and potentially compromise the system.
data_source:
    - Powershell Script Block Logging 4104
search: "`powershell` EventCode=4104 ScriptBlockText = \"*frombase64string*\" OR ScriptBlockText = \"*gnirtS46esaBmorF*\"\n  | fillnull\n  | stats count min(_time) as firstTime max(_time) as lastTime\n    BY dest signature signature_id\n       user_id vendor_product EventID\n       Guid Opcode Name\n       Path ProcessID ScriptBlockId\n       ScriptBlockText\n  | `security_content_ctime(firstTime)`\n  | `security_content_ctime(lastTime)`\n  | `powershell_fileless_script_contains_base64_encoded_content_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: False positives should be limited. Filter as needed.
references:
    - 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.
    - https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63
    - https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/59c1814829f18782e24f1fe2/1505853768977/Windows+PowerShell+Logging+Cheat+Sheet+ver+Sept+2017+v2.1.pdf
    - https://www.crowdstrike.com/blog/investigating-powershell-command-and-script-logging/
    - https://thedfirreport.com/2023/05/22/icedid-macro-ends-in-nokoyawa-ransomware/
finding:
    title: A suspicious powershell script contains base64 command on host $dest$
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Winter Vivern
    - Malicious PowerShell
    - Medusa Ransomware
    - Data Destruction
    - NjRAT
    - AsyncRAT
    - Hermetic Wiper
    - IcedID
    - XWorm
    - 0bj3ctivity Stealer
    - APT37 Rustonotto and FadeStealer
    - GhostRedirector IIS Module and Rungan Backdoor
    - Hellcat Ransomware
    - Microsoft WSUS CVE-2025-59287
    - NetSupport RMM Tool Abuse
    - MuddyWater
    - Axios Supply Chain Post Compromise
    - VIP Keylogger
    - Salat Stealer
    - Phantom Stealer
asset_type: Endpoint
mitre_attack_id:
    - T1027
    - T1059.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`powershell` EventCode=4104 ScriptBlockText = "*frombase64string*"
    OR ScriptBlockText = "*gnirtS46esaBmorF*"

Stage 2: fillnull

| fillnull

Stage 3: stats

| 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

Stage 4: search

| `security_content_ctime(firstTime)`

Stage 5: search

| `security_content_ctime(lastTime)`

Stage 6: search

| `powershell_fileless_script_contains_base64_encoded_content_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 4104 corpus 269 (splunk 269)
field:"EventID" kind:eq value:"4104"
ScriptBlockTexteq
  • *frombase64string* corpus 4 (sigma 2, splunk 2)
  • *gnirtS46esaBmorF*
field:"ScriptBlockText" kind:eq

Remcos client registry install entry

#
Status
production
Severity
medium
Group by
TargetObject, computer_name, details, event_type, process_guid, process_id, registry_hive, registry_path, registry_status, registry_value_name, registry_value_type, user, vendor_product
Author
Steven Dick, Bhavin Patel, Rod Soto, Teoderick Contreras, Splunk
Source
github.com/splunk/security_content

The following analytic detects the presence of a registry key associated with the Remcos RAT agent on a host. It leverages data from the Endpoint.Processes and Endpoint.Registry data models in Splunk, focusing on instances where the "license" key is found in the "Software\Remcos" path. This behavior is significant as it indicates potential compromise by the Remcos RAT, a remote access Trojan used for unauthorized access and data exfiltration. If confirmed malicious, the attacker could gain control over the system, steal sensitive information, or use the compromised host for further attacks. Immediate investigation and remediation are required.

Known False Positives

  • No false positives have been identified at this time.

MITRE ATT&CK Coverage

TacticTechniques
Persistence
Defense Impairment

Telemetry Coverage

Rule Body

name: Remcos client registry install entry
id: f2a1615a-1d63-11ec-97d2-acde48001122
version: 14
creation_date: '2021-09-27'
modification_date: '2026-05-13'
author: Steven Dick, Bhavin Patel, Rod Soto, Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic detects the presence of a registry key associated with the Remcos RAT agent on a host. It leverages data from the Endpoint.Processes and Endpoint.Registry data models in Splunk, focusing on instances where the "license" key is found in the "Software\Remcos" path. This behavior is significant as it indicates potential compromise by the Remcos RAT, a remote access Trojan used for unauthorized access and data exfiltration. If confirmed malicious, the attacker could gain control over the system, steal sensitive information, or use the compromised host for further attacks. Immediate investigation and remediation are required.
data_source:
    - Sysmon EventID 12
    - Sysmon EventID 13
search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path=*\\Software\\Remcos*) 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)` |`remcos_client_registry_install_entry_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://attack.mitre.org/software/S0332/
finding:
    title: A registry entry $registry_path$ with registry keyname $registry_key_name$ related to Remcos RAT in host $dest$
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Remcos
    - Windows Registry Abuse
asset_type: Endpoint
mitre_attack_id:
    - T1112
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
    count
  FROM datamodel=Endpoint.Registry
  WHERE (Registry.registry_path=*\\Software\\Remcos*)
  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

Stage 2: search

| `drop_dm_object_name(Registry)`

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `remcos_client_registry_install_entry_filter`

Indicators

These rows show field, operator, and value matches.

Windows Alternate DataStream - Executable Content

#
Status
production
Severity
medium
Group by
Contents, dest, dvc, file_hash, file_name, process_guid, process_id, process_name, signature, signature_id, target_filename, user_id, vendor_product
Author
Steven Dick, Teoderick Contreras, Splunk
Source
github.com/splunk/security_content

The following analytic detects the writing of data with an IMPHASH value to an Alternate Data Stream (ADS) in the NTFS file system. It leverages Sysmon Event ID 15 and regex to identify files with a Portable Executable (PE) structure. This activity is significant as it may indicate a threat actor staging malicious code in hidden areas for persistence or future execution. If confirmed malicious, this could allow attackers to execute hidden code, maintain persistence, or escalate privileges within the environment.

Known False Positives

  • No false positives have been identified at this time.

MITRE ATT&CK Coverage

Telemetry Coverage

ProviderRecord / event type
SysmonEvent ID 15: FileCreateStreamHash

Rule Body

name: Windows Alternate DataStream - Executable Content
id: a258bf2a-34fd-4986-8086-78f506e00206
version: 13
creation_date: '2024-01-10'
modification_date: '2026-05-13'
author: Steven Dick, Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic detects the writing of data with an IMPHASH value to an Alternate Data Stream (ADS) in the NTFS file system. It leverages Sysmon Event ID 15 and regex to identify files with a Portable Executable (PE) structure. This activity is significant as it may indicate a threat actor staging malicious code in hidden areas for persistence or future execution. If confirmed malicious, this could allow attackers to execute hidden code, maintain persistence, or escalate privileges within the environment.
data_source:
    - Sysmon EventID 15
search: '`sysmon` EventCode=15 IMPHASH!=00000000000000000000000000000000 | regex TargetFilename="(?<!\/)\b\w+(\.\w+)?:\w+(\.\w+)?$" | eval file_name = replace(TargetFilename,"(.*\\\)",""), process = Image , file_path = TargetFilename, file_hash = coalesce(SHA256,SHA1,MD5,Hash) | stats count min(_time) as firstTime max(_time) as lastTime by dest dvc file_hash file_name file_path process_exec process_guid process_id process_name process_path signature signature_id user_id vendor_product Contents Image | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_alternate_datastream___executable_content_filter`'
how_to_implement: Target environment must ingest Sysmon data, specifically Event ID 15, and import hashing/imphash must be enabled within Sysmon.
known_false_positives: No false positives have been identified at this time.
references:
    - https://car.mitre.org/analytics/CAR-2020-08-001/
    - https://blogs.juniper.net/en-us/threat-research/bitpaymer-ransomware-hides-behind-windows-alternate-data-streams
    - https://twitter.com/0xrawsec/status/1002478725605273600?s=21
finding:
    title: Base64 content written to an NTFS alternate data stream in $dest$, see command field for details.
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: file_hash
      type: file_hash
    - field: file_name
      type: file_name
analytic_story:
    - Windows Defense Evasion Tactics
asset_type: Endpoint
mitre_attack_id:
    - T1564.004
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`sysmon` EventCode=15 IMPHASH!=00000000000000000000000000000000

Stage 2: regex

| regex TargetFilename="(?<!\/)\b\w+(\.\w+)?:\w+(\.\w+)?$"

Stage 3: eval

| eval file_name = replace(TargetFilename,"(.*\\\)",""), process = Image ,
    file_path = TargetFilename, file_hash = coalesce(SHA256,SHA1,MD5,Hash)

Stage 4: stats

| stats
    count
    min(_time) as firstTime
    max(_time) as lastTime
  by
    dest
    dvc
    file_hash
    file_name
    file_path
    process_exec
    process_guid
    process_id
    process_name
    process_path
    signature
    signature_id
    user_id
    vendor_product
    Contents
    Image

Stage 5: search

| `security_content_ctime(firstTime)`

Stage 6: search

| `security_content_ctime(lastTime)`

Stage 7: search

| `windows_alternate_datastream___executable_content_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 15 corpus 6 (splunk 6)
field:"EventID" kind:eq value:"15"
IMPHASHne
  • 00000000000000000000000000000000
field:"IMPHASH" kind:ne value:"00000000000000000000000000000000"
TargetFilenameregex_match
  • (?<!\/)\b\w+(.\w+)?:\w+(.\w+)?$ corpus 2 (splunk 2)
field:"TargetFilename" kind:regex_match value:"(?<!\/)\b\w+(.\w+)?:\w+(.\w+)?$"

Windows Computer Account Changed to Domain Controller

#
Status
production
Severity
medium
Group by
UserAccountControl, computer_name, signature_id, target_user_name
Author
Raven Tait, Splunk
Source
github.com/splunk/security_content

Detects a modification to the User Account Control flags for a computer account where the SERVER_TRUST_ACCOUNT flag is set. This flag is normally associated with domain controller computer accounts. This activity may indicate a legitimate domain controller promotion or, if unexpected, an attempt to grant a computer account domain controller-like trust within Active Directory.

Known False Positives

  • Some legitimate administrative activities during domain controller promotions or system updates may trigger this rule. Filter alerts originating from authorized IT personnel or approved change management processes.

MITRE ATT&CK Coverage

TacticTechniques
Persistence

Telemetry Coverage

Rule Body

name: Windows Computer Account Changed to Domain Controller
id: f9df6250-fa45-4f62-bc9a-768c60bf99b2
version: 2
creation_date: '2026-05-05'
modification_date: '2026-05-13'
author: Raven Tait, Splunk
status: production
type: TTP
description: |-
    Detects a modification to the User Account Control flags for a computer account where the `SERVER_TRUST_ACCOUNT` flag is set.
    This flag is normally associated with domain controller computer accounts.
    This activity may indicate a legitimate domain controller promotion or, if unexpected, an attempt to grant a computer account domain controller-like trust within Active Directory.
data_source:
    - Windows Event Log Security 4742
search: |-
    `wineventlog_security`
    EventID=4742
    UserAccountControl="*%%2088*"
    | fillnull
    | stats count min(_time) as firstTime
                  max(_time) as lastTime
      by Computer TargetUserName UserAccountControl EventID

    | rename Computer as dest
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_computer_account_changed_to_domain_controller_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: Some legitimate administrative activities during domain controller promotions or system updates may trigger this rule. Filter alerts originating from authorized IT personnel or approved change management processes.
references:
    - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4742
    - https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties
finding:
    title: Computer account User Account Control flags changed to domain controller $UserAccountControl$ on $dest$.
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Active Directory Privilege Escalation
    - Sneaky Active Directory Persistence Tricks
asset_type: Endpoint
mitre_attack_id:
    - T1136.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`wineventlog_security`
EventID=4742
UserAccountControl="*%%2088*"

Stage 2: fillnull

| fillnull

Stage 3: stats

| stats count min(_time) as firstTime
              max(_time) as lastTime
  by Computer TargetUserName UserAccountControl EventID

Stage 4: rename

| rename Computer as dest

Stage 5: search

| `security_content_ctime(firstTime)`

Stage 6: search

| `security_content_ctime(lastTime)`

Stage 7: search

| `windows_computer_account_changed_to_domain_controller_filter`

Indicators

These rows show field, operator, and value matches.

Windows IIS Server PSWA Console Access

#
Status
production
Group by
Web.src, Web.status, c-uri-query, c-uri-stem, cs-host, cs-method
Author
Michael Haag, Splunk
Source
github.com/splunk/security_content

This analytic detects access attempts to the PowerShell Web Access (PSWA) console on Windows IIS servers. It monitors web traffic for requests to PSWA-related URIs, which could indicate legitimate administrative activity or potential unauthorized access attempts. By tracking source IP, HTTP status, URI path, and HTTP method, it helps identify suspicious patterns or brute-force attacks targeting PSWA. This detection is crucial for maintaining the security of remote PowerShell management interfaces and preventing potential exploitation of this powerful administrative tool.

Known False Positives

  • False positives may occur if legitimate PSWA processes are used for administrative tasks. Careful review of the logs is recommended to distinguish between legitimate and malicious activity.

MITRE ATT&CK Coverage

TacticTechniques
Initial Access

Rule Body

name: Windows IIS Server PSWA Console Access
id: 914ab191-fa8a-48cb-83a6-0565e061f934
version: 6
creation_date: '2024-09-30'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Hunting
description: This analytic detects access attempts to the PowerShell Web Access (PSWA) console on Windows IIS servers. It monitors web traffic for requests to PSWA-related URIs, which could indicate legitimate administrative activity or potential unauthorized access attempts. By tracking source IP, HTTP status, URI path, and HTTP method, it helps identify suspicious patterns or brute-force attacks targeting PSWA. This detection is crucial for maintaining the security of remote PowerShell management interfaces and preventing potential exploitation of this powerful administrative tool.
data_source:
    - Windows IIS
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Web
      WHERE Web.dest IN ("/pswa/*")
      BY Web.src Web.status Web.uri_path
         Web.dest Web.http_method Web.uri_query
    | `drop_dm_object_name("Web")`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_iis_server_pswa_console_access_filter`
how_to_implement: To successfully implement this search you need to be ingesting information on Web traffic, Exchange OR IIS logs, mapped to `Web` datamodel in the `Web` node. In addition, confirm the latest CIM App 4.20 or higher is installed.
known_false_positives: False positives may occur if legitimate PSWA processes are used for administrative tasks. Careful review of the logs is recommended to distinguish between legitimate and malicious activity.
references:
    - https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-241a
analytic_story:
    - CISA AA24-241A
asset_type: Web Server
mitre_attack_id:
    - T1190
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: web
security_domain: network

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
    count
    min(_time) as firstTime
    max(_time) as lastTime
  FROM datamodel=Web
  WHERE Web.dest IN ("/pswa/*")
  BY Web.src Web.status Web.uri_path
     Web.dest Web.http_method Web.uri_query

Stage 2: search

| `drop_dm_object_name("Web")`

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `windows_iis_server_pswa_console_access_filter`

Indicators

These rows show field, operator, and value matches.

Windows Modify Registry LongPathsEnabled

#
Status
production
Severity
low
Group by
TargetObject, computer_name, details, event_type, process_guid, process_id, registry_hive, registry_path, registry_status, registry_value_name, registry_value_type, user, vendor_product
Author
Teoderick Contreras, Splunk
Source
github.com/splunk/security_content

The following analytic detects a modification to the Windows registry setting "LongPathsEnabled," which allows file paths longer than 260 characters. This detection leverages data from the Endpoint.Registry datamodel, focusing on changes to the specific registry path and value. This activity is significant because adversaries, including malware like BlackByte, exploit this setting to bypass file path limitations, potentially aiding in evasion techniques. If confirmed malicious, this modification could facilitate the execution of long-path payloads, aiding in persistence and further system compromise.

Known False Positives

  • Administrators may enable or disable this feature that may cause some false positive.

MITRE ATT&CK Coverage

TacticTechniques
Persistence
Defense Impairment

Telemetry Coverage

Rule Body

name: Windows Modify Registry LongPathsEnabled
id: 36f9626c-4272-4808-aadd-267acce681c0
version: 12
creation_date: '2023-07-10'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects a modification to the Windows registry setting "LongPathsEnabled," which allows file paths longer than 260 characters. This detection leverages data from the Endpoint.Registry datamodel, focusing on changes to the specific registry path and value. This activity is significant because adversaries, including malware like BlackByte, exploit this setting to bypass file path limitations, potentially aiding in evasion techniques. If confirmed malicious, this modification could facilitate the execution of long-path payloads, aiding in persistence and further system compromise.
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= "*\\CurrentControlSet\\Control\\FileSystem\\LongPathsEnabled" Registry.registry_value_data = "0x00000001") 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_modify_registry_longpathsenabled_filter`'
how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
known_false_positives: Administrators may enable or disable this feature that may cause some false positive.
references:
    - https://www.microsoft.com/en-us/security/blog/2023/07/06/the-five-day-job-a-blackbyte-ransomware-intrusion-case-study/
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A registry modification in Windows LongPathEnable configuration on $dest$
analytic_story:
    - BlackByte Ransomware
asset_type: Endpoint
atomic_guid:
    - 4f4e2f9f-6209-4fcf-9b15-3b7455706f5b
mitre_attack_id:
    - T1112
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
    count
    min(_time) as firstTime
    max(_time) as lastTime
  FROM datamodel=Endpoint.Registry
  WHERE (
      Registry.registry_path= "*\\CurrentControlSet\\Control\\FileSystem\\LongPathsEnabled"
      Registry.registry_value_data = "0x00000001"
  )
  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

Stage 2: search

| `drop_dm_object_name(Registry)`

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `windows_modify_registry_longpathsenabled_filter`

Indicators

These rows show field, operator, and value matches.

Windows MSExchange Management Mailbox Cmdlet Usage

#
Status
production
Severity
low
Group by
Message, host
Author
Michael Haag, Splunk
Source
github.com/splunk/security_content

The following analytic identifies suspicious Cmdlet usage in Exchange Management logs, focusing on commands like New-MailboxExportRequest and New-ManagementRoleAssignment. It leverages EventCode 1 and specific Message patterns to detect potential ProxyShell and ProxyNotShell abuse. This activity is significant as it may indicate unauthorized access or manipulation of mailboxes and roles, which are critical for maintaining email security. If confirmed malicious, attackers could export mailbox data, assign new roles, or search mailboxes, leading to data breaches and privilege escalation.

Known False Positives

  • False positives may be present when an Administrator utilizes the cmdlets in the query. Filter or monitor as needed.

MITRE ATT&CK Coverage

Telemetry Coverage

ProviderRecord / event type
MSExchange-CmdletLogsEvent ID 1

Rule Body

name: Windows MSExchange Management Mailbox Cmdlet Usage
id: 396de86f-25e7-4b0e-be09-a330be35249d
version: 12
creation_date: '2022-11-21'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Anomaly
description: The following analytic identifies suspicious Cmdlet usage in Exchange Management logs, focusing on commands like New-MailboxExportRequest and New-ManagementRoleAssignment. It leverages EventCode 1 and specific Message patterns to detect potential ProxyShell and ProxyNotShell abuse. This activity is significant as it may indicate unauthorized access or manipulation of mailboxes and roles, which are critical for maintaining email security. If confirmed malicious, attackers could export mailbox data, assign new roles, or search mailboxes, leading to data breaches and privilege escalation.
data_source: []
search: |-
    `msexchange_management` EventCode=1 Message IN ("*New-MailboxExportRequest*", "*New-ManagementRoleAssignment*", "*New-MailboxSearch*", "*Get-Recipient*", "*Search-Mailbox*")
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY host Message
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | rename host AS dest
      | `windows_msexchange_management_mailbox_cmdlet_usage_filter`
how_to_implement: The following analytic requires collecting the Exchange Management logs via a input. An example inputs is here https://gist.github.com/MHaggis/f66f1d608ea046efb9157020cd34c178. We used multiline as the XML format of the logs will require props/transforms. Multiline gives us everything we need in Message for now. Update the macro with your correct sourcetype.
known_false_positives: False positives may be present when an Administrator utilizes the cmdlets in the query. Filter or monitor as needed.
references:
    - https://gist.github.com/MHaggis/f66f1d608ea046efb9157020cd34c178
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: Cmdlets related to ProxyShell and ProxyNotShell have been identified on $dest$.
analytic_story:
    - ProxyShell
    - BlackByte Ransomware
    - ProxyNotShell
    - Scattered Spider
asset_type: Endpoint
mitre_attack_id:
    - T1059.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`msexchange_management` EventCode=1 Message IN (
    "*New-MailboxExportRequest*",
    "*New-ManagementRoleAssignment*",
    "*New-MailboxSearch*",
    "*Get-Recipient*",
    "*Search-Mailbox*"
)

Stage 2: stats

| stats count min(_time) as firstTime max(_time) as lastTime
    BY host Message

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: rename

| rename host AS dest

Stage 6: search

| `windows_msexchange_management_mailbox_cmdlet_usage_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 1 corpus 226 (splunk 226)
field:"EventID" kind:eq value:"1"
Messagein
  • *Get-Recipient*
  • *New-MailboxExportRequest*
  • *New-MailboxSearch*
  • *New-ManagementRoleAssignment*
  • *Search-Mailbox*
field:"Message" kind:in
sourcetypeeq
  • MSExchange:management
field:"sourcetype" kind:eq value:"MSExchange:management"

Windows Powershell Cryptography Namespace

#
Status
production
Severity
low
Group by
Guid, Name, Opcode, Path, ScriptBlockId, ScriptBlockText, dest, process_id, signature, signature_id, user_id, vendor_product
Author
Teoderick Contreras, Splunk
Source
github.com/splunk/security_content

The following analytic detects suspicious PowerShell script execution involving the cryptography namespace via EventCode 4104. It leverages PowerShell Script Block Logging to identify scripts using cryptographic functions, excluding common hashes like SHA and MD5. This activity is significant as it is often associated with malware that decrypts or decodes additional malicious payloads. If confirmed malicious, this could allow an attacker to execute further code, escalate privileges, or establish persistence within the environment. Analysts should investigate the parent process, decrypted data, network connections, and the user executing the script.

Known False Positives

  • False positives should be limited. Filter as needed.

MITRE ATT&CK Coverage

Telemetry Coverage

Rule Body

name: Windows Powershell Cryptography Namespace
id: f8b482f4-6d62-49fa-a905-dfa15698317b
version: 16
creation_date: '2023-01-26'
modification_date: '2026-06-25'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects suspicious PowerShell script execution involving the cryptography namespace via EventCode 4104. It leverages PowerShell Script Block Logging to identify scripts using cryptographic functions, excluding common hashes like SHA and MD5. This activity is significant as it is often associated with malware that decrypts or decodes additional malicious payloads. If confirmed malicious, this could allow an attacker to execute further code, escalate privileges, or establish persistence within the environment. Analysts should investigate the parent process, decrypted data, network connections, and the user executing the script.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell` EventCode=4104 ScriptBlockText = "*System.Security.Cryptography*" AND NOT(ScriptBlockText IN ("*SHA*", "*MD5*", "*DeriveBytes*"))
      | 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)`
      | `security_content_ctime(lastTime)`
      | `windows_powershell_cryptography_namespace_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: False positives should be limited. Filter as needed.
references:
    - https://malpedia.caad.fkie.fraunhofer.de/details/win.asyncrat
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A suspicious powershell script contains cryptography command detected on host $dest$
        - field: user_id
          type: user
          score: 20
          message: A suspicious powershell script contains cryptography command detected on host $dest$
analytic_story:
    - AsyncRAT
    - XWorm
    - VIP Keylogger
    - Phantom Stealer
asset_type: Endpoint
mitre_attack_id:
    - T1059.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`powershell` EventCode=4104 ScriptBlockText = "*System.Security.Cryptography*" AND NOT(
    ScriptBlockText IN ("*SHA*", "*MD5*", "*DeriveBytes*")
)

Stage 2: fillnull

| fillnull

Stage 3: stats

| 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

Stage 4: search

| `security_content_ctime(firstTime)`

Stage 5: search

| `security_content_ctime(lastTime)`

Stage 6: search

| `windows_powershell_cryptography_namespace_filter`

Indicators

These rows show field, operator, and value matches.

Exclusions

The rule actively suppresses these predicates.

Windows Registry Dotnet ETW Disabled Via ENV Variable

#
Status
production
Severity
medium
Group by
TargetObject, computer_name, details, event_type, process_guid, process_id, registry_hive, registry_path, registry_status, registry_value_name, registry_value_type, user, vendor_product
Author
Nasreddine Bencherchali, Splunk
Source
github.com/splunk/security_content

The following analytic detects a registry modification that disables the ETW for the .NET Framework. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the COMPlus_ETWEnabled registry value under the "Environment" registry key path for both user (HKCU\Environment) and machine (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment) scopes. This activity is significant because disabling ETW can allow attackers to evade Endpoint Detection and Response (EDR) tools and hide their execution from audit logs. If confirmed malicious, this action could enable attackers to operate undetected, potentially leading to further compromise and persistent access within the environment.

Known False Positives

  • Setting the "COMPlus_ETWEnabled" value as a global environment variable either in user or machine scope should only happen during debugging use cases, hence the false positives rate should be very minimal.

MITRE ATT&CK Coverage

TacticTechniques
Defense Impairment

Telemetry Coverage

Rule Body

name: Windows Registry Dotnet ETW Disabled Via ENV Variable
id: 55502381-5cce-491b-9277-7cb1d10bc0df
version: 11
creation_date: '2021-10-07'
modification_date: '2026-08-05'
author: Nasreddine Bencherchali, Splunk
status: production
type: TTP
description: |-
    The following analytic detects a registry modification that disables the ETW for the .NET Framework.
    It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the COMPlus_ETWEnabled registry value under the "Environment" registry key path for both user (HKCU\Environment) and machine (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment) scopes.
    This activity is significant because disabling ETW can allow attackers to evade Endpoint Detection and Response (EDR) tools and hide their execution from audit logs.
    If confirmed malicious, this action could enable attackers to operate undetected, potentially leading to further compromise and persistent access within the environment.
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="*\\Environment*"
    Registry.registry_value_name="COMPlus_ETWEnabled"
    Registry.registry_value_data IN ("0x00000000", "0")

    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)`
    | `windows_registry_dotnet_etw_disabled_via_env_variable_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: |-
    Setting the "COMPlus_ETWEnabled" value as a global environment variable either in user or machine scope should only happen during debugging use cases, hence the false positives rate should be very minimal.
references:
    - https://gist.github.com/Cyb3rWard0g/a4a115fd3ab518a0e593525a379adee3
    - https://blog.xpnsec.com/hiding-your-dotnet-complus-etwenabled/
    - https://attack.mitre.org/techniques/T1562/006/
finding:
    title: The registry key [$registry_path$] with the value name [$registry_value_name$] was modified to the value [$registry_value_data$] to disable the ETW for the .NET Framework in [$dest$]
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: The registry key [$registry_path$] with the value name [$registry_value_name$] was modified to the value [$registry_value_data$] to disable the ETW for the .NET Framework in [$dest$]
analytic_story:
    - Windows Registry Abuse
    - Windows Defense Evasion Tactics
asset_type: Endpoint
mitre_attack_id:
    - T1685
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
  count min(_time) as firstTime
        max(_time) as lastTime

FROM datamodel=Endpoint.Registry WHERE

Registry.registry_path="*\\Environment*"
Registry.registry_value_name="COMPlus_ETWEnabled"
Registry.registry_value_data IN ("0x00000000", "0")

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

Stage 2: search

| `drop_dm_object_name(Registry)`

Stage 3: where

| where isnotnull(registry_value_data)

Stage 4: search

| `security_content_ctime(firstTime)`

Stage 5: search

| `security_content_ctime(lastTime)`

Stage 6: search

| `windows_registry_dotnet_etw_disabled_via_env_variable_filter`

Indicators

These rows show field, operator, and value matches.

Windows Scheduled Task with Suspicious Command

#
Status
production
Severity
medium
Group by
Command, Enabled, Hidden, computer_name, signature_id, task_name, user
Author
Steven Dick
Source
github.com/splunk/security_content

The following analytic detects the creation of scheduled tasks designed to execute commands using native Windows shells like PowerShell, Cmd, Wscript, or Cscript or from public folders such as Users, Temp, or ProgramData. It leverages Windows Security EventCode 4698, 4700, and 4702 to identify when such tasks are registered, enabled, or modified. This activity is significant as it may indicate an attempt to establish persistence or execute malicious commands on a system. If confirmed malicious, this could allow an attacker to maintain access, execute arbitrary code, or escalate privileges, posing a severe threat to the environment.

Known False Positives

  • False positives are possible if legitimate applications are allowed to register tasks that call a shell to be spawned. Filter as needed based on command-line or processes that are used legitimately. Windows Defender, Google Chrome, and MS Edge updates may trigger this detection.

MITRE ATT&CK Coverage

Telemetry Coverage

Rule Body

name: Windows Scheduled Task with Suspicious Command
id: 1f44c126-c26a-4dd3-83bb-0f9a0f03ecc3
version: 9
creation_date: '2025-02-07'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: TTP
description: The following analytic detects the creation of scheduled tasks designed to execute commands using native Windows shells like PowerShell, Cmd, Wscript, or Cscript or from public folders such as Users, Temp, or ProgramData. It leverages Windows Security EventCode 4698, 4700, and 4702 to identify when such tasks are registered, enabled, or modified. This activity is significant as it may indicate an attempt to establish persistence or execute malicious commands on a system. If confirmed malicious, this could allow an attacker to maintain access, execute arbitrary code, or escalate privileges, posing a severe threat to the environment.
data_source:
    - Windows Event Log Security 4698
    - Windows Event Log Security 4700
    - Windows Event Log Security 4702
search: "`wineventlog_security` EventCode IN (4698,4700,4702)\n| eval TaskContent = case(isnotnull(TaskContentNew),TaskContentNew,true(),TaskContent)\n| xmlkv TaskContent\n| stats count min(_time) as firstTime max(_time) as lastTime latest(Arguments) as Arguments latest(Author) as Author by Computer, Caller_User_Name, TaskName, Command, Enabled, Hidden, EventCode\n| lookup windows_suspicious_tasks task_command as Command \n| where tool == \"shell command use\" OR tool == \"suspicious paths\"\n| eval command=TaskName, process=Command+if(isnotnull(Arguments),\" \".Arguments,\"\"), src_user=Author, user = Caller_User_Name, dest = Computer, signature_id = EventCode \n| `security_content_ctime(firstTime)` \n| `security_content_ctime(lastTime)`\n| `windows_scheduled_task_with_suspicious_command_filter` "
how_to_implement: To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required.
known_false_positives: False positives are possible if legitimate applications are allowed to register tasks that call a shell to be spawned. Filter as needed based on command-line or processes that are used legitimately. Windows Defender, Google Chrome, and MS Edge updates may trigger this detection.
references:
    - https://attack.mitre.org/techniques/T1053/005/
    - https://www.ic3.gov/CSA/2023/231213.pdf
    - https://news.sophos.com/en-us/2024/11/06/bengal-cat-lovers-in-australia-get-psspsspssd-in-google-driven-gootloader-campaign/
    - https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_windows_tasks_list.csv
finding:
    title: A suspicious windows scheduled task named [$TaskName$] was detected on $dest$, this may be an indicator of [$tool$]
    entity:
        field: user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: A suspicious windows scheduled task named [$TaskName$] was detected on $dest$, this may be an indicator of [$tool$]
threat_objects:
    - field: Command
      type: signature
analytic_story:
    - SolarWinds WHD RCE Post Exploitation
    - Scheduled Tasks
    - Ransomware
    - Quasar RAT
    - Ryuk Ransomware
    - Windows Persistence Techniques
    - Seashell Blizzard
    - APT37 Rustonotto and FadeStealer
asset_type: Endpoint
mitre_attack_id:
    - T1053.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`wineventlog_security` EventCode IN (4698,4700,4702)

Stage 2: eval

| eval TaskContent = case(isnotnull(TaskContentNew),TaskContentNew,true(),TaskContent)
TaskContent =
ifisnotnull(TaskContentNew)TaskContentNew
elseTaskContent

Stage 3: xmlkv

| xmlkv TaskContent

Stage 4: stats

| stats
    count
    min(_time) as firstTime
    max(_time) as lastTime
    latest(Arguments) as Arguments
    latest(Author) as Author
  by Computer, Caller_User_Name, TaskName, Command, Enabled, Hidden, EventCode

Stage 5: lookup

| lookup windows_suspicious_tasks task_command as Command
Lookup table
windows_suspicious_tasks
Key field
task_command as Command

Stage 6: where

| where tool == "shell command use" OR tool == "suspicious paths"

Stage 7: eval

| eval command=TaskName, process=Command+if(isnotnull(Arguments)," ".Arguments,""), src_user=Author,
    user = Caller_User_Name, dest = Computer, signature_id = EventCode

Stage 8: search

| `security_content_ctime(firstTime)`

Stage 9: search

| `security_content_ctime(lastTime)`

Stage 10: search

| `windows_scheduled_task_with_suspicious_command_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodein
  • 4698 corpus 3 (splunk 3)
  • 4700 corpus 2 (splunk 2)
  • 4702 corpus 2 (splunk 2)
field:"EventID" kind:in
tooleq
  • shell command use
  • suspicious paths
field:"tool" kind:eq

Windows Theme File Creation in Unusual Location

#
Status
production
Severity
low
Group by
CreationUtcTime, computer_name, event_action, file_name, process_guid, process_id, process_name, target_filename, user, vendor_product
Author
Raven Tait, Splunk
Source
github.com/splunk/security_content

Detects theme files being created in unusual locations. These files, used to customize desktop appearances, have been used for remote code execution and NTLM coercion attacks.

Known False Positives

  • Legitimate customization or IT management may use theme files that trigger this detection. Review and allow trusted themes from authorized sources.

MITRE ATT&CK Coverage

Telemetry Coverage

ProviderRecord / event type
SysmonEvent ID 11: FileCreate

Rule Body

name: Windows Theme File Creation in Unusual Location
id: a11f5f36-2c32-4323-8cb0-0fec84b3188d
version: 2
creation_date: '2021-09-02'
modification_date: '2026-05-13'
author: Raven Tait, Splunk
status: production
type: Anomaly
description: |-
    Detects theme files being created in unusual locations. These files, used to customize desktop appearances, have been used for remote code execution and NTLM coercion attacks.
data_source:
    - Sysmon 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 (
        "*\\Desktop\\*",
        "*\\Documents\\*",
        "*\\Downloads\\*",
        "*\\Temp\\*"
    )
    Filesystem.file_name="*.theme"
    Filesystem.action="created"

    by Filesystem.dest Filesystem.file_create_time Filesystem.process_path
       Filesystem.process_guid Filesystem.process_id Filesystem.file_path
       Filesystem.action Filesystem.file_name
       Filesystem.user Filesystem.vendor_product

    | `drop_dm_object_name(Filesystem)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_theme_file_creation_in_unusual_location_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: Legitimate customization or IT management may use theme files that trigger this detection. Review and allow trusted themes from authorized sources.
references:
    - https://www.darkreading.com/vulnerabilities-threats/recurring-windows-flaw-could-expose-user-credentials
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: Windows theme file created in unusual location at $file_path$ on $dest$.
threat_objects:
    - field: file_path
      type: file_path
analytic_story:
    - Spearphishing Attachments
asset_type: Endpoint
mitre_attack_id:
    - T1187
    - T1557.001
    - T1021.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: tstats

| tstats `security_content_summariesonly`
  count min(_time) as firstTime
        max(_time) as lastTime

from datamodel=Endpoint.Filesystem where

Filesystem.file_path IN (
    "*\\Desktop\\*",
    "*\\Documents\\*",
    "*\\Downloads\\*",
    "*\\Temp\\*"
)
Filesystem.file_name="*.theme"
Filesystem.action="created"

by Filesystem.dest Filesystem.file_create_time Filesystem.process_path
   Filesystem.process_guid Filesystem.process_id Filesystem.file_path
   Filesystem.action Filesystem.file_name
   Filesystem.user Filesystem.vendor_product

Stage 2: search

| `drop_dm_object_name(Filesystem)`

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `windows_theme_file_creation_in_unusual_location_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
Filesystem.actioneq
  • created corpus 11 (splunk 11)
field:"event_action" kind:eq value:"created"
Filesystem.file_nameeq
  • *.theme
field:"file_name" kind:eq value:"*.theme"
Filesystem.file_pathin
  • *\Desktop\*
  • *\Documents\*
  • *\Downloads\*
  • *\Temp\* corpus 2 (splunk 2)
field:"TargetFilename" kind:in

Windows Wermgr Alternate Data Stream in Temp Dir

#
Status
production
Severity
low
Group by
Contents, dest, dvc, file_hash, file_name, process_guid, process_id, process_name, signature, signature_id, target_filename, user_id, vendor_product
Author
Teoderick Contreras, Splunk
Source
github.com/splunk/security_content

The following analytic detects the wermgr.exe process creating an alternate stream in the temp directory. It leverages Sysmon EventID 15 to identify these actions. This activity is significant because wermgr.exe is typically associated with error reporting, not file creation. Such activity is significant as it may indicate RoguePlanet malware, which creates an alternate stream in the temp directory to execute malicious code. If confirmed malicious, this could lead to further malware infections, data exfiltration, or system compromise.

Known False Positives

  • No false positives have been identified at this time.

MITRE ATT&CK Coverage

Telemetry Coverage

ProviderRecord / event type
SysmonEvent ID 15: FileCreateStreamHash

Rule Body

name: Windows Wermgr Alternate Data Stream in Temp Dir
id: 65222e9b-9d0b-4bfe-8da1-199b98e1d44a
version: 1
creation_date: '2026-06-11'
modification_date: '2026-06-11'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: |-
    The following analytic detects the wermgr.exe process creating an alternate stream in the temp directory. It leverages Sysmon EventID 15 to identify these actions.
    This activity is significant because wermgr.exe is typically associated with error reporting, not file creation. Such activity is significant as it may indicate RoguePlanet malware, which creates an alternate stream in the temp directory to execute malicious code.
    If confirmed malicious, this could lead to further malware infections, data exfiltration, or system compromise.
data_source:
    - Sysmon EventID 15
search: |-
    `sysmon`
    EventCode=15
    TargetFilename = "*\\Temp\\*"
    TargetFilename = "*\\wermgr.exe:*"

    | stats count min(_time) as firstTime
                  max(_time) as lastTime
    by dest dvc file_hash file_name file_path process_exec
       process_guid process_id process_name process_path
       signature signature_id user_id vendor_product Contents Image

    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_wermgr_alternate_data_stream_in_temp_dir_filter`
how_to_implement: |-
    To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of wermgr.exe may be used.
known_false_positives: |-
    No false positives have been identified at this time.
references:
    - https://github.com/MSNightmare/RoguePlanet/tree/main
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A [$process_name$] created a wermgr.exe alternate stream in the temp directory on $dest$ by $user$
analytic_story:
    - RoguePlanet
asset_type: Endpoint
mitre_attack_id:
    - T1564.004
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

Stages and Predicates

Stage 1: search

`sysmon`
EventCode=15
TargetFilename = "*\\Temp\\*"
TargetFilename = "*\\wermgr.exe:*"

Stage 2: stats

| stats count min(_time) as firstTime
              max(_time) as lastTime
by dest dvc file_hash file_name file_path process_exec
   process_guid process_id process_name process_path
   signature signature_id user_id vendor_product Contents Image

Stage 3: search

| `security_content_ctime(firstTime)`

Stage 4: search

| `security_content_ctime(lastTime)`

Stage 5: search

| `windows_wermgr_alternate_data_stream_in_temp_dir_filter`

Indicators

These rows show field, operator, and value matches.

FieldKindValuesSearch
EventCodeeq
  • 15 corpus 6 (splunk 6)
field:"EventID" kind:eq value:"15"
TargetFilenameeq
  • *\Temp\* corpus 5 (splunk 5)
  • *\wermgr.exe:*
field:"TargetFilename" kind:eq

Back to all Splunk rules