Splunk rules: 12

name: AWS Bedrock Delete GuardRails
id: 7a5e3d62-f743-11ee-9f6e-acde48001122
version: 7
creation_date: '2025-03-25'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: TTP
description: The following analytic identifies attempts to delete AWS Bedrock GuardRails, which are security controls designed to prevent harmful, biased, or inappropriate AI outputs. It leverages AWS CloudTrail logs to detect when a user or service calls the DeleteGuardrail API. This activity is significant as it may indicate an adversary attempting to remove safety guardrails after compromising credentials, potentially to enable harmful or malicious model outputs. Removing guardrails could allow attackers to extract sensitive information, generate offensive content, or bypass security controls designed to prevent prompt injection and other AI-specific attacks. If confirmed malicious, this could represent a deliberate attempt to manipulate model behavior for harmful purposes.
data_source:
    - AWS CloudTrail DeleteGuardrail
search: >-
    `cloudtrail` eventSource=bedrock.amazonaws.com eventName=DeleteGuardrail |
    rename user_name as user | stats count min(_time) as firstTime max(_time) as
    lastTime values(requestParameters.guardrailIdentifier) as guardrailIds by src
    user user_agent vendor_account vendor_product dest signature vendor_region |
    `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` |
    `aws_bedrock_delete_guardrails_filter`
how_to_implement: The Splunk AWS Add-on is required to utilize this data. The search requires AWS CloudTrail logs with Bedrock service events enabled. You must install and configure the AWS App for Splunk (version 6.0.0 or later) and Splunk Add-on for AWS (version 5.1.0 or later) to collect CloudTrail logs from AWS. Ensure the CloudTrail is capturing Bedrock GuardRails management events.
known_false_positives: Legitimate administrators may delete GuardRails as part of normal operations, such as when replacing outdated guardrails with updated versions, cleaning up test resources, or consolidating security controls. Consider implementing an allowlist for expected administrators who regularly manage GuardRails configurations.
references:
    - https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
    - https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html
    - https://attack.mitre.org/techniques/T1562/
finding:
    title: User $user$ deleted AWS Bedrock GuardRails $guardrailIds$ from $src$
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS Bedrock Security
asset_type: AWS Account
mitre_attack_id:
    - T1685.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: Azure AD Block User Consent For Risky Apps Disabled
id: 875de3d7-09bc-4916-8c0a-0929f4ced3d8
version: 13
creation_date: '2023-11-16'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. It monitors Azure Active Directory logs for the "Update authorization policy" operation, specifically changes to the "AllowUserConsentForRiskyApps" setting. This activity is significant because disabling this feature can expose the organization to OAuth phishing threats by allowing users to grant consent to potentially malicious applications. If confirmed malicious, attackers could gain unauthorized access to user data and sensitive information, leading to data breaches and further compromise within the organization.
data_source:
    - Azure Active Directory Update authorization policy
search: "`azure_monitor_aad` operationName=\"Update authorization policy\" | rename properties.* as * | eval index_number = if(mvfind('targetResources{}.modifiedProperties{}.displayName',\"AllowUserConsentForRiskyApps\") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName',\"AllowUserConsentForRiskyApps\"), -1) | search index_number >= 0 | eval AllowUserConsentForRiskyApps = mvindex('targetResources{}.modifiedProperties{}.newValue',index_number) | search AllowUserConsentForRiskyApps = \"[true]\" | rename userAgent as user_agent | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by dest user src vendor_account vendor_product user_agent signature | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_block_user_consent_for_risky_apps_disabled_filter`"
how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization
references:
    - https://attack.mitre.org/techniques/T1562/
    - https://goodworkaround.com/2020/10/19/a-look-behind-the-azure-ad-permission-classifications-preview/
    - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-risk-based-step-up-consent
    - https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth
finding:
    title: User $user$ disabled the BlockUserConsentForRiskyApps Azure AD setting.
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Azure Active Directory Account Takeover
asset_type: Azure Tenant
mitre_attack_id:
    - T1685
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: identity

name: Azure AD FullAccessAsApp Permission Assigned
id: ae286126-f2ad-421c-b240-4ea83bd1c43a
version: 10
creation_date: '2024-02-14'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects the assignment of the 'full_access_as_app' permission to an application within Office 365 Exchange Online. This is identified by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' and the ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. The detection leverages the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This activity is significant as it grants broad control over Office 365 operations, including full access to all mailboxes and the ability to send emails as any user. If malicious, this could lead to unauthorized access and data exfiltration.
data_source:
    - Azure Active Directory Update application
search: "`azure_monitor_aad` category=AuditLogs operationName=\"Update application\" | eval newvalue = mvindex('properties.targetResources{}.modifiedProperties{}.newValue',0) | spath input=newvalue | search \"{}.ResourceAppId\"=\"00000002-0000-0ff1-ce00-000000000000\" \"{}.RequiredAppPermissions{}.EntitlementId\"=\"dc890d15-9560-4a4c-9b7f-a736ec74ec40\" | eval Permissions = '{}.RequiredAppPermissions{}.EntitlementId' | rename properties.userAgent as user_agent | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by dest user src vendor_account vendor_product user_agent Permissions object signature | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_fullaccessasapp_permission_assigned_filter`"
how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
known_false_positives: The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed.
references:
    - https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/
    - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/
    - https://attack.mitre.org/techniques/T1098/002/
