Merge branch 'develop' into getting_started

.github/workflows/datasource-dependabot.yml

@@ -0,0 +1,56 @@
+name: Splunk TA Update
+
+on:
+  workflow_dispatch:  # Manually trigger the workflow
+  schedule:
+    - cron: '55 06 * * *'  # Runs daily at midnight
+
+jobs:
+  data-source-validation-and-update:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          ref: 'develop'
+          token: ${{ secrets.DATA_SOURCES_DEPENDABOT }}
+      
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+          architecture: 'x64'  # or the version your script requires
+
+      - name: Install Python Dependencies and ContentCTL and Atomic Red Team
+        run: |
+          pip install "contentctl>=4.0.0"
+    
+      - name: Run ContentCTL Data source TA validation
+        id: validate
+        run: |
+          pwd
+          contentctl validate --data-source-TA-validation 2>&1 | tee data_source_validation.log
+        continue-on-error: true 
+      
+      - name: Print Validation Log
+        run: |
+          cat data_source_validation.log
+          rm -f =4.0.0
+
+      - name: Update Data Sources if Validation Fails
+        run: |
+          python .github/workflows/update_data_sources_ta.py
+          git status
+
+      - name: Create Pull Request
+        uses: peter-evans/create-pull-request@v6
+        with:
+          token: ${{ secrets.DATA_SOURCES_DEPENDABOT }}
+          commit-message: Updated TAs
+          branch: auto-ta-update-${{ github.run_number }}
+          base: develop
+          title: Automated Splunk TA Update ${{ github.run_number }}
+          body: "This PR contains updates to Splunk TAs made by GitHub Actions workflow."
+          paths: |
+            security_content/data_sources/**

.github/workflows/datasource-ta-check.yml

@@ -1,27 +0,0 @@
-name: datasource-ta-check
-on:
-  pull_request_target:
-  push:
-    branches:
-      - develop
-
-jobs:
-  datasource-ta-check: 
-    runs-on: ubuntu-latest
-    continue-on-error: true
-    steps:
-      - name: Check out the repository code
-        uses: actions/checkout@v4
-       
-      - uses: actions/setup-python@v5
-        with:
-          python-version: '3.11'
-          architecture: 'x64'
-     
-      - name: Install Python Dependencies and contentctl 
-        run: |
-          pip install contentctl>=4.0.0
-          
-      - name: Run datasource TA check
-        run: |
-          contentctl validate --data-source-TA-validation

.github/workflows/update_data_sources_ta.py

@@ -0,0 +1,62 @@
+import os
+import yaml
+from collections import OrderedDict
+
+# Custom YAML loader to preserve the order of keys
+class OrderedLoader(yaml.SafeLoader):
+    pass
+
+def construct_mapping(loader, node):
+    loader.flatten_mapping(node)
+    return OrderedDict(loader.construct_pairs(node))
+
+OrderedLoader.add_constructor(
+    yaml.resolver.BaseResolver.DEFAULT_MAPPING_TAG,
+    construct_mapping
+)
+
+# Custom YAML dumper to preserve the order of keys
+class OrderedDumper(yaml.SafeDumper):
+    pass
+
+def dict_representer(dumper, data):
+    return dumper.represent_dict(data.items())
+
+OrderedDumper.add_representer(OrderedDict, dict_representer)
+
+# Define the paths
+log_file_path = 'data_source_validation.log'
+data_sources_dir = 'data_sources'
+
+# Read the log file to find version mismatches
+with open(log_file_path, 'r') as log_file:
+    log_lines = log_file.readlines()
+
+# Parse the log file to find the TA name and the latest version
+for i, line in enumerate(log_lines):
+    if 'Version mismatch' in line:
+        ta_name = log_lines[i].split("'")[3].strip()
+        latest_version = log_lines[i + 1].split(':')[1].strip()
+        print(f"Found version mismatch for TA: {ta_name}, updating to version: {latest_version}")
+
+        # Update the YAML files in the data sources directory
+        for filename in os.listdir(data_sources_dir):
+            if filename.endswith('.yml'):
+                file_path = os.path.join(data_sources_dir, filename)
+                with open(file_path, 'r') as yml_file:
+                    data = yaml.load(yml_file, Loader=OrderedLoader)
+
+                # Check if the TA name matches and update the version
+                updated = False
+                for ta in data.get('supported_TA', []):
+                    if ta['name'] == ta_name:
+                        if ta['version'] != latest_version:
+                            ta['version'] = latest_version
+                            updated = True
+
+                # Write the updated data back to the YAML file
+                if updated:
+                    with open(file_path, 'w') as yml_file:
+                        yaml.dump(data, yml_file, Dumper=OrderedDumper)
+
+print("Version updates completed.")

data_sources/aws_cloudfront.yml

@@ -9,7 +9,7 @@ sourcetype: aws:cloudfront:accesslogs
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail.yml

@@ -10,5 +10,5 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 

data_sources/aws_cloudtrail_assumerolewithsaml.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_consolelogin.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_copyobject.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - additionalEventData.AuthenticationMethod

data_sources/aws_cloudtrail_createaccesskey.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_createkey.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_createloginprofile.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_createnetworkaclentry.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_createpolicyversion.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_createsnapshot.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_createtask.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_createvirtualmfadevice.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deactivatemfadevice.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deleteaccountpasswordpolicy.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deletealarms.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deletedetector.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_deletegroup.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deleteipset.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_deleteloggroup.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - apiVersion

data_sources/aws_cloudtrail_deletelogstream.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - apiVersion

data_sources/aws_cloudtrail_deletenetworkaclentry.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deletepolicy.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deleterule.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - apiVersion

data_sources/aws_cloudtrail_deletesnapshot.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deletetrail.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_deletevirtualmfadevice.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_deletewebacl.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - apiVersion

data_sources/aws_cloudtrail_describeeventaggregates.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_describeimagescanfindings.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_getaccountpasswordpolicy.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_getobject.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - additionalEventData.AuthenticationMethod

data_sources/aws_cloudtrail_getpassworddata.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_jobcreated.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_modifydbinstance.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_modifyimageattribute.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_modifysnapshotattribute.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_putbucketacl.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_putbucketlifecycle.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - additionalEventData.AuthenticationMethod

data_sources/aws_cloudtrail_putbucketreplication.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - additionalEventData.AuthenticationMethod

data_sources/aws_cloudtrail_putbucketversioning.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - additionalEventData.AuthenticationMethod

data_sources/aws_cloudtrail_putimage.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_putkeypolicy.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_replacenetworkaclentry.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_setdefaultpolicyversion.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_stoplogging.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudtrail_updateaccountpasswordpolicy.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_updateloginprofile.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_updatesamlprovider.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - action

data_sources/aws_cloudtrail_updatetrail.yml

@@ -10,7 +10,7 @@ separator: eventName
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - app

data_sources/aws_cloudwatchlogs_vpcflow.yml

@@ -9,7 +9,7 @@ sourcetype: aws:cloudwatchlogs:vpcflow
 separator: eventName
 supported_TA:
   - name: Splunk Add-on for AWS
-    version: 7.6.0
+    version: 7.7.0
     url: https://splunkbase.splunk.com/app/1876
 fields:
 - _raw

data_sources/aws_security_hub.yml

@@ -9,7 +9,7 @@ sourcetype: aws:securityhub:finding
 supported_TA:
 - name: Splunk Add-on for AWS
   url: https://splunkbase.splunk.com/app/1876
-  version: 7.6.0
+  version: 7.7.0
 fields:
 - _time
 - AwsAccountId

detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml

@@ -15,14 +15,13 @@ description: The following analytic identifies an AWS IAM account with concurren
   to sensitive corporate resources, leading to potential data breaches or further
   exploitation.
 data_source: []
-search: ' `amazon_security_lake` api.operation=DescribeEventAggregates "http_request.user_agent"!="AWS Internal" "src_endpoint.domain"!="health.amazonaws.com" 
-| eval time = time/pow(10,3)
-| `security_content_ctime(time)`
-| bin span=5m time 
-| stats values(src_endpoint.ip) as src_ip dc(src_endpoint.ip) as distinct_ip_count values(cloud.region) as cloud.region by time api.operation actor.user.account_uid actor.user.uid 
-| where distinct_ip_count > 1 
-| rename cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id, actor.user.uid as user
-| `asl_aws_concurrent_sessions_from_different_ips_filter`'
+search: ' `amazon_security_lake` api.operation=DescribeEventAggregates src_endpoint.domain!="AWS Internal" 
+  | bin span=5m _time
+  | stats values(src_endpoint.ip) as src_ip dc(src_endpoint.ip) as distinct_ip_count 
+  by _time identity.user.credential_uid identity.user.name
+  | where distinct_ip_count > 1 
+  | rename identity.user.name as user
+  | `asl_aws_concurrent_sessions_from_different_ips_filter`'
 how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides 
   security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search,
   ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or 
@@ -69,6 +68,7 @@ tags:
   - cloud.region
   risk_score: 42
   security_domain: threat
+  manual_test: Can't be tested automatically because of time span.
 tests:
 - name: True Positive Test
   attack_data:

detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml

@@ -26,6 +26,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml

@@ -25,6 +25,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml

@@ -25,6 +25,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_access_scanning.yml

@@ -26,6 +26,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml

@@ -19,8 +19,12 @@ search: '`kube_audit` user.username="system:anonymous" user.groups{} IN ("system
   requestReceivedTimestamp requestURI responseStatus.code sourceIPs{} stage user.groups{}
   user.uid user.username userAgent verb | rename sourceIPs{} as src_ip, user.username
   as user |`kubernetes_aws_detect_suspicious_kubectl_calls_filter`'
-how_to_implement: You must install splunk AWS add on and Splunk App for AWS. This
-  search works with cloudwatch logs.
+how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster.
+  Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
+  Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
+  Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: Kubectl calls are not malicious by nature. However source IP,
   verb and Object can reveal potential malicious activity, specially anonymous suspicious
   IPs and sensitive objects such as configmaps or secrets

detections/cloud/kubernetes_create_or_update_privileged_pod.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_cron_job_creation.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_daemonset_deployed.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_falco_shell_spawned.yml

@@ -19,11 +19,12 @@ search: '`kube_container_falco` "A shell was spawned in a container"
   |  fillnull
   | stats count by container_image container_image_tag container_name parent proc_exepath process user
   | `kubernetes_falco_shell_spawned_filter`'
-how_to_implement: The detection is based on data that originates from Falco, a cloud native runtime security tool. 
-  Falco is designed to detect anomalous activity in your applications and is a crucial component of this detection rule. 
-  To implement this detection rule, you need to install and configure Falco in your Kubernetes environment. 
-  Once Falco is set up, it will monitor the system calls in your Kubernetes infrastructure and generate logs for any suspicious activity. 
-  These logs are then ingested by Splunk for analysis. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. 
+how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster.
+  Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
+  Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
+  Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_node_port_creation.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_pod_created_in_default_namespace.yml

@@ -23,6 +23,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_pod_with_host_network_attachment.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml

@@ -22,7 +22,12 @@ search: '`kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.c
   | where count > 5
   | rename sourceIPs{} as src_ip, user.username as user
   | `kubernetes_scanning_by_unauthenticated_ip_address_filter`'
-how_to_implement: You must ingest Kubernetes audit logs.
+how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster.
+  Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
+  Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
+  Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_suspicious_image_pulling.yml

@@ -25,6 +25,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/cloud/kubernetes_unauthorized_access.yml

@@ -24,6 +24,8 @@ how_to_implement: The detection is based on data that originates from Kubernetes
   Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities.
   Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server.
   Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
+  When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then
+  you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
 known_false_positives: unknown
 references:
 - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

detections/deprecated/aws_cloud_provisioning_from_previously_unseen_region.yml

@@ -49,7 +49,7 @@ tags:
   - T1535
   observable:
   - name: user
-    type: User Name
+    type: User
     role:
     - Victim
   - name: src_ip

detections/deprecated/detect_activity_related_to_pass_the_hash_attacks.yml

@@ -10,11 +10,11 @@ description: This search looks for specific authentication events from the Windo
 data_source:
 - Windows Event Log Security 4624
 search: '`wineventlog_security` EventCode=4624 (Logon_Type=3 Logon_Process=NtLmSsp NOT AccountName="ANONYMOUS LOGON") OR (Logon_Type=9 Logon_Process=seclogo) 
-| fillnull 
-| stats count min(_time) as firstTime max(_time) as lastTime by EventCode, Logon_Type, WorkstationName, user, dest 
-| `security_content_ctime(firstTime)`
-| `security_content_ctime(lastTime)` 
-| `detect_activity_related_to_pass_the_hash_attacks_filter`'
+  | fillnull 
+  | stats count min(_time) as firstTime max(_time) as lastTime by EventCode, Logon_Type, WorkstationName, user, dest 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` 
+  | `detect_activity_related_to_pass_the_hash_attacks_filter`'
 how_to_implement: To successfully implement this search, you must ingest your Windows
   Security Event logs and leverage the latest TA for Windows.
 known_false_positives: Legitimate logon activity by authorized NTLM systems may be
@@ -23,6 +23,7 @@ references: []
 tags:
   analytic_story:
   - Active Directory Lateral Movement
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 70
   impact: 70

detections/deprecated/detect_aws_api_activities_from_unapproved_accounts.yml

@@ -56,7 +56,7 @@ tags:
   - T1078.004
   observable:
   - name: user
-    type: User Name
+    type: User
     role:
     - Victim
   product:

detections/endpoint/anomalous_usage_of_7zip.yml

@@ -43,6 +43,7 @@ tags:
   - BlackByte Ransomware
   - Cobalt Strike
   - Graceful Wipe Out Attack
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 80
   impact: 80

detections/endpoint/create_local_admin_accounts_using_net_exe.yml

@@ -37,6 +37,7 @@ tags:
   - Azorult
   - CISA AA22-257A
   - DarkGate Malware
+  - CISA AA24-241A
   asset_type: Endpoint
   confidence: 60
   impact: 50

detections/endpoint/create_remote_thread_into_lsass.yml

@@ -31,6 +31,7 @@ references:
 tags:
   analytic_story:
   - Credential Dumping
+  - BlackSuit Ransomware
   asset_type: Windows
   confidence: 90
   impact: 90

detections/endpoint/detect_credential_dumping_through_lsass_access.yml

@@ -35,6 +35,7 @@ tags:
   - Detect Zerologon Attack
   - CISA AA23-347A
   - Credential Dumping
+  - BlackSuit Ransomware
   asset_type: Windows
   confidence: 100
   impact: 80

detections/endpoint/detect_new_local_admin_account.yml

@@ -26,6 +26,7 @@ tags:
   - DHS Report TA18-074A
   - HAFNIUM Group
   - CISA AA22-257A
+  - CISA AA24-241A
   asset_type: Windows
   confidence: 70
   impact: 60

detections/endpoint/detect_remote_access_software_usage_file.yml

@@ -47,6 +47,7 @@ tags:
   - Command And Control
   - Ransomware
   - Gozi Malware
+  - CISA AA24-241A
   asset_type: Endpoint
   confidence: 50
   impact: 50

detections/endpoint/detect_remote_access_software_usage_process.yml

@@ -51,6 +51,7 @@ tags:
   - Command And Control
   - Ransomware
   - Gozi Malware
+  - CISA AA24-241A
   asset_type: Endpoint
   confidence: 50
   impact: 50

detections/endpoint/detect_sharphound_command_line_arguments.yml

@@ -43,6 +43,7 @@ tags:
   analytic_story:
   - Windows Discovery Techniques
   - Ransomware
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 80
   impact: 30

detections/endpoint/detect_sharphound_file_modifications.yml

@@ -37,6 +37,7 @@ tags:
   analytic_story:
   - Windows Discovery Techniques
   - Ransomware
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 80
   impact: 30

detections/endpoint/disable_defender_antivirus_registry.yml

@@ -35,6 +35,7 @@ tags:
   analytic_story:
   - IcedID
   - Windows Registry Abuse
+  - CISA AA24-241A
   asset_type: Endpoint
   confidence: 70
   impact: 70

detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml

@@ -32,6 +32,7 @@ tags:
   analytic_story:
   - CISA AA23-347A
   - Active Directory Kerberos Attacks
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 90
   impact: 60

detections/endpoint/domain_controller_discovery_with_nltest.yml

@@ -39,6 +39,7 @@ tags:
   - Active Directory Discovery
   - CISA AA23-347A
   - Rhysida Ransomware
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 70
   impact: 30

detections/endpoint/elevated_group_discovery_with_net.yml

@@ -47,6 +47,7 @@ tags:
   - Active Directory Discovery
   - Volt Typhoon
   - Rhysida Ransomware
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 70
   impact: 30

detections/endpoint/excessive_usage_of_taskkill.yml

@@ -53,10 +53,6 @@ tags:
   - T1562.001
   - T1562
   observable:
-  - name: dest
-    type: Endpoint
-    role:
-    - Victim
   - name: dest
     type: Endpoint
     role:

detections/endpoint/executable_file_written_in_administrative_smb_share.yml

@@ -42,6 +42,7 @@ tags:
   - Data Destruction
   - Hermetic Wiper
   - Trickbot
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 100
   impact: 70

detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml

@@ -29,6 +29,7 @@ references:
 tags:
   analytic_story:
   - Active Directory Kerberos Attacks
+  - BlackSuit Ransomware
   asset_type: Endpoint
   confidence: 90
   impact: 50
@@ -38,7 +39,7 @@ tags:
   - T1558.004
   observable:
   - name: user
-    type: User Name
+    type: User
     role:
     - Victim
   product:

detections/endpoint/linux_auditd_add_user_account.yml

@@ -0,0 +1,66 @@
+name: Linux Auditd Add User Account
+id: aae66dc0-74b4-4807-b480-b35f8027abb4
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects the creation of new user accounts on Linux
+  systems using commands like "useradd" or "adduser." It leverages data from Endpoint
+  Detection and Response (EDR) agents, focusing on process names and command-line
+  executions. This activity is significant as adversaries often create new user accounts
+  to establish persistence on compromised hosts. If confirmed malicious, this could
+  allow attackers to maintain access, escalate privileges, and further compromise
+  the system, posing a severe security risk.
+data_source:
+- Linux Auditd Proctitle
+search: '`linux_auditd` `linux_auditd_normalized_proctitle_process`| rename host as
+  dest | where LIKE (process_exec, "%useradd%") OR LIKE (process_exec, "%adduser%")
+  | stats count min(_time) as firstTime max(_time) as lastTime by process_exec proctitle
+  dest  | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`|
+  `linux_auditd_add_user_account_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can execute this command.
+  Please update the filter macros to remove false positives.
+references:
+- https://linuxize.com/post/how-to-create-users-in-linux-using-the-useradd-command/
+tags:
+  analytic_story:
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 50
+  impact: 50
+  message: A [$process_exec$] event occurred on host - [$dest$] to add a user account.
+  mitre_attack_id:
+  - T1136.001
+  - T1136
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - proctitle
+  risk_score: 25
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/linux_auditd_add_user/linux_auditd_add_user.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit

detections/endpoint/linux_auditd_add_user_account_type.yml

@@ -0,0 +1,70 @@
+name: Linux Auditd Add User Account Type
+id: f8c325ea-506e-4105-8ccf-da1492e90115
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects the suspicious add user account type.
+  This behavior is critical for a SOC to monitor because it may indicate attempts
+  to gain unauthorized access or maintain control over a system. Such actions could
+  be signs of malicious activity. If confirmed, this could lead to serious consequences,
+  including a compromised system, unauthorized access to sensitive data, or even a
+  wider breach affecting the entire network. Detecting and responding to these signs
+  early is essential to prevent potential security incidents.
+data_source:
+- Linux Auditd Add User
+search: ' `linux_auditd` type=ADD_USER | rename hostname as dest| stats count min(_time)
+  as firstTime max(_time) as lastTime by exe pid dest res UID type | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`| `linux_auditd_add_user_account_type_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can use this application
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://www.splunk.com/en_us/blog/security/deep-dive-on-persistence-privilege-escalation-technique-and-detection-in-linux-platform.html
+tags:
+  analytic_story:
+  - Linux Living Off The Land
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 50
+  impact: 50
+  message: New [$type$] event on host - [$dest$] to add a user account type.
+  mitre_attack_id:
+  - T1136
+  - T1136.001
+  observable:
+  - name: dest
+    type: Hostname
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - exe
+  - pid
+  - hostname
+  - res
+  - UID
+  - type
+  risk_score: 25
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1136.001/linux_auditd_add_user_type/linux_auditd_add_user_type.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit

detections/endpoint/linux_auditd_at_application_execution.yml

@@ -0,0 +1,75 @@
+name: Linux Auditd At Application Execution
+id: 9f306e0a-1c36-469e-8892-968ca12470dd
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects the execution of the "At" application
+  in Linux, which can be used by attackers to create persistence entries on a compromised
+  host. This detection leverages data from Endpoint Detection and Response (EDR) agents,
+  focusing on process names and parent process names associated with "at" or "atd".
+  This activity is significant because the "At" application can be exploited to maintain
+  unauthorized access or deliver additional malicious payloads. If confirmed malicious,
+  this behavior could lead to data theft, ransomware attacks, or other severe consequences.
+  Immediate investigation is required to determine the legitimacy of the execution
+  and mitigate potential risks.
+data_source:
+- Linux Auditd Syscall
+search: '`linux_auditd` type=SYSCALL comm IN ("at", "atd") OR exe IN ("/usr/bin/at","/usr/bin/atd")
+  AND NOT (UID IN("daemon")) | rename host as dest | stats count min(_time) as firstTime
+  max(_time) as lastTime by comm exe  SYSCALL UID ppid pid dest | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`| `linux_auditd_at_application_execution_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can use this application
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://attack.mitre.org/techniques/T1053/001/
+- https://www.linkedin.com/pulse/getting-attacker-ip-address-from-malicious-linux-job-craig-rowland/
+tags:
+  analytic_story:
+  - Scheduled Tasks
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Linux Living Off The Land
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 30
+  impact: 30
+  message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to execute the "at" application.
+  mitre_attack_id:
+  - T1053.002
+  - T1053
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - comm
+  - exe
+  - SYSCALL
+  - UID
+  - ppid
+  - pid
+  risk_score: 9
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/linux_auditd_at/linux_auditd_at_execution.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit

detections/endpoint/linux_auditd_auditd_service_stop.yml

@@ -0,0 +1,69 @@
+name: Linux Auditd Auditd Service Stop
+id: 6cb9d0e1-eabe-41de-a11a-5efade354e9d
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects the suspicious auditd service stop. This
+  behavior is critical for a SOC to monitor because it may indicate attempts to gain
+  unauthorized access or maintain control over a system. Such actions could be signs
+  of malicious activity. If confirmed, this could lead to serious consequences, including
+  a compromised system, unauthorized access to sensitive data, or even a wider breach
+  affecting the entire network. Detecting and responding to these signs early is essential
+  to prevent potential security incidents.
+data_source:
+- Linux Auditd Service Stop
+search: '`linux_auditd` type=SERVICE_STOP unit IN ("auditd") | rename host as dest
+  | stats count min(_time) as firstTime max(_time) as lastTime by type pid UID comm
+  exe unit dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`|
+  `linux_auditd_auditd_service_stop_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can use this application
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://www.splunk.com/en_us/blog/security/deep-dive-on-persistence-privilege-escalation-technique-and-detection-in-linux-platform.html
+tags:
+  analytic_story:
+  - Linux Living Off The Land
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 50
+  impact: 50
+  message: A service event - [$type$] event occured on host - [$dest$].
+  mitre_attack_id:
+  - T1489
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - type
+  - pid
+  - UID
+  - comm
+  - exe
+  risk_score: 49
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1489/linux_auditd_auditd_service_stop/linux_auditd_auditd_service_stop.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit

detections/endpoint/linux_auditd_base64_decode_files.yml

@@ -0,0 +1,69 @@
+name: Linux Auditd Base64 Decode Files
+id: 5890ba10-4e48-4dc0-8a40-3e1ebe75e737
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects suspicious Base64 decode operations that
+  may indicate malicious activity, such as data exfiltration or execution of encoded
+  commands. Base64 is commonly used to encode data for safe transmission, but attackers
+  may abuse it to conceal malicious payloads. This detection focuses on identifying
+  unusual or unexpected Base64 decoding processes, particularly when associated with
+  critical files or directories. By monitoring these activities, the analytic helps
+  uncover potential threats, enabling security teams to respond promptly and mitigate
+  risks associated with encoded malware or unauthorized data access.
+data_source:
+- Linux Auditd Execve
+search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as
+  dest | where LIKE(process_exec, "%base64%") AND (LIKE(process_exec, "%-d %") OR
+  LIKE(process_exec, "% --d%")) | stats count min(_time) as firstTime max(_time) as
+  lastTime by argc process_exec dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`|
+  `linux_auditd_base64_decode_files_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can use this application
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://www.splunk.com/en_us/blog/security/deep-dive-on-persistence-privilege-escalation-technique-and-detection-in-linux-platform.html
+- https://gtfobins.github.io/gtfobins/dd/
+tags:
+  analytic_story:
+  - Linux Living Off The Land
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 50
+  impact: 50
+  message: A [$process_exec$] event occurred on host - [$dest$] to decode a file using base64.
+  mitre_attack_id:
+  - T1140
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - argc
+  - process_exec
+  risk_score: 25
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1140/linux_auditd_base64/linux_auditd_base64.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit

detections/endpoint/linux_auditd_change_file_owner_to_root.yml

@@ -0,0 +1,67 @@
+name: Linux Auditd Change File Owner To Root
+id: 7b87c556-0ca4-47e0-b84c-6cd62a0a3e90
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: TTP
+description: The following analytic detects the use of the 'chown' command to change
+  a file owner to 'root' on a Linux system. It leverages Linux Auditd telemetry, specifically monitoring command-line executions and process details.
+  This activity is significant as it may indicate an attempt to escalate privileges
+  by adversaries, malware, or red teamers. If confirmed malicious, this action could
+  allow an attacker to gain root-level access, leading to full control over the compromised
+  host and potential persistence within the environment.
+data_source:
+- Linux Auditd Proctitle
+search: '`linux_auditd` `linux_auditd_normalized_proctitle_process`| rename host as
+  dest | where LIKE (process_exec, "%chown %") AND LIKE (process_exec, "% root %")
+  | stats count min(_time) as firstTime max(_time) as lastTime by process_exec proctitle
+  normalized_proctitle_delimiter dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`|
+  `linux_auditd_change_file_owner_to_root_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can execute this command.
+  Please update the filter macros to remove false positives.
+references:
+- https://unix.stackexchange.com/questions/101073/how-to-change-permissions-from-root-user-to-all-users
+- https://askubuntu.com/questions/617850/changing-from-user-to-superuser
+tags:
+  analytic_story:
+  - Linux Living Off The Land
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 80
+  impact: 80
+  message: A [$process_exec$] event occurred on host - [$dest$] to change a file owner to root.
+  mitre_attack_id:
+  - T1222.002
+  - T1222
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - proctitle
+  risk_score: 64
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1053.002/linux_auditd_chown_root/linux_auditd_chown_root.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit

detections/endpoint/linux_auditd_clipboard_data_copy.yml

@@ -0,0 +1,68 @@
+name: Linux Auditd Clipboard Data Copy
+id: 9ddfe470-c4d0-4e60-8668-7337bd699edd
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects the use of the Linux 'xclip' command to
+  copy data from the clipboard. It leverages Linux Auditd
+  telemetry, focusing on process names and command-line arguments related to clipboard
+  operations. This activity is significant because adversaries can exploit clipboard
+  data to capture sensitive information such as passwords or IP addresses. If confirmed
+  malicious, this technique could lead to unauthorized data exfiltration, compromising
+  sensitive information and potentially aiding further attacks within the environment.
+data_source:
+- Linux Auditd Execve
+search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as
+  dest | where LIKE(process_exec, "%xclip%") AND (LIKE(process_exec, "%clipboard%")
+  OR LIKE(process_exec, "%-o%") OR LIKE(process_exec, "%clip %") OR LIKE(process_exec,
+  "%-selection %") OR LIKE(process_exec, "%sel %")) | stats count min(_time) as firstTime
+  max(_time) as lastTime by argc process_exec dest | `security_content_ctime(firstTime)`|
+  `security_content_ctime(lastTime)`| `linux_auditd_clipboard_data_copy_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: False positives may be present on Linux desktop as it may commonly
+  be used by administrators or end users. Filter as needed.
+references:
+- https://attack.mitre.org/techniques/T1115/
+- https://linux.die.net/man/1/xclip
+tags:
+  analytic_story:
+  - Linux Living Off The Land
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 40
+  impact: 40
+  message: A [$process_exec$] event occurred on host - [$dest$] to copy data from the clipboard.
+  mitre_attack_id:
+  - T1115
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - argc
+  - process_exec
+  risk_score: 16
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1115/linux_auditd_xclip/linux_auditd_xclip.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit
+    update_timestamp: true

detections/endpoint/linux_auditd_data_destruction_command.yml

@@ -0,0 +1,66 @@
+name: Linux Auditd Data Destruction Command
+id: 4da5ce1a-f71b-4e71-bb73-c0a3c73f3c3c
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: TTP
+description: The following analytic detects the execution of a Unix shell command
+  designed to wipe root directories on a Linux host. It leverages data from Linux Auditd, focusing on the 'rm' command with force recursive deletion and the '--no-preserve-root' option. This activity is significant as it
+  indicates potential data destruction attempts, often associated with malware like
+  Awfulshred. If confirmed malicious, this behavior could lead to severe data loss,
+  system instability, and compromised integrity of the affected Linux host. Immediate
+  investigation and response are crucial to mitigate potential damage.
+data_source:
+- Linux Auditd Execve
+search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as
+  dest | where LIKE (process_exec, "%rm %") AND LIKE (process_exec, "% -rf %") AND
+  LIKE (process_exec, "%--no-preserve-root%") | stats count min(_time) as firstTime
+  max(_time) as lastTime by argc process_exec dest | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`| `linux_auditd_data_destruction_command_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: unknown
+references:
+- https://cert.gov.ua/article/3718487
+- https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/overview-of-the-cyber-weapons-used-in-the-ukraine-russia-war/
+tags:
+  analytic_story:
+  - Data Destruction
+  - AwfulShred
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 90
+  impact: 100
+  message: A [$process_exec$] event occurred on host - [$dest$] to destroy data.
+  mitre_attack_id:
+  - T1485
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - argc
+  - process_exec
+  risk_score: 90
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1485/linux_auditd_no_preserve_root/linux_auditd_no_preserve_root.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit
+    update_timestamp: true

detections/endpoint/linux_auditd_data_transfer_size_limits_via_split.yml

@@ -0,0 +1,67 @@
+name: Linux Auditd Data Transfer Size Limits Via Split
+id: 4669561d-3bbd-44e3-857c-0e3c6ef2120c
+version: 1
+date: '2024-09-04'
+author: Teoderick Contreras, Splunk
+status: production
+type: Anomaly
+description: The following analytic detects suspicious data transfer activities that
+  involve the use of the `split` syscall, potentially indicating an attempt to evade
+  detection by breaking large files into smaller parts. Attackers may use this technique
+  to bypass size-based security controls, facilitating the covert exfiltration of
+  sensitive data. By monitoring for unusual or unauthorized use of the `split` syscall,
+  this analytic helps identify potential data exfiltration attempts, allowing security
+  teams to intervene and prevent the unauthorized transfer of critical information
+  from the network.
+data_source:
+- Linux Auditd Execve
+search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as
+  dest | where LIKE(process_exec, "%split %") AND LIKE(process_exec, "% -b %") | stats
+  count min(_time) as firstTime max(_time) as lastTime by argc process_exec dest |
+  `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `linux_auditd_data_transfer_size_limits_via_split_filter`'
+how_to_implement: To implement this detection, the process begins by ingesting auditd
+  data, that consist SYSCALL, TYPE, EXECVE and PROCTITLE events, which captures command-line
+  executions and process details on Unix/Linux systems. These logs should be ingested
+  and processed using Splunk Add-on for Unix and Linux (https://splunkbase.splunk.com/app/833),
+  which is essential for correctly parsing and categorizing the data. The next step
+  involves normalizing the field names  to match the field names set by the Splunk
+  Common Information Model (CIM) to ensure consistency across different data sources
+  and enhance the efficiency of data modeling. This approach enables effective monitoring
+  and detection of linux endpoints where auditd is deployed
+known_false_positives: Administrator or network operator can use this application
+  for automation purposes. Please update the filter macros to remove false positives.
+references:
+- https://www.splunk.com/en_us/blog/security/deep-dive-on-persistence-privilege-escalation-technique-and-detection-in-linux-platform.html
+tags:
+  analytic_story:
+  - Linux Living Off The Land
+  - Linux Privilege Escalation
+  - Linux Persistence Techniques
+  - Compromised Linux Host
+  asset_type: Endpoint
+  confidence: 70
+  impact: 70
+  message: A [$process_exec$] event occurred on host - [$dest$] to split a file.
+  mitre_attack_id:
+  - T1030
+  observable:
+  - name: dest
+    type: Endpoint
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - argc
+  - process_exec
+  risk_score: 49
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1030/linux_auditd_split_b_exec/linux_auditd_split_b_exec.log
+    source: /var/log/audit/audit.log
+    sourcetype: linux:audit