Merge pull request #2941 from splunk/gitlab_release_v4.19.0

Gitlab release v4.19.0

baselines/baseline_of_kubernetes_container_network_io.yml

@@ -0,0 +1,52 @@
+name: Baseline Of Kubernetes Container Network IO
+id: 6edaca1d-d436-42d0-8df0-6895d3bf5b70
+version: 1
+date: '2023-12-19'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average and standard deviation of inbound and outbound network IO for each Kubernetes container. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. The rule generates a lookup table with the average and 
+  standard deviation of the network IO for each container. This baseline can be used to detect anomalies in network communication behavior, 
+  which may indicate security threats such as data exfiltration, command and control communication, or compromised container behavior.
+search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s 
+  | eval service = replace(''k8s.pod.name'', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "")
+  | eval key = ''k8s.cluster.name'' + ":" + ''service'' 
+  | stats avg(eval(if(direction="transmit", io,null()))) as avg_outbound_network_io avg(eval(if(direction="receive", io,null()))) as avg_inbound_network_io 
+        stdev(eval(if(direction="transmit", io,null()))) as stdev_outbound_network_io stdev(eval(if(direction="receive", io,null()))) as stdev_inbound_network_io
+        count latest(_time) as last_seen by key
+  | outputlookup k8s_container_network_io_baseline '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on (ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  detections:
+  - Kubernetes Anomalous Inbound Outbound Network IO
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.pod.network.io
+  - k8s.cluster.name 
+  - k8s.node.name
+  - k8s.pod.name  
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

baselines/baseline_of_kubernetes_container_network_io_ratio.yml

@@ -0,0 +1,55 @@
+name: Baseline Of Kubernetes Container Network IO Ratio
+id: f395003b-6389-4e14-89bf-ac4dbea215bd
+version: 1
+date: '2023-12-19'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average ratio of inbound to outbound network IO for each Kubernetes container. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. 
+  The rule generates a lookup table with the average and standard deviation of the network IO ratio for each container. 
+  This baseline can be used to detect anomalies in network communication behavior, which may indicate security threats such as data exfiltration, 
+  command and control communication, or compromised container behavior.
+search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s 
+  | eval service = replace(''k8s.pod.name'', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "") 
+  | eval key = ''k8s.cluster.name'' + ":" + ''service'' 
+  | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by key _time 
+  | eval inbound:outbound = inbound_network_io/outbound_network_io 
+  | eval outbound:inbound = outbound_network_io/inbound_network_io 
+  | stats avg(*:*) as avg_*:* stdev(*:*) as stdev_*:*
+    count latest(_time) as last_seen by key 
+  | outputlookup k8s_container_network_io_ratio_baseline '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  detections:
+  - Kubernetes Anomalous Inbound to Outbound Network IO Ratio
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.pod.network.io
+  - k8s.cluster.name 
+  - k8s.node.name
+  - k8s.pod.name  
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

baselines/baseline_of_kubernetes_process_resource.yml

@@ -0,0 +1,50 @@
+name: Baseline Of Kubernetes Process Resource
+id: f749862b-5fae-415f-940b-823bdeba2315
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average and standard deviation of various process resources in a Kubernetes environment. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. The rule generates a lookup table with the average and 
+  standard deviation of the resource utilization for each process. This baseline can be used to detect anomalies in process resource utilization, 
+  which may indicate security threats such as resource exhaustion attacks, cryptojacking, or compromised process behavior.
+search: '| mstats avg(process.*) as avg_process.* stdev(*) as stdev_* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name 
+  | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name''
+  | fillnull
+  | outputlookup k8s_process_resource_baseline'
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  detections:
+  - Kubernetes Process with Anomalous Resource Utilisation
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.*
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

baselines/baseline_of_kubernetes_process_resource_ratio.yml

@@ -0,0 +1,64 @@
+name: Baseline Of Kubernetes Process Resource Ratio
+id: 427f81cf-ce6a-4a24-a73d-70c50171ea66
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average and standard deviation of the ratio of various process resources in a Kubernetes environment. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. The rule generates a lookup table with the average and 
+  standard deviation of the resource ratios for each process. This baseline can be used to detect anomalies in process resource utilization, 
+  which may indicate security threats such as resource exhaustion attacks, cryptojacking, or compromised process behavior.
+search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s 
+  | eval cpu:mem = ''process.cpu.utilization''/''process.memory.utilization'' 
+  | eval cpu:disk = ''process.cpu.utilization''/''process.disk.operations'' 
+  | eval mem:disk = ''process.memory.utilization''/''process.memory.utilization'' 
+  | eval cpu:threads = ''process.cpu.utilization''/''process.threads'' 
+  | eval disk:threads = ''process.disk.operations''/''process.threads'' 
+  | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name''
+  | fillnull 
+  | stats avg(cpu:mem) as avg_cpu:mem stdev(cpu:mem) as stdev_cpu:mem avg(cpu:disk) as avg_cpu:disk stdev(cpu:disk) as stdev_cpu:disk
+    avg(mem:disk) as avg_mem:disk stdev(mem:disk) as stdev_mem:disk avg(cpu:threads) as avg_cpu:threads stdev(cpu:threads) as stdev_cpu:threads
+    avg(disk:threads) as avg_disk:threads stdev(disk:threads) as stdev_disk:threads count latest(_time) as last_seen by key 
+  | outputlookup k8s_process_resource_ratio_baseline '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247) 
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+
+
+
+
+
+
+  detections:
+  - Kubernetes Process with Resource Ratio Anomalies
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.*
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

contentctl.yml

@@ -5,8 +5,8 @@ build:
   name: DA-ESS-ContentUpdate
   path_root: dist
   prefix: ESCU
-  build: 004180
-  version: 4.18.0
+  build: 004190
+  version: 4.19.0
   label: ES Content Updates
   author_name: Splunk Threat Research Team
   author_email: research@splunk.com

detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml

@@ -0,0 +1,49 @@
+name: Splunk ES DoS Investigations Manager via Investigation Creation
+id: 7f6a07bd-82ef-46b8-8eba-802278abd00e
+version: 1
+date: '2024-01-04'
+author: Rod Soto, Eric McGinnis, Chase Franklin
+status: production
+type: TTP
+data_source: []
+description: In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted.
+search: '`splunkd_investigation_rest_handler` method=put msg=*investigation* status=error | stats count min(_time) as firstTime max(_time) as lastTime by user method msg 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` 
+  | `splunk_es_dos_investigations_manager_via_investigation_creation_filter`'
+how_to_implement: This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2. 
+known_false_positives: The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event. 
+references:
+- https://advisory.splunk.com/advisories/SVD-2024-0102
+tags:
+  analytic_story:
+  - Splunk Vulnerabilities
+  asset_type: Endpoint
+  confidence: 100
+  impact: 100
+  message: Denial of Service Attack against Splunk ES Investigation Manager by $user$
+  cve:
+  - CVE-2024-22165
+  mitre_attack_id:
+  - T1499
+  observable:
+  - name: user
+    type: User 
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise Security
+  risk_score: 100
+  required_fields:
+  - method
+  - msg 
+  - status 
+  - user 
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22165_investigation_rest_handler.log
+    source: /opt/splunk/var/log/splunk/investigation_handler.log
+    sourcetype: investigation_rest_handler
+    custom_index: _internal

detections/application/splunk_es_dos_through_investigation_attachments.yml

@@ -0,0 +1,51 @@
+name: Splunk ES DoS Through Investigation Attachments
+id: bb85b25e-2d6b-4e39-bd27-50db42edcb8f
+version: 1
+date: '2024-01-04'
+author: Rod Soto, Eric McGinnis, Chase Franklin
+status: production
+type: TTP
+data_source: []
+description: In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible.
+search: '`splunkd_investigation_rest_handler` status=error object=investigation 
+  | stats min(_time) as firstTime max(_time) as lastTime values(status) as status values(msg) as msg values(id) as investigation_id by user 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `splunk_es_dos_through_investigation_attachments_filter`'
+how_to_implement: This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2. 
+known_false_positives: This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager.
+references:
+- https://advisory.splunk.com/advisories/SVD-2024-0101
+tags:
+  analytic_story:
+  - Splunk Vulnerabilities
+  asset_type: Endpoint
+  confidence: 100
+  impact: 100
+  cve:
+  - CVE-2024-22164
+  message: Denial of Service detected at Splunk ES affecting $user$
+  mitre_attack_id:
+  - T1499
+  observable:
+  - name: user
+    type: User 
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise Security
+  risk_score: 100
+  required_fields:
+  - user 
+  - status 
+  - msg 
+  - id 
+  - object 
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22164_investigation_rest_handler.log
+    source: /opt/splunk/var/log/splunk/investigation_handler.log
+    sourcetype: investigation_rest_handler
+    custom_index: _internal

detections/cloud/azure_active_directory_high_risk_sign_in.yml

@@ -1,7 +1,7 @@
 name: Azure Active Directory High Risk Sign-in
 id: 1ecff169-26d7-4161-9a7b-2ac4c8e61bea
-version: 1
-date: '2022-07-11'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -10,13 +10,16 @@ description: The following analytic triggers on a high risk sign-in against Azur
   sign-in events using heuristics and machine learning to identify potentially malicious
   events and categorizes them in three categories high, medium and low.
 data_source: []
-search: ' `azuread` category=UserRiskEvents properties.riskLevel=high |
-  rename properties.* as * |  stats values(userPrincipalName) as userPrincipalName by _time, ipAddress,
-  activity, riskLevel, riskEventType, additionalInfo | `azure_active_directory_high_risk_sign_in_filter`'
+search: ' `azure_monitor_aad` category=UserRiskEvents properties.riskLevel=high
+ | rename properties.* as * 
+ | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, activity, riskLevel, riskEventType, additionalInfo  
+ | `security_content_ctime(firstTime)` 
+ | `security_content_ctime(lastTime)` 
+ | `azure_active_directory_high_risk_sign_in_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the RiskyUsers and UserRiskEvents log category.
+  Specifically, this analytic leverages the RiskyUsers and UserRiskEvents log category in the azure:monitor:aad sourcetype.
 known_false_positives: Details for the risk calculation algorithm used by Identity
   Protection are unknown and may be prone to false positives.
 references:
@@ -30,18 +33,18 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 60
-  message: A high risk event was identified by Identify Protection for user $userPrincipalName$
+  message: A high risk event was identified by Identify Protection for user $user$
   mitre_attack_id:
   - T1586
   - T1586.003
   - T1110
   - T1110.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -53,8 +56,8 @@ tags:
   - _time
   - category
   - properties.riskLevel
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   - properties.activity
   - properties.riskEventType
   - properties.additionalInfo
@@ -64,6 +67,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/azuread_highrisk/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_application_administrator_role_assigned.yml

@@ -1,7 +1,7 @@
 name: Azure AD Application Administrator Role Assigned
 id: eac4de87-7a56-4538-a21b-277897af6d8d
-version: 1
-date: '2023-04-25'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -12,16 +12,17 @@ description: The following analytic identifies the assignment of the Application
   been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while
   impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments.
   Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant.
-search: ' `azuread` "operationName"="Add member to role"  "properties.targetResources{}.modifiedProperties{}.newValue"="\"Application Administrator\"" 
+search: ' `azure_monitor_aad`  "operationName"="Add member to role"  "properties.targetResources{}.modifiedProperties{}.newValue"="\"Application Administrator\"" 
   | rename properties.* as * 
-  | rename targetResources{}.userPrincipalName as userPrincipalName 
   | rename initiatedBy.user.userPrincipalName as initiatedBy
-  | stats values(userPrincipalName) as userPrincipalName by _time, initiatedBy, result, operationName
+  | stats count min(_time) as firstTime max(_time) as lastTime by user initiatedBy, result, operationName 
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)` 
   | `azure_ad_application_administrator_role_assigned_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category
 known_false_positives: Administrators may legitimately assign the Application Administrator
   role to a user. Filter as needed.
 references:
@@ -37,13 +38,13 @@ tags:
   atomic_guid: []
   confidence: 50
   impact: 70
-  message: The privileged Azure AD role Application Administrator was assigned for User $userPrincipalName$ initiated
+  message: The privileged Azure AD role Application Administrator was assigned for User $user$ initiated
     by $initiatedBy$
   mitre_attack_id:
   - T1098
   - T1098.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -57,7 +58,7 @@ tags:
   - Splunk Cloud
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -67,6 +68,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml

@@ -1,7 +1,7 @@
 name: Azure AD Authentication Failed During MFA Challenge
 id: e62c9c2e-bf51-4719-906c-3074618fcc1c
-version: 1
-date: '2022-07-14'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -11,13 +11,16 @@ description: 'The following analytic identifies an authentication attempt event
   This behavior may represent an adversary trying to authenticate with compromised
   credentials for an account that has multi-factor authentication enabled. '
 data_source: []
-search: ' `azuread` category=SignInLogs properties.status.errorCode=500121
-  | rename properties.* as * | stats values(userPrincipalName) as userPrincipalName by _time, ipAddress,
-  status.additionalDetails, appDisplayName, userAgent | `azure_ad_authentication_failed_during_mfa_challenge_filter`'
+search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=500121
+  | rename properties.* as * 
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, status.additionalDetails, appDisplayName, user_agent
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_authentication_failed_during_mfa_challenge_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
 known_false_positives: Legitimate users may miss to reply the MFA challenge within
   the time window or deny it by mistake.
 references:
@@ -30,7 +33,7 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 60
-  message: User $userPrincipalName$ failed to pass MFA challenge
+  message: User $user$ failed to pass MFA challenge
   mitre_attack_id:
   - T1586
   - T1586.003
@@ -38,11 +41,11 @@ tags:
   - T1078.004
   - T1621
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -54,8 +57,8 @@ tags:
   - _time
   - category
   - properties.status.errorCode
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   - properties.status.additionalDetails
   - properties.appDisplayName
   - properties.userAgent
@@ -65,6 +68,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/azuread/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml

@@ -1,7 +1,7 @@
 name: Azure AD Block User Consent For Risky Apps Disabled
 id: 875de3d7-09bc-4916-8c0a-0929f4ced3d8
-version: 1
-date: '2023-10-26'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP

detections/cloud/azure_ad_concurrent_sessions_from_different_ips.yml

@@ -1,7 +1,7 @@
 name: Azure AD Concurrent Sessions From Different Ips
 id: a9126f73-9a9b-493d-96ec-0dd06695490d
-version: 1
-date: '2023-01-24'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -12,14 +12,18 @@ description: The following analytic identifies an Azure AD account with concurre
   to access corporate online resources. As users may behave differently across organizations,
   security teams should test and customize this detection to fit their environments.
 data_source: []
-search: ' `azuread` properties.authenticationDetails{}.succeeded=true category=NonInteractiveUserSignInLogs
-  | rename properties.* as * | bucket span=5m _time | stats  dc(ipAddress) AS unique_ips
-  values(ipAddress) as ipAddress values(appDisplayName) by _time, userPrincipalName | where unique_ips
-  > 1 | `azure_ad_concurrent_sessions_from_different_ips_filter`'
+search: ' `azure_monitor_aad` properties.authenticationDetails{}.succeeded=true category=NonInteractiveUserSignInLogs
+  | rename properties.* as *
+  | bucket span=30m _time 
+  | stats count min(_time) as firstTime max(_time) as lastTime dc(src_ip) AS unique_ips values(src_ip) as src_ip values(appDisplayName) as appDisplayName by user
+  | where unique_ips  > 1 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_concurrent_sessions_from_different_ips_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
 known_false_positives: A user with concurrent sessions from different Ips may also
   represent the legitimate use of more than one device. Filter as needed and/or customize
   the threshold to fit your environment.
@@ -34,16 +38,16 @@ tags:
   asset_type: Azure AD
   confidence: 60
   impact: 70
-  message: User $userPrincipalName$ has concurrent sessions from more than one unique
+  message: User $user$ has concurrent sessions from more than one unique
     IP address in the span of 5 minutes.
   mitre_attack_id:
   - T1185
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -56,14 +60,14 @@ tags:
   - properties.status.errorCode
   - category
   - properties.authenticationDetails
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   risk_score: 42
   security_domain: threat
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/azure_ad_concurrent_sessions_from_different_ips/azuread.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_device_code_authentication.yml

@@ -1,7 +1,7 @@
 name: Azure AD Device Code Authentication
 id: d68d8732-6f7e-4ee5-a6eb-737f2b990b91
-version: 1
-date: '2023-08-03'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran,  Splunk
 status: production
 type: TTP

detections/cloud/azure_ad_external_guest_user_invited.yml

@@ -1,7 +1,7 @@
 name: Azure AD External Guest User Invited
 id: c1fb4edb-cab1-4359-9b40-925ffd797fb5
-version: 1
-date: '2022-08-18'
+version: 2
+date: '2023-12-20'
 author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -13,15 +13,18 @@ description: The following analytic identifies the invitation of an external gue
   2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking
   Azure AD Accounts by Abusing External Identities`
 data_source: []
-search: '`azuread` "operationName"="Invite external user" | rename properties.*
-  as * | rename targetResources{}.userPrincipalName as userPrincipalName | rename
-  initiatedBy.user.userPrincipalName as initiatedBy | rename targetResources{}.type
-  as type | stats values(userPrincipalName) as userPrincipalName by _time, type, initiatedBy, result, operationName
+search: '`azure_monitor_aad` operationName="Invite external user" 
+  | rename properties.*  as *
+  | rename initiatedBy.user.userPrincipalName as initiatedBy 
+  | rename targetResources{}.type as type
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by type, initiatedBy, result, operationName
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` 
   | `azure_ad_external_guest_user_invited_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
 known_false_positives: Administrator may legitimately invite external guest users.
   Filter as needed.
 references:
@@ -35,11 +38,11 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 50
-  message: External Guest User $userPrincipalName$ initiated by $initiatedBy$
+  message: External Guest User $user$ initiated by $initiatedBy$
   mitre_attack_id:
   - T1136.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -53,7 +56,7 @@ tags:
   - Splunk Cloud
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -63,6 +66,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_external_guest_user_invited/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_global_administrator_role_assigned.yml

@@ -1,7 +1,7 @@
 name: Azure AD Global Administrator Role Assigned
 id: 825fed20-309d-4fd1-8aaf-cd49c1bb093c
-version: 3
-date: '2022-08-17'
+version: 4
+date: '2023-12-20'
 author: Gowthamaraj Rajendran, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -14,16 +14,17 @@ description: The following analytic identifies the assignment of the Azure AD Gl
   to gain control of Azure resources. Adversaries and red teams alike may assign this
   role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment.
 data_source: []
-search: '`azuread` operationName="Add member to role"  properties.targetResources{}.modifiedProperties{}.newValue="\"Global Administrator\""
+search: '`azure_monitor_aad`  operationName="Add member to role"  properties.targetResources{}.modifiedProperties{}.newValue="\"Global Administrator\""
   | rename properties.* as *
-  | rename targetResources{}.userPrincipalName as userPrincipalName
   | rename initiatedBy.user.userPrincipalName as initiatedBy
-  | stats values(userPrincipalName) as userPrincipalName by _time, initiatedBy, result, operationName
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by initiatedBy, result, operationName
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` 
   | `azure_ad_global_administrator_role_assigned_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
 known_false_positives: Administrators may legitimately assign the Global Administrator
   role to a user. Filter as needed.
 references:
@@ -40,12 +41,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 80
-  message: Global Administrator Role assigned for User $userPrincipalName$ initiated
+  message: Global Administrator Role assigned for User $user$ initiated
     by $initiatedBy$
   mitre_attack_id:
   - T1098.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -59,7 +60,7 @@ tags:
   - Splunk Cloud
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -69,6 +70,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_global_administrator/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_high_number_of_failed_authentications_for_user.yml

@@ -1,22 +1,27 @@
 name: Azure AD High Number Of Failed Authentications For User
 id: 630b1694-210a-48ee-a450-6f79e7679f2c
-version: 1
-date: '2023-01-23'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: The following analytic identifies an Azure AD account with more than
-  20 failed authentication events in the span of 5 minutes. This behavior could represent
+  20 failed authentication events in the span of 10 minutes. This behavior could represent
   a brute force attack against the account. As environments differ across organizations,
   security teams should customize the threshold of this detection.
 data_source: []
-search: ' `azuread` category= SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
-  | rename properties.* as * | bucket span=5m _time | stats  dc(_raw) AS failed_attempts  values(ipAddress)
-  by userPrincipalName, _time | where failed_attempts > 20 | `azure_ad_high_number_of_failed_authentications_for_user_filter`'
+search: ' `azure_monitor_aad` category= SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
+  | rename properties.* as * 
+  | bucket span=10m _time
+  | stats count min(_time) as firstTime max(_time) as lastTime values(src_ip) as src_ip by user
+  | where count > 20
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` 
+  | `azure_ad_high_number_of_failed_authentications_for_user_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
 known_false_positives: A user with more than 20 failed authentication attempts in
   the span of 5 minutes may also be triggered by a broken application.
 references:
@@ -29,13 +34,13 @@ tags:
   asset_type: Azure AD
   confidence: 70
   impact: 50
-  message: User $userPrincipalName$ failed to authenticate more than 20 times in the
+  message: User $user$ failed to authenticate more than 20 times in the
     span of 5 minutes.
   mitre_attack_id:
   - T1110
   - T1110.001
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -48,7 +53,7 @@ tags:
   - properties.status.errorCode
   - category
   - properties.authenticationDetails
-  - properties.userPrincipalName
+  - user
   - properties.ipAddress
   risk_score: 35
   security_domain: identity
@@ -56,6 +61,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_high_number_of_failed_authentications_for_user/azuread.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_high_number_of_failed_authentications_from_ip.yml

@@ -1,25 +1,30 @@
 name: Azure AD High Number Of Failed Authentications From Ip
 id: e5ab41bf-745d-4f72-a393-2611151afd8e
-version: 1
-date: '2023-01-23'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: The following analytic identifies an Ip address failing to authenticate
-  20 or more times to an Azure AD tenant in the span of 5 minutes. This behavior could
+  20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could
   represent a brute force attack againstan Azure AD to obtain initial access or elevate
   privileges. As environments differ across organizations, security teams should customize
   the threshold of this detection.
 data_source: []
-search: ' `azuread` category= SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
-  | rename properties.* as * | bucket span=5m _time | stats  dc(_raw) AS failed_attempts
-  values(userPrincipalName) as userPrincipalName by ipAddress, _time | where failed_attempts > 20 | `azure_ad_high_number_of_failed_authentications_from_ip_filter`'
+search: ' `azure_monitor_aad` category= SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
+  | rename properties.* as * 
+  | bucket span=10m _time 
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip
+  | where count > 20
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_high_number_of_failed_authentications_from_ip_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
 known_false_positives: An Ip address with more than 20 failed authentication attempts
-  in the span of 5 minutes may also be triggered by a broken application.
+  in the span of 10 minutes may also be triggered by a broken application.
 references:
 - https://attack.mitre.org/techniques/T1110/
 - https://attack.mitre.org/techniques/T1110/001/
@@ -31,18 +36,18 @@ tags:
   asset_type: Azure AD
   confidence: 70
   impact: 50
-  message: $ipAddress$ failed to authenticate more than 20 times in the span of 5
+  message: $src_ip$ failed to authenticate more than 20 times in the span of 10 minutes
     minutes.
   mitre_attack_id:
   - T1110
   - T1110.001
   - T1110.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -55,14 +60,14 @@ tags:
   - properties.status.errorCode
   - category
   - properties.authenticationDetails
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   risk_score: 35
   security_domain: identity
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_high_number_of_failed_authentications_for_user/azuread.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_multi_factor_authentication_disabled.yml

@@ -1,7 +1,7 @@
 name: Azure AD Multi-Factor Authentication Disabled
 id: 482dd42a-acfa-486b-a0bb-d6fcda27318e
-version: 1
-date: '2022-08-10'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -11,15 +11,18 @@ description: The following analytic identifies an attempt to disable multi-facto
   and maintain persistence using a valid account. This way the attackers can keep
   persistance in the environment without adding new users.
 data_source: []
-search: '`azuread` category=AuditLogs operationName="Disable Strong Authentication"
-  | rename properties.* as * | rename targetResources{}.userPrincipalName as
-  userPrincipalName | rename targetResources{}.type as type | rename initiatedBy.user.userPrincipalName
-  as initiatedBy | stats values(userPrincipalName) as userPrincipalName by _time, type, operationName,
-  initiatedBy, result | `azure_ad_multi_factor_authentication_disabled_filter`'
+search: '`azure_monitor_aad` category=AuditLogs operationName="Disable Strong Authentication"
+  | rename properties.* as *
+  | rename targetResources{}.type as type 
+  | rename initiatedBy.user.userPrincipalName as initiatedBy 
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, type, operationName, initiatedBy, result 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_multi_factor_authentication_disabled_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
 known_false_positives: Legitimate use case may require for users to disable MFA. Filter
   as needed.
 references:
@@ -33,14 +36,14 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 50
-  message: MFA disabled for User $userPrincipalName$ initiated by $initiatedBy$
+  message: MFA disabled for User $user$ initiated by $initiatedBy$
   mitre_attack_id:
   - T1586
   - T1586.003
   - T1556
   - T1556.006
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -54,7 +57,7 @@ tags:
   - Splunk Cloud
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -64,6 +67,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/azuread/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml

@@ -1,7 +1,7 @@
 name: Azure AD Multi-Source Failed Authentications Spike
 id: 116e11a9-63ea-41eb-a66a-6a13bdc7d2c7
-version: 1
-date: '2023-11-08'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: Hunting
@@ -11,8 +11,10 @@ search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50
  | rename properties.* as * 
  | bucket span=5m _time 
  | eval uniqueIPUserCombo = src_ip . "-" . user
- | stats dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, dc(location.countryOrRegion) as uniqueCountries values(user) as users, values(src_ip) as ips, values(user_agent) as user_agents, values(location.countryOrRegion) as countries by _time
- | where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20
+ | stats count min(_time) as firstTime max(_time) as lastTime dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, dc(user_agent) as uniqueUserAgents, dc(location.countryOrRegion) as uniqueCountries values(user) as users, values(src_ip) as ips, values(user_agent) as user_agents, values(location.countryOrRegion) as countries
+ | where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20 AND uniqueUserAgents = 1
+ | `security_content_ctime(firstTime)`
+ | `security_content_ctime(lastTime)`
  | `azure_ad_multi_source_failed_authentications_spike_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.

detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml

@@ -1,7 +1,7 @@
 name: Azure AD Multiple AppIDs and UserAgents Authentication Spike
 id: 5d8bb1f0-f65a-4b4e-af2e-fcdb88276314
-version: 1
-date: '2023-10-25'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: Anomaly
@@ -10,8 +10,10 @@ description: This analytic is crafted to identify unusual and potentially malici
 search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true)
    | bucket span=5m _time
    | rename properties.* as *
-   | stats  dc(_raw) as failed_attempts dc(appId) as unique_app_ids dc(userAgent) as unique_user_agents values(appDisplayName) values(deviceDetail.operatingSystem) by _time user src_ip
-   | where failed_attempts > 5 and unique_app_ids > 2 and unique_user_agents > 5
+   | stats count min(_time) as firstTime max(_time) as lastTime dc(appId) as unique_app_ids dc(userAgent) as unique_user_agents values(appDisplayName) values(deviceDetail.operatingSystem) by user, src_ip
+   | where count > 5 and unique_app_ids > 2 and unique_user_agents > 5
+   | `security_content_ctime(firstTime)`
+   | `security_content_ctime(lastTime)`
    | `azure_ad_multiple_appids_and_useragents_authentication_spike_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
@@ -44,6 +46,8 @@ tags:
   required_fields:
   - _time
   - category
+  - user
+  - src_ip
   - operationName
   - properties.authenticationRequirement
   - properties.status.additionalDetails

detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml

@@ -1,7 +1,7 @@
 name: Azure AD Multiple Denied MFA Requests For User
 id: d0895c20-de71-4fd2-b56c-3fcdb888eba1
-version: 1
-date: '2023-10-31'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -11,8 +11,8 @@ search: '`azure_monitor_aad` category=SignInLogs operationName="Sign-in activity
   | rename properties.* as * 
   | search status.errorCode=500121 status.additionalDetails="MFA denied; user declined the authentication"
   | bucket span=10m _time 
-  | stats dc(_raw) AS mfa_prompts earliest(_time) as firstTime latest(_time) as lastTime by user, status.additionalDetails, appDisplayName, userAgent, _time 
-  | where mfa_prompts > 9
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, appDisplayName, user_agent
+  | where count > 9
   | `security_content_ctime(firstTime)`
   | `security_content_ctime(lastTime)`
   | `azure_ad_multiple_denied_mfa_requests_for_user_filter`'
@@ -50,12 +50,11 @@ tags:
   required_fields:
   - _time
   - category
-  - category
   - properties.status.errorCode
   - properties.status.additionalDetails
   - user
   - properties.appDisplayName
-  - properties.userAgent
+  - user_agent
   security_domain: identity
 tests:
 - name: True Positive Test

detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml

@@ -1,7 +1,7 @@
 name: Azure AD Multiple Failed MFA Requests For User
 id: 264ea131-ab1f-41b8-90e0-33ad1a1888ea
-version: 2
-date: '2022-08-25'
+version: 3
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -22,8 +22,10 @@ data_source: []
 search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; user declined the authentication"
   | rename properties.* as * 
   | bucket span=10m _time 
-  | stats dc(_raw) AS mfa_prompts earliest(_time) as firstTime latest(_time) as lastTime by user, status.additionalDetails, appDisplayName, userAgent, _time 
-  | where mfa_prompts > 9 
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, status.additionalDetails, appDisplayName, user_agent
+  | where count > 9
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_multiple_failed_mfa_requests_for_user_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
@@ -64,8 +66,9 @@ tags:
   - properties.status.errorCode
   - category
   - properties.authenticationDetails
-  - properties.ipAddress
   - user
+  - user_agent
+  - operationName
   risk_score: 54
   security_domain: identity
 tests:

detections/cloud/azure_ad_multiple_users_failing_to_authenticate_from_ip.yml

@@ -1,7 +1,7 @@
 name: Azure AD Multiple Users Failing To Authenticate From Ip
 id: 94481a6a-8f59-4c86-957f-55a71e3612a6
-version: 1
-date: '2022-07-12'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: Anomaly
@@ -15,16 +15,18 @@ description: 'The following analytic identifies one source Ip failing to authent
   Azure AD tenants can be very different depending on the organization. Users should
   test this detection and customize the arbitrary threshold if needed.'
 data_source: []
-search: ' `azuread` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
+search: ' `azure_monitor_aad`  category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
 | rename properties.* as *
 | bucket span=5m _time
