Splunk rules: 18

id: '6143.18229'
title: Adfind Execution
description: 'AdFind is a free command-line query tool that can be used for gathering
  information from Active Directory. This use case looks for process executions of
  Adfind. -- Threat Actor Association: APT29/Nobelium/Cozy Bear, APT31, BlackMatter,
  Conti, DarkSide, FIN6, FIN7, FIN12, Karakurt, Lazarus, Traveling Spider, Wizard
  Spider, Yanluowang - Software Association: ALPHV/BlackCat, BazarLoader, Conti, Dridex,
  Entropy, Lockbit, Nefilim, Quantum, Sodinokibi/REvil - Atomics T1016 Test #6 Atomics
  T1018 Test#10 Atomics T1018 Test#11 Atomics T1069.002 Test #8 Atomics T1087.002
  Test #5 Atomics T1087.002 Test #6 Atomics T1087.002 Test #7 Atomics T1087.002 Test
  #8'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` ("EventCode=1" OR "<EventID>1<")
  "adfind" | table _time, host, user user, process, process_*, parent_* | bin span=5s
  | stats values(*) as * by _time, host | where event_count > 0 '
techniques:
- discovery:account discovery:domain account
- discovery:permission groups discovery:domain groups
- discovery:domain trust discovery
- discovery:system network configuration discovery
- discovery:remote system discovery
technique_id:
- T1087.002
- T1069.002
- T1482
- T1016
- T1018
data_category:
- Windows Sysmon
references:
- https://redcanary.com/blog/how-one-hospital-thwarted-a-ryuk-ransomware-outbreak/
- https://thedfirreport.com/2020/10/08/ryuks-return/
- https://www.fireeye.com/blog/threat-research/2019/04/pick-six-intercepting-a-fin6-intrusion.html

name: AWS ECR Container Upload Outside Business Hours
id: d4c4d4eb-3994-41ca-a25e-a82d64e125bb
version: 12
creation_date: '2021-08-19'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic detects the upload of a new container image to AWS Elastic Container Registry (ECR) outside of standard business hours. It leverages AWS CloudTrail logs to identify `PutImage` events occurring between 8 PM and 8 AM or on weekends. This activity is significant because container uploads outside business hours can indicate unauthorized or suspicious activity, potentially pointing to a compromised account or insider threat. If confirmed malicious, this could allow an attacker to deploy unauthorized or malicious containers, leading to potential data breaches or service disruptions.
data_source:
    - AWS CloudTrail PutImage
search: |-
    `cloudtrail` eventSource=ecr.amazonaws.com eventName=PutImage date_hour>=20 OR date_hour<8 OR date_wday=saturday OR date_wday=sunday
      | rename requestParameters.* as *
      | rename repositoryName AS repository
      | rename user_name as user
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY signature user user_agent
           src vendor_account vendor_region
           vendor_product repository
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `aws_ecr_container_upload_outside_business_hours_filter`
how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
known_false_positives: When your development is spreaded in different time zones, applying this rule can be difficult.
references:
    - https://attack.mitre.org/techniques/T1204/003/
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Container uploaded outside business hours from $user$
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - Dev Sec Ops
asset_type: AWS Account
mitre_attack_id:
    - T1204.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

name: Detect AWS Console Login by User from New City
id: 121b0b11-f8ac-4ed6-a132-3800ca4fc07a
version: 9
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: Bhavin Patel, Eric McGinnis Splunk
status: production
type: Hunting
description: The following analytic identifies AWS console login events by users from a new city within the last hour. It leverages AWS CloudTrail events and compares them against a lookup file of previously seen user locations. This activity is significant for a SOC as it may indicate unauthorized access or credential compromise, especially if the login originates from an unusual location. If confirmed malicious, this could lead to unauthorized access to AWS resources, data exfiltration, or further exploitation within the cloud environment.
data_source:
    - AWS CloudTrail
search: |-
    | tstats earliest(_time) as firstTime latest(_time) as lastTime FROM datamodel=Authentication
      WHERE Authentication.signature=ConsoleLogin
      BY Authentication.user Authentication.src
    | iplocation Authentication.src
    | `drop_dm_object_name(Authentication)`
    | rename City as justSeenCity
    | table firstTime lastTime user justSeenCity
    | join user type=outer [
    | inputlookup previously_seen_users_console_logins
    | rename City as previouslySeenCity
    | stats min(firstTime) AS earliestseen
      BY user previouslySeenCity
    | fields earliestseen user previouslySeenCity]
    | eval userCity=if(firstTime >= relative_time(now(), "-24h@h"), "New City","Previously Seen City")
    | where userCity = "New City"
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | table firstTime lastTime user previouslySeenCity justSeenCity userCity
    | `detect_aws_console_login_by_user_from_new_city_filter`
how_to_implement: You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_city_filter` macro.
known_false_positives: When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
references: []
analytic_story:
    - Suspicious AWS Login Activities
    - Suspicious Cloud Authentication Activities
    - AWS Identity and Access Management Account Takeover
    - Compromised User Account
asset_type: AWS Instance
mitre_attack_id:
    - T1535
    - T1586.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat
baselines:
    - Previously Seen Users in CloudTrail - Initial
    - Previously Seen Users In CloudTrail - Update

name: Detect S3 access from a new IP
id: e6f1bb1b-f441-492b-9126-902acda217da
version: 8
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: experimental
type: Anomaly
description: The following analytic identifies access to an S3 bucket from a new or previously unseen remote IP address. It leverages S3 bucket-access logs, specifically focusing on successful access events (http_status=200). This activity is significant because access from unfamiliar IP addresses could indicate unauthorized access or potential data exfiltration attempts. If confirmed malicious, this activity could lead to unauthorized data access, data theft, or further exploitation of the compromised S3 bucket, posing a significant risk to sensitive information stored within the bucket.
data_source: []
search: |-
    `aws_s3_accesslogs` http_status=200  [search `aws_s3_accesslogs` http_status=200
      | stats earliest(_time) as firstTime latest(_time) as lastTime
        BY bucket_name remote_ip
      | inputlookup append=t previously_seen_S3_access_from_remote_ip
      | stats min(firstTime) as firstTime, max(lastTime) as lastTime
        BY bucket_name remote_ip
      | outputlookup previously_seen_S3_access_from_remote_ip
      | eval newIP=if(firstTime >= relative_time(now(), "-70m@m"), 1, 0)
      | where newIP=1
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | table bucket_name remote_ip]
      | iplocation remote_ip
      | rename remote_ip as src_ip
      | table _time bucket_name src_ip City Country operation request_uri
      | `detect_s3_access_from_a_new_ip_filter`
how_to_implement: You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your S3 access logs' inputs. This search works best when you run the "Previously Seen S3 Bucket Access by Remote IP" support search once to create a history of previously seen remote IPs and bucket names.
known_false_positives: S3 buckets can be accessed from any IP, as long as it can make a successful connection. This will be a false postive, since the search is looking for a new IP within the past hour
references: []
intermediate_findings:
    entities:
        - field: bucketName
          type: other
          score: 20
          message: New S3 access from a new IP - $src_ip$
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - Suspicious AWS S3 Activities
asset_type: S3 Bucket
mitre_attack_id:
    - T1530
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network
baselines:
    - Previously seen S3 bucket access by remote IP

id: '35400.62241'
title: File Executed from INetCache
description: Adversaries may transfer tools or other files from an external system
  into a compromised environment. Tools or files may be copied from an external adversary-controlled
  system to the victim network through the command and control channel or through
  alternate protocols such as ftp. Once present, adversaries may also transfer/spread
  tools between victim devices within a compromised environment (i.e. Lateral Tool
  Transfer). This use case detects when a file was executed from the C:\Users\<user>\AppData\Local\Microsoft\Windows\INetCache\IE
  folder.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_winevent` (TERM(EventCode=4688) OR
  "<EventID>4688<" OR Type=Process) "\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE"
  | regex process_path="(?i)\x5cAppData\x5cLocal\x5cMicrosoft\x5cWindows\x5cINetCache\x5cIE"
  | table _time, host, user, process, process_*, parent_* | bin span=1s | stats values(*)
  as * by _time, host '
techniques:
- command-and-control:ingress tool transfer
technique_id: 
- T1105
data_category:
- Windows event logs
references:
- https://lolbas-project.github.io/lolbas/Binaries/Ngen/
- https://learn.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator
- https://attack.mitre.org/techniques/T1105/
- https://www.elastic.co/guide/en/security/8.14/suspicious-execution-from-inet-cache.html

name: Ivanti Connect Secure Command Injection Attempts
id: 1f32a7e0-a060-4545-b7de-73fcf9ad536e
version: 10
creation_date: '2024-01-17'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic identifies attempts to exploit the CVE-2023-46805 and CVE-2024-21887 vulnerabilities in Ivanti Connect Secure. It detects POST requests to specific URIs that leverage command injection to execute arbitrary commands. The detection uses the Web datamodel to monitor for these requests and checks for a 200 OK response, indicating a successful exploit attempt. This activity is significant as it can lead to unauthorized command execution on the server. If confirmed malicious, attackers could gain control over the system, leading to potential data breaches or further network compromise.
data_source:
    - Suricata
search: |-
    | tstats count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Web
      WHERE Web.url IN("*/api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection*","*/api/v1/totp/user-backup-code/../../license/keys-status/*") Web.http_method IN ("POST", "GET") Web.status=200
      BY Web.src, Web.dest, Web.http_user_agent,
         Web.url, Web.http_method, Web.status
    | `drop_dm_object_name("Web")`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `ivanti_connect_secure_command_injection_attempts_filter`
how_to_implement: This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
known_false_positives: This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
references:
    - https://github.com/RootUp/PersonalStuff/blob/master/http-vuln-cve2023-46805_2024_21887.nse
    - https://github.com/projectdiscovery/nuclei-templates/blob/c6b351e71b0fb0e40e222e97038f1fe09ac58194/http/misconfiguration/ivanti/CVE-2023-46085-CVE-2024-21887-mitigation-not-applied.yaml
    - https://github.com/rapid7/metasploit-framework/pull/18708/files
    - https://attackerkb.com/topics/AdUh6by52K/cve-2023-46805/rapid7-analysis
    - https://labs.watchtowr.com/welcome-to-2024-the-sslvpn-chaos-continues-ivanti-cve-2023-46805-cve-2024-21887/
    - https://twitter.com/GreyNoiseIO/status/1747711939466453301
finding:
    title: Possible exploitation of CVE-2023-46805 and CVE-2024-21887 against $dest$.
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - Ivanti Connect Secure VPN Vulnerabilities
    - CISA AA24-241A
asset_type: VPN Appliance
cve:
    - CVE-2023-46805
    - CVE-2024-21887
mitre_attack_id:
    - T1190
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: web
security_domain: network

name: Kubernetes Nginx Ingress LFI
id: 0f83244b-425b-4528-83db-7a88c5f66e48
version: 11
creation_date: '2021-08-23'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects local file inclusion (LFI) attacks targeting Kubernetes Nginx ingress controllers. It leverages Kubernetes logs, parsing fields such as `request` and `status` to identify suspicious patterns indicative of LFI attempts. This activity is significant because LFI attacks can allow attackers to read sensitive files from the server, potentially exposing critical information. If confirmed malicious, this could lead to unauthorized access to sensitive data, further exploitation, and potential compromise of the Kubernetes environment.
data_source: []
search: '`kubernetes_container_controller` | rex field=_raw "^(?<remote_addr>\S+)\s+-\s+-\s+\[(?<time_local>[^\]]*)\]\s\"(?<request>[^\"]*)\"\s(?<status>\S*)\s(?<body_bytes_sent>\S*)\s\"(?<http_referer>[^\"]*)\"\s\"(?<http_user_agent>[^\"]*)\"\s(?<request_length>\S*)\s(?<request_time>\S*)\s\[(?<proxy_upstream_name>[^\]]*)\]\s\[(?<proxy_alternative_upstream_name>[^\]]*)\]\s(?<upstream_addr>\S*)\s(?<upstream_response_length>\S*)\s(?<upstream_response_time>\S*)\s(?<upstream_status>\S*)\s(?<req_id>\S*)" | rename remote_addr AS src_ip, upstream_status as status, proxy_upstream_name as proxy | rex field=request "^(?<http_method>\S+)\s(?<url>\S+)\s" | eval phase="operate" | eval severity="high" | stats count min(_time) as firstTime max(_time) as lastTime by src_ip, status, url, http_method, host, http_user_agent, proxy, phase, severity, request | lookup local_file_inclusion_paths local_file_inclusion_paths AS request OUTPUT lfi_path | search lfi_path=yes | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `kubernetes_nginx_ingress_lfi_filter`'
how_to_implement: You must ingest Kubernetes logs through Splunk Connect for Kubernetes.
known_false_positives: No false positives have been identified at this time.
references:
    - https://github.com/splunk/splunk-connect-for-kubernetes
    - https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/
finding:
    title: Local File Inclusion Attack detected on $host$
    entity:
        field: host
        type: system
        score: 50
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - Dev Sec Ops
asset_type: Kubernetes
mitre_attack_id:
    - T1212
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

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

id: '20634.36831'
title: ntds.dit Access from Unexpected Location
description: 'Adversaries may attempt to access or create a copy of the Active Directory
  domain database in order to steal credential information, as well as obtain other
  information about domain members such as devices, users, and access rights. This
  use case detects processes and parent processes interacting with ntds.dit from unexpected
  locations which may indicate malicious activity. Due to limitations in EDR logging,
  EDR rules will only detect on process path (not parent process path). -- Threat
  Actor Association: Mustang Panda (aka. Stately Taurus//Earth Preta/BRONZE PRESIDENT/TA416/RedDelta),
  UNC5221, UTA0178'
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=1) OR "<EventID>1<")
  "ntds.dit" ("apache" OR "tomcat" OR "AppData" OR "Temp" OR "Public" OR "PerfLogs"
  OR "Public" OR "Downloads" OR ("Recycle" "Bin") OR "SysWOW64" OR "User" OR ("Program"
  "Files") OR "Debug" OR "fonts" OR "Help" or "repair" OR "ProgramData") | regex process="(?i)ntds\.dit"|
  where match(process_path, "(?i)\x5c(apache|tomcat|AppData|Temp|PerfLogs|Public|Downloads|User|ProgramData|Recycle(\s+|\.)Bin|(\x5cWindows\x5c(Debug|fonts|Help|repair|SysWOW64)))\x5c")
  or match(parent_process_path, "(?i)\x5c(apache|tomcat|AppData|Temp|PerfLogs|Public|Downloads|User|ProgramData|Recycle(\s+|\.)Bin|(\x5cWindows\x5c(Debug|fonts|Help|repair|SysWOW64)))\x5c")
  | table _time, host, user, process*, parent_process_path | bin span=1s | stats values(*)
  as * by _time, host '
techniques:
- credential-access:os credential dumping:ntds
technique_id:
- T1003.003
data_category:
- Windows Sysmon
- Process command-line parameters
references:
- https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html?m=1

name: O365 New Federated Domain Added
id: e155876a-6048-11eb-ae93-0242ac130002
version: 13
creation_date: '2021-01-26'
modification_date: '2026-05-13'
author: Rod Soto, Mauricio Velazco Splunk
status: production
type: TTP
description: The following analytic identifies the addition of a new federated domain in an Office 365 environment. This behavior is detected by analyzing Office 365 management activity logs, specifically filtering for Workload=Exchange and Operation="Add-FederatedDomain". The addition of a new federated domain is significant as it may indicate unauthorized changes or potential compromises. If confirmed malicious, attackers could establish a backdoor, bypass security measures, or exfiltrate data, leading to data breaches and unauthorized access to sensitive information. Immediate investigation is required to review the details of the added domain and any concurrent suspicious activities.
data_source:
    - O365
search: |-
    `o365_management_activity` Operation IN ("*add*", "*new*") AND Operation="*domain*"
      | eval src="NA"
      | fillnull
      | stats count values(ModifiedProperties{}.NewValue) as new_value
        BY user user_agent authentication_service
           signature Workload src
           vendor_account vendor_product dest
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `o365_new_federated_domain_added_filter`
how_to_implement: You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity.
known_false_positives: The creation of a new Federated domain is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a similar or different cloud provider.
references:
    - https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/wp-m-unc2452-2021-000343-01.pdf
    - 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://blog.sygnia.co/detection-and-hunting-of-golden-saml-attack?hsLang=en
    - https://o365blog.com/post/aadbackdoor/
finding:
    title: User $user$ has added a new federated domain $new_value$
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Office 365 Persistence Mechanisms
    - Cloud Federated Credential Abuse
asset_type: O365 Tenant
mitre_attack_id:
    - T1136.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat

name: O365 Security And Compliance Alert Triggered
id: 5b367cdd-8dfc-49ac-a9b7-6406cf27f33e
version: 12
creation_date: '2024-04-17'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies alerts triggered by the Office 365 Security and Compliance Center, indicating potential threats or policy violations. It leverages data from the `o365_management_activity` dataset, focusing on events where the workload is SecurityComplianceCenter and the operation is AlertTriggered. This activity is significant as it highlights security and compliance issues within the O365 environment, which are crucial for maintaining organizational security. If confirmed malicious, these alerts could indicate attempts to breach security policies, leading to unauthorized access, data exfiltration, or other malicious activities.
data_source: []
search: |-
    `o365_management_activity` Workload=SecurityComplianceCenter Category=ThreatManagement Operation=AlertTriggered
      | spath input=Data path=f3u output=user
      | spath input=Data path=op output=operation
      | spath input=_raw path=wl
      | spath input=Data path=rid output=rule_id
      | spath input=Data path=ad output=alert_description
      | spath input=Data path=lon output=operation_name
      | spath input=Data path=an output=alert_name
      | spath input=Data path=sev output=severity
      | fillnull
      | stats count earliest(_time) as firstTime latest(_time) as lastTime
        BY user, Name, rule_id,
           alert_description, alert_name, severity,
           dest, src, vendor_account,
           vendor_product, signature
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `o365_security_and_compliance_alert_triggered_filter`
how_to_implement: You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
known_false_positives: O365 Security and Compliance may also generate false positives or trigger on legitimate behavior, filter as needed.
references:
    - https://attack.mitre.org/techniques/T1078/004/
    - https://learn.microsoft.com/en-us/purview/alert-policies?view=o365-worldwide
    - https://learn.microsoft.com/en-us/purview/alert-policies
finding:
    title: Security and Compliance triggered an alert for $user$
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Office 365 Account Takeover
asset_type: O365 Tenant
mitre_attack_id:
    - T1078.004
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: identity

name: Okta New Device Enrolled on Account
id: bb27cbce-d4de-432c-932f-2e206e9130fb
version: 14
creation_date: '2022-12-19'
modification_date: '2026-05-13'
author: Michael Haag, Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies when a new device is enrolled on an Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud to detect the creation of new device enrollments. This activity is significant as it may indicate a legitimate user setting up a new device or an adversary adding a device to maintain unauthorized access. If confirmed malicious, this could lead to potential account takeover, unauthorized access, and persistent control over the compromised Okta account. Monitoring this behavior is crucial for detecting and mitigating unauthorized access attempts.
data_source:
    - Okta
search: |-
    | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime FROM datamodel=Change
      WHERE All_Changes.action=created All_Changes.command=device.enrollment.create
      BY _time span=5m All_Changes.user
         All_Changes.result All_Changes.command sourcetype
         All_Changes.src All_Changes.action All_Changes.object_category
         All_Changes.dest
    | `drop_dm_object_name("All_Changes")`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `okta_new_device_enrolled_on_account_filter`
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It is possible that the user has legitimately added a new device to their account. Please verify this activity.
references:
    - https://attack.mitre.org/techniques/T1098/005/
    - https://developer.okta.com/docs/reference/api/event-types/?q=device.enrollment.create
finding:
    title: A new device was enrolled on an Okta account for user [$user$]. Investigate further to determine if this was authorized.
    entity:
        field: user
        type: user
        score: 50
analytic_story:
    - Okta Account Takeover
    - Scattered Lapsus$ Hunters
asset_type: Okta Tenant
mitre_attack_id:
    - T1098.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: identity

name: Protocol or Port Mismatch
id: 54dc1265-2f74-4b6d-b30d-49eb506a31b3
version: 12
creation_date: '2020-04-29'
modification_date: '2026-05-13'
author: Rico Valdez, Splunk
status: production
type: Anomaly
description: The following analytic identifies network traffic where the higher layer protocol does not match the expected port, such as non-HTTP traffic on TCP port 80. It leverages data from network traffic inspection technologies like Bro or Palo Alto Networks firewalls. This activity is significant because it may indicate attempts to bypass firewall restrictions or conceal malicious communications. If confirmed malicious, this behavior could allow attackers to evade detection, maintain persistence, or exfiltrate data through commonly allowed ports, posing a significant threat to network security.
data_source:
    - Cisco Secure Firewall Threat Defense Connection Event
search: |
    | tstats `security_content_summariesonly`
      count min(_time) as firstTime
            max(_time) as lastTime

    from datamodel=Network_Traffic where

    (
      All_Traffic.app=dns
      NOT All_Traffic.dest_port IN (53)
    )
    OR
    (
      All_Traffic.app IN (web-browsing, http)
      NOT All_Traffic.dest_port IN (80, 8000, 8080)
    )
    OR
    (
      All_Traffic.app=ssl
      NOT All_Traffic.dest_port IN (443, 465, 993, 8443)
    )
    OR
    (
      All_Traffic.app=smtp
      NOT All_Traffic.dest_port IN (25, 587, 2525)
    )

    by All_Traffic.src_ip All_Traffic.dest_ip All_Traffic.app,
       All_Traffic.dest_port All_Traffic.transport
       All_Traffic.action All_Traffic.rule

    |`security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `drop_dm_object_name("All_Traffic")`
    | `protocol_or_port_mismatch_filter`
how_to_implement: Running this search properly requires a technology that can inspect network traffic and identify common protocols. Technologies such as Zeek, Cisco Secure Firewall or Palo Alto Networks firewalls are examples that will identify protocols via inspection, and not just assume a specific protocol based on the transport protocol and ports.
known_false_positives: Some false positive could occur with some applications that change their default communication port for an added layer of obscurity.
references: []
intermediate_findings:
    entities:
        - field: src_ip
          type: system
          score: 20
          message: Port or Protocol Traffic Mismatch [ $src_ip$ ]
threat_objects:
    - field: dest_ip
      type: ip_address
analytic_story:
    - Prohibited Traffic Allowed or Protocol Mismatch
    - Command And Control
    - Cisco Secure Firewall Threat Defense Analytics
asset_type: Endpoint
mitre_attack_id:
    - T1048.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: network
security_domain: network

name: Suspicious Process DNS Query Known Abuse Web Services
id: 3cf0dc36-484d-11ec-a6bc-acde48001122
version: 17
creation_date: '2021-11-18'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: TTP
description: The following analytic detects a suspicious process making DNS queries to known, abused text-paste web services, VoIP, instant messaging, and digital distribution platforms. It leverages Sysmon EventID 22 logs to identify queries from processes like cmd.exe, powershell.exe, and others. This activity is significant as it may indicate an attempt to download malicious files, a common initial access technique. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the target host.
data_source:
    - Sysmon EventID 22
search: '`sysmon` EventCode=22 QueryName IN ("*pastebin*", "*discord*", "*api.telegram*","*t.me*") process_name IN ("cmd.exe", "*powershell*", "pwsh.exe", "wscript.exe","cscript.exe") OR Image IN ("*\\users\\public\\*", "*\\programdata\\*", "*\\temp\\*", "*\\Windows\\Tasks\\*", "*\\appdata\\*", "*\\perflogs\\*") | stats count min(_time) as firstTime max(_time) as lastTime by answer answer_count dvc process_exec process_guid process_name query query_count reply_code_id signature signature_id src user_id vendor_product QueryName QueryResults QueryStatus | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `suspicious_process_dns_query_known_abuse_web_services_filter`'
how_to_implement: This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days.
known_false_positives: Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed.
references:
    - https://urlhaus.abuse.ch/url/1798923/
    - https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/
finding:
    title: Suspicious process $process_name$ made a DNS query for $QueryName$ on $dvc$
    entity:
        field: dvc
        type: system
        score: 50
threat_objects:
    - field: process_name
      type: process_name
analytic_story:
    - Snake Keylogger
    - Meduza Stealer
    - Malicious Inno Setup Loader
    - Phemedrone Stealer
    - Remcos
    - Data Destruction
    - PXA Stealer
    - WhisperGate
    - Cactus Ransomware
    - Braodo Stealer
    - RedLine Stealer
    - BlankGrabber Stealer
asset_type: Endpoint
mitre_attack_id:
    - T1059.005
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: network
security_domain: endpoint

name: Windows AD Domain Root ACL Modification
id: 4981e2db-1372-440d-816e-3e7e2ed74433
version: 10
creation_date: '2024-07-01'
modification_date: '2026-05-13'
author: Dean Luxton
status: production
type: TTP
description: ACL modification performed on the domain root object, significant AD change with high impact. Following MS guidance all changes at this level should be reviewed. Drill into the logonID within EventCode 4624 for information on the source device during triage.
data_source:
    - Windows Event Log Security 5136
search: '`wineventlog_security` EventCode=5136 ObjectClass=domainDNS  | stats min(_time) as _time values(eval(if(OperationType=="%%14675",AttributeValue,null))) as old_value values(eval(if(OperationType=="%%14674",AttributeValue,null))) as new_value values(OperationType) as OperationType values(dest) as dest by ObjectClass ObjectDN OpCorrelationID src_user SubjectLogonId  | rex field=old_value max_match=10000 "\((?P<old_values>.*?)\)"  | rex field=new_value max_match=10000 "\((?P<new_ace>.*?)\)"  | mvexpand new_ace | where NOT new_ace IN (old_values)  | rex field=new_ace "(?P<aceType>.*?);(?P<aceFlags>.*?);(?P<aceAccessRights>.*?);(?P<aceObjectGuid>.*?);;(?P<aceSid>.*?)$" | rex max_match=100 field=aceAccessRights "(?P<AccessRights>[A-Z]{2})"  | rex max_match=100 field=aceFlags "(?P<aceFlags>[A-Z]{2})"  | lookup msad_guid_lookup guid as aceObjectGuid OUTPUT displayName as ControlAccessRights | lookup ace_access_rights_lookup access_rights_string as AccessRights OUTPUT access_rights_value  | lookup ace_type_lookup ace_type_string as aceType OUTPUT ace_type_value  | lookup ace_flag_lookup flag_string as aceFlags OUTPUT flag_value as ace_flag_value ``` Optional SID resolution lookups | lookup identity_lookup_expanded objectSid as aceSid OUTPUT downLevelDomainName as user  | lookup admon_groups_def objectSid as aceSid OUTPUT cn as group ``` | lookup builtin_groups_lookup builtin_group_string  as aceSid OUTPUT builtin_group_name as builtin_group | eval aceAccessRights=if(aceAccessRights="CCDCLCSWRPWPDTLOCRSDRCWDWO","Full control",''access_rights_value''), aceType=ace_type_value, aceFlags=coalesce(ace_flag_value,"This object only"), aceControlAccessRights=ControlAccessRights, user=coalesce(user, group, builtin_group, aceSid)  | stats values(aceType) as aceType values(aceFlags) as aceFlags(inheritance) values(aceControlAccessRights) as aceControlAccessRights values(aceAccessRights) as aceAccessRights values(new_ace) as new_ace by _time ObjectClass ObjectDN src_user SubjectLogonId user OpCorrelationID | eval aceControlAccessRights=if(mvcount(aceControlAccessRights)=1 AND aceControlAccessRights="","All rights",''aceControlAccessRights'') | `windows_ad_domain_root_acl_modification_filter`'
how_to_implement: Ensure you are ingesting Active Directory audit logs - specifically event 5136. See lantern article in references for further on how to onboard AD audit data. Ensure the wineventlog_security macro is configured with the correct indexes and include lookups for SID resolution if evt_resolve_ad_obj is set to 0.
known_false_positives: No false positives have been identified at this time.
references:
    - https://learn.microsoft.com/en-us/windows/win32/secauthz/ace-strings
    - https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb
    - https://trustedsec.com/blog/a-hitchhackers-guide-to-dacl-based-detections-part-1-a
    - https://lantern.splunk.com/Security/Product_Tips/Enterprise_Security/Enabling_an_audit_trail_from_Active_Directory
finding:
    title: $src_user$ has granted $user$ $aceAccessRights$ ACL rights to domain root $ObjectDN$
    entity:
        field: src_user
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 50
          message: $src_user$ has granted $user$ $aceAccessRights$ ACL rights to domain root $ObjectDN$
analytic_story:
    - Sneaky Active Directory Persistence Tricks
asset_type: Endpoint
mitre_attack_id:
    - T1222.001
    - T1484
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Windows Defender Threat Detected on Kernel Object Path
id: 702631e8-90ce-43db-90fd-cf0228edc8ad
version: 1
creation_date: '2026-08-17'
modification_date: '2026-08-18'
author: Onur Mustafa Erdogan, Splunk
status: production
type: TTP
description: |-
    The following analytic detects a Windows Defender malware detection or remediation event where the scanned path resolves through the NT object manager namespace (\globalroot\).
    It leverages Windows Defender Operational log EventCodes 1116 and 1117 to identify this activity.
    In the ShieldBreak exploit, this is how Defender is coerced into hydrating a cloud file placeholder and copying attacker content through a symbolic link chain that ultimately writes into C:\Windows\System32.
    If confirmed malicious, this activity indicates an attempt to weaponize Windows Defender's own scanning pipeline for local privilege escalation.
data_source:
    - Windows Event Log Defender 1116
    - Windows Event Log Defender 1117
search: |-
    `ms_defender`
    EventCode IN (1116, 1117)
    Path="*\\globalroot\\*"
    | fillnull
    | stats count min(_time) as firstTime
                  max(_time) as lastTime
                  values(EventCode) as EventCode
                  values(Action_Name) as Action_Name
                  values(Additional_Actions_String) as Additional_Actions_String
                  values(FWLink) as FWLink
      by dvc Detection_User Path Threat_Name Severity_Name Category_Name
    | rename dvc as dest, Detection_User as user
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_defender_threat_detected_on_kernel_object_path_filter`
how_to_implement: |-
    The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line, via the Splunk Add-on for Microsoft Windows. Ensure the Microsoft-Windows-Windows Defender/Operational channel is being collected so that EventCode 1116 (detection) and 1117 (remediation) events are ingested.
known_false_positives: |-
    No false positives have been identified at this time. Legitimate Defender scans do not report detections against paths resolved through the NT object manager namespace.
references:
    - https://www.cyderes.com/howler-cell/rogueplanet-windows-zero-day
    - https://www.threatlocker.com/blog/nightmareeclipse-releases-new-poc-shieldbreak-exploits-same-weakness-as-rogueplanet
finding:
    title: Windows Defender reported a detection on a kernel object path $Path$ on $dest$
    entity:
        field: dest
        type: system
        score: 50
threat_objects:
    - field: Path
      type: file_path
analytic_story:
    - RoguePlanet
asset_type: Endpoint
mitre_attack_id:
    - T1068
    - T1211
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Windows Enable PowerShell Web Access
id: 175bb2de-6227-416b-9678-9b61999cd21f
version: 11
creation_date: '2024-09-03'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: TTP
description: The following analytic detects the enabling of PowerShell Web Access via PowerShell commands. It leverages PowerShell script block logging (EventCode 4104) to identify the execution of the `Install-WindowsFeature` cmdlet with the `WindowsPowerShellWebAccess` parameter. This activity is significant because enabling PowerShell Web Access can facilitate remote execution of PowerShell commands, potentially allowing an attacker to gain unauthorized access to systems and networks.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell` EventCode=4104 ScriptBlockText IN ("*Install-WindowsFeature*WindowsPowerShellWebAccess*","*Install-PswaWebApplication*","*Add-PswaAuthorizationRule*UserName *ComputerName *")
      | 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_enable_powershell_web_access_filter`
how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://help.splunk.com/en/security-offerings/splunk-user-behavior-analytics/get-data-in/5.4.1/add-other-data-to-splunk-uba/configure-powershell-logging-to-see-powershell-anomalies-in-splunk-uba.
known_false_positives: It is possible that legitimate scripts or network administrators may enable PowerShell Web Access. Monitor and escalate as needed.
references:
    - https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-241a
    - https://gist.github.com/MHaggis/7e67b659af9148fa593cf2402edebb41
finding:
    title: PowerShell Web Access has been enabled on $dest$.
    entity:
        field: dest
        type: system
        score: 50
analytic_story:
    - CISA AA24-241A
    - Malicious PowerShell
asset_type: Endpoint
mitre_attack_id:
    - T1059.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

id: '8328.18237'
title: Windows Firewall Rule Creation
description: 'Windows has several utility used to interact with networking components
  on local or remote systems. This use case looks for firewall rules added with netsh
  or New-NetFirewallRule. -- Threat Actor Association: APT29/Nobelium/Cozy Bear, APT35/Phosphorus/Magic
  Hound, BlackCat, Magnat, TA428, Volt Typhoon -- Software Association: BianLian,
  BlackByte, Black Basta, Insekt, Lockbit, Trigona -- Atomics T1021.001 Test #3 Atomics
  T1021.001 Test #4 Atomics T1562.004 Test#4'
logic_format: Splunk
logic: '"`get_endpoint_data` `get_endpoint_data_sysmon` ("EventCode=1" OR "<EventID>1<")
  ((TERM(netsh) OR "netsh.exe") TERM(add) TERM(rule)) OR "New-NetFirewallRule" | table
  _time, host, user, signature_id, process, process_*, parent_process_* | bin span=1s
  | stats values(*) as * by _time, host '
techniques:
- defense-evasion:impair defenses:disable or modify system firewall
technique_id:
- T1562.004
data_category:
- Windows Sysmon
references:
- https://www.group-ib.com/resources/threat-research/Anunak_APT_against_financial_institutions.pdf
- https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb490939(v=technet.10)?redirectedfrom=MSDN
- https://docs.microsoft.com/en-us/powershell/module/netsecurity/new-netfirewallrule?view=windowsserver2019-ps

name: Windows PowerShell Script TabExpansion Direct Call
id: d36a09b3-35ac-4d6f-964a-39fd337abc2f
version: 2
creation_date: '2026-05-05'
modification_date: '2026-05-13'
author: Raven Tait, Splunk
status: production
type: Anomaly
description: |-
    Detects specific indicators associated with the execution of the TabExpansion internal function in PowerShell.
    Calling this function directly is not normal and can be indicative of malicious activity such as TabShell.
    Due to the way PowerShell internals work it can be used in conjunction with directory transversal to load any PowerShell functions even in a sandboxed session.
    False positives could include legitimate usage of the TabExpansion function but calling it directly is very rare.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell`
    EventID="4104"
    ScriptBlockText="*$lastWord*"
    ScriptBlockText="*$_val=' + $_expression*"
    ScriptBlockText="*function Write-Members*"
    | fillnull
    | stats count min(_time) as firstTime
                  max(_time) as lastTime
      by Computer EventID ScriptBlockText signature signature_id user_id vendor_product Guid
         Opcode Name Path ProcessID ScriptBlockId

    | rename Computer as dest
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `windows_powershell_script_tabexpansion_direct_call_filter`
how_to_implement: The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
known_false_positives: Legitimate use of the TabExpansion function is rare but possible. Filter alerts if direct calls are from trusted administrative or development activities.
references:
    - https://blog.viettelcybersecurity.com/tabshell-owassrf/
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: Potential PowerShell TabExpansion activity observed on $dest$ via script block $ScriptBlockId$.
analytic_story:
    - Malicious PowerShell
asset_type: Endpoint
mitre_attack_id:
    - T1059.001
    - T1129
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Windows PowerSploit GPP Discovery
id: 0130a0df-83a1-4647-9011-841e950ff302
version: 15
creation_date: '2023-03-16'
modification_date: '2026-05-13'
author: Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic detects the execution of the Get-GPPPassword PowerShell cmdlet, which is used to search for unsecured credentials in Group Policy Preferences (GPP). This detection leverages PowerShell Script Block Logging to identify specific script block text associated with this cmdlet. Monitoring this activity is crucial as it can indicate an attempt to retrieve and decrypt stored credentials from SYSVOL, potentially leading to unauthorized access. If confirmed malicious, this activity could allow an attacker to escalate privileges or move laterally within the network by exploiting exposed credentials.
data_source:
    - Powershell Script Block Logging 4104
search: |-
    `powershell` EventCode=4104  (ScriptBlockText=Get-GPPPassword OR ScriptBlockText=Get-CachedGPPPassword)
      | 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_powersploit_gpp_discovery_filter`
how_to_implement: To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://help.splunk.com/en/security-offerings/splunk-user-behavior-analytics/get-data-in/5.4.1/add-other-data-to-splunk-uba/configure-powershell-logging-to-see-powershell-anomalies-in-splunk-uba.
known_false_positives: No false positives have been identified at this time.
references:
    - https://attack.mitre.org/techniques/T1552/006/
    - https://pentestlab.blog/2017/03/20/group-policy-preferences/
    - https://adsecurity.org/?p=2288
    - https://www.hackingarticles.in/credential-dumping-group-policy-preferences-gpp/
    - https://adsecurity.org/?p=2288
    - https://support.microsoft.com/en-us/topic/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevation-of-privilege-may-13-2014-60734e15-af79-26ca-ea53-8cd617073c30
finding:
    title: Commandlets leveraged to discover GPP credentials were executed on $dest$
    entity:
        field: user_id
        type: user
        score: 50
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 50
          message: Commandlets leveraged to discover GPP credentials were executed on $dest$
analytic_story:
    - Active Directory Privilege Escalation
asset_type: Endpoint
mitre_attack_id:
    - T1552.006
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint

name: Windows Set Network Profile Category to Private via Registry
id: b11bb510-97e1-4b7a-b673-887ab228c280
version: 4
creation_date: '2025-08-14'
modification_date: '2026-05-13'
author: Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following analytic detects attempts to modify the Windows Registry to change a network profile's category to "Private", which may indicate an adversary is preparing the environment for lateral movement or reducing firewall restrictions. Specifically, this activity involves changes to the Category value within the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{GUID} registry path. A value of 1 corresponds to a private network profile, which typically enables less restrictive firewall policies. While this action can occur during legitimate network configuration, it may also be a sign of malicious behavior when combined with other indicators such as suspicious account activity, unexpected administrative privilege usage, or execution of unsigned binaries. Monitoring for this registry modification—especially outside standard IT processes or correlated with persistence mechanisms—can help identify stealthy post-exploitation activity.
data_source:
    - Sysmon EventID 13
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry WHERE Registry.registry_path = "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Profiles\\*" Registry.registry_value_name = "Category" Registry.registry_value_data = 0x00000001 by Registry.action Registry.dest Registry.process_guid Registry.process_id Registry.registry_hive Registry.registry_path Registry.registry_key_name Registry.registry_value_data Registry.registry_value_name Registry.registry_value_type Registry.status Registry.user Registry.vendor_product | `drop_dm_object_name(Registry)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `windows_set_network_profile_category_to_private_via_registry_filter`'
how_to_implement: To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
known_false_positives: Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
references:
    - https://www.microsoft.com/en-us/security/blog/2025/07/31/frozen-in-transit-secret-blizzards-aitm-campaign-against-diplomats/
intermediate_findings:
    entities:
        - field: dest
          type: system
          score: 20
          message: A registry modification that set network profile to private on [$dest$]
analytic_story:
    - Secret Blizzard
asset_type: Endpoint
mitre_attack_id:
    - T1112
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint