Merge pull request #2880 from splunk/release_v4.14.0

Release branch for 4.14.0

.vscode/launch.json

@@ -49,6 +49,15 @@
             "justMyCode": true,
             "args": ["-p", "detections", "content_changer", "-cf", "fix_kill_chain"]
         },
+        {
+            "name": "contentctl convert",
+            "type": "python",
+            "request": "launch",
+            "program": "${workspaceFolder}/contentctl.py",
+            "console": "integratedTerminal",
+            "justMyCode": true,
+            "args": ["-p", ".", "convert", "-dm", "ocsf", "-dp", "dev_ssa/endpoint/ssa___windows_wmiprvse_spawn_msbuild.yml", "-o", "ssa_detections/endpoint"]
+        },
         {
             "name": "Python: Current File",
             "type": "python",

bin/contentctl_project/contentctl_infrastructure/builder/backend_splunk_ba.py

@@ -67,6 +67,7 @@ class SplunkBABackend(TextQueryBackend):
     wildcard_match_expression : ClassVar[Optional[str]] = "{field} LIKE {value}"
 
 
+
     def __init__(self, processing_pipeline: Optional["sigma.processing.pipeline.ProcessingPipeline"] = None, collect_errors: bool = False, min_time : str = "-30d", max_time : str = "now", detection : Detection = None, field_mapping: dict = None, **kwargs):
         super().__init__(processing_pipeline, collect_errors, **kwargs)
         self.min_time = min_time or "-30d"
@@ -110,13 +111,29 @@ def finalize_query_data_model(self, rule: SigmaRule, query: str, index: int, sta
                     parent = new_val
                     i = i + 1
                     continue
-                parser_str = '| eval ' + new_val + ' = ' + parent + '.' + val + ' '
+                new_val_spaces = new_val + "="
+                if new_val_spaces not in query:
+                    parser_str = '| eval ' + new_val + ' = ' + parent + '.' + val + ' '
+                else:
+                    parser_str = '| eval ' + new_val + ' = ' + 'lower(' + parent + '.' + val + ') '
                 detection_str = detection_str + parser_str
                 parsed_fields.append(new_val)
                 parent = new_val
                 i = i + 1
 
-        detection_str = detection_str + "| where " + query
+        ### Convert sigma values into lower case
+        lower_query = ""
+        in_quotes = False
+        for char in query:
+            if char == '"':
+                in_quotes = not in_quotes
+            if in_quotes:
+                lower_query += char.lower()
+            else:
+                lower_query += char
+
+        detection_str = detection_str + "| where " + lower_query
+
         detection_str = detection_str.replace("\\\\\\\\", "\\\\")
         return detection_str
 

contentctl.py

@@ -1,6 +1,6 @@
 import sys
 import argparse
-import os
+import os 
 
 from bin.contentctl_project.contentctl_core.domain.entities.link_validator import LinkValidator
 

detections/application/suspicious_email_attachment_extensions.yml

@@ -5,8 +5,8 @@ date: '2023-04-14'
 author: David Dorsey, Splunk
 status: experimental
 type: Anomaly
-description: This search looks for emails that have attachments with suspicious file
-  extensions.
+description: |-
+  The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack.
 data_source: []
 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
   as lastTime from datamodel=Email where All_Email.file_name="*" by All_Email.src_user,

detections/application/web_servers_executing_suspicious_processes.yml

@@ -5,8 +5,8 @@ date: '2019-04-01'
 author: David Dorsey, Splunk
 status: experimental
 type: TTP
-description: This search looks for suspicious processes on all systems labeled as
-  web servers.
+description: |-
+  The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack.
 data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)

detections/cloud/amazon_eks_kubernetes_pod_scan_detection.yml

@@ -5,8 +5,8 @@ date: '2020-04-15'
 author: Rod Soto, Splunk
 status: experimental
 type: Hunting
-description: This search provides detection information on unauthenticated requests
-  against Kubernetes' Pods API
+description: |-
+  The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action.  Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts.
 data_source: []
 search: '`aws_cloudwatchlogs_eks` "user.username"="system:anonymous" verb=list objectRef.resource=pods
   requestURI="/api/v1/pods" | rename source as cluster_name sourceIPs{} as src_ip

detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml

@@ -5,20 +5,15 @@ date: '2023-04-28'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
-description: The following analytic is geared towards detecting potential privilege escalation threats in Azure Active Directory (AD). It identifies instances where privileged roles, which hold elevated permissions, are assigned to Service Principals. These non-human entities that can access Azure resources could be exploited in an attack scenario, leading to unauthorized access or malicious activities. The analytic runs a specific search within the ingested Azure AD events, specifically leveraging the AuditLogs log category. Keep in mind, however, that there could be false positives, as administrators may legitimately assign privileged roles to Service Principals.
+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: ' `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`'
 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.
@@ -33,8 +28,8 @@ tags:
   asset_type: Azure Active Directory
   confidence: 50
   impact: 70
-  message: A privileged Azure AD role was assigned to the Service Principal $displayName$ initiated
-    by $initiatedBy$
+  message: A privileged Azure AD role was assigned to the Service Principal $displayName$
+    initiated by $initiatedBy$
   mitre_attack_id:
   - T1098
   - T1098.003

detections/cloud/circle_ci_disable_security_job.yml

@@ -5,7 +5,8 @@ date: '2021-09-02'
 author: Patrick Bareiss, Splunk
 status: production
 type: Anomaly
-description: This search looks for disable security job in CircleCI pipeline.
+description: |-
+  This analytic searches for a specific behavior in CircleCI pipelines such as the disabling of security jobs. The detection is made by using a Splunk query that renames certain fields and retrieves values for specified job names, workflow IDs and names, user information, commit messages, URLs, and branches. Then, the query identifies mandatory jobs for each workflow and searches for instances where they were run. The search also identifies the phase of the pipeline as "build" and extracts the repository name from the URL using regular expressions. The detection is important because it detects attempts to bypass security measures in CircleCI pipelines, which can potentially lead to malicious code being introduced into the pipeline, data breaches, system downtime, and reputational damage.  False positives might occur since legitimate use cases can require the disabling of security jobs. However, you can proactively monitor and identify any suspicious activity in the pipeline using this analytic and mitigate potential threats through early detection.
 data_source: []
 search: '`circleci` | rename vcs.committer_name as user vcs.subject as commit_message
   vcs.url as url workflows.* as *  | stats values(job_name) as job_names by workflow_id

detections/cloud/circle_ci_disable_security_step.yml

@@ -5,7 +5,8 @@ date: '2021-09-01'
 author: Patrick Bareiss, Splunk
 status: experimental
 type: Anomaly
-description: This search looks for disable security step in CircleCI pipeline.
+description: |-
+  The following analytic detects the disablement of security steps in a CircleCI pipeline. Addressing instances of security step disablement in CircleCI pipelines can mitigate the risks associated with potential security vulnerabilities and unauthorized changes. A proactive approach helps protect the organization's infrastructure, data, and overall security posture. The detection is made by a Splunk query that searches for specific criteria within CircleCI logs through a combination of field renaming, joining, and statistical analysis to identify instances where security steps are disabled. It retrieves information such as job IDs, job names, commit details, and user information from the CircleCI logs.  The detection is important because it indicates potential security vulnerabilities or unauthorized changes to the pipeline caused by someone within the organization intentionally or unintentionally disabling security steps in the CircleCI pipeline.Disabling security steps can leave the pipeline and the associated infrastructure exposed to potential attacks, data breaches, or the introduction of malicious code into the pipeline. Investigate by reviewing the job name, commit details, and user information associated with the disablement of security steps. You must also examine any relevant on-disk artifacts and identify concurrent processes that might indicate the source of the attack or unauthorized change.
 data_source: []
 search: '`circleci` | rename workflows.job_id AS job_id | join job_id [ | search `circleci`
   | stats values(name) as step_names count by job_id job_name ] | stats count by step_names