finding:
    title: User $user$ assigned the full_access_as_app permission to the app registration $object$
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Azure Active Directory Persistence
    - NOBELIUM Group
asset_type: Azure Active Directory
mitre_attack_id:
    - T1098.002
    - T1098.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

id: '36746.69167'
title: Certificate Enumeration - Windows
description: Threat actors may use tools such as Certipy or Certify.exe to enumerate
  misconfigurations in certificate services, allowing them to gather information on
  potential vulnerabilities that could be exploited for privilege escalation or lateral
  movement within a network. This use case identifies potential abuse of Active Directory
  Certificate Services by monitoring file access events (event ID 5145) related to
  certificate or certification authority data or process creation events (event ID
  4688) involving tools commonly used to enumerate or exploit vulnerable configurations
  in AD CS (e.g., Certipy or Certify).
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("certipy" OR "find" OR "vulnerable" OR "enrolleeSuppliesSubject" OR TERM(/ca))
  OR "certify.exe" | where match(process, "(?i)(certipy|find|vulnerable|enrolleeSuppliesSubject|/ca)\s")
  and !match(process_name, "(?i)find\.exe")) or match(process_name, "(?i)certify\.exe")
  | table _time, host, user user, process, process_*, parent_* | bin span=1s | stats
  values(*) as * by _time, host '
techniques:
- credential-access:steal or forge authentication certificates
technique_id: 
- T1649
data_category:
- Windows Sysmon
references:
- https://github.com/ly4k/Certipy
- https://www.kali.org/tools/certipy-ad/
- https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation

name: Cisco ASA - User Account Lockout Threshold Exceeded
id: 3e8f9c2a-6d4b-4a7e-9c5f-1b8d7e3a9f2c
version: 5
creation_date: '2025-11-21'
modification_date: '2026-05-13'
author: Nasreddine Bencherchali, Splunk
status: production
type: Anomaly
description: |
    This analytic detects user account lockouts on Cisco ASA devices resulting from excessive failed authentication attempts.
    Account lockouts may indicate brute force attacks, password spraying campaigns, credential stuffing attempts using compromised credentials from external breaches, or misconfigured automation attempting authentication with incorrect credentials. These activities represent attempts to gain unauthorized access to network infrastructure.
    The detection monitors for ASA message ID 113006, which is generated when a user account is locked out after exceeding the configured maximum number of failed authentication attempts, capturing the locked account name and the failure threshold that was exceeded.
    Investigate account lockouts for privileged or administrative accounts, multiple simultaneous lockouts affecting different accounts (suggesting password spraying), lockouts originating from unusual source IP addresses, lockouts during off-hours, or patterns suggesting automated attack tools.
data_source:
    - Cisco ASA Logs
