Splunk rules: 04

name: ASL AWS Defense Evasion Update Cloudtrail
id: f3eb471c-16d0-404d-897c-7653f0a78cba
version: 12
creation_date: '2024-05-22'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects `UpdateTrail` events within AWS CloudTrail logs, aiming to identify attempts by attackers to evade detection by altering logging configurations. By updating CloudTrail settings with incorrect parameters, such as changing multi-regional logging to a single region, attackers can impair the logging of their activities across other regions. This behavior is crucial for Security Operations Centers (SOCs) to identify, as it indicates an adversary's intent to operate undetected within a compromised AWS environment. The impact of such evasion tactics is significant, potentially allowing malicious activities to proceed without being logged, thereby hindering incident response and forensic investigations.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` api.operation=UpdateTrail
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor.user.uid api.operation api.service.name
           http_request.user_agent src_endpoint.ip actor.user.account.uid
           cloud.provider cloud.region
      | rename actor.user.uid as user api.operation as action api.service.name as dest http_request.user_agent as user_agent src_endpoint.ip as src actor.user.account.uid as vendor_account cloud.provider as vendor_product cloud.region as vendor_region
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `asl_aws_defense_evasion_update_cloudtrail_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: While this search has no known false positives, it is possible that an AWS admin has updated cloudtrail logging. Please investigate this activity.
references:
    - https://attack.mitre.org/techniques/T1562/008/
finding:
    title: User $user$ has updated a cloudtrail logging for account id $vendor_account$ from IP $src$
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS Defense Evasion
asset_type: AWS Account
mitre_attack_id:
    - T1685.002
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: ASL AWS Network Access Control List Deleted
id: e010ddf5-e9a5-44e5-bdd6-0c919ba8fc8b
version: 10
creation_date: '2022-10-04'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic detects the deletion of AWS Network Access Control Lists (ACLs). It leverages AWS CloudTrail logs to identify events where a user deletes a network ACL entry. This activity is significant because deleting a network ACL can remove critical access restrictions, potentially allowing unauthorized access to cloud instances. If confirmed malicious, this action could enable attackers to bypass network security controls, leading to unauthorized access, data exfiltration, or further compromise of the cloud environment.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` api.operation=DeleteNetworkAclEntry status=Success
      | spath input=api.request.data path=egress output=egress
      | spath input=api.request.data path=networkAclId output=networkAclId
      | search egress=false
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor.user.uid api.operation api.service.name
           http_request.user_agent src_endpoint.ip actor.user.account.uid
           cloud.provider cloud.region networkAclId
      | 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_network_access_control_list_deleted_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: It's possible that a user has legitimately deleted a network ACL.
references: []
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: User $user$ from $src$ has sucessfully deleted network ACLs entry.
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - AWS Network ACL Activity
    - Scattered Lapsus$ Hunters
asset_type: AWS Instance
mitre_attack_id:
    - T1686.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

name: ASL AWS SAML Update identity provider
id: 635c26cc-0fd1-4098-8ec9-824bf9544b11
version: 7
creation_date: '2022-10-04'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects updates to the SAML provider in AWS. It leverages AWS CloudTrail logs to identify the `UpdateSAMLProvider` event, analyzing fields such as `sAMLProviderArn`, `sourceIPAddress`, and `userIdentity` details. Monitoring updates to the SAML provider is crucial as it may indicate a perimeter compromise of federated credentials or unauthorized backdoor access set by an attacker. If confirmed malicious, this activity could allow attackers to manipulate identity federation, potentially leading to unauthorized access to cloud resources and sensitive data.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` api.operation=UpdateSAMLProvider
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor.user.uid api.operation api.service.name
           http_request.user_agent src_endpoint.ip actor.user.account.uid
           cloud.provider cloud.region
      | rename actor.user.uid as user api.operation as action api.service.name as dest http_request.user_agent as user_agent src_endpoint.ip as src actor.user.account.uid as vendor_account cloud.provider as vendor_product cloud.region as vendor_region
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `asl_aws_saml_update_identity_provider_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: Updating a SAML provider or creating a new one may not necessarily be malicious however it needs to be closely monitored.
references:
    - https://www.cisa.gov/uscert/ncas/alerts/aa21-008a
    - https://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html
    - https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/wp-m-unc2452-2021-000343-01.pdf
    - https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