-| stats  dc(userPrincipalName) AS unique_accounts values(userPrincipalName) as userPrincipalName by _time, ipAddress
-| where unique_accounts > 30 
+| stats count min(_time) as firstTime max(_time) as lastTime dc(user) AS unique_accounts values(user) as user by src_ip
+| where unique_accounts > 30
+| `security_content_ctime(firstTime)` 
+| `security_content_ctime(lastTime)`
 | `azure_ad_multiple_users_failing_to_authenticate_from_ip_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
 known_false_positives: A source Ip failing to authenticate with multiple users is
   not a common for legitimate behavior.
 references:
@@ -38,7 +40,7 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 70
-  message: Source Ip $ipAddress$ failed to authenticate with 30 users
+  message: Source Ip $src_ip$ failed to authenticate with 30 users
     within 5 minutes.
   mitre_attack_id:
   - T1586
@@ -47,11 +49,11 @@ tags:
   - T1110.003
   - T1110.004
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -64,14 +66,14 @@ tags:
   - properties.status.errorCode
   - category
   - properties.authenticationDetails
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - user_agent
   risk_score: 63
   security_domain: identity
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/password_spraying_azuread/azuread_signin.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_new_custom_domain_added.yml

@@ -1,7 +1,7 @@
 name: Azure AD New Custom Domain Added
 id: 30c47f45-dd6a-4720-9963-0bca6c8686ef
-version: 1
-date: '2022-09-02'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -19,15 +19,17 @@ description: The following analytic identifies the addition of a new custom doma
   persistence and be able to authenticate to Azure AD impersonating any user and bypassing
   the requirement to have a valid password and/or perform MFA.
 data_source: []
-search: ' `azuread` operationName="Add unverified domain" "properties.result"=success
-  | rename properties.* as * | rename callerIpAddress as callerIpAddress
-  | rename initiatedBy.user.userPrincipalName as initiatedBy | rename targetResources{}.displayName
-  as domain | stats values(domain) by _time, initiatedBy, result, operationName,
-  callerIpAddress | `azure_ad_new_custom_domain_added_filter`'
+search: ' `azure_monitor_aad`  operationName="Add unverified domain" properties.result=success
+  | rename properties.* as * 
+  | rename targetResources{}.displayName as domain
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, domain, result, operationName, src_ip
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_new_custom_domain_added_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
 known_false_positives: In most organizations, new customm domains will be updated
   infrequently. Filter as needed.
 references:
@@ -43,12 +45,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 60
-  message: A new custom domain, $domain$ , was added by $initiatedBy$
+  message: A new custom domain, $domain$ , was added by $user$
   mitre_attack_id:
   - T1484
   - T1484.002
   observable:
-  - name: initiatedBy
+  - name: user
     type: User
     role:
     - Attacker
@@ -60,15 +62,15 @@ tags:
   - _time
   - operationName
   - properties.result
-  - callerIpAddress
+  - src_ip
   - properties.targetResources{}.displayName
-  - properties.initiatedBy.user.userPrincipalName
+  - user
   risk_score: 54
   security_domain: threat
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.002/new_federated_domain/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_new_federated_domain_added.yml

@@ -1,7 +1,7 @@
 name: Azure AD New Federated Domain Added
 id: a87cd633-076d-4ab2-9047-977751a3c1a0
-version: 1
-date: '2022-09-02'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -19,15 +19,17 @@ description: The following analytic identifies the addition of a new federated d
   persistence and be able to authenticate to Azure AD impersonating any user and bypassing
   the requirement to have a valid password and/or perform MFA.
 data_source: []
-search: ' `azuread` operationName="Set domain authentication" "properties.result"=success
-  | rename properties.* as * | rename callerIpAddress as callerIpAddress
-  | rename initiatedBy.user.userPrincipalName as initiatedBy | rename targetResources{}.displayName
-  as domain | stats values(domain) by _time, initiatedBy, result, operationName,
-  callerIpAddress | `azure_ad_new_federated_domain_added_filter`'
+search: ' `azure_monitor_aad`  operationName="Set domain authentication" "properties.result"=success
+  | rename properties.* as * 
+  | rename targetResources{}.displayName as domain 
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, domain, result, operationName, src_ip
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_new_federated_domain_added_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
 known_false_positives: In most organizations, domain federation settings will be updated
   infrequently. Filter as needed.
 references:
@@ -42,12 +44,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 90
-  message: A new federated domain, $domain$ , was added by $initiatedBy$
+  message: A new federated domain, $domain$ , was added by $user$
   mitre_attack_id:
   - T1484
   - T1484.002
   observable:
-  - name: initiatedBy
+  - name: user
     type: User
     role:
     - Attacker
@@ -59,15 +61,15 @@ tags:
   - _time
   - operationName
   - properties.result
-  - callerIpAddress
+  - src_ip
   - properties.targetResources{}.displayName
-  - properties.initiatedBy.user.userPrincipalName
+  - user
   risk_score: 81
   security_domain: threat
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1484.002/new_federated_domain/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_new_mfa_method_registered.yml

@@ -1,7 +1,7 @@
 name: Azure AD New MFA Method Registered
 id: 0488e814-eb81-42c3-9f1f-b2244973e3a3
-version: 1
-date: '2023-10-31'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP

detections/cloud/azure_ad_new_mfa_method_registered_for_user.yml

@@ -1,7 +1,7 @@
 name: Azure AD New MFA Method Registered For User
 id: 2628b087-4189-403f-9044-87403f777a1b
-version: 1
-date: '2023-01-30'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -9,14 +9,17 @@ description: The following analytic identifies the registration of a new Multi F
   authentication method for an Azure AD account. Adversaries who have obtained unauthorized
   access to an Azure AD account may register a new MFA method to maintain persistence.
 data_source: []
-search: ' `azuread` category=AuditLogs operationName="User registered security info"
-  properties.operationType=Add | rename properties.* as * | rename targetResources{}.*
-  as * | stats  values(userPrincipalName) as userPrincipalName by _time, resultDescription, result, callerIpAddress
+search: ' `azure_monitor_aad` category=AuditLogs operationName="User registered security info" properties.operationType=Add 
+  | rename properties.* as *
+  | rename targetResources{}.* as *
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, resultDescription, result, src_ip
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_new_mfa_method_registered_for_user_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
 known_false_positives: Newly onboarded users who are registering an MFA method for
   the first time will also trigger this detection.
 references:
@@ -31,16 +34,16 @@ tags:
   asset_type: Azure Active Directory
   confidence: 80
   impact: 80
-  message: UPDATE message
+  message: A new MFA method was registered for user $user$
   mitre_attack_id:
   - T1556
   - T1556.006
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: callerIpAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -53,16 +56,16 @@ tags:
   - category
   - operationName
   - properties.operationType
-  - userPrincipalName
+  - user
   - resultDescription
   - result
-  - callerIpAddress
+  - src_ip
   risk_score: 64
   security_domain: identity
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/azure_ad_new_mfa_method_registered_for_user/azuread.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml

@@ -1,7 +1,7 @@
 name: Azure AD OAuth Application Consent Granted By User
 id: 10ec9031-015b-4617-b453-c0c1ab729007
-version: 1
-date: '2023-10-27'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP

detections/cloud/azure_ad_pim_role_assigned.yml

@@ -1,7 +1,7 @@
 name: Azure AD PIM Role Assigned
 id: fcd6dfeb-191c-46a0-a29c-c306382145ab
 version: 2
-date: '2023-11-07'
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -12,16 +12,16 @@ description: The following analytic identifies the assignment of the Azure AD PI
   assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful
   security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their
   legitimacy.
-search: ' `azuread` operationName="Add eligible member to role in PIM completed*"
+search: ' `azure_monitor_aad` operationName="Add eligible member to role in PIM completed*"
   | rename properties.* as * 
-  | rename targetResources{}.userPrincipalName as userPrincipalName 
-  | rename initiatedBy.user.userPrincipalName as initiatedBy
-  | stats values(userPrincipalName) as userPrincipalName values(targetResources{}.displayName) as target_display_name by _time, result, operationName, initiatedBy
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user values(targetResources{}.displayName) as displayName  by result, operationName, initiatedBy.user.displayName 
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_pim_role_assigned_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: As part of legitimate administrative behavior, users may be assigned PIM roles. Filter as needed
 references:
 - https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
@@ -34,16 +34,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 50
   impact: 70
-  message: An Azure AD PIM role assignment was assiged to $userPrincipalName$ by $initiatedBy$
+  message: An Azure AD PIM role assignment was assiged to $user$
   mitre_attack_id:
   - T1098
   - T1098.003
   observable:
-  - name: initiatedBy
-    type: User
-    role:
-    - Attacker
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -56,7 +52,7 @@ tags:
   - _time
   - properties
   - operationName
-  - userPrincipalName
+  - user
   - initiatedBy.user.userPrincipalName 
   - result
   security_domain: identity
@@ -64,5 +60,5 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_pim_role_activated/azure-audit.log
-    source: eventhub://researchhub1.servicebus.windows.net/azureadhub;
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad

detections/cloud/azure_ad_pim_role_assignment_activated.yml

@@ -1,7 +1,7 @@
 name: Azure AD PIM Role Assignment Activated
 id: 952e80d0-e343-439b-83f4-808c3e6fbf2e
-version: 2
-date: '2023-11-07'
+version: 3
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -12,15 +12,17 @@ description: The following analytic identifies the assignment of the Azure AD PI
   assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful
   security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their
   legitimacy.
-search: ' `azuread` operationName="Add member to role completed (PIM activation)"
+search: ' `azure_monitor_aad` operationName="Add member to role completed (PIM activation)"
   | rename properties.* as * 
-  | rename targetResources{}.userPrincipalName as userPrincipalName | rename initiatedBy.user.userPrincipalName as initiatedBy
-  | stats values(userPrincipalName) as userPrincipalName values(targetResources{}.displayName) as target_display_name by _time, initiatedBy, result, operationName,
+  | rename initiatedBy.user.userPrincipalName as initiatedBy
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user values(targetResources{}.displayName) as displayName by initiatedBy, result, operationName
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_pim_role_assignment_activated_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: As part of legitimate administrative behavior, users may activate PIM roles. Filter as needed
 references:
 - https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
@@ -33,12 +35,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 50
   impact: 70
-  message: An Azure AD PIM role assignment was activated by $initiatedBy$
+  message: An Azure AD PIM role assignment was activated by $initiatedBy$ by $user$
   mitre_attack_id:
   - T1098
   - T1098.003
   observable:
-  - name: initiatedBy
+  - name: user
     type: User
     role:
     - Attacker
@@ -50,7 +52,7 @@ tags:
   - _time
   - properties
   - operationName
-  - userPrincipalName
+  - user
   - initiatedBy.user.userPrincipalName 
   - result
   risk_score: 35
@@ -60,4 +62,4 @@ tests:
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_pim_role_activated/azure-audit.log
     source: eventhub://researchhub1.servicebus.windows.net/azureadhub;
-    sourcetype: mscs:azure:eventhub
+    sourcetype: azure:monitor:aad

detections/cloud/azure_ad_privileged_authentication_administrator_role_assigned.yml

@@ -1,7 +1,7 @@
 name: Azure AD Privileged Authentication Administrator Role Assigned
 id: a7da845d-6fae-41cf-b823-6c0b8c55814a
-version: 1
-date: '2023-04-25'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -10,16 +10,17 @@ description: The following analytic identifies the assignment of the Privileged
   methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive
   or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions.
   Red teams and adversaries alike may abuse this role to escalate their privileges.
-search: ' `azuread` "operationName"="Add member to role"  "properties.targetResources{}.modifiedProperties{}.newValue"="\"Privileged Authentication Administrator\"" 
+search: ' `azure_monitor_aad`  "operationName"="Add member to role"  "properties.targetResources{}.modifiedProperties{}.newValue"="\"Privileged Authentication Administrator\"" 
   | rename properties.* as * 
-  | rename targetResources{}.userPrincipalName as userPrincipalName 
   | rename initiatedBy.user.userPrincipalName as initiatedBy
-  | stats values(userPrincipalName) as userPrincipalName by _time, initiatedBy, result, operationName
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by initiatedBy, result, operationName
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_privileged_authentication_administrator_role_assigned_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: Administrators may legitimately assign the Privileged Authentication Administrator role
   as part of administrative tasks. Filter as needed.
 references:
@@ -32,12 +33,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 50
   impact: 100
-  message: The privileged Azure AD role Privileged Authentication Administrator was assigned for User $userPrincipalName$ initiated
+  message: The privileged Azure AD role Privileged Authentication Administrator was assigned for User $user$ initiated
     by $initiatedBy$
   mitre_attack_id:
   - T1003.002
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -51,7 +52,7 @@ tags:
   - Splunk Cloud
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -61,6 +62,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_privileged_role_assigned.yml

@@ -1,7 +1,7 @@
 name: Azure AD Privileged Role Assigned
 id: a28f0bc3-3400-4a6e-a2da-89b9e95f0d2a
-version: 1
-date: '2022-08-29'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -10,19 +10,20 @@ description: The following analytic identifies the assignment of sensitive and p
   may assign these roles to a compromised account to establish Persistence in an Azure
   AD environment.
 data_source: []
-search: ' `azuread` "operationName"="Add member to role" | rename properties.*  as * 
-  | rename targetResources{}.userPrincipalName as userPrincipalName 
+search: ' `azure_monitor_aad`  "operationName"="Add member to role" | rename properties.*  as * 
   | rename initiatedBy.user.userPrincipalName as initiatedBy 
   | rename targetResources{}.modifiedProperties{}.newValue  as roles 
   | eval role=mvindex(roles,1) 
   | lookup privileged_azure_ad_roles azureadrole AS role OUTPUT isprvilegedadrole description 
   | search isprvilegedadrole = True
-  | stats values(userPrincipalName) as userPrincipalName by _time, initiatedBy, result, operationName, role, description 
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by initiatedBy, result, operationName, role, description 
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_privileged_role_assigned_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: Administrators will legitimately assign the privileged roles
   users as part of administrative tasks. Filter as needed.
 references:
@@ -38,13 +39,13 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 70
-  message: A privileged Azure AD role was assigned for User $userPrincipalName$ initiated
+  message: A privileged Azure AD role was assigned for User $user$ initiated
     by $initiatedBy$
   mitre_attack_id:
   - T1098
   - T1098.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -58,7 +59,7 @@ tags:
   - Splunk Cloud
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -68,6 +69,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_assign_privileged_role/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml

@@ -1,23 +1,30 @@
 name: Azure AD Privileged Role Assigned to Service Principal
 id: 5dfaa3d3-e2e4-4053-8252-16d9ee528c41
 version: 2
-date: '2023-04-28'
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: "The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals."
 data_source: []
-search: ' `azuread` operationName="Add member to role" | rename properties.* as *
-  | search "targetResources{}.type"=ServicePrincipal | rename initiatedBy.user.userPrincipalName
-  as initiatedBy | rename targetResources{}.modifiedProperties{}.newValue  as roles
-  | eval role=mvindex(roles,1) | rename targetResources{}.displayName as apps | eval
-  displayName=mvindex(apps,0) | lookup privileged_azure_ad_roles azureadrole AS role
-  OUTPUT isprvilegedadrole description | search isprvilegedadrole = True | stats values(displayName)
-  by _time, initiatedBy, result, operationName, role | `azure_ad_privileged_role_assigned_to_service_principal_filter`'
+search: ' `azure_monitor_aad`  operationName="Add member to role" 
+  | rename properties.* as *
+  | search "targetResources{}.type"=ServicePrincipal
+  | rename initiatedBy.user.userPrincipalName as initiatedBy 
+  | rename targetResources{}.modifiedProperties{}.newValue  as roles
+  | eval role=mvindex(roles,1) 
+  | rename targetResources{}.displayName as apps 
+  | eval displayName=mvindex(apps,0) 
+  | lookup privileged_azure_ad_roles azureadrole AS role OUTPUT isprvilegedadrole description 
+  | search isprvilegedadrole = True 
+  | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by initiatedBy, result, operationName, role
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_privileged_role_assigned_to_service_principal_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: Administrators may legitimately assign the privileged roles
   to Service Principals as part of administrative tasks. Filter as needed.
 references:
@@ -45,7 +52,6 @@ tags:
   risk_score: 35
   required_fields:
   - _time
-  - properties.targetResources{}.userPrincipalName
   - properties.targetResources{}.type
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
@@ -54,6 +60,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_privileged_role_serviceprincipal/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_service_principal_created.yml

@@ -14,17 +14,18 @@ description: The following analytic identifies the creation of a Service Princip
   access may create a Service Principal to establish Persistence and obtain single-factor
   access to an Azure AD environment.
 data_source: []
-search: '`azuread` operationName="Add service principal" properties.initiatedBy.user.id=*
+search: '`azure_monitor_aad`  operationName="Add service principal" properties.initiatedBy.user.id=*
   | rename properties.* as * 
   | rename targetResources{}.displayName as displayName
-  | rename initiatedBy.user.userPrincipalName as initiatedBy
   | rename targetResources{}.type as type
-  | stats values(displayName) as displayName by _time, type, initiatedBy, result, operationName
+  | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by type, user, result, operationName 
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_service_principal_created_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment thorough an EventHub.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: Administrator may legitimately create Service Principal. Filter
   as needed.
 references:
@@ -39,7 +40,7 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 50
-  message: Service Principal named $displayName$ created by $initiatedBy$
+  message: Service Principal named $displayName$ created by $user$
   mitre_attack_id:
   - T1136.003
   observable:
@@ -47,7 +48,7 @@ tags:
     type: Other
     role:
     - Victim
-  - name: initiatedBy
+  - name: user
     type: User
     role:
     - Attacker
@@ -59,7 +60,7 @@ tags:
   - _time
   - properties.targetResources{}.displayName
   - properties.targetResources{}.type
-  - properties.initiatedBy.user.userPrincipalName
+  - user
   - properties.result
   risk_score: 45
   security_domain: threat
@@ -67,6 +68,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.003/azure_ad_add_service_principal/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_service_principal_new_client_credentials.yml

@@ -1,7 +1,7 @@
 name: Azure AD Service Principal New Client Credentials
 id: e3adc0d3-9e4b-4b5d-b662-12cec1adff2a
 version: 2
-date: '2022-08-17'
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -16,14 +16,17 @@ description: The following analytic identifies the addition of new credentials f
   with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and 
   logging in as the service principal.
 data_source: []
-search: ' `azuread` category=AuditLogs operationName="Update application*Certificates
-  and secrets management " | rename * as * | rename properties.* as * | rename
-  targetResources{}.* as * | stats values(displayName) as displayName by _time, initiatedBy.user.userPrincipalName,
-  modifiedProperties{}.newValue | `azure_ad_service_principal_new_client_credentials_filter`'
+search: ' `azure_monitor_aad`  category=AuditLogs operationName="Update application*Certificates and secrets management "
+ | rename properties.* as * 
+ | rename  targetResources{}.* as * 
+ | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by user, modifiedProperties{}.newValue, src_ip
+ | `security_content_ctime(firstTime)` 
+ | `security_content_ctime(lastTime)`
+ | `azure_ad_service_principal_new_client_credentials_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
 known_false_positives: Service Principal client credential modifications may be part
   of legitimate administrative operations. Filter as needed.
 references:
@@ -49,7 +52,7 @@ tags:
     type: User
     role:
     - Victim
-  - name: initiatedBy.user.userPrincipalName
+  - name: user
     type: User
     role:
     - Attacker
@@ -61,15 +64,16 @@ tags:
   - _time
   - category
   - operationName
-  - properties.initiatedBy.user.userPrincipalName
+  - user
   - properties.targetResources{}.displayName
   - properties.targetResources{}.modifiedProperties{}.newValue
+  - src_ip
   risk_score: 35
   security_domain: threat
 tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/azure_ad_service_principal_credentials/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_service_principal_owner_added.yml

@@ -1,7 +1,7 @@
 name: Azure AD Service Principal Owner Added
 id: 7ddf2084-6cf3-4a44-be83-474f7b73c701
-version: 2
-date: '2022-08-30'
+version: 3
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -15,19 +15,21 @@ description: The following analytic identifies the addition of a new owner for a
   and obtain single-factor access to an Azure AD environment. Attackers who are looking to
   escalate their privileges by leveraging a Service Principals permissions may also add a new owner.
 data_source: []
-search: ' `azuread` operationName="Add owner to application"
+search: ' `azure_monitor_aad`  operationName="Add owner to application"
   | rename properties.* as *
   | rename initiatedBy.user.userPrincipalName as initiatedBy
   | rename targetResources{}.userPrincipalName as newOwner
   | rename targetResources{}.modifiedProperties{}.newValue as displayName
   | eval displayName = mvindex(displayName,1) 
   | where initiatedBy!=newOwner
-  | stats values(displayName) as displayName by _time, initiatedBy, result, operationName, newOwner
+  | stats count min(_time) as firstTime max(_time) as lastTime values(displayName) as displayName by initiatedBy, result, operationName, newOwner
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
   | `azure_ad_service_principal_owner_added_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: Administrator may legitimately add new owners for Service Principals.
   Filter as needed.
 references:
@@ -68,6 +70,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_add_serviceprincipal_owner/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_successful_authentication_from_different_ips.yml

@@ -1,25 +1,29 @@
 name: Azure AD Successful Authentication From Different Ips
 id: be6d868d-33b6-4aaa-912e-724fb555b11a
-version: 1
-date: '2023-01-24'
+version: 3
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: The following analytic identifies an Azure AD account successfully authenticating
-  from more than one unique Ip address in the span of 5 minutes. This behavior could
+  from more than one unique Ip address in the span of 30 minutes. This behavior could
   represent an adversary who has stolen credentials via a phishing attack or some
   other method and using them to access corporate online resources around the same
   time as a legitimate user. As users may behave differently across organizations,
   security teams should test and customize this detection to fit their environments.
 data_source: []
-search: ' `azuread` properties.authenticationDetails{}.succeeded=true category=SignInLogs
-  | rename properties.* as * | bucket span=5m _time | stats  dc(ipAddress) AS unique_ips
-  values(ipAddress) as ipAddress values(appDisplayName) by _time, userPrincipalName | where unique_ips
-  > 1 | `azure_ad_successful_authentication_from_different_ips_filter`'
+search: ' `azure_monitor_aad`  properties.authenticationDetails{}.succeeded=true category=SignInLogs
+  | rename properties.* as *
+  | bucket span=30m _time 
+  | stats count min(_time) as firstTime max(_time) as lastTime dc(src_ip) AS unique_ips values(src_ip) as src_ip values(appDisplayName) as appDisplayName by user
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | where unique_ips  > 1 
+  | `azure_ad_successful_authentication_from_different_ips_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
 known_false_positives: A user with successful authentication events from different
   Ips may also represent the legitimate use of more than one device. Filter as needed
   and/or customize the threshold to fit your environment.
@@ -34,18 +38,18 @@ tags:
   asset_type: Azure AD
   confidence: 80
   impact: 70
-  message: User $userPrincipalName$ has had successful authentication events from
-    more than one unique IP address in the span of 5 minutes.
+  message: User $user$ has had successful authentication events from
+    more than one unique IP address in the span of 30 minutes.
   mitre_attack_id:
   - T1110
   - T1110.001
   - T1110.003
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -58,8 +62,8 @@ tags:
   - properties.status.errorCode
   - category
   - properties.authenticationDetails
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   - properties.appDisplayName
   risk_score: 56
   security_domain: identity
@@ -67,6 +71,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.001/azure_ad_successful_authentication_from_different_ips/azuread.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_successful_powershell_authentication.yml

@@ -1,7 +1,7 @@
 name: Azure AD Successful PowerShell Authentication
 id: 62f10052-d7b3-4e48-b57b-56f8e3ac7ceb
-version: 1
-date: '2022-07-13'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -11,14 +11,16 @@ description: The following analytic identifies a successful authentication event
   and red teams  alike will perform enumeration and discovery techniques. One method
   of executing these techniques is leveraging the native PowerShell modules.
 data_source: []
-search: ' `azuread` category=SignInLogs properties.authenticationDetails{}.succeeded=true
-  properties.appDisplayName="Microsoft Azure PowerShell" | rename properties.*
-  as * |  stats values(userPrincipalName) as userPrincipalName by _time, ipAddress, appDisplayName, userAgent
-  | `azure_ad_successful_powershell_authentication_filter`'
+search: ' `azure_monitor_aad`  category=SignInLogs properties.authenticationDetails{}.succeeded=true properties.appDisplayName="Microsoft Azure PowerShell"
+ | rename properties.*  as * 
+ | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, appDisplayName, user_agent
+ | `security_content_ctime(firstTime)` 
+ | `security_content_ctime(lastTime)`
+ | `azure_ad_successful_powershell_authentication_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
 known_false_positives: Administrative users will likely use PowerShell commandlets
   to troubleshoot and maintain the environment. Filter as needed.
 references:
@@ -32,7 +34,7 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 60
-  message: Successful authentication for user $userPrincipalName$
+  message: Successful authentication for user $user$
     using PowerShell.
   mitre_attack_id:
   - T1586
@@ -40,11 +42,11 @@ tags:
   - T1078
   - T1078.004
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -56,8 +58,8 @@ tags:
   - _time
   - properties.appDisplayName
   - category
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   - properties.appDisplayName
   - properties.userAgent
   risk_score: 54
@@ -66,6 +68,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azuread_pws/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_successful_single_factor_authentication.yml

@@ -1,7 +1,7 @@
 name: Azure AD Successful Single-Factor Authentication
 id: a560e7f6-1711-4353-885b-40be53101fcd
-version: 1
-date: '2022-07-12'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -10,14 +10,14 @@ description: The following analytic identifies a successful authentication event
   This could be evidence of a missconfiguration, a policy violation or an account
   take over attempt that should be investigated
 data_source: []
-search: ' `azuread`  category=SignInLogs properties.authenticationRequirement=singleFactorAuthentication
-  properties.authenticationDetails{}.succeeded=true | rename properties.*
-  as * |  stats values(userPrincipalName) as userPrincipalName by _time, ipAddress, appDisplayName, authenticationRequirement
-  | `azure_ad_successful_single_factor_authentication_filter`'
+search: ' `azure_monitor_aad` category=SignInLogs properties.authenticationRequirement=singleFactorAuthentication properties.authenticationDetails{}.succeeded=true
+   | rename properties.* as * 
+   | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user by src_ip, appDisplayName, authenticationRequirement
+   | `azure_ad_successful_single_factor_authentication_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
 known_false_positives: Although not recommended, certain users may be required without
   multi-factor authentication. Filter as needed
 references:
@@ -30,7 +30,7 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 50
-  message: Successful authentication for user $userPrincipalName$
+  message: Successful authentication for user $user$
     without MFA
   mitre_attack_id:
   - T1586
@@ -38,11 +38,11 @@ tags:
   - T1078
   - T1078.004
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
-  - name: ipAddress
+  - name: src_ip
     type: IP Address
     role:
     - Attacker
@@ -55,8 +55,8 @@ tags:
   - category
   - properties.authenticationRequirement
   - properties.authenticationDetails
-  - properties.userPrincipalName
-  - properties.ipAddress
+  - user
+  - src_ip
   - properties.appDisplayName
   risk_score: 45
   security_domain: identity
@@ -64,6 +64,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/azuread/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_unusual_number_of_failed_authentications_from_ip.yml

@@ -21,7 +21,7 @@ description: 'The following analytic identifies one source Ip failing to authent
   coverage. A similar analytic following the threshold model is `Azure AD Multiple
   Users Failing To Authenticate From Ip`.'
 data_source: []
-search: ' `azuread` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
+search: ' `azure_monitor_aad`  category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false
   | rename properties.* as *
   | bucket span=5m _time
   | stats  dc(userPrincipalName) AS unique_accounts values(userPrincipalName) as userPrincipalName by _time, ipAddress
@@ -33,7 +33,7 @@ search: ' `azuread` category=SignInLogs properties.status.errorCode=50126 proper
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub.
-  Specifically, this analytic leverages the SignInLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
 known_false_positives: A source Ip failing to authenticate with multiple users is
   not a common for legitimate behavior.
 references:
@@ -80,6 +80,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/password_spraying_azuread/azuread_signin.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml

@@ -1,7 +1,7 @@
 name: Azure AD User Consent Denied for OAuth Application
 id: bb093c30-d860-4858-a56e-cd0895d5b49c
-version: 1
-date: '2023-10-27'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP

detections/cloud/azure_ad_user_enabled_and_password_reset.yml

@@ -1,7 +1,7 @@
 name: Azure AD User Enabled And Password Reset
 id: 1347b9e8-2daa-4a6f-be73-b421d3d9e268
-version: 1
-date: '2022-08-29'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk
 status: production
 type: TTP
@@ -10,17 +10,18 @@ description: The following analytic identifies an Azure AD user enabling a previ
   represent an adversary who has obtained administrative access and is trying to establish
   a backdoor identity within an Azure AD tenant.
 data_source: []
-search: ' `azuread` (operationName="Enable account" OR operationName="Reset password (by admin)" 
-  OR operationName="Update user") | transaction properties.targetResources{}.userPrincipalName
-  startsWith=(operationName="Enable account") endsWith=(operationName="Reset password (by admin)") maxspan=2m 
-  | rename properties.* as * | rename targetResources{}.userPrincipalName
-  as user | rename initiatedBy.user.userPrincipalName as initiatedBy
-  | stats values(operationName) values(initiatedBy) as initiatedBy by _time, user,
-  result | `azure_ad_user_enabled_and_password_reset_filter`'
+search: ' `azure_monitor_aad`  (operationName="Enable account" OR operationName="Reset password (by admin)" OR operationName="Update user")
+   | transaction user startsWith=(operationName="Enable account") endsWith=(operationName="Reset password (by admin)") maxspan=2m 
+   | rename properties.* as * 
+   | rename initiatedBy.user.userPrincipalName as initiatedBy
+   | stats count min(_time) as firstTime max(_time) as lastTime values(operationName) as operationName values(initiatedBy) as initiatedBy by user, result
+   | `security_content_ctime(firstTime)`
+   | `security_content_ctime(lastTime)`
+   | `azure_ad_user_enabled_and_password_reset_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: While not common, Administrators may enable accounts and reset
   their passwords for legitimate reasons. Filter as needed.
 references:
@@ -31,7 +32,7 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 50
-  message: A user account, $userPrincipalName$, was enabled and its password reset within
+  message: A user account, $user$, was enabled and its password reset within
     2 minutes by $initiatedBy$
   mitre_attack_id:
   - T1098
@@ -51,7 +52,7 @@ tags:
   required_fields:
   - _time
   - operationName
-  - properties.targetResources{}.userPrincipalName
+  - user
   - properties.initiatedBy.user.userPrincipalName
   - properties.result
   risk_score: 45
@@ -60,6 +61,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_enable_and_reset/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_ad_user_immutableid_attribute_updated.yml

@@ -20,16 +20,18 @@ description: The following analytic identifies the modification of the SourceAnc
   to Azure AD impersonating any user and bypassing the requirement to have a valid
   password and/or perform MFA.
 data_source: []
-search: ' `azuread` operationName="Update user" properties.targetResources{}.modifiedProperties{}.displayName=SourceAnchor
-  | rename properties.* as * | rename targetResources{}.userPrincipalName as
-  userPrincipalName | rename initiatedBy.user.userPrincipalName as initiatedBy | rename
-  callerIpAddress as callerIpAddress | rename targetResources{}.modifiedProperties{}.newValue
-  as modifiedProperties | stats values(userPrincipalName) as userPrincipalName values(modifiedProperties)
-  by _time, initiatedBy, callerIpAddress, result, operationName | `azure_ad_user_immutableid_attribute_updated_filter`'
+search: ' `azure_monitor_aad`  operationName="Update user" properties.targetResources{}.modifiedProperties{}.displayName=SourceAnchor
+  | rename properties.* as * 
+  | rename initiatedBy.user.userPrincipalName as initiatedBy 
+  | rename targetResources{}.modifiedProperties{}.newValue as modifiedProperties
+  | stats count min(_time) as firstTime max(_time) as lastTime values(user) as user values(modifiedProperties) as modifiedProperties by initiatedBy, src_ip, result, operationName
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `azure_ad_user_immutableid_attribute_updated_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Active Directory events into your Splunk environment.
-  Specifically, this analytic leverages the AuditLogs log category.
+  This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
 known_false_positives: The SourceAnchor (also called ImmutableId) Azure AD attribute
   has legitimate uses for directory synchronization. Investigate and filter as needed.
 references:
@@ -45,12 +47,12 @@ tags:
   asset_type: Azure Active Directory
   confidence: 90
   impact: 50
-  message: The SourceAnchor or ImmutableID attribute has been modified for user $userPrincipalName$
+  message: The SourceAnchor or ImmutableID attribute has been modified for user $user$
     by $initiatedBy$
   mitre_attack_id:
   - T1098
   observable:
-  - name: userPrincipalName
+  - name: user
     type: User
     role:
     - Victim
@@ -70,6 +72,6 @@ tests:
 - name: True Positive Test
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/azure_ad_set_immutableid/azure-audit.log
-    source: mscs:azure:eventhub
-    sourcetype: mscs:azure:eventhub
+    source: Azure AD
+    sourcetype: azure:monitor:aad
     update_timestamp: true

detections/cloud/azure_automation_account_created.yml

@@ -1,7 +1,7 @@
 name: Azure Automation Account Created
 id: 860902fd-2e76-46b3-b050-ba548dab576c
-version: 1
-date: '2022-08-18'
+version: 2
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -18,9 +18,14 @@ description: The following analytic identifies the creation of a new Azure Autom
   to maintain persistence in the Azure tenant. A malicious Automation Runbook can
   be created to create Global Administrators in Azure AD, execute code on VMs, etc.
 data_source: []
-search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation
-  account" status.value=Succeeded | dedup object | stats values(object) by _time,
-  caller, claims.ipaddr, resourceGroupName, object_path | `azure_automation_account_created_filter`'
+search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation account" status.value=Succeeded 
+  | dedup object 
+  | rename claims.ipaddr as src_ip
+  | rename caller as user
+  | stats count min(_time) as firstTime max(_time) as lastTime values(object) as object by user, src_ip, resourceGroupName, object_path 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `azure_automation_account_created_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Audit events into your Splunk environment. Specifically,
@@ -41,7 +46,7 @@ tags:
   asset_type: Azure
   confidence: 90
   impact: 70
-  message: A new Azure Automation account $object$ was created by $caller$
+  message: A new Azure Automation account $object$ was created by $user$
   mitre_attack_id:
   - T1136
   - T1136.003
@@ -50,7 +55,7 @@ tags:
     type: Other
     role:
     - Victim
-  - name: caller
+  - name: user
     type: User
     role:
     - Attacker

detections/cloud/azure_automation_runbook_created.yml

@@ -15,9 +15,13 @@ description: The following analytic identifies the creation of a new Azure Autom
   Automation Runbook can be created to create Global Administrators in Azure AD, execute
   code on VMs, etc.
 data_source: []
-search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation
-  Runbook" object!=AzureAutomationTutorial* status.value=Succeeded | dedup object
-  | stats values(object) as object by _time, caller, claims.ipaddr, resourceGroupName, object_path
+search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation Runbook" object!=AzureAutomationTutorial* status.value=Succeeded 
+  | dedup object
+  | rename claims.ipaddr as src_ip
+  | rename caller as user
+  | stats count min(_time) as firstTime max(_time) as lastTime values(object) as object by user, src_ip, resourceGroupName, object_path 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
   | `azure_automation_runbook_created_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
@@ -48,7 +52,7 @@ tags:
     type: Other
     role:
     - Victim
-  - name: caller
+  - name: user
     type: User
     role:
     - Attacker

detections/cloud/azure_runbook_webhook_created.yml

@@ -1,7 +1,7 @@
 name: Azure Runbook Webhook Created
 id: e98944a9-92e4-443c-81b8-a322e33ce75a
-version: 2
-date: '2023-11-07'
+version: 3
+date: '2023-12-20'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -16,9 +16,14 @@ description: The following analytic identifies the creation of a new Automation
   of an Automation Runbook with malicious code that can create users or execute code
   on a VM. This provides a persistent foothold on the environment.
 data_source: []
-search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation
-  webhook" status.value=Succeeded | stats values(object) as object by _time, caller, claims.ipaddr,
-  resourceGroupName, object_path | `azure_runbook_webhook_created_filter`'
+search: ' `azure_audit` operationName.localizedValue="Create or Update an Azure Automation webhook" status.value=Succeeded 
+  | dedup object
+  | rename claims.ipaddr as src_ip
+  | rename caller as user
+  | stats count min(_time) as firstTime max(_time) as lastTime values(object) as object by user, src_ip, resourceGroupName, object_path 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `azure_runbook_webhook_created_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Microsoft
   Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details).
   You must be ingesting Azure Audit events into your Splunk environment. Specifically,
@@ -48,7 +53,7 @@ tags:
     type: Other
     role:
     - Victim
-  - name: caller
+  - name: user
     type: User
     role:
     - Attacker

detections/cloud/gcp_authentication_failed_during_mfa_challenge.yml

@@ -1,8 +1,8 @@
 name: GCP Authentication Failed During MFA Challenge
 id: 345f7e1d-a3fe-4158-abd8-e630f9878323
-version: 1
-date: '2022-10-12'
-author: Mauricio Velazco, Splunk
+version: 2
+date: '2024-01-04'
+author: Bhavin Patel, Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: 'The following analytic identifies an authentication attempt event against
@@ -11,7 +11,7 @@ description: 'The following analytic identifies an authentication attempt event
   compromised credentials for an account that has multi-factor authentication enabled. '
 data_source: []
 search: ' `gws_reports_login` event.name=login_failure `gws_login_mfa_methods` | stats
-  values(user) by _time, src_ip, login_challenge_method | `gcp_authentication_failed_during_mfa_challenge_filter`'
+  count min(_time) as firstTime max(_time) as lastTime by user, src_ip, login_challenge_method | `gcp_authentication_failed_during_mfa_challenge_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Google
   Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows
   Splunk administrators to collect Google Workspace event data in Splunk using Google

detections/cloud/gcp_multi_factor_authentication_disabled.yml

@@ -1,8 +1,8 @@
 name: GCP Multi-Factor Authentication Disabled
 id: b9bc5513-6fc1-4821-85a3-e1d81e451c83
-version: 1
-date: '2022-10-12'
-author: Mauricio Velazco, Splunk
+version: 2
+date: '2024-01-04'
+author: Bhavin Patel, Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: The following analytic identifies an attempt to disable multi-factor
@@ -11,8 +11,7 @@ description: The following analytic identifies an attempt to disable multi-facto
   persistence using a valid account. This way the attackers can keep persistance in
   the environment without adding new users.
 data_source: []
-search: ' `gws_reports_admin` command=UNENROLL_USER_FROM_STRONG_AUTH | stats values(user)
-  by _time, command, actor.email, status | `gcp_multi_factor_authentication_disabled_filter`'
+search: '`gws_reports_admin` command=UNENROLL_USER_FROM_STRONG_AUTH | stats count min(_time) as firstTime max(_time) as lastTime by user, command, actor.email, status, id.applicationName, event.name, vendor_account, action | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `gcp_multi_factor_authentication_disabled_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Google
   Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows
   Splunk administrators to collect Google Workspace event data in Splunk using Google

detections/cloud/gcp_successful_single_factor_authentication.yml

@@ -1,8 +1,8 @@
 name: GCP Successful Single-Factor Authentication
 id: 40e17d88-87da-414e-b253-8dc1e4f9555b
-version: 1
-date: '2022-10-12'
-author: Mauricio Velazco, Splunk
+version: 2
+date: '2024-01-04'
+author: Bhavin Patel, Mauricio Velazco, Splunk
 status: production
 type: TTP
 description: The following analytic identifies a successful authentication event against
@@ -10,8 +10,9 @@ description: The following analytic identifies a successful authentication event
   This could be evidence of a missconfiguration, a policy violation or an account
   take over attempt that should be investigated
 data_source: []
-search: ' `gws_reports_login` event.name=login_success NOT `gws_login_mfa_methods`
-  | stats values(user) by _time, src_ip, login_challenge_method | `gcp_successful_single_factor_authentication_filter`'
+search: '`gws_reports_login` event.name=login_success NOT `gws_login_mfa_methods`
+  | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip,  login_challenge_method, app, event.name, vendor_account, action
+ |`security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `gcp_successful_single_factor_authentication_filter`'
 how_to_implement: You must install the latest version of Splunk Add-on for Google
   Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows
   Splunk administrators to collect Google Workspace event data in Splunk using Google

detections/cloud/kubernetes_anomalous_inbound_outbound_network_traffic_io.yml

@@ -0,0 +1,75 @@
+name: Kubernetes Anomalous Inbound Outbound Network IO
+id: 4f3b0c97-657e-4547-a89a-9a50c656e3cd
+version: 1
+date: '2023-12-19'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic identifies high Inbound or Outbound Network IO anomalies in a Kubernetes container. 
+  It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. 
+  A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. 
+  An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, 
+  command and control communication, service disruptions, or unauthorized data transfers. They can compromise the confidentiality, availability, 
+  and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, 
+  potentially leading to data breaches, service outages, financial losses, and reputational damage.
+data_source: []
+search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s 
+  | eval service = replace(''k8s.pod.name'', "-\w{5}$$|-[abcdef0-9]{8,10}-\w{5}$$", "") 
+  | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by k8s.cluster.name k8s.node.name k8s.pod.name service _time 
+  | eval key = ''k8s.cluster.name'' + ":" + ''service'' 
+  | lookup k8s_container_network_io_baseline key 
+  | eval anomalies = "" 
+  | foreach stdev_* 
+    [ eval anomalies =if( ''<<MATCHSTR>>'' > (''avg_<<MATCHSTR>>'' + 4 * ''stdev_<<MATCHSTR>>''), anomalies + "<<MATCHSTR>> higher than average by " + 
+        tostring(round((''<<MATCHSTR>>'' - ''avg_<<MATCHSTR>>'')/''stdev_<<MATCHSTR>>'' ,2)) + " Standard Deviations. <<MATCHSTR>>=" + tostring(''<<MATCHSTR>>'') + " avg_<<MATCHSTR>>=" 
+        + tostring(''avg_<<MATCHSTR>>'') + " ''stdev_<<MATCHSTR>>''=" + tostring(''stdev_<<MATCHSTR>>'') + ", "
+        , anomalies)
+        ] 
+  | eval anomalies = replace(anomalies, ",\s$$", "") 
+  | where anomalies!="" 
+  | stats count values(anomalies) as anomalies by k8s.cluster.name k8s.node.name k8s.pod.name service 
+  | rename service as k8s.service   
+  | where count > 5
+  | rename k8s.node.name as host
+  | `kubernetes_anomalous_inbound_outbound_network_traffic_io_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.
+  11. Run the Search Baseline Of Kubernetes Container Network IO Ratio '
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Anomalous Inbound Outbound Network IO from container on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.pod.network.io
+  - direction
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - k8s.pod.name
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_anomalous_inbound_to_outbound_network_io_ratio.yml

@@ -0,0 +1,77 @@
+name: Kubernetes Anomalous Inbound to Outbound Network IO Ratio
+id: 9d8f6e3f-39df-46d8-a9d4-96173edc501f
+version: 1
+date: '2023-12-19'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic identifies changes in network communication behavior in a Kubernetes container by examining inbound to outbound network IO ratios. 
+  It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. 
+  A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. 
+  An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, 
+  or compromised container behavior. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. 
+  Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, and unauthorized access within the Kubernetes cluster.
+data_source: []
+search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s 
+  | eval service = replace(''k8s.pod.name'', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "") 
+  | eval key = ''k8s.cluster.name'' + ":" + ''service''
+  | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by key service k8s.cluster.name k8s.pod.name k8s.node.name _time 
+  | eval inbound:outbound = inbound_network_io/outbound_network_io 
+  | eval outbound:inbound = outbound_network_io/inbound_network_io 
+  | fields - *network_io 
+  | lookup k8s_container_network_io_ratio_baseline key 
+  | eval anomalies = "" 
+  | foreach stdev_* 
+    [ eval anomalies =if( ''<<MATCHSTR>>'' > (''avg_<<MATCHSTR>>'' + 4 * ''stdev_<<MATCHSTR>>''), anomalies + "<<MATCHSTR>> ratio higher than average by " + 
+        tostring(round((''<<MATCHSTR>>'' - ''avg_<<MATCHSTR>>'')/''stdev_<<MATCHSTR>>'' ,2)) + " Standard Deviations. <<MATCHSTR>>=" + tostring(''<<MATCHSTR>>'') + " avg_<<MATCHSTR>>=" 
+        + tostring(''avg_<<MATCHSTR>>'') + " ''stdev_<<MATCHSTR>>''=" + tostring(''stdev_<<MATCHSTR>>'') + ", "
+        , anomalies)
+        ] 
+  | eval anomalies = replace(anomalies, ",\s$", "") 
+  | where anomalies!="" 
+  | stats count values(anomalies) as anomalies by k8s.cluster.name k8s.node.name k8s.pod.name service 
+  | rename service as k8s.service  
+  | where count > 5
+  | rename k8s.node.name as host
+  | `kubernetes_anomalous_inbound_to_outbound_network_io_ratio_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.
+  11. Run the search Baseline Of Kubernetes Container Network IO Ratio'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Anomalous Inbound to Outbound Network IO Ratio from Container on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.pod.network.io
+  - direction
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - k8s.pod.name
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_previously_unseen_container_image_name.yml

@@ -0,0 +1,66 @@
+name: Kubernetes Previously Unseen Container Image Name
+id: fea515a4-b1d8-4cd6-80d6-e0d71397b891
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: The following analytic identifies containerised workloads that have been created using a previously unseen image. 
+  This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). 
+  This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected.
+  When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. 
+  Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. 
+  The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. 
+  The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, 
+  or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. 
+  A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. 
+  Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster
+data_source: []
+search: '| mstats  count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-24h by host.name k8s.cluster.name k8s.node.name container.image.name
+  | eval current="True"
+  | append [mstats  count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-30d latest=-1h  by host.name k8s.cluster.name k8s.node.name container.image.name
+  | eval current="false"
+  ]
+  | stats values(current) as current by host.name k8s.cluster.name k8s.node.name container.image.name
+  | search current="true" AND current!="false"
+  | rename host.name as host
+  | `kubernetes_previously_unseen_container_image_name_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Previously Unseen Container Image Name on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.container.ready_count
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_previously_unseen_process.yml

@@ -0,0 +1,65 @@
+name: Kubernetes Previously Unseen Process
+id: c8119b2f-d7f7-40be-940a-1c582870e8e2
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic detects newly seen process within the Kubernetes scope on a master or worker node. This detection leverages process metrics harvested using an 
+  OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). 
+  This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour. 
+  The specific metric used by this detection is process.memory.utilization. Newly seen processes on a Kubernetes worker node are concerning as they may represent security risks and 
+  anomalies that could be related to unauthorized activity. New processes may be introduced  in an attempt to compromise the node or gain control of the Kubernetes cluster. 
+  By detecting these processes, they can be investigated, and correlated with other anomalous activity for that host. Newly seen processes may be part of an attacker's strategy to compromise the node, 
+  gain unauthorized access, and subsequently extend their control to the entire Kubernetes cluster. These processes could facilitate activities such as data exfiltration, privilege escalation, 
+  denial-of-service attacks, or the introduction of malware and backdoors, putting sensitive data, applications, and the entire infrastructure at risk.  
+  The consequences may include data breaches, service disruptions, financial losses, and reputational damage, underscoring the need to identify anomalous process and associate them with any concurrent risk activity.
+data_source: []
+search: '| mstats  count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name
+  | eval current="True"
+  | append [mstats  count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name process.executable.name
+  ]
+  | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.executable.name
+  | where count=1 and current="True"
+  | rename host.name as host
+  | `kubernetes_previously_unseen_process_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior  using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Previously Unseen Process on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.memory.utilization
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_process_running_from_new_path.yml

@@ -0,0 +1,66 @@
+name: Kubernetes Process Running From New Path
+id: 454076fb-0e9e-4adf-b93a-da132621c5e6
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic detects processes running within the same scope as Kubernetes that have been run from a newly seen path. 
+  This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud 
+  using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for 
+  each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour, and alerts if the path for that process was not seen over the previous 30 days. 
+  The specific metric used by this detection is process.memory.utilization. Processes running from a newly seen path can signify potential security risks and anomalies. 
+  A process executing from an unfamiliar file path may indicate unauthorized changes to the file system, a compromised node, or the introduction of malicious software.
+  If the presence of a process running from a newly seen file path on a Kubernetes node indicates malicious activity, the security implications could be severe. 
+  It suggests that an attacker has potentially compromised the node, allowing them to execute unauthorized processes and potentially gain control over critical resources. 
+  This could lead to further exploitation, data exfiltration, privilege escalation, or the introduction of malware and backdoors within the Kubernetes cluster.
+data_source: []
+search: '| mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name 
+  | eval current="True" 
+  | append 
+    [ mstats count(process.memory.utilization) as process.memory.utilization_count where `kubernetes_metrics` AND earliest=-30d latest=-1h by host.name k8s.cluster.name k8s.node.name process.pid process.executable.path process.executable.name
+        ] 
+  | stats count values(current) as current by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name process.executable.path
+  | where count=1 and current="True"
+  | rename host.name as host
+  | `kubernetes_process_running_from_new_path_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Process Running From New Path on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.memory.utilization
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_process_with_anomalous_resource_utilisation.yml

@@ -0,0 +1,71 @@
+name: Kubernetes Process with Anomalous Resource Utilisation
+id: 25ca9594-7a0d-4a95-a5e5-3228d7398ec8
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic identifies high resource utilization anomalies in Kubernetes processes. It uses process metrics from an OTEL collector and hostmetrics receiver, 
+  fetched from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values 
+  for various process metrics to identify anomalies. High resource utilization can indicate security threats or operational issues, such as cryptojacking, unauthorized data exfiltration, 
+  or compromised containers. These anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access.
+data_source: []
+search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s 
+  | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name''
+  | lookup k8s_process_resource_baseline key 
+  | fillnull 
+  | eval anomalies = "" 
+  | foreach stdev_* 
+      [ eval anomalies =if( ''<<MATCHSTR>>'' > (''avg_<<MATCHSTR>>'' + 4 * ''stdev_<<MATCHSTR>>''), anomalies + "<<MATCHSTR>> higher than average by " + 
+          tostring(round((''<<MATCHSTR>>'' - ''avg_<<MATCHSTR>>'')/''stdev_<<MATCHSTR>>'' ,2)) + " Standard Deviations. <<MATCHSTR>>=" + tostring(''<<MATCHSTR>>'') + " avg_<<MATCHSTR>>=" 
+          + tostring(''avg_<<MATCHSTR>>'') + " ''stdev_<<MATCHSTR>>''=" + tostring(''stdev_<<MATCHSTR>>'') + ", "
+          , anomalies)
+          ] 
+  | eval anomalies = replace(anomalies, ",\s$", "") 
+  | where anomalies!="" 
+  | stats count values(anomalies) as anomalies by host.name k8s.cluster.name k8s.node.name process.executable.name 
+  | sort - count
+  | where count > 5
+  | rename host.name as host
+  | `kubernetes_process_with_anomalous_resource_utilisation_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.
+  11. Run the search Baseline Of Kubernetes Process Resource'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Process with Anomalous Resource Utilisation on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.*
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_process_with_resource_ratio_anomalies.yml

@@ -0,0 +1,78 @@
+name: Kubernetes Process with Resource Ratio Anomalies
+id: 0d42b295-0f1f-4183-b75e-377975f47c65
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic detects anomalously changes in the ratio between specific process resources on a Kubernetes node, based on the past behavior for each process running in the Kubernetes scope on that node.
+  This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247).   
+  This detection also leverages a lookup table that contains average and standard deviation for the cpu:disk operations, cpu:mem, cpu:thread count, disk operations:thread count, and mem:disk operations ratios.  
+  This is used to indicate an anomalous change in resource ratios that indicate the workload has changed behavior irrespective of load.
+  Changes in the relationship between utilization of different resources can indicate a change in behavior of the monitored process, which can indicate a potentially compromised application. 
+  Deviations in resource ratios, such as memory-to-CPU or CPU-to-disk utilization, may signify compromised processes, malicious activity, or misconfigurations that could pose risks. 
+  A change in process behavior could signify a potential security breach within the Kubernetes environment, where an attacker may have compromised a process either on the node or running within a container. 
+data_source: []
+search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s 
+  | eval cpu:mem = ''process.cpu.utilization''/''process.memory.utilization'' 
+  | eval cpu:disk = ''process.cpu.utilization''/''process.disk.operations'' 
+  | eval mem:disk = ''process.memory.utilization''/''process.disk.operations'' 
+  | eval cpu:threads = ''process.cpu.utilization''/''process.threads'' 
+  | eval disk:threads = ''process.disk.operations''/''process.threads'' 
+  | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name'' 
+  | lookup k8s_process_resource_ratio_baseline key 
+  | fillnull 
+  | eval anomalies = "" 
+  | foreach stdev_* 
+    [ eval anomalies =if( ''<<MATCHSTR>>'' > (''avg_<<MATCHSTR>>'' + 4 * ''stdev_<<MATCHSTR>>''), anomalies + "<<MATCHSTR>> ratio higher than average by " + 
+        tostring(round((''<<MATCHSTR>>'' - ''avg_<<MATCHSTR>>'')/''stdev_<<MATCHSTR>>'' ,2)) + " Standard Deviations. <<MATCHSTR>>=" + tostring(''<<MATCHSTR>>'') + " avg_<<MATCHSTR>>=" 
+        + tostring(''avg_<<MATCHSTR>>'') + " ''stdev_<<MATCHSTR>>''=" + tostring(''stdev_<<MATCHSTR>>'') + ", "
+        , anomalies)
+        ] 
+  | eval anomalies = replace(anomalies, ",\s$", "") 
+  | where anomalies!="" 
+  | stats count values(anomalies) as anomalies by host.name k8s.cluster.name k8s.node.name process.executable.name 
+  | where count > 5
+  | rename host.name as host
+  | `kubernetes_process_with_resource_ratio_anomalies_filter`'
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.
+  11. Run the search Baseline Of Kubernetes Process Resource Ratio'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes Process with Resource Ratio Anomalies on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.*
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_shell_running_on_worker_node.yml

@@ -0,0 +1,62 @@
+name: Kubernetes Shell Running on Worker Node
+id: efebf0c4-dcf4-496f-85a2-5ab7ad8fa876
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic identifies shell activity within the Kubernetes privilege scope on a worker node, returning a list of shell processes regardless of CPU resource consumption. 
+  It uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. 
+  Metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized or suspicious activity, posing a security threat. 
+  Shell access to worker nodes can provide attackers an entry point to compromise the node and the entire Kubernetes cluster. Monitoring and detecting shell processes is crucial for anomaly identification, security policy enforcement, and breach mitigation.
+  Unauthorized shell processes on a Kubernetes worker node can severely compromise the cluster's security and integrity. Such access can lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. 
+  It may also enable attackers to manipulate configurations, deploy malicious containers, and execute arbitrary code, posing a severe risk to the confidentiality, availability, and integrity of applications and sensitive data.
+data_source: []
+search: '| mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization 
+  where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s
+  | search process.cpu.utilization>0 OR process.memory.utilization>0
+  | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name
+  | rename host.name as host
+  | `kubernetes_shell_running_on_worker_node_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart/tree/main
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes shell running on worker node on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.cpu.utilization
+  - process.memory.utilization
+  - process.executable.name
+  - host.name
+  - k8s.cluster.name
+  - k8s.node.name
+  - process.pid
+  risk_score: 25
+  security_domain: network

detections/cloud/kubernetes_shell_running_on_worker_node_with_cpu_activity.yml

@@ -0,0 +1,64 @@
+name: Kubernetes Shell Running on Worker Node with CPU Activity
+id: cc1448e3-cc7a-4518-bc9f-2fa48f61a22b
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+status: experimental
+type: Anomaly
+description: This analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It returns shell processes only if they're consuming CPU resources. 
+  The detection uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. 
+  The metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized activity, posing a security threat. 
+  Attackers could compromise the node and the entire Kubernetes cluster via shell access to worker nodes. Monitoring shell processes is crucial for anomaly detection, 
+  policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node could severely impact the cluster's security and integrity. 
+  Attackers could gain full control over the host's resources and file system, compromising all hosted workloads and data. This access could lead to data theft, service disruption, 
+  privilege escalation, lateral movement, and further attacks within the cluster. Attackers could also manipulate configurations, deploy malicious containers, and execute arbitrary code, 
+  severely risking the confidentiality, availability, and integrity of applications and sensitive data. A rapid and comprehensive incident response is required to mitigate and recover from such a breach.
+data_source: []
+search: '| mstats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization 
+  where `kubernetes_metrics` AND process.executable.name IN ("sh","bash","csh", "tcsh") by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name span=10s
+  | search process.cpu.utilization>0 
+  | stats avg(process.cpu.utilization) as process.cpu.utilization avg(process.memory.utilization) as process.memory.utilization by host.name k8s.cluster.name k8s.node.name process.pid process.executable.name
+  | rename host.name as host
+  | `kubernetes_shell_running_on_worker_node_with_cpu_activity_filter` '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: unknown
+references:
+- https://github.com/signalfx/splunk-otel-collector-chart/tree/main
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  asset_type: Kubernetes
+  confidence: 50
+  impact: 50
+  message: Kubernetes shell with cpu activity running on worker node on host $host$
+  mitre_attack_id:
+  - T1204
+  observable:
+  - name: host
+    type: Hostname
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.cpu.utilization
+  - process.memory.utilization
+  - process.executable.name
+  - host.name
+  - k8s.cluster.name
+  - k8s.node.name
+  - process.pid
+  risk_score: 25
+  security_domain: network

detections/cloud/o365_concurrent_sessions_from_different_ips.yml

@@ -0,0 +1,60 @@
+name: O365 Concurrent Sessions From Different Ips
+id: 58e034de-1f87-4812-9dc3-a4f68c7db930
+version: 1
+date: '2023-12-04'
+author: Mauricio Velazco, Splunk
+status: production
+type: TTP
+description: The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns. 
+data_source: []
+search: ' `o365_management_activity` Workload=AzureActiveDirectory  Operation=UserLoggedIn
+  | stats min(_time) as firstTime max(_time) as lastTime values(src_ip) as ips values(user_agent) as user_agents by Operation, user, SessionId
+  | where mvcount(ips) > 1
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `o365_concurrent_sessions_from_different_ips_filter`'
+how_to_implement: You must install splunk Microsoft Office 365 add-on. This search
+  works with o365:management:activity
+known_false_positives: Unknown
+references:
+- https://attack.mitre.org/techniques/T1185/
+- https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens/
+- https://github.com/kgretzky/evilginx2
+tags:
+  analytic_story:
+  - Office 365 Account Takeover
+  asset_type: O365
+  confidence: 60
+  impact: 70
+  message: User $user$ has logged in with the same session id from more than one unique IP address
+  mitre_attack_id:
+  - T1185
+  observable:
+  - name: user
+    type: User
+    role:
+    - Victim
+  - name: ips
+    type: IP Address
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - Operation
+  - Workload
+  - src_ip
+  - user
+  - user_agent
+  risk_score: 42
+  security_domain: threat
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/o365_concurrent_sessions_from_different_ips/o365_concurrent_sessions_from_different_ips.log
+    sourcetype: o365:management:activity
+    source: o365
+    update_timestamp: true

detections/endpoint/access_lsass_memory_for_dump_creation.yml

@@ -1,12 +1,19 @@
 name: Access LSASS Memory for Dump Creation
 id: fb4c31b0-13e8-4155-8aa5-24de4b8d6717
 version: 2
-date: '2019-12-06'
+date: '2023-12-27'
 author: Patrick Bareiss, Splunk
 status: production
 type: TTP
-description: |-
-  The following analytic detects the dumping of the LSASS process memory, which occurs during credential dumping attacks.The detection is made by using Sysmon logs, specifically EventCode 10, which is related to lsass.exe. This helps to search for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll and dbghelp.dll. This detection is important because it prevents credential dumping attacks and the theft of sensitive information such as login credentials, which can be used to gain unauthorized access to systems and data. False positives might occur due to legitimate administrative tasks. Next steps include reviewing and investigating each case, given the high risk associated with potential credential dumping attacks.
+description: The following analytic detects the dumping of the LSASS process memory,
+  which occurs during credential dumping attacks.The detection is made by using Sysmon
+  logs, specifically EventCode 10, which is related to lsass.exe. This helps to search
+  for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll
+  and dbghelp.dll. This detection is important because it prevents credential dumping
+  attacks and the theft of sensitive information such as login credentials, which
+  can be used to gain unauthorized access to systems and data. False positives might
+  occur due to legitimate administrative tasks. Next steps include reviewing and investigating
+  each case, given the high risk associated with potential credential dumping attacks.
 data_source:
 - Sysmon Event ID 1
 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe CallTrace=*dbgcore.dll* OR CallTrace=*dbghelp.dll*
@@ -25,6 +32,7 @@ references:
 - https://2017.zeronights.org/wp-content/uploads/materials/ZN17_Kheirkhabarov_Hunting_for_Credentials_Dumping_in_Windows_Environment.pdf
 tags:
   analytic_story:
+  - CISA AA23-347A
   - Credential Dumping
   asset_type: Windows
   confidence: 90

detections/endpoint/adsisearcher_account_discovery.yml

@@ -1,7 +1,7 @@
 name: AdsiSearcher Account Discovery
 id: de7fcadc-04f3-11ec-a241-acde48001122
 version: 2
-date: '2023-04-14'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -13,8 +13,9 @@ data_source:
 - Powershell 4104
 search: '`powershell` EventCode=4104 ScriptBlockText = "*[adsisearcher]*" ScriptBlockText
   = "*objectcategory=user*" ScriptBlockText = "*.findAll()*" | stats count min(_time)
-  as firstTime max(_time) as lastTime by EventCode Computer ScriptBlockText UserID | rename Computer as dest, UserID as user
-  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `adsisearcher_account_discovery_filter`'
+  as firstTime max(_time) as lastTime by EventCode Computer ScriptBlockText UserID
+  | rename Computer as dest, UserID as user | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `adsisearcher_account_discovery_filter`'
 how_to_implement: The following Hunting analytic requires PowerShell operational logs
   to be imported. Modify the powershell macro as needed to match the sourcetype or
   add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
@@ -25,13 +26,15 @@ references:
 - https://devblogs.microsoft.com/scripting/use-the-powershell-adsisearcher-type-accelerator-to-search-active-directory/
 tags:
   analytic_story:
-  - Data Destruction
-  - Active Directory Discovery
   - Industroyer2
+  - Active Directory Discovery
+  - CISA AA23-347A
+  - Data Destruction
   asset_type: Endpoint
   confidence: 50
   impact: 50
-  message: Powershell process having commandline "AdsiSearcher" used for user enumeration on $dest$
+  message: Powershell process having commandline "AdsiSearcher" used for user enumeration
+    on $dest$
   mitre_attack_id:
   - T1087.002
   - T1087

detections/endpoint/allow_network_discovery_in_firewall.yml

@@ -41,7 +41,7 @@ tags:
   asset_type: Endpoint
   confidence: 50
   impact: 50
-  message: ''
+  message: Suspicious modification to the firewall to allow network discovery detected on host - $dest$
   mitre_attack_id:
   - T1562.007
   - T1562

detections/endpoint/attempted_credential_dump_from_registry_via_reg_exe.yml

@@ -1,7 +1,7 @@
 name: Attempted Credential Dump From Registry via Reg exe
 id: e9fb4a59-c5fb-440a-9f24-191fbc6b2911
 version: 7
-date: '2023-04-14'
+date: '2023-12-27'
 author: Patrick Bareiss, Splunk
 status: production
 type: TTP
@@ -35,6 +35,7 @@ tags:
   - Industroyer2
   - Windows Registry Abuse
   - Credential Dumping
+  - CISA AA23-347A
   - DarkSide Ransomware
   - Data Destruction
   asset_type: Endpoint

detections/endpoint/cmd_carry_out_string_command_parameter.yml

@@ -1,7 +1,7 @@
 name: CMD Carry Out String Command Parameter
 id: 54a6ed00-3256-11ec-b031-acde48001122
 version: 4
-date: '2023-12-13'
+date: '2023-12-27'
 author: Teoderick Contreras, Bhavin Patel, Splunk
 status: production
 type: Hunting
@@ -14,10 +14,11 @@ description: The following analytic identifies command-line arguments where `cmd
 data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time)
-  as lastTime from datamodel=Endpoint.Processes where `process_cmd` AND Processes.process="* /c*" by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name
-  Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id
-  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
-  | `cmd_carry_out_string_command_parameter_filter`'
+  as lastTime from datamodel=Endpoint.Processes where `process_cmd` AND Processes.process="*
+  /c*" by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process
+  Processes.process_name Processes.original_file_name Processes.process Processes.process_id
+  Processes.parent_process_id | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `cmd_carry_out_string_command_parameter_filter`'
 how_to_implement: The detection is based on data that originates from Endpoint Detection
   and Response (EDR) agents. These agents are designed to provide security-related
   telemetry from the endpoints where the agent is installed. To implement this search,
@@ -34,33 +35,34 @@ references:
 - https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/
 tags:
   analytic_story:
-  - ProxyNotShell
-  - Qakbot
-  - Winter Vivern
-  - DarkCrystal RAT
   - AsyncRAT
-  - Log4Shell CVE-2021-44228
-  - Hermetic Wiper
-  - Chaos Ransomware
-  - IcedID
+  - Winter Vivern
   - WhisperGate
-  - Data Destruction
   - Living Off The Land
-  - Azorult
-  - Data Destruction
-  - Warzone RAT
-  - NjRAT
-  - PlugX
   - DarkGate Malware
+  - ProxyNotShell
+  - Log4Shell CVE-2021-44228
+  - NjRAT
   - RedLine Stealer
   - Rhysida Ransomware
+  - IcedID
+  - Chaos Ransomware
+  - PlugX
+  - Azorult
+  - Qakbot
+  - Hermetic Wiper
+  - Warzone RAT
+  - DarkCrystal RAT
+  - CISA AA23-347A
+  - Data Destruction
   asset_type: Endpoint
   automated_detection_testing: passed
   confidence: 50
   cve:
   - CVE-2021-44228
   impact: 60
-  message: An instance of $parent_process_name$ spawning $process_name$ was identified on endpoint $dest$ by user $user$ attempting spawn a new process.
+  message: An instance of $parent_process_name$ spawning $process_name$ was identified
+    on endpoint $dest$ by user $user$ attempting spawn a new process.
   mitre_attack_id:
   - T1059.003
   - T1059

detections/endpoint/cmdline_tool_not_executed_in_cmd_shell.yml

@@ -1,7 +1,7 @@
 name: Cmdline Tool Not Executed In CMD Shell
 id: 6c3f7dd8-153c-11ec-ac2d-acde48001122
 version: 2
-date: '2022-10-27'
+date: '2023-12-27'
 author: Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -45,13 +45,13 @@ references:
 - https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/
 tags:
   analytic_story:
+  - Volt Typhoon
+  - Rhysida Ransomware
   - FIN7
+  - DarkGate Malware
   - Qakbot
   - CISA AA22-277A
-  - Qakbot
-  - Volt Typhoon
-  - DarkGate Malware
-  - Rhysida Ransomware
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 80
   impact: 70

detections/endpoint/detect_credential_dumping_through_lsass_access.yml

@@ -1,18 +1,28 @@
 name: Detect Credential Dumping through LSASS access
 id: 2c365e57-4414-4540-8dc0-73ab10729996
 version: 3
-date: '2019-12-03'
+date: '2023-12-27'
 author: Patrick Bareiss, Splunk
 status: production
 type: TTP
-description: |-
-  The following analytic detects the reading of lsass memory, which is consistent with credential dumping. Reading lsass memory is a common technique used by attackers to steal credentials from the Windows operating system. The detection is made by monitoring the sysmon events and filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances of credential dumping.The detection is important because it suggests that an attacker is attempting to extract credentials from the lsass memory, which can lead to unauthorized access, data breaches, and compromise of sensitive information. Credential dumping is often a precursor to further attacks, such as lateral movement, privilege escalation, or data exfiltration. False positives can occur due to legitimate actions that involve accessing lsass memory. Therefore, extensive triage and investigation are necessary to differentiate between malicious and benign activities.
+description: The following analytic detects the reading of lsass memory, which is
+  consistent with credential dumping. Reading lsass memory is a common technique used
+  by attackers to steal credentials from the Windows operating system. The detection
+  is made by monitoring the sysmon events and filtering for specific access permissions
+  (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances
+  of credential dumping.The detection is important because it suggests that an attacker
+  is attempting to extract credentials from the lsass memory, which can lead to unauthorized
+  access, data breaches, and compromise of sensitive information. Credential dumping
+  is often a precursor to further attacks, such as lateral movement, privilege escalation,
+  or data exfiltration. False positives can occur due to legitimate actions that involve
+  accessing lsass memory. Therefore, extensive triage and investigation are necessary
+  to differentiate between malicious and benign activities.
 data_source:
 - Sysmon Event ID 1
 search: '`sysmon` EventCode=10 TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410)
   | stats count min(_time) as firstTime max(_time) as lastTime by dest, SourceImage,
-  SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`
-  | `detect_credential_dumping_through_lsass_access_filter` '
+  SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess | `security_content_ctime(firstTime)`|
+  `security_content_ctime(lastTime)` | `detect_credential_dumping_through_lsass_access_filter` '
 how_to_implement: This search needs Sysmon Logs and a sysmon configuration, which
   includes EventCode 10 with lsass.exe. This search uses an input macro named `sysmon`.
   We strongly recommend that you specify your environment-specific configurations
@@ -26,14 +36,14 @@ known_false_positives: The activity may be legitimate. Other tools can access ls
 references: []
 tags:
   analytic_story:
-  - Credential Dumping
   - Detect Zerologon Attack
+  - CISA AA23-347A
+  - Credential Dumping
   asset_type: Windows
   confidence: 100
   impact: 80
   message: The $SourceImage$ has attempted access to read $TargetImage$ was identified
-    on endpoint $dest$, this is indicative of credential dumping and should be
-    investigated.
+    on endpoint $dest$, this is indicative of credential dumping and should be investigated.
   mitre_attack_id:
   - T1003.001
   - T1003

detections/endpoint/detect_mimikatz_with_powershell_script_block_logging.yml

@@ -1,7 +1,7 @@
 name: Detect Mimikatz With PowerShell Script Block Logging
 id: 8148c29c-c952-11eb-9255-acde48001122
 version: 2
-date: '2022-02-24'
+date: '2023-12-27'
 author: Michael Haag, Splunk
 status: production
 type: TTP
@@ -37,11 +37,12 @@ references:
 - https://www.splunk.com/en_us/blog/security/hunting-for-malicious-powershell-using-script-block-logging.html
 tags:
   analytic_story:
-  - Hermetic Wiper
   - Malicious PowerShell
+  - Hermetic Wiper
+  - Sandworm Tools
   - CISA AA22-264A
   - CISA AA22-320A
-  - Sandworm Tools
+  - CISA AA23-347A
   - Data Destruction
   asset_type: Endpoint
   confidence: 100

detections/endpoint/disable_amsi_through_registry.yml

@@ -1,22 +1,23 @@
 name: Disable AMSI Through Registry
 id: 9c27ec42-d338-11eb-9044-acde48001122
 version: 4
-date: '2023-04-11'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
 description: this search is to identify modification in registry to disable AMSI windows
   feature to evade detections. This technique was seen in several ransomware, RAT
   and even APT to impaire defenses of the compromise machine and to be able to execute
-  payload with minimal alert as much as possible.  
+  payload with minimal alert as much as possible.
 data_source:
 - Sysmon Event ID 1
-search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows Script\\Settings\\AmsiEnable" Registry.registry_value_data = "0x00000000") BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.dest Registry.user
- | `drop_dm_object_name(Registry)`
- | where isnotnull(registry_value_data)
- | `security_content_ctime(firstTime)` 
- | `security_content_ctime(lastTime)`
- | `disable_amsi_through_registry_filter`'
+search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
+  WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows Script\\Settings\\AmsiEnable"
+  Registry.registry_value_data = "0x00000000") BY _time span=1h Registry.registry_path
+  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
+  Registry.process_guid Registry.dest Registry.user | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `disable_amsi_through_registry_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -29,6 +30,7 @@ references:
 tags:
   analytic_story:
   - Ransomware
+  - CISA AA23-347A
   - Windows Registry Abuse
   asset_type: Endpoint
   confidence: 50

detections/endpoint/disable_defender_blockatfirstseen_feature.yml

@@ -1,21 +1,22 @@
 name: Disable Defender BlockAtFirstSeen Feature
 id: 2dd719ac-3021-11ec-97b4-acde48001122
 version: 4
-date: '2023-04-11'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
 data_source:
 - Sysmon Event ID 1
-description: This analytic is intended to detect a suspicious modification of the Windows registry to disable
-  a Windows Defender feature. This technique is intended to bypass or evade detection from
-  Windows Defender AV, specifically the BlockAtFirstSeen feature where it blocks
-  suspicious files the first time seen on the host.
-search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry WHERE (Registry.registry_path = "*\\Microsoft\\Windows Defender\\SpyNet*" Registry.registry_value_name = DisableBlockAtFirstSeen Registry.registry_value_data = 0x00000001) BY _time span=1h Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data Registry.process_guid Registry.user Registry.dest 
-  | `drop_dm_object_name(Registry)`
-  | where isnotnull(registry_value_data)
-  | `security_content_ctime(firstTime)` 
-  | `security_content_ctime(lastTime)`
+description: This analytic is intended to detect a suspicious modification of the
+  Windows registry to disable a Windows Defender feature. This technique is intended
+  to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen
+  feature where it blocks suspicious files the first time seen on the host.
+search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
+  WHERE (Registry.registry_path = "*\\Microsoft\\Windows Defender\\SpyNet*" Registry.registry_value_name
+  = DisableBlockAtFirstSeen Registry.registry_value_data = 0x00000001) BY _time span=1h
+  Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
+  Registry.process_guid Registry.user Registry.dest | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
   | `disable_defender_blockatfirstseen_feature_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
@@ -26,9 +27,10 @@ references:
 - https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/
 tags:
   analytic_story:
+  - Azorult
+  - CISA AA23-347A
   - IcedID
   - Windows Registry Abuse
-  - Azorult
   asset_type: Endpoint
   confidence: 70
   impact: 70

detections/endpoint/disable_defender_enhanced_notification.yml

@@ -1,7 +1,7 @@
 name: Disable Defender Enhanced Notification
 id: dc65678c-301f-11ec-8e30-acde48001122
 version: 3
-date: '2022-11-14'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -38,9 +38,10 @@ references:
 - https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/
 tags:
   analytic_story:
+  - Azorult
+  - CISA AA23-347A
   - IcedID
   - Windows Registry Abuse
-  - Azorult
   asset_type: Endpoint
   confidence: 70
   impact: 70

detections/endpoint/disable_defender_spynet_reporting.yml

@@ -1,7 +1,7 @@
 name: Disable Defender Spynet Reporting
 id: 898debf4-3021-11ec-ba7c-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -15,8 +15,9 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint
   WHERE (Registry.registry_path = "*\\Microsoft\\Windows Defender\\SpyNet*" Registry.registry_value_name
   = SpynetReporting Registry.registry_value_data = 0x00000000) BY _time span=1h Registry.registry_path
   Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
-  Registry.process_guid Registry.user Registry.dest  | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data)
-  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_defender_spynet_reporting_filter`'
+  Registry.process_guid Registry.user Registry.dest  | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `disable_defender_spynet_reporting_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -26,10 +27,11 @@ references:
 - https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/
 tags:
   analytic_story:
-  - IcedID
-  - Windows Registry Abuse
   - Azorult
+  - Windows Registry Abuse
   - Qakbot
+  - IcedID
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 70
   impact: 70

detections/endpoint/disable_defender_submit_samples_consent_feature.yml

@@ -1,7 +1,7 @@
 name: Disable Defender Submit Samples Consent Feature
 id: 73922ff8-3022-11ec-bf5e-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -14,9 +14,10 @@ data_source:
 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
   WHERE (Registry.registry_path = "*\\Microsoft\\Windows Defender\\SpyNet*" Registry.registry_value_name
   = SubmitSamplesConsent Registry.registry_value_data = 0x00000000) BY _time span=1h
-  Registry.user Registry.dest Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
-  Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data)
-  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_defender_submit_samples_consent_feature_filter`'
+  Registry.user Registry.dest Registry.registry_path Registry.registry_key_name Registry.registry_value_name
+  Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `disable_defender_submit_samples_consent_feature_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -26,9 +27,10 @@ references:
 - https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/
 tags:
   analytic_story:
+  - Azorult
+  - CISA AA23-347A
   - IcedID
   - Windows Registry Abuse
-  - Azorult
   asset_type: Endpoint
   confidence: 70
   impact: 70

detections/endpoint/disable_etw_through_registry.yml

@@ -1,7 +1,7 @@
 name: Disable ETW Through Registry
 id: f0eacfa4-d33f-11eb-8f9d-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -28,6 +28,7 @@ references:
 tags:
   analytic_story:
   - Ransomware
+  - CISA AA23-347A
   - Windows Registry Abuse
   asset_type: Endpoint
   confidence: 50

detections/endpoint/disable_logs_using_wevtutil.yml

@@ -1,7 +1,7 @@
 name: Disable Logs Using WevtUtil
 id: 236e7c8e-c9d9-11eb-a824-acde48001122
 version: 1
-date: '2021-06-10'
+date: '2023-12-27'
 author: Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -32,6 +32,7 @@ references:
 tags:
   analytic_story:
   - Ransomware
+  - CISA AA23-347A
   - Rhysida Ransomware
   asset_type: Endpoint
   confidence: 80

detections/endpoint/disable_security_logs_using_minint_registry.yml

@@ -1,7 +1,7 @@
 name: Disable Security Logs Using MiniNt Registry
 id: 39ebdc68-25b9-11ec-aec7-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -12,10 +12,11 @@ description: This analytic is to detect a suspicious registry modification to di
 data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
-  WHERE (Registry.registry_path="*\\Control\\MiniNt\\*") BY _time span=1h  Registry.user Registry.dest Registry.registry_path
-  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
-  Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data)
-  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_security_logs_using_minint_registry_filter`'
+  WHERE (Registry.registry_path="*\\Control\\MiniNt\\*") BY _time span=1h  Registry.user
+  Registry.dest Registry.registry_path Registry.registry_key_name Registry.registry_value_name
+  Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `disable_security_logs_using_minint_registry_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -26,6 +27,7 @@ references:
 tags:
   analytic_story:
   - Windows Defense Evasion Tactics
+  - CISA AA23-347A
   - Windows Registry Abuse
   asset_type: Endpoint
   confidence: 100

detections/endpoint/disable_uac_remote_restriction.yml

@@ -1,7 +1,7 @@
 name: Disable UAC Remote Restriction
 id: 9928b732-210e-11ec-b65e-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -14,8 +14,8 @@ data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
   WHERE (Registry.registry_path="*\\CurrentVersion\\Policies\\System*" Registry.registry_value_name="LocalAccountTokenFilterPolicy"
-  Registry.registry_value_data="0x00000001"  ) BY _time span=1h Registry.user Registry.dest Registry.registry_path
-  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
+  Registry.registry_value_data="0x00000001"  ) BY _time span=1h Registry.user Registry.dest
+  Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
   Registry.process_guid | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data)
   | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_uac_remote_restriction_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
@@ -27,8 +27,9 @@ references:
 - https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction
 tags:
   analytic_story:
-  - Windows Defense Evasion Tactics
   - Suspicious Windows Registry Activities
+  - Windows Defense Evasion Tactics
+  - CISA AA23-347A
   - Windows Registry Abuse
   asset_type: Endpoint
   confidence: 100

detections/endpoint/disable_windows_behavior_monitoring.yml

@@ -1,7 +1,7 @@
 name: Disable Windows Behavior Monitoring
 id: 79439cae-9200-11eb-a4d3-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -19,10 +19,11 @@ search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint
   Protection\\DisableRealtimeMonitoring" OR Registry.registry_path= "*\\Real-Time
   Protection\\DisableIntrusionPreventionSystem" OR Registry.registry_path= "*\\Real-Time
   Protection\\DisableIOAVProtection" OR Registry.registry_path= "*\\Real-Time Protection\\DisableScriptScanning"
-  AND Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path
-  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
-  Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data)
-  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disable_windows_behavior_monitoring_filter`'
+  AND Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest
+  Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name
+  Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `disable_windows_behavior_monitoring_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -33,11 +34,12 @@ references:
 tags:
   analytic_story:
   - Azorult
-  - Windows Registry Abuse
-  - Revil Ransomware
-  - RedLine Stealer
   - Ransomware
+  - Windows Registry Abuse
+  - RedLine Stealer
   - Windows Defense Evasion Tactics
+  - CISA AA23-347A
+  - Revil Ransomware
   asset_type: Endpoint
   confidence: 100
   impact: 40

detections/endpoint/disable_windows_smartscreen_protection.yml

@@ -1,7 +1,7 @@
 name: Disable Windows SmartScreen Protection
 id: 664f0fd0-91ff-11eb-a56f-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -14,9 +14,10 @@ data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
   WHERE (Registry.registry_path= "*HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\SmartScreenEnabled"  Registry.registry_value_data=
-  "Off") BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name
-  Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`| `security_content_ctime(firstTime)`
-  | `security_content_ctime(lastTime)` | `disable_windows_smartscreen_protection_filter`'
+  "Off") BY _time span=1h Registry.dest Registry.user Registry.registry_path Registry.registry_key_name
+  Registry.registry_value_name Registry.registry_value_data Registry.process_guid
+  | `drop_dm_object_name(Registry)`| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `disable_windows_smartscreen_protection_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -27,6 +28,7 @@ references:
 tags:
   analytic_story:
   - Windows Defense Evasion Tactics
+  - CISA AA23-347A
   - Windows Registry Abuse
   asset_type: Endpoint
   confidence: 50

detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml

@@ -1,7 +1,7 @@
 name: Disabled Kerberos Pre-Authentication Discovery With Get-ADUser
 id: 114c6bfe-9406-11ec-bcce-acde48001122
 version: 2
-date: '2022-05-03'
+date: '2023-12-27'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -17,7 +17,8 @@ data_source:
 - Powershell 4104
 search: ' `powershell` EventCode=4104 (ScriptBlockText = "*Get-ADUser*" AND ScriptBlockText="*4194304*")
   | stats count min(_time)  as firstTime max(_time) as lastTime by Opcode Computer
-  UserID EventCode ScriptBlockText | rename Computer as dest | `security_content_ctime(firstTime)` | `disabled_kerberos_pre_authentication_discovery_with_get_aduser_filter`'
+  UserID EventCode ScriptBlockText | rename Computer as dest | `security_content_ctime(firstTime)`
+  | `disabled_kerberos_pre_authentication_discovery_with_get_aduser_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://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
@@ -29,6 +30,7 @@ references:
 - https://stealthbits.com/blog/cracking-active-directory-passwords-with-as-rep-roasting/
 tags:
   analytic_story:
+  - CISA AA23-347A
   - Active Directory Kerberos Attacks
   asset_type: endpoint
   confidence: 90

detections/endpoint/disabling_folderoptions_windows_feature.yml

@@ -1,7 +1,7 @@
 name: Disabling FolderOptions Windows Feature
 id: 83776de4-921a-11eb-868a-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -14,8 +14,8 @@ data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
   WHERE (Registry.registry_path= "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\NoFolderOptions"
-  Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user Registry.registry_path
-  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
+  Registry.registry_value_data = "0x00000001") BY _time span=1h Registry.dest Registry.user
+  Registry.registry_path Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
   Registry.process_guid | `drop_dm_object_name(Registry)`| where isnotnull(registry_value_data)
   | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `disabling_folderoptions_windows_feature_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
@@ -28,6 +28,7 @@ references:
 tags:
   analytic_story:
   - Windows Defense Evasion Tactics
+  - CISA AA23-347A
   - Windows Registry Abuse
   asset_type: Endpoint
   confidence: 50

detections/endpoint/domain_controller_discovery_with_nltest.yml

@@ -1,7 +1,7 @@
 name: Domain Controller Discovery with Nltest
 id: 41243735-89a7-4c83-bcdd-570aa78f00a1
 version: 1
-date: '2021-08-30'
+date: '2023-12-27'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -33,6 +33,7 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   - Rhysida Ransomware
   asset_type: Endpoint
   confidence: 70

detections/endpoint/etw_registry_disabled.yml

@@ -1,7 +1,7 @@
 name: ETW Registry Disabled
 id: 8ed523ac-276b-11ec-ac39-acde48001122
 version: 4
-date: '2023-04-27'
+date: '2023-12-27'
 author: Steven Dick, Teoderick Contreras, Splunk
 status: production
 type: TTP
@@ -12,10 +12,11 @@ data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Registry
   WHERE (Registry.registry_path="*\\SOFTWARE\\Microsoft\\.NETFramework*" Registry.registry_value_name
-  = ETWEnabled Registry.registry_value_data=0x00000000) BY _time span=1h Registry.dest Registry.user Registry.registry_path
-  Registry.registry_key_name Registry.registry_value_name Registry.registry_value_data
-  Registry.process_guid | `drop_dm_object_name(Registry)` | where isnotnull(registry_value_data)
-  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `etw_registry_disabled_filter`'
+  = ETWEnabled Registry.registry_value_data=0x00000000) BY _time span=1h Registry.dest
+  Registry.user Registry.registry_path Registry.registry_key_name Registry.registry_value_name
+  Registry.registry_value_data Registry.process_guid | `drop_dm_object_name(Registry)`
+  | where isnotnull(registry_value_data) | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
+  | `etw_registry_disabled_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
   logs with the registry value name, registry path, and registry value data from your
   endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical
@@ -26,9 +27,10 @@ references:
 tags:
   analytic_story:
   - Hermetic Wiper
-  - Windows Privilege Escalation
   - Windows Persistence Techniques
+  - Windows Privilege Escalation
   - Windows Registry Abuse
+  - CISA AA23-347A
   - Data Destruction
   asset_type: Endpoint
   confidence: 100

detections/endpoint/executables_or_script_creation_in_suspicious_path.yml

@@ -1,14 +1,17 @@
 name: Executables Or Script Creation In Suspicious Path
 id: a7e3f0f0-ae42-11eb-b245-acde48001122
 version: 1
-date: '2023-06-13'
+date: '2023-12-27'
 author: Teoderick Contreras, Splunk
 status: production
 type: Anomaly
-description: This analytic identifies potentially malicious executables or scripts by examining a list of suspicious file paths on Windows Operating System. 
-  The purpose of this technique is to uncover files with known file extensions that could be used by adversaries to evade detection and persistence. 
-  The suspicious file paths selected for investigation are typically uncommon and uncommonly associated with executable or script files. 
-  By scrutinizing these paths, we can proactively identify potential security threats and enhance overall system security.
+description: This analytic identifies potentially malicious executables or scripts
+  by examining a list of suspicious file paths on Windows Operating System. The purpose
+  of this technique is to uncover files with known file extensions that could be used
+  by adversaries to evade detection and persistence. The suspicious file paths selected
+  for investigation are typically uncommon and uncommonly associated with executable
+  or script files. By scrutinizing these paths, we can proactively identify potential
+  security threats and enhance overall system security.
 data_source:
 - Sysmon Event ID 11
 search: '|tstats `security_content_summariesonly` values(Filesystem.file_path) as
@@ -38,34 +41,35 @@ references:
 - https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/
 tags:
   analytic_story:
-  - WhisperGate
-  - XMRig
-  - Industroyer2
-  - Remcos
-  - Data Destruction
-  - Hermetic Wiper
-  - Azorult
-  - DarkCrystal RAT
-  - Graceful Wipe Out Attack
-  - IcedID
-  - Swift Slicer
-  - Qakbot
-  - RedLine Stealer
-  - Brute Ratel C4
-  - AsyncRAT
-  - LockBit Ransomware
-  - AgentTesla
   - Double Zero Destructor
-  - Volt Typhoon
+  - Graceful Wipe Out Attack
+  - AsyncRAT
+  - WhisperGate
+  - DarkGate Malware
+  - AgentTesla
+  - Brute Ratel C4
+  - NjRAT
+  - RedLine Stealer
+  - Rhysida Ransomware
+  - Swift Slicer
+  - IcedID
+  - DarkCrystal RAT
   - Chaos Ransomware
+  - PlugX
+  - Industroyer2
+  - Azorult
+  - Remcos
+  - XMRig
+  - Qakbot
+  - Volt Typhoon
+  - Hermetic Wiper
+  - Warzone RAT
   - Trickbot
   - Amadey
   - BlackByte Ransomware
-  - Warzone RAT
-  - NjRAT
-  - PlugX
-  - DarkGate Malware
-  - Rhysida Ransomware
+  - LockBit Ransomware
+  - CISA AA23-347A
+  - Data Destruction
   asset_type: Endpoint
   confidence: 50
   impact: 40

detections/endpoint/extraction_of_registry_hives.yml

@@ -1,7 +1,7 @@
 name: Extraction of Registry Hives
 id: 8bbb7d58-b360-11eb-ba21-acde48001122
 version: 2
-date: '2021-09-09'
+date: '2023-12-27'
 author: Michael Haag, Splunk
 status: production
 type: TTP
@@ -35,10 +35,11 @@ references:
 - https://media.defense.gov/2023/May/24/2003229517/-1/-1/0/CSA_Living_off_the_Land.PDF
 tags:
   analytic_story:
-  - DarkSide Ransomware
-  - Credential Dumping
-  - CISA AA22-257A
   - Volt Typhoon
+  - Credential Dumping
+  - CISA AA23-347A
+  - DarkSide Ransomware
+  - CISA AA22-257A
   asset_type: Endpoint
   confidence: 70
   impact: 80

detections/endpoint/get_aduser_with_powershell.yml

@@ -1,7 +1,7 @@
 name: Get ADUser with PowerShell
 id: 0b6ee3f4-04e3-11ec-a87d-acde48001122
 version: 1
-date: '2021-08-24'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: Hunting
@@ -35,6 +35,7 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 50
   impact: 50

detections/endpoint/get_aduser_with_powershell_script_block.yml

@@ -1,7 +1,7 @@
 name: Get ADUser with PowerShell Script Block
 id: 21432e40-04f4-11ec-b7e6-acde48001122
 version: 2
-date: '2022-09-13'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: Hunting
@@ -14,8 +14,8 @@ data_source:
 - Powershell 4104
 search: '`powershell` EventCode=4104 ScriptBlockText = "*get-aduser*" ScriptBlockText
   = "*-filter*" | stats count min(_time) as firstTime max(_time) as lastTime by EventCode
-  ScriptBlockText Computer UserID | rename Computer as dest, UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
-  | `get_aduser_with_powershell_script_block_filter`'
+  ScriptBlockText Computer UserID | rename Computer as dest, UserID as user| `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `get_aduser_with_powershell_script_block_filter`'
 how_to_implement: The following Hunting analytic requires PowerShell operational logs
   to be imported. Modify the powershell macro as needed to match the sourcetype or
   add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
@@ -27,10 +27,12 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 50
   impact: 50
-  message: Powershell process having commandline "get-aduser" for user enumeration on $dest$
+  message: Powershell process having commandline "get-aduser" for user enumeration
+    on $dest$
   mitre_attack_id:
   - T1087.002
   - T1087

detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell.yml

@@ -1,7 +1,7 @@
 name: Get ADUserResultantPasswordPolicy with Powershell
 id: 8b5ef342-065a-11ec-b0fc-acde48001122
 version: 1
-date: '2021-08-26'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -35,6 +35,7 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 50
   impact: 50

detections/endpoint/get_aduserresultantpasswordpolicy_with_powershell_script_block.yml

@@ -1,7 +1,7 @@
 name: Get ADUserResultantPasswordPolicy with Powershell Script Block
 id: 737e1eb0-065a-11ec-921a-acde48001122
 version: 3
-date: '2023-11-07'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -14,8 +14,8 @@ data_source:
 - Powershell 4104
 search: '`powershell` EventCode=4104 ScriptBlockText="*Get-ADUserResultantPasswordPolicy*"
   | stats count min(_time) as firstTime max(_time) as lastTime by Opcode Computer
-  UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
-  | `get_aduserresultantpasswordpolicy_with_powershell_script_block_filter`'
+  UserID EventCode ScriptBlockText | rename Computer as dest | rename UserID as user
+  | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `get_aduserresultantpasswordpolicy_with_powershell_script_block_filter`'
 how_to_implement: The following Hunting analytic requires PowerShell operational logs
   to be imported. Modify the powershell macro as needed to match the sourcetype or
   add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
@@ -27,11 +27,12 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 30
   impact: 30
-  message: powershell process having commandline to query domain
-    user password policy detected on host - $dest$.
+  message: powershell process having commandline to query domain user password policy
+    detected on host - $dest$.
   mitre_attack_id:
   - T1201
   observable:
@@ -61,4 +62,4 @@ tests:
   attack_data:
   - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/sbl_xml.log
     source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational
-    sourcetype: xmlwineventlog
+    sourcetype: xmlwineventlog

detections/endpoint/get_domainuser_with_powershell.yml

@@ -1,7 +1,7 @@
 name: Get DomainUser with PowerShell
 id: 9a5a41d6-04e7-11ec-923c-acde48001122
 version: 1
-date: '2021-08-24'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -34,6 +34,7 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 50
   impact: 50

detections/endpoint/get_domainuser_with_powershell_script_block.yml

@@ -1,7 +1,7 @@
 name: Get DomainUser with PowerShell Script Block
 id: 61994268-04f4-11ec-865c-acde48001122
 version: 3
-date: '2022-11-13'
+date: '2023-12-27'
 author: Teoderick Contreras, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -14,8 +14,8 @@ data_source:
 - Powershell 4104
 search: '`powershell` EventCode=4104 ScriptBlockText = "*Get-DomainUser*" | stats
   count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText
-  Computer UserID | rename Computer as dest, UserID as user| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
-  | `get_domainuser_with_powershell_script_block_filter`'
+  Computer UserID | rename Computer as dest, UserID as user| `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `get_domainuser_with_powershell_script_block_filter`'
 how_to_implement: The following Hunting analytic requires PowerShell operational logs
   to be imported. Modify the powershell macro as needed to match the sourcetype or
   add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
@@ -25,10 +25,12 @@ references:
 tags:
   analytic_story:
   - Active Directory Discovery
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 50
   impact: 50
-  message: Powershell process having commandline "*Get-DomainUser*" for user enumeration on $dest$
+  message: Powershell process having commandline "*Get-DomainUser*" for user enumeration
+    on $dest$
   mitre_attack_id:
   - T1087.002
   - T1087

detections/endpoint/mimikatz_passtheticket_commandline_parameters.yml

@@ -1,7 +1,7 @@
 name: Mimikatz PassTheTicket CommandLine Parameters
 id: 13bbd574-83ac-11ec-99d4-acde48001122
 version: 1
-date: '2022-02-01'
+date: '2023-12-27'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -35,9 +35,10 @@ references:
 - https://attack.mitre.org/techniques/T1550/003/
 tags:
   analytic_story:
-  - Active Directory Kerberos Attacks
-  - CISA AA22-320A
   - Sandworm Tools
+  - CISA AA23-347A
+  - CISA AA22-320A
+  - Active Directory Kerberos Attacks
   asset_type: endpoint
   confidence: 60
   impact: 60

detections/endpoint/msmpeng_application_dll_side_loading.yml

@@ -6,7 +6,7 @@ author: Teoderick Contreras, Splunk, Sanjay Govind
 status: production
 type: TTP
 description: This search is to detect a suspicious creation of msmpeng.exe or mpsvc.dll
-  in non default windows defender folder. This technique was seen couple days ago
+  in non default windows defender folder. This technique was seen
   with revil ransomware in Kaseya Supply chain. The approach is to drop an old version
   of msmpeng.exe to load the actual payload name as mspvc.dll which will load the
   revil ransomware to the compromise machine
@@ -16,7 +16,7 @@ search: '|tstats `security_content_summariesonly` values(Filesystem.file_path) a
   file_path count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem
   where (Filesystem.file_name = "msmpeng.exe" OR Filesystem.file_name = "mpsvc.dll")  AND NOT 
   (Filesystem.file_path IN ("*\\Program Files\\windows defender\\*","*\\WinSxS\\*defender-service*","*\\WinSxS\\Temp\\*defender-service*")) by Filesystem.file_create_time
-  Filesystem.process_id  Filesystem.file_name Filesystem.user | `drop_dm_object_name(Filesystem)`
+  Filesystem.process_id  Filesystem.file_name Filesystem.user Filesystem.dest | `drop_dm_object_name(Filesystem)`
   | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `msmpeng_application_dll_side_loading_filter`'
 how_to_implement: To successfully implement this search you need to be ingesting information
   on process that include the name of the Filesystem responsible for the changes from
@@ -31,7 +31,7 @@ tags:
   asset_type: Endpoint
   confidence: 50
   impact: 50
-  message: ''
+  message: Suspicious creation of msmpeng.exe or mpsvc.dll in non default windows defender folder on host - $dest$
   mitre_attack_id:
   - T1574.002
   - T1574

detections/endpoint/network_connection_discovery_with_netstat.yml

@@ -1,7 +1,7 @@
 name: Network Connection Discovery With Netstat
 id: 2cf5cc25-f39a-436d-a790-4857e5995ede
 version: 1
-date: '2021-09-10'
+date: '2023-12-27'
 author: Mauricio Velazco, Splunk
 status: production
 type: Hunting
@@ -32,12 +32,13 @@ references:
 - https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/
 tags:
   analytic_story:
+  - Volt Typhoon
   - Active Directory Discovery
+  - Prestige Ransomware
+  - Windows Post-Exploitation
   - Qakbot
   - CISA AA22-277A
-  - Windows Post-Exploitation
-  - Prestige Ransomware
-  - Volt Typhoon
+  - CISA AA23-347A
   - PlugX
   asset_type: Endpoint
   confidence: 50

detections/endpoint/non_chrome_process_accessing_chrome_default_dir.yml

@@ -1,7 +1,7 @@
 name: Non Chrome Process Accessing Chrome Default Dir
 id: 81263de4-160a-11ec-944f-acde48001122
 version: 1
-date: '2023-04-25'
+date: '2023-12-27'
 author: Teoderick Contreras, Splunk
 status: production
 type: Anomaly
@@ -29,13 +29,14 @@ references: []
 tags:
   analytic_story:
   - Remcos
+  - NjRAT
+  - Warzone RAT
   - 3CX Supply Chain Attack
-  - AgentTesla
   - RedLine Stealer
   - FIN7
-  - Warzone RAT
-  - NjRAT
   - DarkGate Malware
+  - AgentTesla
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 70
   impact: 50

detections/endpoint/non_firefox_process_access_firefox_profile_dir.yml

@@ -1,7 +1,7 @@
 name: Non Firefox Process Access Firefox Profile Dir
 id: e6fc13b0-1609-11ec-b533-acde48001122
 version: 1
-date: '2023-04-25'
+date: '2023-12-27'
 author: Teoderick Contreras, Splunk
 status: production
 type: Anomaly
@@ -30,13 +30,14 @@ tags:
   analytic_story:
   - Azorult
   - Remcos
+  - NjRAT
+  - Warzone RAT
   - 3CX Supply Chain Attack
-  - AgentTesla
   - RedLine Stealer
   - FIN7
-  - Warzone RAT
-  - NjRAT
   - DarkGate Malware
+  - AgentTesla
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 70
   impact: 50

detections/endpoint/powershell_4104_hunting.yml

@@ -1,7 +1,7 @@
 name: PowerShell 4104 Hunting
 id: d6f2b006-0041-11ec-8885-acde48001122
 version: 4
-date: '2023-06-14'
+date: '2023-12-27'
 author: Michael Haag, Splunk
 status: production
 type: Hunting
@@ -20,9 +20,8 @@ search: '`powershell` EventCode=4104 | eval DoIt = if(match(ScriptBlockText,"(?i
   AND match(lower(ScriptBlockText), "frombase64string") ,5,0) | eval mimikatz=if(match(lower(ScriptBlockText),"mimikatz")
   OR match(lower(ScriptBlockText), "-dumpcr") OR match(lower(ScriptBlockText), "SEKURLSA::Pth")
   OR match(lower(ScriptBlockText), "kerberos::ptt") OR match(lower(ScriptBlockText),
-  "kerberos::golden") ,5,0) 
-   | eval iex=if(match(ScriptBlockText, "(?i)iex|invoke-expression"),2,0)
-   | eval webclient=if(match(lower(ScriptBlockText),"http") OR match(lower(ScriptBlockText),"web(client|request)")
+  "kerberos::golden") ,5,0) | eval iex=if(match(ScriptBlockText, "(?i)iex|invoke-expression"),2,0)
+  | eval webclient=if(match(lower(ScriptBlockText),"http") OR match(lower(ScriptBlockText),"web(client|request)")
   OR match(lower(ScriptBlockText),"socket") OR match(lower(ScriptBlockText),"download(file|string)")
   OR match(lower(ScriptBlockText),"bitstransfer") OR match(lower(ScriptBlockText),"internetexplorer.application")
   OR match(lower(ScriptBlockText),"xmlhttp"),5,0) | eval get = if(match(lower(ScriptBlockText),"get-"),
@@ -37,10 +36,10 @@ search: '`powershell` EventCode=4104 | eval DoIt = if(match(ScriptBlockText,"(?i
   | eval invokecmd = if(match(lower(ScriptBlockText),"invoke-command"), "4", 0) |
   addtotals fieldname=Score DoIt, enccom, suspcmdlet, suspkeywrd, compressed, downgrade,
   mimikatz, iex, empire, rundll32, webclient, syswow64, httplocal, reflection, invokewmi,
-  invokecmd, base64, get | stats values(Score) by UserID, Computer, DoIt, enccom, compressed, downgrade,
-  iex, mimikatz, rundll32, empire, webclient, syswow64, httplocal, reflection, invokewmi,
-  invokecmd, base64, get, suspcmdlet, suspkeywrd | rename Computer as dest, UserID as user
-  | `powershell_4104_hunting_filter`'
+  invokecmd, base64, get | stats values(Score) by UserID, Computer, DoIt, enccom,
+  compressed, downgrade, iex, mimikatz, rundll32, empire, webclient, syswow64, httplocal,
+  reflection, invokewmi, invokecmd, base64, get, suspcmdlet, suspkeywrd | rename Computer
+  as dest, UserID as user | `powershell_4104_hunting_filter`'
 how_to_implement: The following Hunting analytic requires PowerShell operational logs
   to be imported. Modify the powershell macro as needed to match the sourcetype or
   add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
@@ -59,14 +58,16 @@ tags:
   analytic_story:
   - Malicious PowerShell
   - Hermetic Wiper
-  - Data Destruction
-  - Flax Typhoon
-  - DarkGate Malware
   - Rhysida Ransomware
+  - DarkGate Malware
+  - Flax Typhoon
+  - CISA AA23-347A
+  - Data Destruction
   asset_type: Endpoint
   confidence: 100
   impact: 80
-  message: Powershell was identified on endpoint $host$ by user $user$ executing suspicious commands.
+  message: Powershell was identified on endpoint $host$ by user $user$ executing suspicious
+    commands.
   mitre_attack_id:
   - T1059
   - T1059.001

detections/endpoint/powershell_domain_enumeration.yml

@@ -1,7 +1,7 @@
 name: PowerShell Domain Enumeration
 id: e1866ce2-ca22-11eb-8e44-acde48001122
 version: 2
-date: '2023-04-14'
+date: '2023-12-27'
 author: Michael Haag, Splunk
 status: production
 type: TTP
@@ -21,7 +21,8 @@ data_source:
 - Powershell 4104
 search: '`powershell` EventCode=4104 ScriptBlockText IN (*get-netdomaintrust*, *get-netforesttrust*,
   *get-addomain*, *get-adgroupmember*, *get-domainuser*) | stats count min(_time)
-  as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText UserID | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)`
+  as firstTime max(_time) as lastTime by Computer EventCode ScriptBlockText UserID
+  | rename Computer as dest | rename UserID as user | `security_content_ctime(firstTime)`
   | `security_content_ctime(lastTime)` | `powershell_domain_enumeration_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
@@ -35,8 +36,9 @@ references:
 - https://www.splunk.com/en_us/blog/security/hunting-for-malicious-powershell-using-script-block-logging.html
 tags:
   analytic_story:
-  - Malicious PowerShell
   - Hermetic Wiper
+  - Malicious PowerShell
+  - CISA AA23-347A
   - Data Destruction
   asset_type: Endpoint
   confidence: 70

detections/endpoint/registry_keys_used_for_persistence.yml

@@ -1,16 +1,17 @@
 name: Registry Keys Used For Persistence
 id: f5f6af30-7aa7-4295-bfe9-07fe87c01a4b
 version: 9
-date: '2023-06-06'
+date: '2023-12-27'
 author: Jose Hernandez, David Dorsey, Teoderick Contreras, Rod Soto, Splunk
 status: production
 type: TTP
-description: The search looks for modifications or alterations made to registry keys 
-  that have the potential to initiate the launch of an application or service during system startup. 
-  By monitoring and detecting modifications in these registry keys, we can identify suspicious or 
-  unauthorized changes that could be indicative of malicious activity. 
-  This proactive approach helps in safeguarding the system's 
-  integrity and security by promptly identifying and mitigating potential threats that aim to gain persistence or execute malicious actions during the startup process.
+description: The search looks for modifications or alterations made to registry keys
+  that have the potential to initiate the launch of an application or service during
+  system startup. By monitoring and detecting modifications in these registry keys,
+  we can identify suspicious or unauthorized changes that could be indicative of malicious
+  activity. This proactive approach helps in safeguarding the system's integrity and
+  security by promptly identifying and mitigating potential threats that aim to gain
+  persistence or execute malicious actions during the startup process.
 data_source:
 - Sysmon Event ID 12
 - Sysmon Event ID 13
@@ -18,9 +19,9 @@ data_source:
 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\\CurrentVersion\\RunOnce
   OR Registry.registry_path=*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\StartupApproved\\Run
-  OR Registry.registry_path= "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\*"
-  OR Registry.registry_path= "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\*"
-  OR Registry.registry_path=*\\currentversion\\run* OR Registry.registry_path=*\\currentVersion\\Windows\\Appinit_Dlls*
+  OR Registry.registry_path= "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User
+  Shell Folders\\*" OR Registry.registry_path= "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell
+  Folders\\*" OR Registry.registry_path=*\\currentversion\\run* OR Registry.registry_path=*\\currentVersion\\Windows\\Appinit_Dlls*
   OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Shell* OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Notify*
   OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\Userinit* OR Registry.registry_path=*\\CurrentVersion\\Winlogon\\VmApplet*
   OR Registry.registry_path=*\\currentversion\\policies\\explorer\\run* OR Registry.registry_path=*\\currentversion\\runservices*
@@ -51,27 +52,28 @@ known_false_positives: There are many legitimate applications that must execute
 references: []
 tags:
   analytic_story:
-  - Suspicious Windows Registry Activities
-  - Suspicious MSHTA Activity
-  - DHS Report TA18-074A
-  - Possible Backdoor Activity Associated With MUDCARP Espionage Campaigns
+  - AsyncRAT
   - Ransomware
   - Windows Persistence Techniques
-  - 'Emotet Malware  DHS Report TA18-201A '
+  - DarkGate Malware
+  - NjRAT
+  - RedLine Stealer
   - IcedID
+  - Sneaky Active Directory Persistence Tricks
+  - Chaos Ransomware
+  - Azorult
+  - DHS Report TA18-074A
+  - 'Emotet Malware  DHS Report TA18-201A '
   - Remcos
   - Windows Registry Abuse
-  - Azorult
   - Qakbot
-  - Chaos Ransomware
-  - AsyncRAT
-  - Amadey
-  - Sneaky Active Directory Persistence Tricks
-  - BlackByte Ransomware
+  - Suspicious MSHTA Activity
+  - Suspicious Windows Registry Activities
   - Warzone RAT
-  - NjRAT
-  - DarkGate Malware
-  - RedLine Stealer
+  - Possible Backdoor Activity Associated With MUDCARP Espionage Campaigns
+  - Amadey
+  - BlackByte Ransomware
+  - CISA AA23-347A
   asset_type: Endpoint
   confidence: 95
   impact: 80

detections/endpoint/remote_process_instantiation_via_wmi.yml

@@ -1,7 +1,7 @@
 name: Remote Process Instantiation via WMI
 id: d25d2c3d-d9d8-40ec-8fdf-e86fe155a3da
 version: 7
-date: '2021-11-12'
+date: '2023-12-27'
 author: Rico Valdez, Mauricio Velazco, Splunk
 status: production
 type: TTP
@@ -34,8 +34,9 @@ references:
 tags:
   analytic_story:
   - Ransomware
-  - Suspicious WMI Use
+  - CISA AA23-347A
   - Active Directory Lateral Movement
+  - Suspicious WMI Use
   asset_type: Endpoint
   confidence: 70
   impact: 70