Manually update the .yml

detections/cloud/azure_ad_privileged_role_assigned_to_service_principal.yml

@@ -5,14 +5,7 @@ date: '2023-04-28'
 author: Mauricio Velazco, Splunk
 status: production
 type: TTP
-description: "This 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.\
-  \ \nThis 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."
+description: "This 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

detections/cloud/github_dependabot_alert.yml

@@ -5,9 +5,7 @@ date: '2021-09-01'
 author: Patrick Bareiss, Splunk
 status: production
 type: Anomaly
-description: |-
-  As a prerequisite, ensure that you ingest Github logs that contain information about Dependabot Alerts. This analytic detects Dependabot Alerts in Github logs.
-  The detection is made by first searching for logs that contain the action ""create"" and renames certain fields for easier analysis. Then, this analytic uses the ""stats"" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The ""phase"" field is set to ""code"" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the ""create"" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps.
+description: "As a prerequisite, ensure that you ingest Github logs that contain information about Dependabot Alerts. This analytic detects Dependabot Alerts in Github logs. The detection is made by first searching for logs that contain the action \"create\" and renames certain fields for easier analysis. Then, this analytic uses the \"stats\" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The \"phase\" field is set to \"code\" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the \"create\" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps."
 data_source: []
 search: '`github` alert.id=* action=create | rename repository.full_name as repository,
   repository.html_url as repository_url sender.login as user | stats min(_time) as

detections/cloud/github_pull_request_from_unknown_user.yml

@@ -5,25 +5,7 @@ date: '2021-09-01'
 author: Patrick Bareiss, Splunk
 status: production
 type: Anomaly
-description: "As a prerequisite, ensure that  you ingest GitHub logs into Splunk.\
-  \ \nand have access to the following fields: (i)`check_suite.pull_requests` (ii)\
-  \ `check_suite.head_commit.author.name`(iii) `repository.full_name` (iv) `check_suite.pull_requests.head.ref`(v)`check_suite.head_commit.message`\
-  \ This analytic detects pull requests from unknown users on GitHub. The detection\
-  \ is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests`\
-  \ field where the `id` is not specified. Next, the analytic retrieves information\
-  \ such as the author's name, the repository's full name, the head reference of the\
-  \ pull request, and the commit message from the `check_suite.head_commit` field.\
-  \ The analytic also includes a step to exclude known users by using the `github_known_users`\
-  \ lookup table, which helps to filter out pull requests from known users and focus\
-  \ on the pull requests from unknown users.\nThe detection is important because it\
-  \ locates potential malicious activity or unauthorized access since unknown users\
-  \ can introduce malicious code or gain unauthorized access to repositories leading\
-  \ to unauthorized code changes, data breaches, or other security incidents. Next\
-  \ steps include reviewing the author's name, the repository involved, the head reference\
-  \ of the pull request, and the commit message upon triage of a potential pull request\
-  \ from an unknown user. You must also analyze any relevant on-disk artifacts and\
-  \ investigate any concurrent processes to determine the source and intent of the\
-  \ pull request."
+description: "As a prerequisite, ensure that you ingest GitHub logs into Splunk and have access to the following fields: (i)`check_suite.pull_requests` (ii) `check_suite.head_commit.author.name` (iii) `repository.full_name` (iv) `check_suite.pull_requests.head.ref` (v) `check_suite.head_commit.message`. This analytic detects pull requests from unknown users on GitHub. The detection is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests` field where the `id` is not specified. Next, the analytic retrieves information such as the author's name, the repository's full name, the head reference of the pull request, and the commit message from the `check_suite.head_commit` field. The analytic also includes a step to exclude known users by using the `github_known_users` lookup table, which helps to filter out pull requests from known users and focus on the pull requests from unknown users. The detection is important because it locates potential malicious activity or unauthorized access since unknown users can introduce malicious code or gain unauthorized access to repositories leading to unauthorized code changes, data breaches, or other security incidents. Next steps include reviewing the author's name, the repository involved, the head reference of the pull request, and the commit message upon triage of a potential pull request from an unknown user. You must also analyze any relevant on-disk artifacts and investigate any concurrent processes to determine the source and intent of the pull request."
 data_source: []
 search: '`github` check_suite.pull_requests{}.id=* | stats count by check_suite.head_commit.author.name
   repository.full_name check_suite.pull_requests{}.head.ref check_suite.head_commit.message

detections/endpoint/common_ransomware_extensions.yml

@@ -5,16 +5,7 @@ date: '2022-11-10'
 author: David Dorsey, Michael Haag, Splunk, Steven Dick
 status: production
 type: Hunting
-description: "This analytic detects Searches for file modifications that commonly\
-  \ occur with Ransomware to detect modifications to files with extensions that are\
-  \ commonly used by Ransomware. The detection is made by searches for changes in\
-  \ the datamodel=Endpoint.Filesystem, specifically modifications to file extensions\
-  \ that match those commonly used by Ransomware.\nThe detection is important because\
-  \ it suggests that an attacker is attempting to encrypt or otherwise modify files\
-  \ in the environment using malware, potentially leading to data loss that can cause\
-  \ significant damage to an organization's data and systems. \nFalse positives might\
-  \ occur so the SOC must investigate the affected system to determine the source\
-  \ of the modification and take appropriate action to contain and remediate the attack."
+description: "This analytic detects Searches for file modifications that commonly occur with Ransomware to detect modifications to files with extensions that are commonly used by Ransomware. The detection is made by searches for changes in the datamodel=Endpoint.Filesystem, specifically modifications to file extensions that match those commonly used by Ransomware. The detection is important because it suggests that an attacker is attempting to encrypt or otherwise modify files in the environment using malware, potentially leading to data loss that can cause significant damage to an organization's data and systems. False positives might occur so the SOC must investigate the affected system to determine the source of the modification and take appropriate action to contain and remediate the attack."
 data_source:
 - Sysmon Event ID 11
 search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_time)

detections/endpoint/create_remote_thread_into_lsass.yml

@@ -5,9 +5,7 @@ date: '2019-12-06'
 author: Patrick Bareiss, Splunk
 status: production
 type: TTP
-description: |-
-  This analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon Event ID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security.
-  The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats.
+description: "This analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon Event ID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats."
 data_source:
 - Sysmon Event ID 8
 search: '`sysmon` EventID=8 TargetImage=*lsass.exe | stats count min(_time) as firstTime

detections/endpoint/credential_dumping_via_copy_command_from_shadow_copy.yml

@@ -5,24 +5,7 @@ date: '2021-09-16'
 author: Patrick Bareiss, Splunk
 status: production
 type: TTP
-description: "As a prerequisite, ensure that you are ingesting endpoint process logs\
-  \ into your Splunk instance. \nThis analytic detects the use of the copy command\
-  \ to dump credentials from a shadow copy so that you can detect potential threats\
-  \ earlier and mitigate the risks associated with credential dumping. The detection\
-  \ is made by using a Splunk query to search for specific processes that indicate\
-  \ credential dumping activity. The query looks for processes with command lines\
-  \ that include references to certain files, such as \"sam\", \"security\", \"system\"\
-  , and \"ntds.dit\", located in system directories like \"system32\" or \"windows\"\
-  . The detection is important because it suggests that an attacker is attempting\
-  \ to extract credentials from a shadow copy. Credential dumping is a common technique\
-  \ used by attackers to obtain sensitive login information and gain unauthorized\
-  \ access to systems to escalate privileges, move laterally within the network, or\
-  \ gain unauthorized access to sensitive data. False positives might occur since\
-  \ legitimate processes might also reference these files. During triage, it is crucial\
-  \ to review the process details, including the source and the command that is run.\
-  \ Additionally, you must capture and analyze any relevant on-disk artifacts and\
-  \ investigate concurrent processes to determine the source of the attack. Additional\
-  \ steps include...."
+description: "As a prerequisite, ensure that you are ingesting endpoint process logs into your Splunk instance. This analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as \"sam\", \"security\", \"system\", and \"ntds.dit\", located in system directories like \"system32\" or \"windows\". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack. Additional steps include...."
 data_source:
 - Sysmon Event ID 1
 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)

detections/endpoint/detect_baron_samedit_cve_2021_3156_via_osquery.yml

@@ -5,24 +5,7 @@ date: '2021-01-28'
 author: Shannon Davis, Splunk
 status: experimental
 type: TTP
-description: "This analytic detects the heap-based buffer overflow for the sudoedit\
-  \ command and identifies instances where the command \"sudoedit -s *\" is run using\
-  \ the osquery_process data source. \nThis indicates that the sudoedit command is\
-  \ used with the \"-s\" flag, which is associated with the heap-based buffer overflow\
-  \ vulnerability. The detection is important because it indicates a potential security\
-  \ vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify\
-  \ and respond to potential heap-based buffer overflow attacks to enhance the security\
-  \ posture of the organization. This vulnerability allows an attacker to escalate\
-  \ privileges and potentially gain unauthorized access to the system. If the attack\
-  \ is successful, the attacker can gain full control of the system, run arbitrary\
-  \ code, or access sensitive data. Such attacks can lead to data breaches, unauthorized\
-  \ access, and potential disruption of critical systems. False positives might occur\
-  \ since the legitimate use of the sudoedit command with the \"-s\" flag can also\
-  \ trigger this detection. You must carefully review and validate the findings before\
-  \ taking any action. Next steps include investigating all true positive detections\
-  \ promptly, reviewing the associated processes, gather relevant artifacts, identifying\
-  \ the source of the attack to contain the threat, mitigate the risks, and prevent\
-  \ further damage to the environment."
+description: "This analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command \"sudoedit -s *\" is run using the osquery_process data source. This indicates that the sudoedit command is used with the \"-s\" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the \"-s\" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment."
 data_source: []
 search: '`osquery_process` | search "columns.cmdline"="sudoedit -s \\*" | `detect_baron_samedit_cve_2021_3156_via_osquery_filter`'
 how_to_implement: OSQuery installed and configured to pick up process events (info