finding:
    title: User $user$ from IP address $src$ updated the SAML provider
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - Cloud Federated Credential Abuse
asset_type: AWS Federated Account
mitre_attack_id:
    - T1078
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: Cisco Duo Admin Login Unusual Os
id: c4824cc6-d644-458e-a39a-67cd67da75e3
version: 6
creation_date: '2025-07-10'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic identifies Duo admin login attempts from operating systems that are unusual for your environment, excluding commonly used OS such as Mac OS X. Please adjust to your environment. It works by analyzing Duo activity logs for admin login actions and filtering out logins from expected operating systems. The analytic then aggregates events by browser, version, source IP, location, and OS details to highlight anomalies. Detecting admin logins from unexpected operating systems is critical for a SOC, as it may indicate credential compromise, unauthorized access, or attacker activity using unfamiliar devices. Such behavior can precede privilege escalation, policy changes, or other malicious actions within the Duo environment. Early detection enables rapid investigation and response, reducing the risk of account takeover and minimizing potential damage to organizational security controls.
data_source:
    - Cisco Duo Activity
search: |-
    `cisco_duo_activity` "action.name"=admin_login NOT access_device.os IN ("Mac OS X")
      | rename actor.name as user access_device.ip.address as src_ip
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY access_device.browser access_device.browser_version src_ip
           access_device.location.city access_device.location.country access_device.location.state
           access_device.os access_device.os_version actor.details
           actor.type outcome.result user
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `cisco_duo_admin_login_unusual_os_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 user $user$ has logged in using an unusual OS $access_device.os$ using browser $access_device.browser$ from $src_ip$.
    entity:
        field: user
        type: user
        score: 50
threat_objects:
    - field: access_device.browser
      type: http_user_agent
    - field: src_ip
      type: ip_address
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

name: Cisco Secure Firewall - Rare Snort Rule Triggered
id: e20313d2-7d63-4fcf-b2d9-d6e12c6c7bd7
version: 6
creation_date: '2025-04-16'
modification_date: '2026-05-13'
author: Nasreddine Bencherchali, Splunk
status: production
type: Hunting
description: |
    This analytic identifies Snort signatures that have triggered only once in the past 7 days across all Cisco Secure Firewall IntrusionEvent logs. While these rules typically do not trigger in day-to-day network activity, their sudden appearance may indicate early-stage compromise, previously unseen malware, or reconnaissance activity against less commonly exposed services. Investigating these outliers can provide valuable insight into new or low-noise adversary behaviors.
data_source:
    - Cisco Secure Firewall Threat Defense Intrusion Event
search: |
    `cisco_secure_firewall` EventType=IntrusionEvent earliest=-7d
    | stats dc(_time) as TriggerCount min(_time) as firstTime max(_time) as lastTime
            values(signature) as signature
            values(src) as src
            values(dest) as dest
            values(dest_port) as dest_port
            values(transport) as transport
            values(app) as app
            values(rule) as rule
            by signature_id class_desc MitreAttackGroups InlineResult InlineResultReason
    | where TriggerCount = 1
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_secure_firewall___rare_snort_rule_triggered_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 may occur with certain rare activity. Apply additional filters where required.
references:
    - https://www.cisco.com/c/en/us/td/docs/security/firepower/741/api/FQE/secure_firewall_estreamer_fqe_guide_740.pdf
analytic_story:
    - Cisco Secure Firewall Threat Defense Analytics
asset_type: Network
mitre_attack_id:
    - T1598
    - T1583.006
product:
    - Splunk Enterprise
    - Splunk Cloud
    - Splunk Enterprise Security
category: network
security_domain: network

id: '31193.55843'
title: ConsentPromptBehaviorAdmin Registry Value Modified
description: 'Adversaries may bypass UAC mechanisms to elevate process privileges
  on system. Windows User Account Control (UAC) allows a program to elevate its privileges
  (tracked as integrity levels ranging from low to high) to perform a task under administrator-level
  permissions, possibly by prompting the user for confirmation. The impact to the
  user ranges from denying the operation under high enforcement to allowing the user
  to perform the action if they are in the local administrators group and click through
  the prompt or allowing them to enter an administrator password to complete the action.
  This use case detects registry modification events or process executions with registry
  modification commands targeting \Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin.
  -- Software Association: 8Base'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_powershell` (TERM(EventCode=4103) OR
  "<EventID>4103<" OR TERM(EventCode=4104) OR "<EventID>4104<") ("Set-Item-Property"
  OR "sp " OR "ADD") "ConsentPromptBehaviorAdmin" "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System"
  | table _time, host, user, process | bin span=1s | stats values(*) as * by _time,
  host '
techniques:
- privilege-escalation:abuse elevation control mechanism:bypass user account control
technique_id:
- T1548.002
data_category:
- PowerShell logs
references:
- https://attack.mitre.org/techniques/T1548/002/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1548.002/T1548.002.md#atomic-test-22---disable-uac-admin-consent-prompt-via-consentpromptbehavioradmin-registry-key
- https://www.trendmicro.com/vinfo/us/security/news/ransomware-spotlight/ransomware-spotlight-8base?utm_source=trendmicroresearch&utm_medium=smk&utm_campaign=0424_8base

id: '6583.7596'
title: Dxcap Proxy Execution
description: DXCap.exe is a command-line tool for graphics diagnostics capture and
  playback. It supports Direct3D 10 through Direct3D 12 across all feature levels.
  Local execution of a process as a subprocess of Dxcap.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) "dxcap" | table _time, host, user user, process,
  process_*, parent_* | bin span=1s | stats values(*) as * by _time, host | where
  match(parent_process_name, "(?i)dxcap") OR match(process, "(?i)dxcap.+?\-c") '
techniques:
- defense-evasion:system binary proxy execution
technique_id: 
- T1218
data_category:
- Windows event logs
references:
- https://lolbas-project.github.io/lolbas/OtherMSBinaries/Dxcap/

name: ESXi Shell Access Enabled
id: 15e79d0a-c659-42fd-9668-94108528f2ec
version: 4
creation_date: '2025-07-11'
modification_date: '2026-05-13'
author: Raven Tait, Splunk
status: production
type: TTP
description: This detection identifies when the ESXi Shell is enabled on a host, which may indicate that a malicious actor is preparing to execute commands locally or establish persistent access. Enabling the shell outside of approved maintenance windows can be a sign of compromise or unauthorized administrative activity.
data_source:
    - VMWare ESXi Syslog
search: '`esxi_syslog` Message="*ESXi Shell*" Message="*has been enabled*" | rex field=_raw "''(?<user>\w+)@" | rex field=_raw "Z (?<dest>[\w\.]+)\s" | stats min(_time) as firstTime max(_time) as lastTime count by dest user Message | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `esxi_shell_access_enabled_filter`'
how_to_implement: This is based on syslog data generated by VMware ESXi hosts. To implement this search, you must configure your ESXi systems to forward syslog output to your Splunk deployment. These logs must be ingested with the appropriate Splunk Technology Add-on for VMware ESXi Logs, which provides field extractions and CIM compatibility.
known_false_positives: Limited false positives in most environments, however tune as needed. Some Administrators may enable this for troubleshooting.
finding:
    title: ESXi Shell access was enabled on ESXi host $dest$.
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - ESXi Post Compromise
    - Black Basta Ransomware
asset_type: Infrastructure
mitre_attack_id:
    - T1021
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: endpoint

name: Geographic Improbable Location
id: 64f91df1-49ec-46aa-81bd-2282d3cea765
version: 4
creation_date: '2025-06-12'
modification_date: '2026-05-13'
author: Marissa Bower, Raven Tait
status: experimental
type: Anomaly
description: Geolocation data can be inaccurate or easily spoofed by Remote Employment Fraud (REF) workers. REF actors sometimes slip up and reveal their true location, creating what we call 'improbable travel' scenarios — logins from opposite sides of the world within minutes. This identifies situations where these travel scenarios occur.
data_source:
    - Okta
search: '| tstats summariesonly=true values(Authentication.app) as app from datamodel=Authentication.Authentication where (`okta` OR (index="firewall" AND sourcetype="pan:globalprotect")) AND Authentication.action="success" AND Authentication.app IN ("Workday", "Slack", "*GlobalProtect", "Jira*", "Atlassian Cloud", "Zoom") AND NOT Authentication.user="unknown" by _time index sourcetype host Authentication.user Authentication.src span=1s | `drop_dm_object_name("Authentication")` | fields user,src,app,_time,count,host | eval user=lower(replace(user, "((^.*\\\)|(@.*$))", "")) | join type=outer user [| inputlookup identity_lookup_expanded where user_status=active | rex field=email "^(?<user>[a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$" | rename email as user_email bunit as user_bunit priority as user_priority work_country as user_work_country work_city as user_work_city | fields user user_email user_bunit user_priority user_work_country user_work_city] | eventstats dc(src) as src_count by user | eventstats dc(user) as user_count by src | sort 0 + _time | iplocation src | lookup local=true asn_lookup_by_cidr ip as src OUTPUT ip asn description | eval session_lat=if(isnull(src_lat), lat, src_lat), session_lon=if(isnull(src_long), lon, src_long), session_city=if(isnull(src_city), City, src_city), session_country=if(isnull(src_country), Country, src_country), session_region=if(isnull(src_region), Region, src_region) | eval session_city=if(isnull(session_city) OR match(session_city,"^\s+|^$"), null(), session_city), session_country=if(isnull(session_country) OR match(session_country,"^\s+|^$"), null(), session_country), session_region=if(isnull(session_region) OR match(session_region,"^\s+|^$"), null(), session_region) | where isnotnull(session_lat) and isnotnull(session_lon) | eval session_city=if(isnull(session_city),"-",session_city), session_country=if(isnull(session_country),"-",session_country), session_region=if(isnull(session_region),"-",session_region) | streamstats current=t window=2 earliest(session_region) as prev_region,earliest(session_lat) as prev_lat, earliest(session_lon) as prev_lon, earliest(session_city) as prev_city, earliest(session_country) as prev_country, earliest(_time) as prev_time, earliest(src) as prev_src, latest(user_bunit) as user_bunit, earliest(app) as prev_app values(user_work_country) as user_work_country by user | where (src!=prev_src) AND !(prev_city=session_city AND prev_country=session_country) AND ((isnotnull(prev_city) AND isnotnull(session_city)) OR prev_country!=session_country) | `globedistance(session_lat,session_lon,prev_lat,prev_lon,"m")` | eval time_diff=if((_time-prev_time)==0, 1, _time - prev_time) | eval speed = round(distance*3600/time_diff,2) | eval distance= round(distance,2) | eval user_work_country=case(user_work_country="usa","United States", user_work_country="cze","Czechia", user_work_country="pol","Poland", user_work_country="ind","India", user_work_country="fra","France", user_work_country="can","Canada", user_work_country="mys","Malaysia", user_work_country="kor","South Korea", user_work_country="aus","Australia", user_work_country="bel","Belgium", user_work_country="dnk","Denmark", user_work_country="bra","Brazil", user_work_country="deu","Germany", user_work_country="jpn","Japan", user_work_country="che","Switzerland", user_work_country="swe","Sweden", user_work_country="zaf","South Africa", user_work_country="irl","Ireland", user_work_country="ita","Italy", user_work_country="nor","Norway", user_work_country="gbr","United Kingdom", user_work_country="hkg","Hong Kong", user_work_country="chn","China", user_work_country="esp","Spain", user_work_country="nld", "Netherlands", user_work_country="twn","Taiwan", user_work_country="est","Estonia", user_work_country="sgp","Singapore", user_work_country="are","United Arab Emirates", 1=1,"N/A") | lookup local=true asn_lookup_by_cidr ip as prev_src OUTPUT ip as prev_ip asn as prev_asn description as prev_description | eval suspect=if(!user_work_country==session_country,"Sketchy","Normal") | search (speed>500 AND distance>750) | table _time,prev_time,user,host,src,prev_src,app,prev_app,distance,speed,suspect,session_city,session_region, session_country,prev_city,prev_region,prev_country,user_priority,user_work_*,prev_ip,ip,asn,prev_asn,prev_description,description | rename _time as event_time | convert ctime(event_time) timeformat="%Y-%m-%d %H:%M:%S" | convert ctime(prev_time) timeformat="%Y-%m-%d %H:%M:%S" | eval problem=if(!session_country==prev_country AND (!session_country==user_work_country),"Yes","Nope") | search NOT (prev_city="-" OR session_city="-") AND NOT [inputlookup known_devices_public_ip_filter.csv | fields ip | rename ip as src] | dedup user host prev_src src | fillnull value="N/A" | search problem="Yes"| `geographic_improbable_location_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). This also utilizes Splunk Enterprise Security Suite for several macros and lookups. The known_devices_public_ip_filter lookup is a placeholder for known public edge devices in your network.
known_false_positives: Legitimate usage of some VPNs may cause false positives. Tune as needed.
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Improbable travel speed between locations observed for $user$.
analytic_story:
    - Remote Employment Fraud
asset_type: Identity
mitre_attack_id:
    - T1078
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: identity

name: GitHub Enterprise Repository Archived
id: 8367cb99-bae1-4748-ae3b-0927bb381424
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 repository is archived in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for repository archival events by tracking actor details, repository information, and associated metadata. For a SOC, identifying repository archival is important as it could indicate attempts to make critical code inaccessible or preparation for repository deletion. While archiving is a legitimate feature, unauthorized archival of active repositories could signal account compromise, insider threats, or attempts to disrupt development operations. The impact of unauthorized repository archival includes loss of active development access, disruption to workflows and CI/CD pipelines, and potential business delays if critical repositories are affected. Additionally, archived repositories may be targeted for subsequent deletion, potentially resulting in permanent loss of intellectual property if proper backups are not maintained.
data_source:
    - GitHub Enterprise Audit Logs
search: |-
    `github_enterprise` action=repo.archived
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor, actor_id, actor_is_bot,
           actor_location.country_code, business, business_id,
           org, org_id, repo,
           repo_id, user_agent, visibility,
           action
      | eval user=actor
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `github_enterprise_repository_archived_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: $user$ archived a repository in GitHub Enterprise
threat_objects:
    - field: user_agent
      type: http_user_agent
analytic_story:
    - GitHub Malicious Activity
    - NPM Supply Chain Compromise
asset_type: GitHub
mitre_attack_id:
    - T1485
    - T1195
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

name: Linux Auditd Find Credentials From Password Stores
id: 4de73044-9a1d-4a51-a1c2-85267d8dcab3
version: 11
creation_date: '2024-08-12'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic detects suspicious attempts to find credentials stored in password stores, indicating a potential attacker's effort to access sensitive login information. Password stores are critical repositories that contain valuable credentials, and unauthorized access to them can lead to significant security breaches. By monitoring for unusual or unauthorized activities related to password store access, this analytic helps identify potential credential theft attempts, allowing security teams to respond promptly and prevent unauthorized access to critical systems and data.
data_source:
    - Linux Auditd Execve
search: |-
    `linux_auditd` execve_command IN ("*find*", "*grep*") AND execve_command IN ("*password*", "*pass *", "*credential*", "*creds*")
      | rename host as dest
      | rename comm as process_name
      | rename exe as process
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY argc execve_command dest
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `linux_auditd_find_credentials_from_password_stores_filter`
how_to_implement: To implement this detection, the process begins by ingesting auditd data, that consists of 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
    - https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS
finding:
    title: A [$execve_command$] event occurred on host - [$dest$] to find credentials stored in password managers.
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Linux Living Off The Land
    - Linux Privilege Escalation
    - Linux Persistence Techniques
    - Compromised Linux Host
    - Scattered Lapsus$ Hunters
    - Hellcat Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1555.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Malicious PowerShell Process With Obfuscation Techniques
id: cde75cf6-3c7a-4dd6-af01-27cdb4511fd4
version: 18
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: David Dorsey, Splunk
status: production
type: TTP
description: The following analytic detects PowerShell processes launched with command-line arguments indicative of obfuscation techniques. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process names, parent processes, and complete command-line executions. This activity is significant because obfuscated PowerShell commands are often used by attackers to evade detection and execute malicious scripts. If confirmed malicious, this activity could lead to unauthorized code execution, privilege escalation, or persistent access within the environment, posing a significant security risk.
data_source:
    - Sysmon EventID 1
search: '| tstats `security_content_summariesonly` count values(Processes.process) as process values(Processes.parent_process) as parent_process min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_powershell` 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)`| eval num_obfuscation = (mvcount(split(process,"`"))-1) + (mvcount(split(process, "^"))-1) + (mvcount(split(process, "''"))-1) | search num_obfuscation > 10 | `malicious_powershell_process_with_obfuscation_techniques_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: These characters might be legitimately on the command-line, but it is not common.
references: []
finding:
    title: Powershell.exe running with potential obfuscated arguments on $dest$
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Malicious PowerShell
    - Hermetic Wiper
    - Data Destruction
    - GhostRedirector IIS Module and Rungan Backdoor
    - Hellcat Ransomware
asset_type: Endpoint
mitre_attack_id:
    - T1059.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '32492.57742'