detections/cloud/cloud_api_calls_from_previously_unseen_user_roles.yml

@@ -5,7 +5,8 @@ date: '2020-09-04'
 author: David Dorsey, Splunk
 status: experimental
 type: Anomaly
-description: This search looks for new commands from each user role.
+description: |-
+  The following analytic detects when a new command is run by a user, who typically does not run those commands. The detection is made by a Splunk query to search for these commands in the Change data model. Identifies commands run by users with the user_type of AssumedRole and a status of success. The query retrieves the earliest and latest timestamps of each command run and groups the results by the user and command. Then, it drops the unnecessary data model object name and creates a lookup to verify if the command was seen before. The lookup table contains information about previously seen cloud API calls for each user role, including the first time the command was seen and whether enough data is available for analysis. If the firstTimeSeenUserApiCall field is null or greater than the relative time of 24 hours ago, it indicates that the command is new and was not seen before. The final result table includes the firstTime, user, object, and command fields of the new commands. It also applies the security_content_ctime function to format the timestamps and applies a filter to remove any cloud API calls from previously unseen user roles. The detection is important because it helps to identify new commands run by different user roles. New commands can indicate potential malicious activity or unauthorized actions within the environment. Detecting and investigating these new commands can help identify and mitigate potential security threats earlier, preventing data breaches, unauthorized access, or other damaging outcomes.
 data_source: []
 search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime from datamodel=Change
   where All_Changes.user_type=AssumedRole AND All_Changes.status=success by All_Changes.user,