search: |
    `cisco_asa`
    message_id IN (113006)
    | rex "locked out on exceeding '(?<attempts_count>\d+)' successive failed authentication attempts"
    | rex "User '(?<user>[^']+)' locked out"
    | eval failure_description="locked out on exceeding " . attempts_count . " successive failed authentication attempts"
    | fillnull
    | stats earliest(_time) as firstTime
            latest(_time) as lastTime
            values(message_id) as message_id
            values(failure_description) as failure_description
      by host user
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_asa___user_account_lockout_threshold_exceeded_filter`
how_to_implement: |
    This search requires Cisco ASA syslog data to be ingested into Splunk via the Cisco Security Cloud TA.
    To ensure this detection works effectively, configure your ASA and FTD devices to generate and forward message ID 113006.
    If your logging level is set to 'Informational' or higher, these messages should already be included, else we recommend setting an event list that keeps the severity level you are using and adds message ID 113006.
    You can find specific instructions on how to set this up here : https://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/63884-config-asa-00.html.
    You can also change the severity level of the above message id's to the syslog level you have currently enabled using the logging message syslog_id level severity_level command in global configuration mode. For more information, see Change the Severity Level of a Syslog Message : https://www.cisco.com/c/en/us/td/docs/security/asa/asa922/configuration/general/asa-922-general-config/monitor-syslog.html#ID-2121-000006da
known_false_positives: |
    Legitimate lockouts occur from forgotten passwords, typos, script misconfigurations, or connectivity issues. Verify against help desk tickets. Filter known accounts during business hours or establish baseline patterns.
references:
    - https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/asa-syslog/syslog-messages-101001-to-199021.html#con_4769446
intermediate_findings:
    entities:
        - field: host
          type: system
          score: 20
          message: User account $user$ was $failure_description$ on Cisco ASA host $host$.
        - field: user
          type: user
          score: 20
          message: User account $user$ was $failure_description$ on Cisco ASA host $host$.
analytic_story:
    - Suspicious Cisco Adaptive Security Appliance Activity
asset_type: Network
mitre_attack_id:
    - T1110.001
    - T1110.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: network

name: Cisco NVM - MSHTML or MSHTA Network Execution Without URL in CLI
id: f2a9df84-9b01-4a21-9e3a-7aa1a217f69e
version: 6
creation_date: '2025-07-01'
modification_date: '2026-07-14'
author: Nasreddine Bencherchali, Splunk
status: production
type: Anomaly
description: |
    This analytic detects suspicious use of 'mshta.exe' or 'rundll32.exe' invoking 'mshtml.dll'
    or the 'RunHTMLApplication' export without including a direct HTTP/HTTPS URL in the command line.
    This pattern could be associated with obfuscated script execution used by threat actors during
    initial access or payload staging. The absence of a visible URL may indicate attempts to evade static
    detections by embedding the URL via string concatenation, encoding (e.g., hex), or indirect script loaders
    like 'GetObject()'.
data_source:
    - Cisco Network Visibility Module Flow Data
search: |
    `cisco_network_visibility_module_flowdata`
    (
      (
        process_name = "mshta.exe"
        process_arguments IN ("*javascript*", "*vbscript*")
      )
      OR
      ( process_name = "rundll32.exe" AND
        process_arguments = "*mshtml*" AND
        process_arguments = "*RunHTMLApplication*"
      )
    )
    NOT process_arguments IN ("*http://*", "*https://*")
    | stats count min(_time) as firstTime max(_time) as lastTime
            values(parent_process_arguments) as parent_process_arguments
            values(process_arguments) as process_arguments
            values(parent_process_hash) as parent_process_hash
            values(process_hash) as process_hash
            values(module_name_list) as module_name_list
            values(module_hash_list) as module_hash_list
            values(dest_port) as dest_port
            values(aliul) as additional_logged_in_users_list
            values(dest_hostname) as dest_hostname
            by src dest parent_process_path parent_process_integrity_level process_path process_name process_integrity_level process_id transport
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | table
      parent_process_integrity_level parent_process_path parent_process_arguments parent_process_hash
      process_integrity_level process_path process_name process_arguments process_hash process_id
      additional_logged_in_users_list module_name_list module_hash_list
      src dest_hostname dest dest_port transport firstTime lastTime
    | `cisco_nvm___mshtml_or_mshta_network_execution_without_url_in_cli_filter`
how_to_implement: |
    This search requires Network Visibility Module logs, which includes the flow data sourcetype.
    This search uses an input macro named `cisco_network_visibility_module_flowdata`.
    We strongly recommend that you specify your environment-specific configurations
    (index, source, sourcetype, etc.) for Cisco Network Visibility Module 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 Endpoint Security Analytics (CESA) (https://splunkbase.splunk.com/app/4221).
known_false_positives: |
    False positives should be minimal as the presence of a network connection during such executions increases the likelihood of malicious behavior.
references:
    - https://attack.mitre.org/techniques/T1218/005/
    - https://redcanary.com/blog/mshta-attack-technique/
    - https://lolbas-project.github.io/lolbas/Binaries/Rundll32/
    - https://learn.microsoft.com/en-us/windows/win32/api/mshtml/nf-mshtml-mshtml_runhtmlapplication
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: The host $src$ executed $process_name$ with potential obfuscated logic and initiated a network connection to $dest_hostname$ / $dest$ over $dest_port$.
threat_objects:
    - field: process_name
      type: process_name
analytic_story:
    - Cisco Network Visibility Module Analytics
    - BlankGrabber Stealer
asset_type: Endpoint
mitre_attack_id:
    - T1218.005
    - T1059.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Detect Remote Access Software Usage URL
id: 9296f515-073c-43a5-88ec-eda5a4626654
version: 16
creation_date: '2024-03-06'
modification_date: '2026-05-13'
author: Steven Dick
status: production
type: Anomaly
description: |
    The following analytic detects the execution of known remote access software within the environment.
    It leverages network logs mapped to the Web data model, identifying specific URLs and user agents associated with remote access tools like AnyDesk, GoToMyPC, LogMeIn, and TeamViewer.
    This activity is significant as adversaries often use these utilities to maintain unauthorized remote access. If confirmed malicious, this could allow attackers to control systems remotely, exfiltrate data, or further compromise the network, posing a severe security risk.
data_source:
    - Palo Alto Network Threat
search: |
    | tstats `security_content_summariesonly`
             count min(_time) as firstTime
                   max(_time) as lastTime
                   latest(Web.http_method) as http_method
                   latest(Web.http_user_agent) as http_user_agent
                   latest(Web.url) as url
                   latest(Web.user) as user
                   latest(Web.dest) as dest

    from datamodel=Web where

    Web.url_domain=*
    NOT Web.url_domain IN (
        "-",
        "unknown"
    )
    by Web.action Web.src Web.category
       Web.url_domain Web.url_length

    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `drop_dm_object_name("Web")`
    | lookup remote_access_software remote_domain AS url_domain OUTPUT isutility, description as signature, comment_reference
    as desc, category
    | search isutility = True
    | `remote_access_software_usage_exceptions`
    | `detect_remote_access_software_usage_url_filter`
how_to_implement: |
    The detection is based on data that originates from network logs. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the network logs. The logs must also be mapped to the `Web` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process. The "exceptions" macro leverages both an Assets and Identities lookup, as well as a KVStore collection called "remote_software_exceptions" that lets you track and maintain device- based exceptions for this set of detections.
known_false_positives: |
    It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. Known false positives can be added to the remote_access_software_usage_exception.csv lookup to globally suppress these situations across all remote access content
references:
    - https://attack.mitre.org/techniques/T1219/
    - https://thedfirreport.com/2022/08/08/bumblebee-roasts-its-way-to-domain-admin/
    - https://thedfirreport.com/2022/11/28/emotet-strikes-again-lnk-file-leads-to-domain-wide-ransomware/
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: A domain for a known remote access software $url_domain$ was contacted by $src$.
        - field: user
          type: user
          score: 20
          message: A domain for a known remote access software $url_domain$ was contacted by $src$.
threat_objects:
    - field: signature
      type: signature
    - field: url_domain
      type: domain
analytic_story:
    - Insider Threat
    - Command And Control
    - Ransomware
    - CISA AA24-241A
    - Remote Monitoring and Management Software
    - Interlock Ransomware
    - Scattered Lapsus$ Hunters
asset_type: Network
mitre_attack_id:
    - T1219
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: web
security_domain: network

id: '25100.46547'
title: Event Logs Queried for RDP Sessions
description: 'Threat actors may query Windows Terminal Services logs for RDP session
  information. - Example 1: During post-compromise reconnaissance activities, Lazarus
  was observed using wevtutil to query Windows Terminal Services logs for RDP sessions
  (Event Code 25) in order to gather session reconnection information. - Example 2:
  Threat actor tracked as Cluster Charlie (STAC1305) searched Windows Event Logs for
  Windows Remote Connection Manager event ID 1149 -- This use case detects commands
  querying Terminal Services logs for event 25 for user disconnection or event 1149
  for records of successful Remote Desktop Services (RDP) logon attempt. While threat
  actors will most likely be using wevtutil to perform the queries, it has been omitted
  from the logic to account for instances where it has been renamed. -- Threat Actor
  Association: Cluster Charlie (STAC1305), Lazarus'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("qe" OR "Query-Event") "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational"
  ("EventID=25" OR "EventID=1149") | table _time, host, user, process, process_*,
  user, parent_process_name, parent_process_path | bin span=1s | stats values(*) as
  * by _time, host '
techniques:
- discovery:system information discovery
technique_id: 
- T1082
data_category:
- Windows Sysmon
references:
- https://blog.talosintelligence.com/lazarus_new_rats_dlang_and_telegram/
- https://news.sophos.com/en-us/2024/09/10/crimson-palace-new-tools-tactics-targets/

name: GitHub Enterprise Disable Dependabot
id: 787dd1c1-eb3a-4a31-8e8c-2ad24b214bc8
version: 8
creation_date: '2025-01-15'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic detects when a user disables Dependabot security features within a GitHub repository. Dependabot helps automatically identify and fix security vulnerabilities in dependencies. The detection monitors GitHub Enterprise logs for configuration changes that disable Dependabot functionality. This behavior could indicate an attacker attempting to prevent the automatic detection of vulnerable dependencies, which would allow them to exploit known vulnerabilities that would otherwise be patched. For a SOC, identifying the disabling of security features like Dependabot is critical as it may be a precursor to supply chain attacks where attackers exploit vulnerable dependencies. The impact could be severe if vulnerabilities remain unpatched, potentially leading to code execution, data theft, or other compromises through the software supply chain.
data_source:
    - GitHub Enterprise Audit Logs
search: |-
    `github_enterprise` action=repository_vulnerability_alerts.disable
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor, actor_id, actor_ip,
           actor_is_bot, actor_location.country_code, business,
           business_id, org, org_id,
           repo, repo_id, user,
           user_agent, user_id, action
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `github_enterprise_disable_dependabot_filter`
how_to_implement: You must ingest GitHub Enterprise logs using Audit log streaming as described in this documentation https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-streaming-to-splunk using a Splunk HTTP Event Collector.
known_false_positives: No false positives have been identified at this time.
references:
    - https://www.googlecloudcommunity.com/gc/Community-Blog/Monitoring-for-Suspicious-GitHub-Activity-with-Google-Security/ba-p/763610
    - https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-streaming-to-splunk
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Dependabot security features are disabled in repository $repo$ by $user$
threat_objects:
    - field: user_agent
      type: http_user_agent
analytic_story:
    - GitHub Malicious Activity
asset_type: GitHub
mitre_attack_id:
    - T1685
    - T1195
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

name: Linux Auditd Possible Append Cronjob Entry On Existing Cronjob File
id: fea71cf0-fa10-4ef6-9202-9682b2e0c477
version: 10
creation_date: '2024-08-12'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Hunting
description: |
    The following analytic detects potential tampering with cronjob files on a Linux system.
    It leverages logs from Linux Auditd, focusing on events of type PATH or CWD.
    This activity could be significant because adversaries often use it for persistence or privilege escalation.
    Correlate this with related EXECVE or PROCTITLE events to identify the process or user responsible for the access or modification.
    If confirmed malicious, this could allow attackers to execute unauthorized code automatically, leading to system compromises and unauthorized data access, thereby impacting business operations and data integrity.
data_source:
    - Linux Auditd Path
    - Linux Auditd Cwd
search: |
    `linux_auditd` (type=PATH OR type=CWD)
    | rex "msg=audit\([^)]*:(?<audit_id>\d+)\)"

    | stats
      values(type) as types
      values(name) as names
      values(nametype) as nametype
      values(cwd) as cwd_list
      values(_time) as event_times
      by audit_id, host

    | eval current_working_directory = coalesce(mvindex(cwd_list, 0), "N/A")
    | eval candidate_paths = mvmap(names, if(match(names, "^/"), names, current_working_directory + "/" + names))
    | eval matched_paths = mvfilter(match(candidate_paths, "/etc/cron.*|.*/cron/.*|/etc/anacrontab.*"))
    | eval match_count = mvcount(matched_paths)
    | eval reconstructed_path = mvindex(matched_paths, 0)
    | eval e_time = mvindex(event_times, 0)
    | where match_count > 0
    | rename host as dest

    | stats count min(e_time) as firstTime max(e_time) as lastTime
      values(nametype) as nametype
      by current_working_directory
         reconstructed_path
         match_count
         dest
         audit_id

    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `linux_auditd_possible_append_cronjob_entry_on_existing_cronjob_file_filter`
how_to_implement: |
    To implement this detection, the process begins by ingesting auditd
    data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
    executions and process details on Unix/Linux systems. These logs should be ingested
    and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
    which is essential for correctly parsing and categorizing the data. The next step
    involves normalizing the field names  to match the field names set by the Splunk
    Common Information Model (CIM) to ensure consistency across different data sources
    and enhance the efficiency of data modeling and make sure the type=CWD record type is activate in your auditd configuration.
    This approach enables effective monitoring and detection of linux endpoints where auditd is deployed.
known_false_positives: |
    False positives may arise from legitimate actions by administrators or network operators who may use these commands for automation purposes.
    Therefore, it's recommended to adjust filter macros to eliminate such false positives.
references:
    - https://attack.mitre.org/techniques/T1053/003/
    - https://blog.aquasec.com/threat-alert-kinsing-malware-container-vulnerability
    - https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/
analytic_story:
    - XorDDos
    - Linux Living Off The Land
    - Compromised Linux Host
    - Linux Privilege Escalation
    - Scheduled Tasks
    - Linux Persistence Techniques
asset_type: Endpoint
mitre_attack_id:
    - T1053.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Linux Auditd Sysmon Service Stop
id: 20901256-633a-40de-8753-7b88811a460f
version: 10
creation_date: '2024-08-12'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects the suspicious sysmon service stop. This behavior is critical for a SOC to monitor because it may indicate attempts to gain unauthorized access or maintain control over a system. Such actions could be signs of malicious activity. If confirmed, this could lead to serious consequences, including a compromised system, unauthorized access to sensitive data, or even a wider breach affecting the entire network. Detecting and responding to these signs early is essential to prevent potential security incidents.
data_source:
    - Linux Auditd Service Stop
search: |-
    `linux_auditd` type=SERVICE_STOP unit IN ("sysmon")
      | rename host as dest
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY type pid comm
           exe unit dest
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `linux_auditd_sysmon_service_stop_filter`
how_to_implement: To implement this detection, the process begins by ingesting auditd data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line executions and process details on Unix/Linux systems. These logs should be ingested and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833), which is essential for correctly parsing and categorizing the data. The next step involves normalizing the field names  to match the field names set by the Splunk Common Information Model (CIM) to ensure consistency across different data sources and enhance the efficiency of data modeling. This approach enables effective monitoring and detection of linux endpoints where auditd is deployed
known_false_positives: Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
references:
    - https://www.splunk.com/en_us/blog/security/deep-dive-on-persistence-privilege-escalation-technique-and-detection-in-linux-platform.html
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A service event - [$type$] event occurred on host - [$dest$] to stop or disable the sysmon service.
analytic_story:
    - Linux Living Off The Land
    - Linux Privilege Escalation
    - Linux Persistence Techniques
    - Compromised Linux Host
asset_type: Endpoint
mitre_attack_id:
    - T1489
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Linux Indicator Removal Service File Deletion
id: 6c077f81-2a83-4537-afbc-0e62e3215d55
version: 11
creation_date: '2023-02-08'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects the deletion of Linux service unit configuration files by suspicious processes. It leverages Endpoint Detection and Response (EDR) telemetry, focusing on processes executing the 'rm' command targeting '.service' files. This activity is significant as it may indicate malware attempting to disable critical services or security products, a common defense evasion tactic. If confirmed malicious, this behavior could lead to service disruption, security tool incapacitation, or complete system compromise, severely impacting the integrity and availability of the affected Linux host.
data_source:
    - Sysmon for Linux EventID 1
search: |-
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes
      WHERE Processes.process_name = "rm"
        AND
        Processes.process = "*rm *"
        AND
        Processes.process = "*.service"
      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)`
    | `linux_indicator_removal_service_file_deletion_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: network admin can delete services unit configuration file as part of normal software installation. Filter is needed.
references:
    - https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/overview-of-the-cyber-weapons-used-in-the-ukraine-russia-war/
    - https://cert.gov.ua/article/3718487
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: a $process_name$ has a commandline $process$ to delete service configuration file on $dest$
        - field: user
          type: user
          score: 20
          message: a $process_name$ has a commandline $process$ to delete service configuration file on $dest$
analytic_story:
    - AwfulShred
    - Data Destruction
asset_type: Endpoint
mitre_attack_id:
    - T1070.004
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Living Off The Land Detection
id: 1be30d80-3a39-4df9-9102-64a467b24abc
version: 12
creation_date: '2022-07-13'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Correlation
description: The following correlation identifies multiple risk events associated with the "Living Off The Land" analytic story, indicating potentially suspicious behavior. It leverages the Risk data model to aggregate and correlate events tagged under this story, focusing on systems with a high count of distinct sources. This activity is significant as it often involves the use of legitimate tools for malicious purposes, making detection challenging. If confirmed malicious, this behavior could allow attackers to execute code, escalate privileges, or persist within the environment using trusted system utilities.
data_source: []
search: |-
    | tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime sum(All_Risk.calculated_risk_score) as risk_score, count(All_Risk.calculated_risk_score) as risk_event_count, values(All_Risk.annotations.mitre_attack.mitre_tactic_id) as annotations.mitre_attack.mitre_tactic_id, dc(All_Risk.annotations.mitre_attack.mitre_tactic_id) as mitre_tactic_id_count, values(All_Risk.annotations.mitre_attack.mitre_technique_id) as annotations.mitre_attack.mitre_technique_id, dc(All_Risk.annotations.mitre_attack.mitre_technique_id) as mitre_technique_id_count, values(All_Risk.tag) as tag, values(source) as source, dc(source) as source_count FROM datamodel=Risk.All_Risk
      WHERE All_Risk.analyticstories="Living Off The Land" All_Risk.risk_object_type="system"
      BY All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic
    | `drop_dm_object_name(All_Risk)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | where source_count >= 5
    | `living_off_the_land_detection_filter`