title: Microsoft Build Engine Suspicious Parent Process
description: Adversaries may take advantage of trusted developer utilities to proxy
  execution of malicious payloads. There are many utilities used for software development
  related tasks that can be used to execute code in various forms to assist in development,
  debugging, and reverse engineering. These utilities may often be signed with legitimate
  certificates that allow them to execute on a system and proxy execution of malicious
  code through a trusted process that effectively bypasses application control solutions.
  This use case detects msbuild.exe spawned by a scripting interpreter (such as CMD,
  PowerShell, etc.).
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("msbuild.exe" OR TERM(msbuild)) ("cmd.exe" OR "powershell.exe" OR "pwsh.exe" OR
  "powershell_ise.exe" OR "cscript.exe" OR "wscript.exe" OR "mshta.exe") | regex process_name="(?i)msbuild\.exe"|
  regex parent_process_name="(?i)(cmd|powershell(_ise)?|pwsh|cscript|wscript|mshta)\.exe"
  | table _time, host, user, process, process_*, parent_* | bin span=1s | stats values(*)
  as * by _time, host '
techniques:
- execution:command and scripting interpreter:powershell
- defense-evasion:trusted developer utilities proxy execution:msbuild
- execution:command and scripting interpreter
- defense-evasion:trusted developer utilities proxy execution
- execution:command and scripting interpreter:visual basic
- execution:command and scripting interpreter:windows command shell
technique_id:
- T1059.001
- T1127.001
- T1059
- T1127
- T1059.005
- T1059.003
data_category:
- Windows Sysmon
references:
- https://attack.mitre.org/techniques/T1127/
- https://attack.mitre.org/techniques/T1127/001/
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1059/003/
- https://attack.mitre.org/techniques/T1059/005/
- https://detection.fyi/elastic/detection-rules/windows/defense_evasion_execution_msbuild_started_by_script/?query=msbuild

id: '12915.18551'
title: Multiple nslookup commands
description: 'Threat actors have been observed gathering host based network information
  by running a batch script, which ran nslookup for each host in the environment.Living
  Off the Land Binary and Scripts (LOLBAS) (LOLBIN) -- Software Association: Rhysida'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("nslookup" OR "nslookup.exe") | table _time, host, user process, process_*, signature_id,
  parent_* | bin span=60s | stats values(*) as * by _time, host | where match(process_name,
  "(?i)nslookup.exe") and event_count > 2 '
techniques:
- discovery:system network configuration discovery
- discovery:remote system discovery
technique_id: 
- T1016
- T1018
data_category:
- Windows Sysmon
references:
- https://thedfirreport.com/2022/04/25/quantum-ransomware/

name: Okta Suspicious Use of a Session Cookie
id: 71ad47d1-d6bd-4e0a-b35c-020ad9a6959e
version: 12
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Scott Dermott, Felicity Robson, Okta, Michael Haag, Bhavin Patel, Splunk
status: production
type: Anomaly
description: The following analytic identifies suspicious use of a session cookie by detecting multiple client values (IP, User Agent, etc.) changing for the same Device Token associated with a specific user. It leverages policy evaluation events from successful authentication logs in Okta. This activity is significant as it may indicate an adversary attempting to reuse a stolen web session cookie, potentially bypassing authentication mechanisms. If confirmed malicious, this could allow unauthorized access to user accounts, leading to data breaches or further exploitation within the environment.
data_source:
    - Okta
search: |-
    `okta` eventType IN (policy.evaluate_sign_on) outcome.result IN (ALLOW, SUCCESS)
      | stats earliest(_time) as _time, values(client.ipAddress) as src_ip, values(client.userAgent.rawUserAgent) as user_agent, values(client.userAgent.os) as userAgentOS_list, values(client.geographicalContext.city) as city, values(client.userAgent.browser) as userAgentBrowser_list, values(device.os_platform) as okta_device_os, dc(client.userAgent.browser) as dc_userAgentBrowser, dc(client.userAgent.os) as dc_userAgentOS, dc(client.ipAddress) as dc_src_ip, values(outcome.reason) as reason values(dest) as dest
        BY debugContext.debugData.dtHash, user
      | where dc_src_ip>1 AND (dc_userAgentOS>1 OR dc_userAgentBrowser>1)
      | `okta_suspicious_use_of_a_session_cookie_filter`
how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may occur, depending on the organization's size and the configuration of Okta.
references:
    - https://attack.mitre.org/techniques/T1539/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: A user [$user$] is attempting to use a session cookie from multiple IP addresses or devices. Investigate further to determine if this was authorized.
analytic_story:
    - Suspicious Okta Activity
    - Okta Account Takeover
    - Scattered Lapsus$ Hunters
asset_type: Okta Tenant
mitre_attack_id:
    - T1539
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: identity

id: '19129.34163'
title: Potential Cryptomining Commands
description: Adversaries may leverage the resources of co-opted systems in order to
  solve resource intensive problems, which may impact system and/or hosted service
  availability. One common purpose for Resource Hijacking is to validate transactions
  of cryptocurrency networks and earn virtual currency. This use case detects common
  plaintext and base64 encoded commands for cryptomining activity.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  ("--cpu-priority=" OR "--donate-level=" OR " -o pool." OR " --nicehash" OR " --algo="
  OR "stratum+tcp://" OR "stratum+udp://" OR "LS1kb25hdGUtbGV2ZWw9" OR "0tZG9uYXRlLWxldmVsP"
  OR "tLWRvbmF0ZS1sZXZlbD" OR "c3RyYXR1bSt0Y3A6Ly" OR "N0cmF0dW0rdGNwOi8v" OR "zdHJhdHVtK3RjcDovL"
  OR "c3RyYXR1bSt1ZHA6Ly" OR "N0cmF0dW0rdWRwOi8v" OR "zdHJhdHVtK3VkcDovL") | regex
  process!="(?i)(pool\.(c|o))\s|gcc\s-" | table _time, host, user, process, process_*,
  parent_process_name | bin span=1s | stats values(*) as * by _time, host '
techniques:
- impact:resource hijacking
technique_id: 
- T1496
data_category:
- Windows Sysmon
- Process command-line parameters
references:
- https://xmrig.com/docs/miner/command-line-options
- https://www.trendmicro.com/en_us/research/24/j/unmasking-prometei-a-deep-dive-into-our-mxdr-findings.html

id: '17778.29991'
title: Read-Only Attribute Removed - Windows
description: 'This use case detects commands removing read-only attributes from files
  on Windows systems. This technique is used by threat actors to modify or delete
  critical system files. Atomics T1222.001 Test #3'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  (TERM(attrib) OR TERM(attrib.exe)) "-r" | regex process="(?i)\s+-r\s+" | table _time,
  host, user parent_*, process, process_* | bin span=1s | stats values(*) as * by
  _time, host '
techniques:
- defense-evasion:file and directory permissions modification:windows file and directory
  permissions modification
technique_id:
- T1222.001
data_category:
- Windows Sysmon
references:
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1222.001/T1222.001.md#atomic-test-3---attrib---remove-read-only-attribute

name: Splunk XSS Privilege Escalation via Custom Urls in Dashboard
id: 01e1e386-7656-4f36-a55a-52fe39b04a96
version: 7
creation_date: '2024-07-01'
modification_date: '2026-05-14'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
description: This is a composed hunting search that looks for POST requests to splunk_internal_metrics/data/ui/views which can be used to elevate privileges on the Splunk server via custom urls. The way to find privilege escalation is by looking at created users with high privielges after payload has been executed. This search looks at POST request and then looks at created users privileges.
data_source:
    - Splunk
search: '`splunkd_ui` method=POST /*/data/ui/views* | stats values(method) as method by _time index, sourcetype, host | eval event="post_request" | append [| search `audittrail` action="edit_user" operation="create" | rex field=_raw "object=\"(?<newUser>.*)\"" | stats count values(operation) as operation values(splunk_server) as splunk_server values(user) as user by _time index, sourcetype, host, newUser | eval event="create_user"] | sort - _time | transaction host startswith=event="post_request" endswith=event="create_user" maxspan=10m | table _time index, sourcetype, host, method, user, splunk_server, operation, event, newUser eventcount | `splunk_xss_privilege_escalation_via_custom_urls_in_dashboard_filter`'
how_to_implement: Requires access to internal indexes _audit and _internal.
known_false_positives: This is a hunting search and requires operator to search for specific indicators of user creation in proximity to POST requests against vulnerable endpoint. It is not possible to detect payload during runtime.
references:
    - https://advisory.splunk.com/
analytic_story:
    - Splunk Vulnerabilities
asset_type: Splunk Server
cve:
    - CVE-2024-36992
mitre_attack_id:
    - T1189
product:
    - Splunk Enterprise
    - Splunk Cloud
    - Splunk Enterprise Security
category: application
security_domain: endpoint