detections/cloud/cloud_compute_instance_created_with_previously_unseen_image.yml

@@ -5,8 +5,8 @@ date: '2018-10-12'
 author: David Dorsey, Splunk
 status: experimental
 type: Anomaly
-description: This search looks for cloud compute instances being created with previously
-  unseen image IDs.
+description: |-
+  The following analytic detects potential instances that are created in a cloud computing environment using new or unknown image IDs that have not been seen before. This detection is important because it helps to investigate and take appropriate action to prevent further damage or unauthorized access to the Cloud environment, which can include data breaches, unauthorized access to sensitive information, or the deployment of malicious payloads within the cloud environment. False positives might occur since legitimate instances can also have previously unseen image IDs. Next steps include conducting an extensive triage and investigation to determine the nature of the activity. During triage, review the details of the created instances, including the user responsible for the creation, the image ID used, and any associated metadata. Additionally, consider inspecting any relevant on-disk artifacts and analyzing concurrent processes to identify the source of the attack.
 data_source: []
 search: '| tstats count earliest(_time) as firstTime, latest(_time) as lastTime values(All_Changes.object_id)
   as dest from datamodel=Change where All_Changes.action=created by All_Changes.Instance_Changes.image_id,

detections/cloud/cloud_compute_instance_created_with_previously_unseen_instance_type.yml

@@ -5,7 +5,7 @@ date: '2020-09-12'
 author: David Dorsey, Splunk
 status: experimental
 type: Anomaly
-description: Find EC2 instances being created with previously unseen instance types.
+description: The following analytic detects the creation of EC2 instances with previously unseen instance types. The detection is made by using a Splunk query to identify the EC2 instances. First, the query searches for changes in the EC2 instance creation action and filters for instances with instance types that are not recognized or previously seen. Next, the query uses the Splunk tstats command to gather the necessary information from the Change data model. Then, it filters the instances with unknown instance types and reviews previously seen instance types to determine if they are new or not. The detection is important because it identifies attackers attempting to create instances with unknown or potentially compromised instance types, which can be an attempt to gain unauthorized access to sensitive data, compromise of systems, exfiltrate data, potential disruption of services, or launch other malicious activities within the environment. False positives might occur since there might be legitimate reasons for creating instances with previously unseen instance types. Therefore, you must carefully review and triage all alerts.
 data_source: []
 search: '| tstats earliest(_time) as firstTime, latest(_time) as lastTime values(All_Changes.object_id)
   as dest, count from datamodel=Change where All_Changes.action=created by All_Changes.Instance_Changes.instance_type,