how_to_implement: To implement this correlation search a user needs to enable all detections in the Living Off The Land Analytic Story and confirm it is generating risk events. A simple search `index=risk analyticstories="Living Off The Land"` should contain events.
known_false_positives: There are no known false positive for this search, but it could contain false positives as multiple detections can trigger and not have successful exploitation. Modify the static value distinct_detection_name to a higher value. It is also required to tune analytics that are also tagged to ensure volume is never too much.
references:
    - https://www.splunk.com/en_us/blog/security/living-off-the-land-threat-research-february-2022-release.html
    - https://research.splunk.com/stories/living_off_the_land/
finding:
    title: Living Off The Land Behavior detected - $risk_object$
    entity:
        field: risk_object
        type: system
        score: 0
analytic_story:
    - Living Off The Land
    - Hellcat Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1105
    - T1190
    - T1059
    - T1133
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: O365 Mailbox Email Forwarding Enabled
id: 0b6bc75c-05d1-4101-9fc3-97e706168f24
version: 10
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Patrick Bareiss, Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies instances where email forwarding has been enabled on mailboxes within an Office 365 environment. It detects this activity by monitoring the Set-Mailbox operation within the o365_management_activity logs, specifically looking for changes to the ForwardingAddress or ForwardingSmtpAddress parameters. This activity is significant as unauthorized email forwarding can lead to data exfiltration and unauthorized access to sensitive information. If confirmed malicious, attackers could intercept and redirect emails, potentially compromising confidential communications and leading to data breaches.
data_source: []
search: "`o365_management_activity` Operation=Set-Mailbox | eval match1=mvfind('Parameters{}.Name',\"ForwardingAddress\") | eval match2=mvfind('Parameters{}.Name', \"ForwardingSmtpAddress\") | where match1>= 0 OR match2>= 0 | eval ForwardTo=coalesce(ForwardingAddress,ForwardingSmtpAddress) | search ForwardTo!=\"\" | rename user_id as user | stats count earliest(_time) as firstTime latest(_time) as lastTime values(ForwardTo) as ForwardTo by signature dest user src vendor_account vendor_product object ObjectId | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_mailbox_email_forwarding_enabled_filter`"
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
known_false_positives: Email forwarding may be configured for legitimate purposes, filter as needed.
references:
    - https://attack.mitre.org/techniques/T1114/003/
    - https://learn.microsoft.com/en-us/exchange/recipients/user-mailboxes/email-forwarding?view=exchserver-2019
finding:
    title: Email forwarding configured by $user$ on mailbox $ObjectId$
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Office 365 Collection Techniques
asset_type: O365 Tenant
mitre_attack_id:
    - T1114.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: O365 Tenant Wide Admin Consent Granted
id: 50eaabf8-5180-4e86-bfb2-011472c359fc
version: 10
creation_date: '2023-12-06'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. This activity is significant because admin consent allows applications to access data across the entire tenant, potentially exposing vast amounts of organizational data. If confirmed malicious, an attacker could gain extensive and persistent access to organizational data, leading to data exfiltration, espionage, further malicious activities, and potential compliance violations.
data_source:
    - O365 Consent to application.
search: "`o365_management_activity` Operation=\"Consent to application.\" | eval new_field=mvindex('ModifiedProperties{}.NewValue', 4) | rex field=new_field \"ConsentType: (?<ConsentType>[^\\,]+)\" | rex field=new_field \"Scope: (?<Scope>[^\\,]+)\" | search ConsentType = \"AllPrincipals\" | fillnull | stats count min(_time) as firstTime max(_time) as lastTime by user, object, ObjectId, ConsentType, Scope, dest, vendor_account, vendor_product, signature, src | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `o365_tenant_wide_admin_consent_granted_filter`"
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
known_false_positives: Legitimate applications may be granted tenant wide consent, filter as needed.
references:
    - https://attack.mitre.org/techniques/T1098/003/
    - https://www.mandiant.com/resources/blog/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452
    - https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent
    - https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=portal
    - https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/
finding:
    title: The $object$ application registration was granted tenant wide admin consent.
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Office 365 Persistence Mechanisms
    - NOBELIUM Group
asset_type: O365 Tenant
mitre_attack_id:
    - T1098.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: identity

name: Okta Multiple Accounts Locked Out
id: a511426e-184f-4de6-8711-cfd2af29d1e1
version: 10
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Michael Haag, Mauricio Velazco, Splunk
status: production
type: Anomaly
description: The following analytic detects multiple Okta accounts being locked out within a short period. It uses the user.account.lock event from Okta logs, aggregated over a 5-minute window, to identify this behavior. This activity is significant as it may indicate a brute force or password spraying attack, where an adversary attempts to guess passwords, leading to account lockouts. If confirmed malicious, this could result in potential account takeovers or unauthorized access to sensitive Okta accounts, posing a significant security risk.
data_source:
    - Okta
search: |-
    | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime values(All_Changes.user) as user FROM datamodel=Change
      WHERE All_Changes.change_type=AAA All_Changes.object_category=User
        AND
        All_Changes.action=lockout
        AND
        All_Changes.command=user.account.lock
      BY _time span=5m All_Changes.result
         All_Changes.command sourcetype All_Changes.src
         All_Changes.dest
    | where count > 5
    | `drop_dm_object_name("All_Changes")`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `okta_multiple_accounts_locked_out_filter`
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Multiple account lockouts may be also triggered by an application malfunction. Filter as needed, and monitor for any unusual activity.
references:
    - https://attack.mitre.org/techniques/T1110/
    - https://splunkbase.splunk.com/app/6553
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Multiple accounts locked out in Okta from [$src$]. Investigate further to determine if this was authorized.
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - Okta Account Takeover
asset_type: Okta Tenant
mitre_attack_id:
    - T1110
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: identity

name: Powershell Load Module in Meterpreter
id: d5905da5-d050-48db-9259-018d8f034fcf
version: 12
creation_date: '2022-11-22'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic detects the execution of suspicious PowerShell commands associated with Meterpreter modules, such as "MSF.Powershell" and "MSF.Powershell.Meterpreter". It leverages PowerShell Script Block Logging (EventCode=4104) to capture and analyze the full command sent to PowerShell. This activity is significant as it indicates potential post-exploitation actions, including credential dumping and persistence mechanisms. If confirmed malicious, an attacker could gain extensive control over the compromised system, escalate privileges, and maintain long-term access, posing a severe threat to the environment.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell` EventCode=4104 ScriptBlockText IN ("*MSF.Powershell*","*MSF.Powershell.Meterpreter*","*MSF.Powershell.Meterpreter.Kiwi*","*MSF.Powershell.Meterpreter.Transport*")
      | 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)`
      | `powershell_load_module_in_meterpreter_filter`
how_to_implement: The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
known_false_positives: False positives should be very limited as this is strict to MetaSploit behavior.
references:
    - https://github.com/OJ/metasploit-payloads/blob/master/powershell/MSF.Powershell/Scripts.cs
finding:
    title: PowerShell was identified running a script utilized by Meterpreter from MetaSploit on endpoint $dest$ by user $user_id$.
    entity:
        field: user_id
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: PowerShell was identified running a script utilized by Meterpreter from MetaSploit on endpoint $dest$ by user $user_id$.
analytic_story:
    - MetaSploit
asset_type: Endpoint
mitre_attack_id:
    - T1059.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '5529.5745'
title: SharpHound Enumeration
description: 'Sharphound can be used to collect Active Directory information in order
  to easily identify highly complex attack paths that would otherwise be impossible
  to quickly identify. Once collected information can be utilized by BloodHound to
  apply graph theory in order to reveal the hidden and often unintended relationships
  within an Active Directory environment. -- Threat Actor Association: APT29/Nobelium/Cozy
  Bear, BlackMatter, DarkSide, FIN12, Muddled Libra, UNC2465, Wizard Spider - Software
  Association: ALPHV/BlackCat, Bazar, Black Basta, Conti, LockBit, Play, Qakbot/Qbot,
  Sodinokibi/REvil, XingLocker -- #TrendingThreat #Russia #Ukraine -- Atomics T1059.001
  Test #2 Atomics T1059.001 Test #3'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4799) OR
  "<EventID>4799<") ((TERM(Remote) (TERM(Management) OR TERM(Desktop)) TERM(Users))
  OR TERM(Administrators) OR (TERM(Distributed) TERM(COM) TERM(Users))) | table _time,
  host, user process, process_*, parent_process_*, signature_id, user_group | bin
  span=5s | stats values(*) as * by _time, host | eventstats dc(user_group) as dc_user_group
  by host, user, _time | eventstats c(process_name) as c_process_name by process_name
  |where dc_user_group=4 or c_process_name < 10 '
techniques:
- discovery:account discovery:domain account
- discovery:permission groups discovery:domain groups
- discovery:account discovery:local account
- discovery:system information discovery
- execution:command and scripting interpreter:windows command shell
- discovery:domain trust discovery
- discovery:password policy discovery
- discovery:permission groups discovery:local groups
technique_id:
- T1087.002
- T1069.002
- T1087.001
- T1082
- T1059.003
- T1482
- T1201
- T1069.001
data_category:
- Windows event logs
references:
- https://medium.com/securonix-tech-blog/detecting-ldap-enumeration-and-bloodhound-s-sharphound-collector-using-active-directory-decoys-dfc840f2f644

name: Windows EDRSilencer Execution
id: a206324d-4945-4b0c-a731-87c311ddae2f
version: 3
creation_date: '2026-05-05'
modification_date: '2026-06-13'
author: Raven Tait, Splunk
status: production
type: Anomaly
description: |-
    Detects the usage of EDRSilencer.
    Inspired by the closed-source FireBlock tool from MdSec NightHawk, this custom tool was developed to block outbound traffic of running Endpoint Detection and Response (EDR) processes using Windows Filtering Platform (WFP) APIs.
    Its features include searching for running EDR processes and applying WFP filters to block outbound traffic, adding filters for specific processes, and removing filters either individually or globally.
    The tool includes a custom implementation to avoid file handle access issues with EDR processes by bypassing the CreateFileW API.
    It supports a wide range of EDRs, including Microsoft Defender, Carbon Black, SentinelOne, and more, though further testing on various EDRs is recommended.
    The tool has been tested on Windows 10 and Windows Server 2016, and its usage involves simple commands for blocking or unblocking traffic.
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="EDRSilencer.exe"
    OR
    (
        Processes.process IN ("* blockedr", "* blockedr *")
        NOT Processes.process="*blockedreport*"
    )

    by Processes.process Processes.vendor_product Processes.user_id Processes.process_hash
       Processes.parent_process_name Processes.parent_process_exec Processes.action
       Processes.dest Processes.process_current_directory Processes.process_path
       Processes.process_integrity_level Processes.original_file_name Processes.parent_process
       Processes.parent_process_path Processes.parent_process_guid Processes.parent_process_id
       Processes.process_guid Processes.process_id Processes.user Processes.process_name

    | `drop_dm_object_name(Processes)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_edrsilencer_execution_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, parent process, and 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 tools or security workflows may use similar techniques to block or filter EDR traffic for maintenance or troubleshooting. Verify the context and authorized use before flagging.
references:
    - https://github.com/netero1010/EDRSilencer
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: Potential EDRSilencer execution [$process_path$] with the CommandLine [$process$] observed on $dest$.
threat_objects:
    - field: parent_process_name
      type: parent_process_name
    - field: process_name
      type: process_name
analytic_story:
    - Security Solution Tampering
asset_type: Endpoint
mitre_attack_id:
    - T1685
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Windows Forest Discovery with GetForestDomain
id: a14803b2-4bd9-4c08-8b57-c37980edebe8
version: 11
creation_date: '2023-09-01'
modification_date: '2026-05-13'
author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects the execution of the `Get-ForestDomain` cmdlet, a component of the PowerView toolkit used for Windows domain enumeration. It leverages PowerShell Script Block Logging (EventCode=4104) to identify this activity. Detecting `Get-ForestDomain` is significant because adversaries and Red Teams use it to gather detailed information about Active Directory forest and domain configurations. If confirmed malicious, this activity could enable attackers to understand the domain structure, facilitating lateral movement or privilege escalation within the environment.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell` EventCode=4104 ScriptBlockText = "*Get-ForestDomain*"
      | 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_forest_discovery_with_getforestdomain_filter`
how_to_implement: The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
known_false_positives: Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed.
references:
    - https://powersploit.readthedocs.io/en/latest/Recon/Get-ForestDomain/
    - https://attack.mitre.org/techniques/T1087/002/
    - https://book.hacktricks.xyz/windows-hardening/basic-powershell-for-pentesters/powerview
finding:
    title: Suspicious PowerShell Get-ForestDomain was identified on endpoint $dest$ by user $user_id$.
    entity:
        field: user_id
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: Suspicious PowerShell Get-ForestDomain was identified on endpoint $dest$ by user $user_id$.
analytic_story:
    - Active Directory Discovery
asset_type: Endpoint
mitre_attack_id:
    - T1087.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint