diff --git a/.github/workflows/datasource-dependabot.yml b/.github/workflows/datasource-dependabot.yml new file mode 100644 index 0000000000..b61cf6cdde --- /dev/null +++ b/.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/** \ No newline at end of file diff --git a/.github/workflows/datasource-ta-check.yml b/.github/workflows/datasource-ta-check.yml deleted file mode 100644 index 20e50d5841..0000000000 --- a/.github/workflows/datasource-ta-check.yml +++ /dev/null @@ -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 \ No newline at end of file diff --git a/.github/workflows/update_data_sources_ta.py b/.github/workflows/update_data_sources_ta.py new file mode 100644 index 0000000000..83239de4bc --- /dev/null +++ b/.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.") \ No newline at end of file diff --git a/data_sources/aws_cloudfront.yml b/data_sources/aws_cloudfront.yml index 2ae90e54e6..3072afe9c4 100644 --- a/data_sources/aws_cloudfront.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail.yml b/data_sources/aws_cloudtrail.yml index 5230cb083b..950c084e69 100644 --- a/data_sources/aws_cloudtrail.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_assumerolewithsaml.yml b/data_sources/aws_cloudtrail_assumerolewithsaml.yml index c5738f8dee..310c8f6c18 100644 --- a/data_sources/aws_cloudtrail_assumerolewithsaml.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_consolelogin.yml b/data_sources/aws_cloudtrail_consolelogin.yml index cdbe7a49df..96f9e92804 100644 --- a/data_sources/aws_cloudtrail_consolelogin.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_copyobject.yml b/data_sources/aws_cloudtrail_copyobject.yml index b632e6926d..3f2d51f81d 100644 --- a/data_sources/aws_cloudtrail_copyobject.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createaccesskey.yml b/data_sources/aws_cloudtrail_createaccesskey.yml index 71199a2ca4..1039eb23be 100644 --- a/data_sources/aws_cloudtrail_createaccesskey.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createkey.yml b/data_sources/aws_cloudtrail_createkey.yml index 0470b8cb3b..96991dc1e6 100644 --- a/data_sources/aws_cloudtrail_createkey.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createloginprofile.yml b/data_sources/aws_cloudtrail_createloginprofile.yml index abeb97372b..5c7a0eafe2 100644 --- a/data_sources/aws_cloudtrail_createloginprofile.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createnetworkaclentry.yml b/data_sources/aws_cloudtrail_createnetworkaclentry.yml index 52a545ca68..95541fa4ab 100644 --- a/data_sources/aws_cloudtrail_createnetworkaclentry.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createpolicyversion.yml b/data_sources/aws_cloudtrail_createpolicyversion.yml index 47e1dcbf41..303eb014a6 100644 --- a/data_sources/aws_cloudtrail_createpolicyversion.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createsnapshot.yml b/data_sources/aws_cloudtrail_createsnapshot.yml index 883dbf7df6..cc50c8c5cc 100644 --- a/data_sources/aws_cloudtrail_createsnapshot.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createtask.yml b/data_sources/aws_cloudtrail_createtask.yml index 7bbd4c6690..8a4682fa86 100644 --- a/data_sources/aws_cloudtrail_createtask.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_createvirtualmfadevice.yml b/data_sources/aws_cloudtrail_createvirtualmfadevice.yml index 734e236dca..9710c82d05 100644 --- a/data_sources/aws_cloudtrail_createvirtualmfadevice.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deactivatemfadevice.yml b/data_sources/aws_cloudtrail_deactivatemfadevice.yml index 98f7b43725..e0110fc907 100644 --- a/data_sources/aws_cloudtrail_deactivatemfadevice.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deleteaccountpasswordpolicy.yml b/data_sources/aws_cloudtrail_deleteaccountpasswordpolicy.yml index d05dfd1796..738682463b 100644 --- a/data_sources/aws_cloudtrail_deleteaccountpasswordpolicy.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletealarms.yml b/data_sources/aws_cloudtrail_deletealarms.yml index f386f3a8ac..afa67dcffc 100644 --- a/data_sources/aws_cloudtrail_deletealarms.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletedetector.yml b/data_sources/aws_cloudtrail_deletedetector.yml index 66f43c2593..ff5a1ea250 100644 --- a/data_sources/aws_cloudtrail_deletedetector.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletegroup.yml b/data_sources/aws_cloudtrail_deletegroup.yml index 2bd9310f35..d8ceeabb9b 100644 --- a/data_sources/aws_cloudtrail_deletegroup.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deleteipset.yml b/data_sources/aws_cloudtrail_deleteipset.yml index 29c2dd686f..db3537f9bd 100644 --- a/data_sources/aws_cloudtrail_deleteipset.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deleteloggroup.yml b/data_sources/aws_cloudtrail_deleteloggroup.yml index 32d487d65f..58962e5032 100644 --- a/data_sources/aws_cloudtrail_deleteloggroup.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletelogstream.yml b/data_sources/aws_cloudtrail_deletelogstream.yml index 8f7a92c3e0..11d3a33a40 100644 --- a/data_sources/aws_cloudtrail_deletelogstream.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletenetworkaclentry.yml b/data_sources/aws_cloudtrail_deletenetworkaclentry.yml index 534106dc32..363d322419 100644 --- a/data_sources/aws_cloudtrail_deletenetworkaclentry.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletepolicy.yml b/data_sources/aws_cloudtrail_deletepolicy.yml index 7012fa6ed9..a3918a3610 100644 --- a/data_sources/aws_cloudtrail_deletepolicy.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deleterule.yml b/data_sources/aws_cloudtrail_deleterule.yml index d857e41e47..3ab3eaf43d 100644 --- a/data_sources/aws_cloudtrail_deleterule.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletesnapshot.yml b/data_sources/aws_cloudtrail_deletesnapshot.yml index 45be13588c..b2ca515c08 100644 --- a/data_sources/aws_cloudtrail_deletesnapshot.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletetrail.yml b/data_sources/aws_cloudtrail_deletetrail.yml index 07f58db804..c5cc623566 100644 --- a/data_sources/aws_cloudtrail_deletetrail.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletevirtualmfadevice.yml b/data_sources/aws_cloudtrail_deletevirtualmfadevice.yml index 821f144e7f..48f5a3f577 100644 --- a/data_sources/aws_cloudtrail_deletevirtualmfadevice.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_deletewebacl.yml b/data_sources/aws_cloudtrail_deletewebacl.yml index a177153e90..2a31e3d682 100644 --- a/data_sources/aws_cloudtrail_deletewebacl.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_describeeventaggregates.yml b/data_sources/aws_cloudtrail_describeeventaggregates.yml index 919a2d3be2..48db84fd22 100644 --- a/data_sources/aws_cloudtrail_describeeventaggregates.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_describeimagescanfindings.yml b/data_sources/aws_cloudtrail_describeimagescanfindings.yml index 831d5975da..d8b9d33380 100644 --- a/data_sources/aws_cloudtrail_describeimagescanfindings.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_getaccountpasswordpolicy.yml b/data_sources/aws_cloudtrail_getaccountpasswordpolicy.yml index 52c3247f8f..a2d51c0989 100644 --- a/data_sources/aws_cloudtrail_getaccountpasswordpolicy.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_getobject.yml b/data_sources/aws_cloudtrail_getobject.yml index 202531ea99..ebf3d788ea 100644 --- a/data_sources/aws_cloudtrail_getobject.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_getpassworddata.yml b/data_sources/aws_cloudtrail_getpassworddata.yml index 16185f9770..0db535958e 100644 --- a/data_sources/aws_cloudtrail_getpassworddata.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_jobcreated.yml b/data_sources/aws_cloudtrail_jobcreated.yml index 0c12590897..9be9e2fb97 100644 --- a/data_sources/aws_cloudtrail_jobcreated.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_modifydbinstance.yml b/data_sources/aws_cloudtrail_modifydbinstance.yml index 2accf99155..1873888fa1 100644 --- a/data_sources/aws_cloudtrail_modifydbinstance.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_modifyimageattribute.yml b/data_sources/aws_cloudtrail_modifyimageattribute.yml index b2bdddff08..e55497168f 100644 --- a/data_sources/aws_cloudtrail_modifyimageattribute.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_modifysnapshotattribute.yml b/data_sources/aws_cloudtrail_modifysnapshotattribute.yml index dc09302ede..b375933610 100644 --- a/data_sources/aws_cloudtrail_modifysnapshotattribute.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_putbucketacl.yml b/data_sources/aws_cloudtrail_putbucketacl.yml index 2a31c5adbe..a952b9a63b 100644 --- a/data_sources/aws_cloudtrail_putbucketacl.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_putbucketlifecycle.yml b/data_sources/aws_cloudtrail_putbucketlifecycle.yml index fc20e9a7aa..c09cb998c7 100644 --- a/data_sources/aws_cloudtrail_putbucketlifecycle.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_putbucketreplication.yml b/data_sources/aws_cloudtrail_putbucketreplication.yml index 3a0a6e093c..6dbf254e24 100644 --- a/data_sources/aws_cloudtrail_putbucketreplication.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_putbucketversioning.yml b/data_sources/aws_cloudtrail_putbucketversioning.yml index b4019b7926..1e078ec5b4 100644 --- a/data_sources/aws_cloudtrail_putbucketversioning.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_putimage.yml b/data_sources/aws_cloudtrail_putimage.yml index 2f99322eba..0c9ac4c1b1 100644 --- a/data_sources/aws_cloudtrail_putimage.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_putkeypolicy.yml b/data_sources/aws_cloudtrail_putkeypolicy.yml index 28d36464c3..42060d8194 100644 --- a/data_sources/aws_cloudtrail_putkeypolicy.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_replacenetworkaclentry.yml b/data_sources/aws_cloudtrail_replacenetworkaclentry.yml index 4544f65574..9feaa44932 100644 --- a/data_sources/aws_cloudtrail_replacenetworkaclentry.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_setdefaultpolicyversion.yml b/data_sources/aws_cloudtrail_setdefaultpolicyversion.yml index 6193228164..c06285fa73 100644 --- a/data_sources/aws_cloudtrail_setdefaultpolicyversion.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_stoplogging.yml b/data_sources/aws_cloudtrail_stoplogging.yml index db15c8e372..c2a6b50c4e 100644 --- a/data_sources/aws_cloudtrail_stoplogging.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_updateaccountpasswordpolicy.yml b/data_sources/aws_cloudtrail_updateaccountpasswordpolicy.yml index 6e2cab06ca..43e8359afd 100644 --- a/data_sources/aws_cloudtrail_updateaccountpasswordpolicy.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_updateloginprofile.yml b/data_sources/aws_cloudtrail_updateloginprofile.yml index 0f21f975bb..15561da71c 100644 --- a/data_sources/aws_cloudtrail_updateloginprofile.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_updatesamlprovider.yml b/data_sources/aws_cloudtrail_updatesamlprovider.yml index 40c704a7be..b3ac874b2f 100644 --- a/data_sources/aws_cloudtrail_updatesamlprovider.yml +++ b/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 diff --git a/data_sources/aws_cloudtrail_updatetrail.yml b/data_sources/aws_cloudtrail_updatetrail.yml index 448209d713..7e840ba557 100644 --- a/data_sources/aws_cloudtrail_updatetrail.yml +++ b/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 diff --git a/data_sources/aws_cloudwatchlogs_vpcflow.yml b/data_sources/aws_cloudwatchlogs_vpcflow.yml index 2bf06edc58..c6c83b636c 100644 --- a/data_sources/aws_cloudwatchlogs_vpcflow.yml +++ b/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 diff --git a/data_sources/aws_security_hub.yml b/data_sources/aws_security_hub.yml index a37b28ca37..e9c1a8ca4b 100644 --- a/data_sources/aws_security_hub.yml +++ b/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 diff --git a/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml b/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml index 2edc3ae569..48dbeea690 100644 --- a/detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml +++ b/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: diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml index d012c1e6ef..0c573114e7 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_location.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml index e26121f0c5..bf02cc46f0 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_agent.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml index 6d81b53ba3..a4e2033405 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_group.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml b/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml index 5b44d1e7f8..09aa5ce093 100644 --- a/detections/cloud/kubernetes_abuse_of_secret_by_unusual_user_name.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_access_scanning.yml b/detections/cloud/kubernetes_access_scanning.yml index 55e2362f32..e715e79d09 100644 --- a/detections/cloud/kubernetes_access_scanning.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml b/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml index 2c4d27b19c..7b17ca2a8a 100644 --- a/detections/cloud/kubernetes_aws_detect_suspicious_kubectl_calls.yml +++ b/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 diff --git a/detections/cloud/kubernetes_create_or_update_privileged_pod.yml b/detections/cloud/kubernetes_create_or_update_privileged_pod.yml index b9f1be1cba..c1548914f4 100644 --- a/detections/cloud/kubernetes_create_or_update_privileged_pod.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_cron_job_creation.yml b/detections/cloud/kubernetes_cron_job_creation.yml index fd414326bb..afb0a60ad8 100644 --- a/detections/cloud/kubernetes_cron_job_creation.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_daemonset_deployed.yml b/detections/cloud/kubernetes_daemonset_deployed.yml index 059055675a..930e108119 100644 --- a/detections/cloud/kubernetes_daemonset_deployed.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_falco_shell_spawned.yml b/detections/cloud/kubernetes_falco_shell_spawned.yml index 71c85b1554..81905e2ade 100644 --- a/detections/cloud/kubernetes_falco_shell_spawned.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_node_port_creation.yml b/detections/cloud/kubernetes_node_port_creation.yml index 513e043486..b2cfc9d2cd 100644 --- a/detections/cloud/kubernetes_node_port_creation.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_pod_created_in_default_namespace.yml b/detections/cloud/kubernetes_pod_created_in_default_namespace.yml index c5b94b6782..4ea0899b26 100644 --- a/detections/cloud/kubernetes_pod_created_in_default_namespace.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_pod_with_host_network_attachment.yml b/detections/cloud/kubernetes_pod_with_host_network_attachment.yml index 763299bf0c..d671a16dd3 100644 --- a/detections/cloud/kubernetes_pod_with_host_network_attachment.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml b/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml index a94b5cf3fe..5550717c64 100644 --- a/detections/cloud/kubernetes_scanning_by_unauthenticated_ip_address.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_suspicious_image_pulling.yml b/detections/cloud/kubernetes_suspicious_image_pulling.yml index 4eeaa70812..61e35c50fb 100644 --- a/detections/cloud/kubernetes_suspicious_image_pulling.yml +++ b/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/ diff --git a/detections/cloud/kubernetes_unauthorized_access.yml b/detections/cloud/kubernetes_unauthorized_access.yml index 893a445494..1eb5382e69 100644 --- a/detections/cloud/kubernetes_unauthorized_access.yml +++ b/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/ diff --git a/detections/deprecated/aws_cloud_provisioning_from_previously_unseen_region.yml b/detections/deprecated/aws_cloud_provisioning_from_previously_unseen_region.yml index 17c217ab38..f1a7c1ec92 100644 --- a/detections/deprecated/aws_cloud_provisioning_from_previously_unseen_region.yml +++ b/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 diff --git a/detections/deprecated/detect_activity_related_to_pass_the_hash_attacks.yml b/detections/deprecated/detect_activity_related_to_pass_the_hash_attacks.yml index 9b8abca9a6..a2496efcd6 100644 --- a/detections/deprecated/detect_activity_related_to_pass_the_hash_attacks.yml +++ b/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 diff --git a/detections/deprecated/detect_aws_api_activities_from_unapproved_accounts.yml b/detections/deprecated/detect_aws_api_activities_from_unapproved_accounts.yml index 81446134ca..39cf8a3869 100644 --- a/detections/deprecated/detect_aws_api_activities_from_unapproved_accounts.yml +++ b/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: diff --git a/detections/endpoint/anomalous_usage_of_7zip.yml b/detections/endpoint/anomalous_usage_of_7zip.yml index 8244563d1b..85d7f4a5c7 100644 --- a/detections/endpoint/anomalous_usage_of_7zip.yml +++ b/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 diff --git a/detections/endpoint/create_local_admin_accounts_using_net_exe.yml b/detections/endpoint/create_local_admin_accounts_using_net_exe.yml index ba8cbe5360..ef030a83c0 100644 --- a/detections/endpoint/create_local_admin_accounts_using_net_exe.yml +++ b/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 diff --git a/detections/endpoint/create_remote_thread_into_lsass.yml b/detections/endpoint/create_remote_thread_into_lsass.yml index ea1084f575..a4c32abbf2 100644 --- a/detections/endpoint/create_remote_thread_into_lsass.yml +++ b/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 diff --git a/detections/endpoint/detect_credential_dumping_through_lsass_access.yml b/detections/endpoint/detect_credential_dumping_through_lsass_access.yml index 77f0b0e806..9d50d54086 100644 --- a/detections/endpoint/detect_credential_dumping_through_lsass_access.yml +++ b/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 diff --git a/detections/endpoint/detect_new_local_admin_account.yml b/detections/endpoint/detect_new_local_admin_account.yml index 3713d9963f..d347d12505 100644 --- a/detections/endpoint/detect_new_local_admin_account.yml +++ b/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 diff --git a/detections/endpoint/detect_remote_access_software_usage_file.yml b/detections/endpoint/detect_remote_access_software_usage_file.yml index aaf1b8c515..58187a2203 100644 --- a/detections/endpoint/detect_remote_access_software_usage_file.yml +++ b/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 diff --git a/detections/endpoint/detect_remote_access_software_usage_process.yml b/detections/endpoint/detect_remote_access_software_usage_process.yml index 0ce8bcbe32..4c96567bb5 100644 --- a/detections/endpoint/detect_remote_access_software_usage_process.yml +++ b/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 diff --git a/detections/endpoint/detect_sharphound_command_line_arguments.yml b/detections/endpoint/detect_sharphound_command_line_arguments.yml index 51d16a6f89..e604f18487 100644 --- a/detections/endpoint/detect_sharphound_command_line_arguments.yml +++ b/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 diff --git a/detections/endpoint/detect_sharphound_file_modifications.yml b/detections/endpoint/detect_sharphound_file_modifications.yml index 718559e461..9baff85c8e 100644 --- a/detections/endpoint/detect_sharphound_file_modifications.yml +++ b/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 diff --git a/detections/endpoint/disable_defender_antivirus_registry.yml b/detections/endpoint/disable_defender_antivirus_registry.yml index 9ed2c7f702..a0b2e38264 100644 --- a/detections/endpoint/disable_defender_antivirus_registry.yml +++ b/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 diff --git a/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml b/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml index fc69094941..8aeb4e05b9 100644 --- a/detections/endpoint/disabled_kerberos_pre_authentication_discovery_with_get_aduser.yml +++ b/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 diff --git a/detections/endpoint/domain_controller_discovery_with_nltest.yml b/detections/endpoint/domain_controller_discovery_with_nltest.yml index 6a1dd7d0e5..1bc0a5d35c 100644 --- a/detections/endpoint/domain_controller_discovery_with_nltest.yml +++ b/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 diff --git a/detections/endpoint/elevated_group_discovery_with_net.yml b/detections/endpoint/elevated_group_discovery_with_net.yml index f667778adf..9459acf2cb 100644 --- a/detections/endpoint/elevated_group_discovery_with_net.yml +++ b/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 diff --git a/detections/endpoint/excessive_usage_of_taskkill.yml b/detections/endpoint/excessive_usage_of_taskkill.yml index 06abc48814..e916838efd 100644 --- a/detections/endpoint/excessive_usage_of_taskkill.yml +++ b/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: diff --git a/detections/endpoint/executable_file_written_in_administrative_smb_share.yml b/detections/endpoint/executable_file_written_in_administrative_smb_share.yml index ac28c68fd7..ee4b3e4655 100644 --- a/detections/endpoint/executable_file_written_in_administrative_smb_share.yml +++ b/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 diff --git a/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml b/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml index 43385ce72c..a242036c87 100644 --- a/detections/endpoint/kerberos_pre_authentication_flag_disabled_in_useraccountcontrol.yml +++ b/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: diff --git a/detections/endpoint/linux_auditd_add_user_account.yml b/detections/endpoint/linux_auditd_add_user_account.yml new file mode 100644 index 0000000000..c33bc16d25 --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_add_user_account_type.yml b/detections/endpoint/linux_auditd_add_user_account_type.yml new file mode 100644 index 0000000000..1b7d6b8f9f --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_at_application_execution.yml b/detections/endpoint/linux_auditd_at_application_execution.yml new file mode 100644 index 0000000000..49d5a50c87 --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_auditd_service_stop.yml b/detections/endpoint/linux_auditd_auditd_service_stop.yml new file mode 100644 index 0000000000..20ddf0f391 --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_base64_decode_files.yml b/detections/endpoint/linux_auditd_base64_decode_files.yml new file mode 100644 index 0000000000..15b0b91e2d --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_change_file_owner_to_root.yml b/detections/endpoint/linux_auditd_change_file_owner_to_root.yml new file mode 100644 index 0000000000..23917623b0 --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_clipboard_data_copy.yml b/detections/endpoint/linux_auditd_clipboard_data_copy.yml new file mode 100644 index 0000000000..20b1cf0179 --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_data_destruction_command.yml b/detections/endpoint/linux_auditd_data_destruction_command.yml new file mode 100644 index 0000000000..0ce3e41f48 --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_data_transfer_size_limits_via_split.yml b/detections/endpoint/linux_auditd_data_transfer_size_limits_via_split.yml new file mode 100644 index 0000000000..742d1323bb --- /dev/null +++ b/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 diff --git a/detections/endpoint/linux_auditd_data_transfer_size_limits_via_split_syscall.yml b/detections/endpoint/linux_auditd_data_transfer_size_limits_via_split_syscall.yml new file mode 100644 index 0000000000..45a7e337e4 --- /dev/null +++ b/detections/endpoint/linux_auditd_data_transfer_size_limits_via_split_syscall.yml @@ -0,0 +1,71 @@ +name: Linux Auditd Data Transfer Size Limits Via Split Syscall +id: c03d4a49-cf9d-435b-86e9-c6f8c9b6c42e +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 Syscall +search: '`linux_auditd` type=SYSCALL comm=split OR exe= "*/split" | rename host as + dest | stats count min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL + UID ppid pid success dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `linux_auditd_data_transfer_size_limits_via_split_syscall_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 SYSCALL - [$comm$] event was executed on host - [$dest$] that limits the size of data transfer. + mitre_attack_id: + - T1030 + 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: 25 + 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_syscall/linux_auditd_split_syscall.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_database_file_and_directory_discovery.yml b/detections/endpoint/linux_auditd_database_file_and_directory_discovery.yml new file mode 100644 index 0000000000..b6d0662dfe --- /dev/null +++ b/detections/endpoint/linux_auditd_database_file_and_directory_discovery.yml @@ -0,0 +1,68 @@ +name: Linux Auditd Database File And Directory Discovery +id: f616c4f3-bde9-41cf-856c-019b65f668bb +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: "The following analytic detects suspicious database file and directory discovery activities, which may signal an attacker attempt to locate and assess critical database assets on a compromised system. This behavior is often a precursor to data theft, unauthorized access, or privilege escalation, as attackers seek to identify valuable information stored in databases. By monitoring for unusual or unauthorized attempts to locate database files and directories, this analytic aids in early detection of potential reconnaissance or data breach efforts, enabling security teams to respond swiftly and mitigate the risk of further compromise." +data_source: +- Linux Auditd Execve +search: ' `linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%.db%") OR LIKE (process_exec, "%.sql%") OR LIKE (process_exec, + "%.sqlite%") OR LIKE (process_exec, "%.mdb%")OR LIKE (process_exec, "%.accdb%")OR + LIKE (process_exec, "%.mdf%")OR LIKE (process_exec, "%.ndf%")OR LIKE (process_exec, + "%.ldf%")OR LIKE (process_exec, "%.frm%")OR LIKE (process_exec, "%.idb%")OR LIKE + (process_exec, "%.myd%")OR LIKE (process_exec, "%.myi%")OR LIKE (process_exec, "%.dbf%")OR + LIKE (process_exec, "%.db2%")OR LIKE (process_exec, "%.dbc%")OR LIKE (process_exec, + "%.fpt%")OR LIKE (process_exec, "%.ora%")) | 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_database_file_and_directory_discovery_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 discover database files and directories. + mitre_attack_id: + - T1083 + 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/T1083/linux_auditd_find_db/linux_auditd_find_db.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_dd_file_overwrite.yml b/detections/endpoint/linux_auditd_dd_file_overwrite.yml new file mode 100644 index 0000000000..4dfca37b55 --- /dev/null +++ b/detections/endpoint/linux_auditd_dd_file_overwrite.yml @@ -0,0 +1,65 @@ +name: Linux Auditd Dd File Overwrite +id: d1b74420-4cea-4752-a123-9b40dfcca49a +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the use of the 'dd' command to overwrite + files on a Linux system. It leverages data from Linux Auditd telemetry, focusing on process execution logs that include command-line details. + This activity is significant because adversaries often use the 'dd' command to destroy + or irreversibly overwrite files, disrupting system availability and services. If + confirmed malicious, this behavior could lead to data destruction, making recovery + difficult and potentially causing significant operational disruptions. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE(process_exec, "%dd %") AND LIKE(process_exec, "% of=%") | 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_dd_file_overwrite_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://gtfobins.github.io/gtfobins/dd/ +- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1485/T1485.md +tags: + analytic_story: + - Industroyer2 + - Data Destruction + - Compromised Linux Host + asset_type: Endpoint + confidence: 90 + impact: 90 + message: A [$process_exec$] event occurred on host - [$dest$]. + mitre_attack_id: + - T1485 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - proctitle + risk_score: 81 + 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_dd_overwrite/linux_auditd_dd_overwrite.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_disable_or_modify_system_firewall.yml b/detections/endpoint/linux_auditd_disable_or_modify_system_firewall.yml new file mode 100644 index 0000000000..c06023c1cc --- /dev/null +++ b/detections/endpoint/linux_auditd_disable_or_modify_system_firewall.yml @@ -0,0 +1,70 @@ +name: Linux Auditd Disable Or Modify System Firewall +id: 07052556-d4b5-4bae-89aa-cbdc1bb11250 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the suspicious disable or modify system + firewall. 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 ("firewalld", "ufw") | 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_disable_or_modify_system_firewall_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: 80 + impact: 80 + message: A service event - [$type$] to disable or modify system firewall occured on host - [$dest$] . + mitre_attack_id: + - T1562.004 + - T1562 + 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: 64 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.004/linux_auditd_disable_firewall/linux_auditd_disable_firewall.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_doas_conf_file_creation.yml b/detections/endpoint/linux_auditd_doas_conf_file_creation.yml new file mode 100644 index 0000000000..563cd85b6c --- /dev/null +++ b/detections/endpoint/linux_auditd_doas_conf_file_creation.yml @@ -0,0 +1,68 @@ +name: Linux Auditd Doas Conf File Creation +id: 61059783-574b-40d2-ac2f-69b898afd6b4 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the creation of the doas.conf file on + a Linux host. This file is used by the doas utility to allow standard users to perform + tasks as root, similar to sudo. The detection leverages Linux Auditd data, focusing on + the creation of the doas.conf file. This activity is significant because it can + indicate an attempt to gain elevated privileges, potentially by an adversary. If + confirmed malicious, this could allow an attacker to execute commands with root + commands with root privileges, leading to full system compromise. +data_source: +- Linux Auditd Path +search: '`linux_auditd` type=PATH name ="/etc/doas.conf*" | rename host as dest | + stats count min(_time) as firstTime max(_time) as lastTime by name nametype OGID + dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_doas_conf_file_creation_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://wiki.gentoo.org/wiki/Doas +- https://www.makeuseof.com/how-to-install-and-use-doas/ +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 80 + impact: 80 + message: A [$type$] event occured on host - [$dest$] to create a doas.conf file. + mitre_attack_id: + - T1548.003 + - T1548 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - name + - nametype + - OGID + 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/T1548.003/linux_audited_doas_conf/linux_audited_doas_conf.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_doas_tool_execution.yml b/detections/endpoint/linux_auditd_doas_tool_execution.yml new file mode 100644 index 0000000000..884e79ac0d --- /dev/null +++ b/detections/endpoint/linux_auditd_doas_tool_execution.yml @@ -0,0 +1,70 @@ +name: Linux Auditd Doas Tool Execution +id: 91b8ca78-f205-4826-a3ef-cd8d6b24e97b +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the execution of the 'doas' tool on a + Linux host. This tool allows standard users to perform tasks with root privileges, + similar to 'sudo'. The detection leverages data from Linux Auditd, focusing on process names and command-line executions. This activity + is significant as 'doas' can be exploited by adversaries to gain elevated privileges + on a compromised host. If confirmed malicious, this could lead to unauthorized administrative + access, potentially compromising the entire system. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm=doas | rename host as dest | stats count + min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL UID ppid pid + success dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `linux_auditd_doas_tool_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 execute this command. + Please update the filter macros to remove false positives. +references: +- https://wiki.gentoo.org/wiki/Doas +- https://www.makeuseof.com/how-to-install-and-use-doas/ +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 70 + impact: 70 + message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to execute the "doas" tool. + mitre_attack_id: + - T1548.003 + - T1548 + 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: 49 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.003/linux_auditd_doas/linux_auditd_doas.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_edit_cron_table_parameter.yml b/detections/endpoint/linux_auditd_edit_cron_table_parameter.yml new file mode 100644 index 0000000000..f8a4b96e3b --- /dev/null +++ b/detections/endpoint/linux_auditd_edit_cron_table_parameter.yml @@ -0,0 +1,73 @@ +name: Linux Auditd Edit Cron Table Parameter +id: f4bb7321-7e64-4d1e-b1aa-21f8b019a91f +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the suspicious editing of cron jobs in + Linux using the crontab command-line parameter (-e). It identifies this activity + by monitoring command-line executions involving 'crontab' and the edit parameter. + This behavior is significant for a SOC as cron job manipulations can indicate unauthorized + persistence attempts or scheduled malicious actions. If confirmed malicious, this + activity could lead to system compromise, unauthorized access, or broader network + compromise. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL SYSCALL=rename (comm IN ("crontab") OR exe IN + ("*/crontab")) success=yes 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_edit_cron_table_parameter_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/003/ +tags: + analytic_story: + - Scheduled Tasks + - Linux Privilege Escalation + - Linux Persistence Techniques + - Linux Living Off The Land + - Compromised Linux Host + asset_type: Endpoint + confidence: 80 + impact: 80 + message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to edit the cron table. + mitre_attack_id: + - T1053.003 + - 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: 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.003/linux_auditd_crontab_edit/linux_auditd_crontab_edit.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_file_and_directory_discovery.yml b/detections/endpoint/linux_auditd_file_and_directory_discovery.yml new file mode 100644 index 0000000000..bf39f2489c --- /dev/null +++ b/detections/endpoint/linux_auditd_file_and_directory_discovery.yml @@ -0,0 +1,79 @@ +name: Linux Auditd File And Directory Discovery +id: 0bbfb79c-a755-49a5-a38a-1128d0a452f1 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects suspicious file and directory discovery + activities, which may indicate an attacker's effort to locate sensitive documents + and files on a compromised system. This behavior often precedes data exfiltration, + as adversaries seek to identify valuable or confidential information for theft. + By identifying unusual or unauthorized attempts to browse or enumerate files and + directories, this analytic helps security teams detect potential reconnaissance + or preparatory actions by an attacker, enabling timely intervention to prevent data + breaches or unauthorized access. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%.tif%") OR LIKE (process_exec, "%.tiff%") OR LIKE (process_exec, + "%.gif%") OR LIKE (process_exec, "%.jpeg%")OR LIKE (process_exec, "%.jpg%")OR LIKE + (process_exec, "%.jif%")OR LIKE (process_exec, "%.jfif%")OR LIKE (process_exec, + "%.jp2%")OR LIKE (process_exec, "%.jpx%")OR LIKE (process_exec, "%.j2k%")OR LIKE + (process_exec, "%.j2c%")OR LIKE (process_exec, "%.fpx%")OR LIKE (process_exec, "%.pcd%")OR + LIKE (process_exec, "%.png%")OR LIKE (process_exec, "%.flv%") OR LIKE (process_exec, + "%.pdf%")OR LIKE (process_exec, "%.mp4%")OR LIKE (process_exec, "%.mp3%")OR LIKE + (process_exec, "%.gifv%")OR LIKE (process_exec, "%.avi%")OR LIKE (process_exec, + "%.mov%")OR LIKE (process_exec, "%.mpeg%")OR LIKE (process_exec, "%.wav%")OR LIKE + (process_exec, "%.doc%")OR LIKE (process_exec, "%.docx%")OR LIKE (process_exec, + "%.xls%")OR LIKE (process_exec, "%.xlsx%")OR LIKE (process_exec, "%.svg%")) | 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_file_and_directory_discovery_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 discover files and directories. + mitre_attack_id: + - T1083 + 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/T1083/linux_auditd_find_document/linux_auditd_find_document.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_file_permission_modification_via_chmod.yml b/detections/endpoint/linux_auditd_file_permission_modification_via_chmod.yml new file mode 100644 index 0000000000..9ef853f1f3 --- /dev/null +++ b/detections/endpoint/linux_auditd_file_permission_modification_via_chmod.yml @@ -0,0 +1,69 @@ +name: Linux Auditd File Permission Modification Via Chmod +id: 5f1d2ea7-eec0-4790-8b24-6875312ad492 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects suspicious file permission modifications + using the `chmod` command, which may indicate an attacker attempting to alter access + controls on critical files or directories. Such modifications can be used to grant + unauthorized users elevated privileges or to conceal malicious activities by restricting + legitimate access. By monitoring for unusual or unauthorized `chmod` usage, this + analytic helps identify potential security breaches, allowing security teams to + respond promptly to prevent privilege escalation, data tampering, or other unauthorized + actions on the system. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE(process_exec, "%chmod%") AND (LIKE(process_exec, "% 777 %") + OR LIKE(process_exec, "% 755 %") OR LIKE(process_exec, "%x%") OR LIKE(process_exec, + "% 754 %") OR LIKE(process_exec, "% 700 %")) | 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_file_permission_modification_via_chmod_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 [$process_exec$] event occurred on host - [$dest$] to modify file permissions using the "chmod" command. + 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: 25 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1222.002/linux_auditd_chmod_exec_attrib/linux_auditd_chmod_exec_attrib.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_file_permissions_modification_via_chattr.yml b/detections/endpoint/linux_auditd_file_permissions_modification_via_chattr.yml new file mode 100644 index 0000000000..02dd37610f --- /dev/null +++ b/detections/endpoint/linux_auditd_file_permissions_modification_via_chattr.yml @@ -0,0 +1,69 @@ +name: Linux Auditd File Permissions Modification Via Chattr +id: f2d1110d-b01c-4a58-9975-90a9edeb083a +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects suspicious file permissions modifications + using the chattr command, which may indicate an attacker attempting to manipulate + file attributes to evade detection or prevent alteration. The chattr command can + be used to make files immutable or restrict deletion, which can be leveraged to + protect malicious files or disrupt system operations. By monitoring for unusual + or unauthorized chattr usage, this analytic helps identify potential tampering with + critical files, enabling security teams to quickly respond to and mitigate threats + associated with unauthorized file attribute changes. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE(process_exec, "%chattr %") AND LIKE(process_exec, "% -i%") + | 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_file_permissions_modification_via_chattr_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 modify file permissions using the "chattr" command. + mitre_attack_id: + - T1222.002 + - T1222 + 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/T1222.002/linux_auditd_chattr_i/linux_auditd_chattr_i.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_find_credentials_from_password_managers.yml b/detections/endpoint/linux_auditd_find_credentials_from_password_managers.yml new file mode 100644 index 0000000000..fbb9f814e0 --- /dev/null +++ b/detections/endpoint/linux_auditd_find_credentials_from_password_managers.yml @@ -0,0 +1,76 @@ +name: Linux Auditd Find Credentials From Password Managers +id: 784241aa-85a5-4782-a503-d071bd3446f9 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects suspicious attempts to find credentials + stored in password managers, which may indicate an attacker's effort to retrieve + sensitive login information. Password managers are often targeted by adversaries + seeking to access stored passwords for further compromise or lateral movement within + a network. By monitoring for unusual or unauthorized access to password manager + files or processes, this analytic helps identify potential credential theft attempts, + enabling security teams to respond quickly to protect critical accounts and prevent + further unauthorized access. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%.kdbx%") OR LIKE (process_exec, "%KeePass%") OR LIKE (process_exec, + "%KeePass\.enforced%") OR LIKE (process_exec, "%.lpdb%")OR LIKE (process_exec, "%.opvault%")OR + LIKE (process_exec, "%.agilekeychain%")OR LIKE (process_exec, "%.dashlane%")OR LIKE + (process_exec, "%.rfx%")OR LIKE (process_exec, "%passbolt%")OR LIKE (process_exec, + "%.spdb%")OR LIKE (process_exec, "%StickyPassword%")OR LIKE (process_exec, "%.walletx%")OR + LIKE (process_exec, "%enpass%")OR LIKE (process_exec, "%vault%")OR LIKE (process_exec, + "%.kdb%")) | 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_find_credentials_from_password_managers_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 find credentials stored in password managers. + mitre_attack_id: + - T1555.005 + - T1555 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - argc + - process_exec + 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/T1555.005/linux_auditd_find_password_db/linux_auditd_find_password_db.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_find_credentials_from_password_stores.yml b/detections/endpoint/linux_auditd_find_credentials_from_password_stores.yml new file mode 100644 index 0000000000..a6124b82e4 --- /dev/null +++ b/detections/endpoint/linux_auditd_find_credentials_from_password_stores.yml @@ -0,0 +1,71 @@ +name: Linux Auditd Find Credentials From Password Stores +id: 4de73044-9a1d-4a51-a1c2-85267d8dcab3 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects suspicious attempts to find credentials + stored in password stores, indicating a potential attacker's effort to access sensitive + login information. Password stores are critical repositories that contain valuable + credentials, and unauthorized access to them can lead to significant security breaches. + By monitoring for unusual or unauthorized activities related to password store access, + this analytic helps identify potential credential theft attempts, allowing security + teams to respond promptly and prevent unauthorized access to critical systems and + data. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%password%") OR LIKE (process_exec, "%pass %") OR LIKE (process_exec, + "%credential%")OR LIKE (process_exec, "%creds%")) | 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_find_credentials_from_password_stores_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 find credentials stored in password managers. + mitre_attack_id: + - T1555.005 + - T1555 + 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/T1555.005/linux_auditd_find_credentials/linux_auditd_find_credentials.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_find_private_keys.yml b/detections/endpoint/linux_auditd_find_private_keys.yml new file mode 100644 index 0000000000..9ff566aa84 --- /dev/null +++ b/detections/endpoint/linux_auditd_find_private_keys.yml @@ -0,0 +1,66 @@ +name: Linux Auditd Find Private Keys +id: 80bb9988-190b-4ee0-a3c3-509545a8f678 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: "The following analytic detects suspicious attempts to find private keys, which may indicate an attacker's effort to access sensitive cryptographic information. Private keys are crucial for securing encrypted communications and data, and unauthorized access to them can lead to severe security breaches, including data decryption and identity theft. By monitoring for unusual or unauthorized searches for private keys, this analytic helps identify potential threats to cryptographic security, enabling security teams to take swift action to protect the integrity and confidentiality of encrypted information." +data_source: +- Linux Auditd Execve +search: ' `linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%.pem%") OR LIKE (process_exec, "%.cer%") OR LIKE (process_exec, + "%.crt%") OR LIKE (process_exec, "%.pgp%") OR LIKE (process_exec, "%.key%") OR LIKE + (process_exec, "%.gpg%")OR LIKE (process_exec, "%.ppk%") OR LIKE (process_exec, + "%.p12%")OR LIKE (process_exec, "%.pfx%")OR LIKE (process_exec, "%.p7b%")) | 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_find_private_keys_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 find private keys. + mitre_attack_id: + - T1552.004 + - T1552 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - argc + - process_exec + 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/T1552.004/linux_auditd_find_gpg/linux_auditd_find_gpg.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_find_ssh_private_keys.yml b/detections/endpoint/linux_auditd_find_ssh_private_keys.yml new file mode 100644 index 0000000000..c4498b01eb --- /dev/null +++ b/detections/endpoint/linux_auditd_find_ssh_private_keys.yml @@ -0,0 +1,65 @@ +name: Linux Auditd Find Ssh Private Keys +id: e2d2bd10-dcd1-4b2f-8a76-0198eab32ba5 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: "The following analytic detects suspicious attempts to find SSH private keys, which may indicate an attacker's effort to compromise secure access to systems. SSH private keys are essential for secure authentication, and unauthorized access to these keys can enable attackers to gain unauthorized access to servers and other critical infrastructure. By monitoring for unusual or unauthorized searches for SSH private keys, this analytic helps identify potential threats to network security, allowing security teams to quickly respond and safeguard against unauthorized access and potential breaches." +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%id_rsa%") OR LIKE (process_exec, "%id_dsa%")OR LIKE (process_exec, + "%.key%") OR LIKE (process_exec, "%ssh_key%")OR LIKE (process_exec, "%authorized_keys%")) + | 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_find_ssh_private_keys_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 find SSH private keys. + mitre_attack_id: + - T1552.004 + - T1552 + 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/T1552.004/linux_auditd_find_ssh_files/linux_auditd_find_ssh_files.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_hardware_addition_swapoff.yml b/detections/endpoint/linux_auditd_hardware_addition_swapoff.yml new file mode 100644 index 0000000000..fcede5c55c --- /dev/null +++ b/detections/endpoint/linux_auditd_hardware_addition_swapoff.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Hardware Addition Swapoff +id: 5728bb16-1a0b-4b66-bce2-0074ac839770 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the execution of the "swapoff" command, + which disables the swapping of paging devices on a Linux system. It leverages data + from Endpoint Detection and Response (EDR) agents, focusing on process execution + logs. This activity is significant because disabling swap can be a tactic used by + malware, such as Awfulshred, to evade detection and hinder forensic analysis. If + confirmed malicious, this action could allow an attacker to manipulate system memory + management, potentially leading to data corruption, system instability, or evasion + of memory-based detection mechanisms. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE(process_exec, "%swapoff %") AND LIKE(process_exec, "% -a%") + | 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_hardware_addition_swapoff_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 may disable swapping of devices in a linux host. + Filter is needed. +references: +- 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: 60 + impact: 60 + message: A [$process_exec$] event occurred on host - [$dest$] to disable the swapping + of paging devices on a Linux system. + mitre_attack_id: + - T1200 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - argc + - process_exec + risk_score: 36 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1200/linux_auditd_swapoff/linux_auditd_swapoff.log + source: /var/log/audit/audit.log + sourcetype: linux:audit + update_timestamp: true diff --git a/detections/endpoint/linux_auditd_hidden_files_and_directories_creation.yml b/detections/endpoint/linux_auditd_hidden_files_and_directories_creation.yml new file mode 100644 index 0000000000..c8a07b3865 --- /dev/null +++ b/detections/endpoint/linux_auditd_hidden_files_and_directories_creation.yml @@ -0,0 +1,72 @@ +name: Linux Auditd Hidden Files And Directories Creation +id: 555cc358-bf16-4e05-9b3a-0f89c73b7261 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: "The following analytic detects suspicious creation of hidden files and + directories, which may indicate an attacker's attempt to conceal malicious activities + or unauthorized data. Hidden files and directories are often used to evade detection + by security tools and administrators, providing a stealthy means for storing malware, + logs, or sensitive information. By monitoring for unusual or unauthorized creation of + hidden files and directories, this analytic helps identify potential attempts to hide + or unauthorized creation of hidden files and directories, this analytic helps identify + potential attempts to hide malicious operations, enabling security teams to uncover + and address hidden threats effectively." +data_source: +- Linux Auditd Execve +search: ' `linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec,"%touch %") OR LIKE (process_exec,"%mkdir %")OR + LIKE (process_exec,"%vim %") OR LIKE (process_exec,"%vi %") OR LIKE (process_exec,"%nano + %")) AND (LIKE (process_exec,"% ./.%") OR LIKE (process_exec," .%")OR LIKE (process_exec," + /.%")) | 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_hidden_files_and_directories_creation_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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$]. + mitre_attack_id: + - T1083 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - argc + - process_exec + 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/T1083/linux_auditd_hidden_file/linux_auditd_hidden_file.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_insert_kernel_module_using_insmod_utility.yml b/detections/endpoint/linux_auditd_insert_kernel_module_using_insmod_utility.yml new file mode 100644 index 0000000000..215c54dcc4 --- /dev/null +++ b/detections/endpoint/linux_auditd_insert_kernel_module_using_insmod_utility.yml @@ -0,0 +1,73 @@ +name: Linux Auditd Insert Kernel Module Using Insmod Utility +id: bc0ca53f-dea6-4906-9b12-09c396fdf1d3 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the insertion of a Linux kernel module + using the insmod utility. It leverages data from Linux Auditd, focusing on process execution logs that include process names and + command-line details. This activity is significant as it may indicate the installation + of a rootkit or malicious kernel module, potentially allowing an attacker to gain + elevated privileges and bypass security detections. If confirmed malicious, this + could lead to unauthorized code execution, persistent access, and severe compromise + of the affected system. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm=insmod | rename host as dest | stats count + min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL UID ppid pid + success dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `linux_auditd_insert_kernel_module_using_insmod_utility_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://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/ +- https://security.stackexchange.com/questions/175953/how-to-load-a-malicious-lkm-at-startup +- https://0x00sec.org/t/kernel-rootkits-getting-your-hands-dirty/1485 +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Rootkit + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 80 + impact: 80 + message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to insert a Linux kernel module using the insmod utility. + mitre_attack_id: + - T1547.006 + - T1547 + 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: 64 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/linux_auditd_insmod/linux_auditd_insmod.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_install_kernel_module_using_modprobe_utility.yml b/detections/endpoint/linux_auditd_install_kernel_module_using_modprobe_utility.yml new file mode 100644 index 0000000000..d1753399c9 --- /dev/null +++ b/detections/endpoint/linux_auditd_install_kernel_module_using_modprobe_utility.yml @@ -0,0 +1,73 @@ +name: Linux Auditd Install Kernel Module Using Modprobe Utility +id: 95165985-ace5-4d42-9c42-93a89a5af901 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the installation of a Linux kernel module + using the modprobe utility. It leverages data from Linux Auditd, focusing on process names and command-line executions. This activity + is significant because installing a kernel module can indicate an attempt to deploy + a rootkit or other malicious kernel-level code, potentially leading to elevated + privileges and bypassing security detections. If confirmed malicious, this could + allow an attacker to gain persistent, high-level access to the system, compromising + its integrity and security. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm=modprobe | rename host as dest | stats count + min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL UID ppid pid + success dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_install_kernel_module_using_modprobe_utility_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://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/ +- https://security.stackexchange.com/questions/175953/how-to-load-a-malicious-lkm-at-startup +- https://0x00sec.org/t/kernel-rootkits-getting-your-hands-dirty/1485 +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Rootkit + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 80 + impact: 80 + message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to install a Linux kernel module using the modprobe utility. + mitre_attack_id: + - T1547.006 + - T1547 + 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: 64 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/linux_auditd_modprobe/linux_auditd_modprobe.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_kernel_module_enumeration.yml b/detections/endpoint/linux_auditd_kernel_module_enumeration.yml new file mode 100644 index 0000000000..a9ef21100c --- /dev/null +++ b/detections/endpoint/linux_auditd_kernel_module_enumeration.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Kernel Module Enumeration +id: d1b088de-c47a-4572-9339-bdcc26493b32 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic identifies the use of the 'kmod' process to list + kernel modules on a Linux system. This detection leverages data from Linux Auditd, focusing on process names and command-line executions. + While listing kernel modules is not inherently malicious, it can be a precursor + to loading unauthorized modules using 'insmod'. If confirmed malicious, this activity + could allow an attacker to load kernel modules, potentially leading to privilege + escalation, persistence, or other malicious actions within the system. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm=lsmod | rename host as dest | stats count + min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL UID ppid pid + success dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` + | `linux_auditd_kernel_module_enumeration_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 are present based on automated tooling or system + administrative usage. Filter as needed. +references: +- https://man7.org/linux/man-pages/man8/kmod.8.html +tags: + analytic_story: + - Linux Rootkit + - Compromised Linux Host + asset_type: Endpoint + confidence: 50 + impact: 30 + message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to list kernel modules. + mitre_attack_id: + - T1082 + - T1014 + 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: 15 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1082/linux_auditd_lsmod/linux_auditd_lsmod.log + source: /var/log/audit/audit.log + sourcetype: linux:audit + update_timestamp: true diff --git a/detections/endpoint/linux_auditd_kernel_module_using_rmmod_utility.yml b/detections/endpoint/linux_auditd_kernel_module_using_rmmod_utility.yml new file mode 100644 index 0000000000..0203fa75c1 --- /dev/null +++ b/detections/endpoint/linux_auditd_kernel_module_using_rmmod_utility.yml @@ -0,0 +1,65 @@ +name: Linux Auditd Kernel Module Using Rmmod Utility +id: 31810b7a-0abe-42be-a210-0dec8106afee +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: "The following analytic detects suspicious use of the `rmmod` utility for kernel module removal, which may indicate an attacker attempt to unload critical or security-related kernel modules. The `rmmod` command is used to remove modules from the Linux kernel, and unauthorized use can be a tactic to disable security features, conceal malicious activities, or disrupt system operations. By monitoring for unusual or unauthorized `rmmod` activity, this analytic helps identify potential tampering with kernel modules, enabling security teams to take proactive measures to protect system integrity and security." +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm=rmmod | rename host as dest | stats count + min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL UID ppid pid + success dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_kernel_module_using_rmmod_utility_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: 80 + impact: 90 + message: A SYSCALL - [$comm$] event was executed on host - [$dest$] to remove a Linux kernel module using the rmmod utility. + mitre_attack_id: + - T1547.006 + - T1547 + 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: 72 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1547.006/linux_auditd_rmmod/linux_auditd_rmmod.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_nopasswd_entry_in_sudoers_file.yml b/detections/endpoint/linux_auditd_nopasswd_entry_in_sudoers_file.yml new file mode 100644 index 0000000000..511e1a611b --- /dev/null +++ b/detections/endpoint/linux_auditd_nopasswd_entry_in_sudoers_file.yml @@ -0,0 +1,67 @@ +name: Linux Auditd Nopasswd Entry In Sudoers File +id: 651df959-ad17-4b73-a323-90cb96d5fa1b +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the addition of NOPASSWD entries to the + /etc/sudoers file on Linux systems. It leverages Linux Auditd data to identify command lines containing "NOPASSWD:". This activity + is significant because it allows users to execute commands with elevated privileges + without requiring a password, which can be exploited by adversaries to maintain + persistent, privileged access. If confirmed malicious, this could lead to unauthorized + privilege escalation, persistent access, and potential compromise of sensitive data + and system integrity. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE (process_exec, "%NOPASSWD%") | 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_nopasswd_entry_in_sudoers_file_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://askubuntu.com/questions/334318/sudoers-file-enable-nopasswd-for-user-all-commands +- https://help.ubuntu.com/community/Sudoers +tags: + analytic_story: + - 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 add NOPASSWD entry in sudoers file. + mitre_attack_id: + - T1548.003 + - T1548 + 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/T1548.003/linux_auditd_nopasswd/linux_auditd_nopasswd.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_osquery_service_stop.yml b/detections/endpoint/linux_auditd_osquery_service_stop.yml new file mode 100644 index 0000000000..072d6a1dc6 --- /dev/null +++ b/detections/endpoint/linux_auditd_osquery_service_stop.yml @@ -0,0 +1,70 @@ +name: Linux Auditd Osquery Service Stop +id: 0c320fea-6e87-4b99-a884-74d09d4b655d +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects suspicious stopping of the `osquery` service, + which may indicate an attempt to disable monitoring and evade detection. `Osquery` + is a powerful tool used for querying system information and detecting anomalies, + and stopping its service can be a sign that an attacker is trying to disrupt security + monitoring or hide malicious activities. By monitoring for unusual or unauthorized + stops of the `osquery` service, this analytic helps identify potential efforts to + bypass security controls, enabling security teams to investigate and respond to + possible threats effectively. +data_source: +- Linux Auditd Service Stop +search: '`linux_auditd` type=SERVICE_STOP unit IN ("osqueryd") | 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_osquery_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: 80 + impact: 80 + message: A service event - [$type$] event occured on host - [$dest$] to stop the osquery service. + 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: 64 + 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_osquerd_service_stop/linux_auditd_osquerd_service_stop.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_possible_access_or_modification_of_sshd_config_file.yml b/detections/endpoint/linux_auditd_possible_access_or_modification_of_sshd_config_file.yml new file mode 100644 index 0000000000..b7577183a0 --- /dev/null +++ b/detections/endpoint/linux_auditd_possible_access_or_modification_of_sshd_config_file.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Possible Access Or Modification Of Sshd Config File +id: acb3ea33-70f7-47aa-b335-643b3aebcb2f +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects suspicious access or modification of the + sshd_config file on Linux systems. It leverages data from Linux Auditd, focusing on command-line executions involving processes like + "cat," "nano," "vim," and "vi" accessing the sshd_config file. This activity is + significant because unauthorized changes to sshd_config can allow threat actors + to redirect port connections or use unauthorized keys, potentially compromising + the system. If confirmed malicious, this could lead to unauthorized access, privilege + escalation, or persistent backdoor access, posing a severe security risk. +data_source: +- Linux Auditd Path +search: '`linux_auditd` type=PATH name="/etc/ssh/ssh_config*" | rename host as dest + | stats count min(_time) as firstTime max(_time) as lastTime by name nametype OGID + dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_possible_access_or_modification_of_sshd_config_file_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 commandline + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.hackingarticles.in/ssh-penetration-testing-port-22/ +- https://attack.mitre.org/techniques/T1098/004/ +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 [$type$] has been accessed/modified on host - [$dest$] to modify the sshd_config file. + mitre_attack_id: + - T1098.004 + - T1098 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - name + - nametype + - OGID + 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/T1098.004/linux_auditd_nopasswd/linux_auditd_ssh_config.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_possible_access_to_credential_files.yml b/detections/endpoint/linux_auditd_possible_access_to_credential_files.yml new file mode 100644 index 0000000000..eb214c17fe --- /dev/null +++ b/detections/endpoint/linux_auditd_possible_access_to_credential_files.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Possible Access To Credential Files +id: 0419cb7a-57ea-467b-974f-77c303dfe2a3 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects attempts to access or dump the contents + of /etc/passwd and /etc/shadow files on Linux systems. It leverages data from Linux + Auditd, focusing on processes like 'cat', 'nano', 'vim', and 'vi' accessing these + files. This activity is significant as it may indicate credential dumping, a technique + used by adversaries to gain persistence or escalate privileges. If confirmed malicious, + privileges. If confirmed malicious, attackers could obtain hashed passwords for + offline cracking, leading to unauthorized access and potential system compromise. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where (LIKE (process_exec, "%shadow%") OR LIKE (process_exec, "%passwd%")) + AND (LIKE (process_exec, "%cat %") OR LIKE (process_exec, "%nano %")OR LIKE (process_exec, + "%vim %") OR LIKE (process_exec, "%vi %")) | 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_possible_access_to_credential_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 execute this command. + Please update the filter macros to remove false positives. +references: +- https://askubuntu.com/questions/445361/what-is-difference-between-etc-shadow-and-etc-passwd +- https://attack.mitre.org/techniques/T1003/008/ +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 access or dump the contents of /etc/passwd and /etc/shadow files. + mitre_attack_id: + - T1003.008 + - T1003 + 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/T1003.008/linux_auditd_access_credential/linux_auditd_access_credential.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_possible_access_to_sudoers_file.yml b/detections/endpoint/linux_auditd_possible_access_to_sudoers_file.yml new file mode 100644 index 0000000000..7c5b6fc127 --- /dev/null +++ b/detections/endpoint/linux_auditd_possible_access_to_sudoers_file.yml @@ -0,0 +1,66 @@ +name: Linux Auditd Possible Access To Sudoers File +id: 8be88f46-f7e8-4ae6-b15e-cf1b13392834 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects potential access or modification of the + /etc/sudoers file on a Linux system. It leverages data from Linux Auditd, focusing on processes like "cat," "nano," "vim," and "vi" + accessing the /etc/sudoers file. This activity is significant because the sudoers + file controls user permissions for executing commands with elevated privileges. + If confirmed malicious, an attacker could gain persistence or escalate privileges, + compromising the security of the targeted host. +data_source: +- Linux Auditd Path +search: '`linux_auditd` type=PATH name="/etc/sudoers*" | rename host as dest | stats + count min(_time) as firstTime max(_time) as lastTime by name nametype OGID dest + | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| `linux_auditd_possible_access_to_sudoers_file_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://attack.mitre.org/techniques/T1548/003/ +- https://web.archive.org/web/20210708035426/https://www.cobaltstrike.com/downloads/csmanual43.pdf +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 50 + impact: 50 + message: A [$type$] has been accessed/modified on host - [$dest$] to access or modify the sudoers file. + mitre_attack_id: + - T1548.003 + - T1548 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - name + - nametype + - OGID + 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/T1548.003/linux_auditd_sudoers_access/linux_auditd_sudoers_access.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_possible_append_cronjob_entry_on_existing_cronjob_file.yml b/detections/endpoint/linux_auditd_possible_append_cronjob_entry_on_existing_cronjob_file.yml new file mode 100644 index 0000000000..3dbb2bf6cd --- /dev/null +++ b/detections/endpoint/linux_auditd_possible_append_cronjob_entry_on_existing_cronjob_file.yml @@ -0,0 +1,72 @@ +name: Linux Auditd Possible Append Cronjob Entry On Existing Cronjob File +id: fea71cf0-fa10-4ef6-9202-9682b2e0c477 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Hunting +description: The following analytic detects potential tampering with cronjob files + on a Linux system by identifying 'echo' commands that append code to existing cronjob + files. It leverages logs from Linux Auditd, focusing on process names, parent processes, and command-line executions. This activity is + significant because adversaries often use it for persistence or privilege escalation. + If confirmed malicious, this could allow attackers to execute unauthorized code + automatically, leading to system compromises and unauthorized data access, thereby + impacting business operations and data integrity. +data_source: +- Linux Auditd Path +search: '`linux_auditd` type=PATH name IN("*/etc/cron*", "*/var/spool/cron/*", "*/etc/anacrontab*") + | rename host as dest | stats count min(_time) as firstTime max(_time) as lastTime + by name nametype OGID dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_possible_append_cronjob_entry_on_existing_cronjob_file_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 arise from legitimate actions by administrators + or network operators who may use these commands for automation purposes. Therefore, + it's recommended to adjust filter macros to eliminate such false positives. +references: +- https://attack.mitre.org/techniques/T1053/003/ +- https://blog.aquasec.com/threat-alert-kinsing-malware-container-vulnerability +- https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/ +tags: + analytic_story: + - Scheduled Tasks + - Linux Privilege Escalation + - Linux Persistence Techniques + - Linux Living Off The Land + - Compromised Linux Host + asset_type: Endpoint + confidence: 70 + impact: 70 + message: A [$type$] event has occured on host - [$dest$] to append a cronjob entry on an existing cronjob file. + mitre_attack_id: + - T1053.003 + - T1053 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - name + - nametype + - OGID + 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/T1053.003/linux_auditd_cron_file_audited/linux_auditd_cron_file_audited2.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_preload_hijack_library_calls.yml b/detections/endpoint/linux_auditd_preload_hijack_library_calls.yml new file mode 100644 index 0000000000..1a1d49c96b --- /dev/null +++ b/detections/endpoint/linux_auditd_preload_hijack_library_calls.yml @@ -0,0 +1,66 @@ +name: Linux Auditd Preload Hijack Library Calls +id: 35c50572-a70b-452f-afa9-bebdf3c3ce36 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the use of the LD_PRELOAD environment + variable to hijack or hook library functions on a Linux platform. It leverages data + from Linux Auditd, focusing on process execution logs that include command-line details. This activity is significant because adversaries, + malware authors, and red teamers commonly use this technique to gain elevated privileges + and establish persistence on a compromised machine. If confirmed malicious, this + behavior could allow attackers to execute arbitrary code, escalate privileges, and + maintain long-term access to the system. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where LIKE (process_exec, "%LD_PRELOAD%")| 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_preload_hijack_library_calls_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://compilepeace.medium.com/memory-malware-part-0x2-writing-userland-rootkits-via-ld-preload-30121c8343d5 +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 90 + impact: 90 + message: A [$process_exec$] event occurred on host - [$dest$] to hijack or hook library functions using the LD_PRELOAD environment variable. + mitre_attack_id: + - T1574.006 + - T1574 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - argc + - process_exec + risk_score: 81 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.006/linux_auditd_ldpreload/linux_auditd_ldpreload.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_preload_hijack_via_preload_file.yml b/detections/endpoint/linux_auditd_preload_hijack_via_preload_file.yml new file mode 100644 index 0000000000..109ef8c438 --- /dev/null +++ b/detections/endpoint/linux_auditd_preload_hijack_via_preload_file.yml @@ -0,0 +1,62 @@ +name: Linux Auditd Preload Hijack Via Preload File +id: c1b7abca-55cb-4a39-bdfb-e28c1c12745f +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: "The following analytic detects suspicious preload hijacking via the `preload` file, which may indicate an attacker's attempt to intercept or manipulate library loading processes. The `preload` file can be used to force the loading of specific libraries before others, potentially allowing malicious code to execute or alter application behavior. By monitoring for unusual or unauthorized modifications to the `preload` file, this analytic helps identify attempts to hijack preload mechanisms, enabling security teams to investigate and address potential threats to system integrity and security." +data_source: +- Linux Auditd Path +search: '`linux_auditd` type=PATH name="/etc/ld.so.preload*" | rename host as dest + | stats count min(_time) as firstTime max(_time) as lastTime by name nametype OGID + dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_preload_hijack_via_preload_file_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: 90 + impact: 90 + message: A [$type$] event has occured on host - [$dest$] to modify the preload file. + mitre_attack_id: + - T1574.006 + - T1574 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - name + - nametype + - OGID + risk_score: 81 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1574.006/linux_auditd_preload_file/linux_auditd_preload_file.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_service_restarted.yml b/detections/endpoint/linux_auditd_service_restarted.yml new file mode 100644 index 0000000000..051df9e2ab --- /dev/null +++ b/detections/endpoint/linux_auditd_service_restarted.yml @@ -0,0 +1,72 @@ +name: Linux Auditd Service Restarted +id: 8eb3e858-18d3-44a4-a514-52cfa39f154a +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the restarting or re-enabling of services + on Linux systems using the `systemctl` or `service` commands. It leverages data + from Linux Auditd, focusing on process and command-line execution logs. This activity + is significant as adversaries may use it to maintain persistence or execute unauthorized + actions. If confirmed malicious, this behavior could lead to repeated execution + of malicious payloads, unauthorized access, or data destruction. Security analysts + should investigate these events to mitigate risks and prevent further compromise. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where (LIKE(process_exec, "%systemctl %") OR LIKE(process_exec, "%service + %") ) AND(LIKE(process_exec, "%restart%") OR LIKE(process_exec, "%reenable%") OR + LIKE(process_exec, "%reload%")) | 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_service_restarted_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 commandline + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://attack.mitre.org/techniques/T1543/003/ +tags: + analytic_story: + - AwfulShred + - Scheduled Tasks + - Linux Privilege Escalation + - Data Destruction + - Linux Persistence Techniques + - Linux Living Off The Land + - Gomir + - Compromised Linux Host + asset_type: Endpoint + confidence: 50 + impact: 50 + message: A [$process_exec$] event occurred on host - [$dest$] to restart or re-enable a service. + mitre_attack_id: + - T1053.006 + - T1053 + 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/T1053.006/linux_services_restart/linux_services_restart.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_service_started.yml b/detections/endpoint/linux_auditd_service_started.yml new file mode 100644 index 0000000000..0cccf2d1c4 --- /dev/null +++ b/detections/endpoint/linux_auditd_service_started.yml @@ -0,0 +1,68 @@ +name: Linux Auditd Service Started +id: b5eed06d-5c97-4092-a3a1-fa4b7e77c71a +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the suspicious service started. 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 Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where (LIKE(process_exec, "%systemctl %") OR LIKE(process_exec, "%service + %") ) AND(LIKE(process_exec, "% start %") OR LIKE(process_exec, "% enable %")) | + 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_service_started_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: 80 + impact: 80 + message: A [$process_exec$] event occurred on host - [$dest$] to start or enable a service. + mitre_attack_id: + - T1569.002 + - T1569 + 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/T1569.002/linux_service_start/linux_service_start.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_setuid_using_chmod_utility.yml b/detections/endpoint/linux_auditd_setuid_using_chmod_utility.yml new file mode 100644 index 0000000000..40d98c4d48 --- /dev/null +++ b/detections/endpoint/linux_auditd_setuid_using_chmod_utility.yml @@ -0,0 +1,68 @@ +name: Linux Auditd Setuid Using Chmod Utility +id: 8230c407-1b47-4d95-ac2e-718bd6381386 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the execution of the chmod utility to + set the SUID or SGID bit on files, which can allow users to temporarily gain root + or group-level access. This detection leverages data from Linux Auditd, focusing on process names and command-line arguments related + to chmod. This activity is significant as it can indicate an attempt to escalate + privileges or maintain persistence on a system. If confirmed malicious, an attacker + could gain elevated access, potentially compromising sensitive data or critical + system functions. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE (process_exec, "%chmod %") AND (LIKE (process_exec, "% u+s + %") OR LIKE (process_exec, "% g+s %") OR LIKE (process_exec, "% 4777 %") OR LIKE + (process_exec, "% 4577 %")) | 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_setuid_using_chmod_utility_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://www.hackingarticles.in/linux-privilege-escalation-using-capabilities/ +tags: + analytic_story: + - Linux Living Off The Land + - Linux Privilege Escalation + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 90 + impact: 90 + message: A [$process_exec$] event occurred on host - [$dest$] to set the SUID or SGID bit on files using the chmod utility. + mitre_attack_id: + - T1548.001 + - T1548 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - proctitle + risk_score: 81 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_auditd_setuid/linux_auditd_setuid.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_setuid_using_setcap_utility.yml b/detections/endpoint/linux_auditd_setuid_using_setcap_utility.yml new file mode 100644 index 0000000000..ba6c251de4 --- /dev/null +++ b/detections/endpoint/linux_auditd_setuid_using_setcap_utility.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Setuid Using Setcap Utility +id: 1474459a-302b-4255-8add-d82f96d14cd9 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the execution of the 'setcap' utility + to enable the SUID bit on Linux systems. It leverages Linux Auditd data, focusing on process names and command-line arguments that indicate the + use of 'setcap' with specific capabilities. This activity is significant because + setting the SUID bit allows a user to temporarily gain root access, posing a substantial + security risk. If confirmed malicious, an attacker could escalate privileges, execute + arbitrary commands with elevated permissions, and potentially compromise the entire + system. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where LIKE (process_exec, "%setcap %") AND (LIKE (process_exec, "% cap_setuid+ep + %") OR LIKE (process_exec, "% cap_setuid=ep %") OR LIKE (process_exec, "% cap_net_bind_service+p + %") OR LIKE (process_exec, "% cap_net_raw+ep %") OR LIKE (process_exec, "% cap_dac_read_search+ep + %")) | 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_setuid_using_setcap_utility_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://www.hackingarticles.in/linux-privilege-escalation-using-capabilities/ +tags: + analytic_story: + - Linux Privilege Escalation + - Linux Persistence Techniques + - Compromised Linux Host + asset_type: Endpoint + confidence: 90 + impact: 90 + message: A [$process_exec$] event occurred on host - [$dest$] to set the SUID or SGID bit on files using the setcap utility. + mitre_attack_id: + - T1548.001 + - T1548 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - argc + - process_exec + risk_score: 81 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.001/linux_auditd_setuid/linux_auditd_setcap_priv.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_shred_overwrite_command.yml b/detections/endpoint/linux_auditd_shred_overwrite_command.yml new file mode 100644 index 0000000000..c139a7582d --- /dev/null +++ b/detections/endpoint/linux_auditd_shred_overwrite_command.yml @@ -0,0 +1,66 @@ +name: Linux Auditd Shred Overwrite Command +id: ce2bde4d-a1d4-4452-8c87-98440e5adfb3 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the execution of the 'shred' command on + a Linux machine, which is used to overwrite files to make them unrecoverable. It + leverages data from Linux Auditd, focusing on process names and command-line arguments. This activity is significant because the 'shred' command can be used in destructive attacks, such as those seen in the Industroyer2 malware targeting energy facilities. If confirmed malicious, this activity could lead to the permanent destruction of critical files, severely impacting system integrity and data availability. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE (process_exec, "%shred%") AND (LIKE (process_exec, "%-n%") + OR LIKE (process_exec, "%-z%") OR LIKE (process_exec, "%-u%") OR LIKE (process_exec, + "%-s%")) | 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_shred_overwrite_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: Administrator or network operator can use this application + for automation purposes. Please update the filter macros to remove false positives. +references: +- https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - AwfulShred + - Linux Privilege Escalation + - Data Destruction + - Linux Persistence Techniques + - Industroyer2 + - Compromised Linux Host + asset_type: Endpoint + confidence: 90 + impact: 90 + message: A [$process_exec$] event occurred on host - [$dest$] to overwrite files using the shred utility. + mitre_attack_id: + - T1485 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - proctitle + risk_score: 81 + 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_shred/linux_auditd_shred.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_stop_services.yml b/detections/endpoint/linux_auditd_stop_services.yml new file mode 100644 index 0000000000..c2ca43a903 --- /dev/null +++ b/detections/endpoint/linux_auditd_stop_services.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Stop Services +id: 43bc9281-753b-4743-b4b7-60af84f085f3 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects attempts to stop or clear a service on + Linux systems. It leverages data from Linux Auditd, focusing on processes like "systemctl," "service," and "svcadm" executing stop commands. + This activity is significant as adversaries often terminate security or critical + services to disable defenses or disrupt operations, as seen in malware like Industroyer2. + If confirmed malicious, this could lead to the disabling of security mechanisms, + allowing attackers to persist, escalate privileges, or deploy destructive payloads, + severely impacting system integrity and availability. +data_source: +- Linux Auditd Service Stop +search: '`linux_auditd` type=SERVICE_STOP | rename host as dest | stats count min(_time) + as firstTime max(_time) as lastTime by type pid UID comm exe dest | `security_content_ctime(firstTime)`| + `security_content_ctime(lastTime)`| `linux_auditd_stop_services_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.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/ +- https://cert.gov.ua/article/39518 +tags: + analytic_story: + - Industroyer2 + - Data Destruction + - AwfulShred + - Compromised Linux Host + asset_type: Endpoint + confidence: 70 + impact: 70 + message: A service event - [$type$] event occured on host - [$dest$] to stop or disable a service. + 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_service_stop/linux_auditd_service_stop.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_sudo_or_su_execution.yml b/detections/endpoint/linux_auditd_sudo_or_su_execution.yml new file mode 100644 index 0000000000..d49703030f --- /dev/null +++ b/detections/endpoint/linux_auditd_sudo_or_su_execution.yml @@ -0,0 +1,66 @@ +name: Linux Auditd Sudo Or Su Execution +id: 817a5c89-5b92-4818-a22d-aa35e1361afe +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the execution of the "sudo" or "su" command + on a Linux operating system. It leverages data from Linux Auditd, focusing on process names and parent process names. This activity + is significant because "sudo" and "su" commands are commonly used by adversaries + to elevate privileges, potentially leading to unauthorized access or control over + the system. If confirmed malicious, this activity could allow attackers to execute + commands with root privileges, leading to severe security breaches, data exfiltration, + or further system compromise. +data_source: +- Linux Auditd Proctitle +search: '`linux_auditd` `linux_auditd_normalized_proctitle_process` | rename host + as dest | where LIKE(process_exec, "%sudo %") OR LIKE(process_exec, "%su %") | 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_sudo_or_su_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 execute this command. + Please update the filter macros to remove false positives. +references: +- https://attack.mitre.org/techniques/T1548/003/ +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 execute the sudo or su command. + mitre_attack_id: + - T1548.003 + - T1548 + 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/T1548.003/linux_auditd_sudo_su/linux_auditd_sudo_su.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_sysmon_service_stop.yml b/detections/endpoint/linux_auditd_sysmon_service_stop.yml new file mode 100644 index 0000000000..b441b1e23a --- /dev/null +++ b/detections/endpoint/linux_auditd_sysmon_service_stop.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Sysmon Service Stop +id: 20901256-633a-40de-8753-7b88811a460f +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects the suspicious sysmon 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 ("sysmon") | 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_sysmon_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: 80 + impact: 80 + message: A service event - [$type$] event occured on host - [$dest$] to stop or disable the sysmon service. + 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: 64 + 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_sysmon_service_stop.log/linux_auditd_sysmon_service_stop.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_system_network_configuration_discovery.yml b/detections/endpoint/linux_auditd_system_network_configuration_discovery.yml new file mode 100644 index 0000000000..299ac8abec --- /dev/null +++ b/detections/endpoint/linux_auditd_system_network_configuration_discovery.yml @@ -0,0 +1,74 @@ +name: Linux Auditd System Network Configuration Discovery +id: 5db16825-81bd-4923-a8d6-d6a13a59832a +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects suspicious system network configuration + discovery activities, which may indicate an adversary's attempt to gather information + about the network environment. Such actions typically involve commands or tools + used to identify network interfaces, routing tables, and active connections. Detecting + these activities is crucial, as they often precede more targeted attacks like lateral + movement or data exfiltration. By identifying unusual or unauthorized network discovery + efforts, this analytic helps security teams to swiftly detect and respond to potential + reconnaissance operations, mitigating the risk of further compromise. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm IN ("arp", "ifconfig", "ip", "netstat", + "firewall-cmd", "ufw", "iptables", "ss", "route") | bucket _time span=15m | rename + host as dest | stats dc(comm) as unique_commands, values(comm) as comm, values(exe) + as exe, values(SYSCALL) as SYSCALL, values(UID) as UID, values(ppid) as ppid, values(pid) + as pid, count, min(_time) as firstTime, max(_time) as lastTime by success dest | + where unique_commands >= 4 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` + | `linux_auditd_system_network_configuration_discovery_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 SYSCALL - [$comm$] event was executed on host - [$dest$] to discover system network configuration. + mitre_attack_id: + - T1016 + 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: 25 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1016/linux_auditd_net_tool/linux_auditd_net_tool.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_unix_shell_configuration_modification.yml b/detections/endpoint/linux_auditd_unix_shell_configuration_modification.yml new file mode 100644 index 0000000000..e1af798091 --- /dev/null +++ b/detections/endpoint/linux_auditd_unix_shell_configuration_modification.yml @@ -0,0 +1,75 @@ +name: Linux Auditd Unix Shell Configuration Modification +id: 66f737c6-3f7f-46ed-8e9b-cc0e5bf01f04 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects suspicious modifications to Unix shell + configuration files, which may indicate an attempt to alter system behavior or gain + unauthorized access. Unix shell configuration files, such as `.bashrc` or `.profile`, + control user environment settings and command execution. Unauthorized changes to + these files can be used to execute malicious commands, escalate privileges, or hide + malicious activities. By monitoring for unusual or unauthorized modifications to + shell configuration files, this analytic helps identify potential security threats, + allowing security teams to respond quickly and mitigate risks. +data_source: +- Linux Auditd Path +search: '`linux_auditd` type=PATH name IN ("/etc/profile", "/etc/shells", "/etc/profile.d", + "/etc/bash.bashrc", "/etc/bashrc", "/etc/zsh/zprofile", "/etc/zsh/zshrc", "/etc/zsh/zlogin", + "/etc/zsh/zlogout", "/etc/csh.cshrc", "/etc/csh.login", "/root/.bashrc", "/root/.bash_profile", + "root/.profile", "/root/.zshrc", "/root/.zprofile", "/home/*/.bashrc", "/home/*/.zshrc", + "/home/*/.bash_profile", "/home/*/.zprofile", "/home/*/.profile", "/home/*/.bash_login", + "/home/*/.bash_logout", "/home/*/.zlogin", "/home/*/.zlogout") | rename host as + dest | stats count min(_time) as firstTime max(_time) as lastTime by name nametype + OGID dest | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)`| + `linux_auditd_unix_shell_configuration_modification_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 [$type$] event occured on host - [$dest$] to modify the unix shell configuration file. + mitre_attack_id: + - T1546.004 + - T1546 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - name + - nametype + - OGID + 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/T1546.004/linux_auditd_unix_shell_mod_config/linux_auditd_unix_shell_mod_config.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_unload_module_via_modprobe.yml b/detections/endpoint/linux_auditd_unload_module_via_modprobe.yml new file mode 100644 index 0000000000..5fb708ae4e --- /dev/null +++ b/detections/endpoint/linux_auditd_unload_module_via_modprobe.yml @@ -0,0 +1,69 @@ +name: Linux Auditd Unload Module Via Modprobe +id: 90964d6a-4b5f-409a-85bd-95e261e03fe9 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: TTP +description: The following analytic detects suspicious use of the `modprobe` command + to unload kernel modules, which may indicate an attempt to disable critical system + components or evade detection. The `modprobe` utility manages kernel modules, and + unauthorized unloading of modules can disrupt system security features, remove logging + capabilities, or conceal malicious activities. By monitoring for unusual or unauthorized + `modprobe` operations involving module unloading, this analytic helps identify potential + tampering with kernel functionality, enabling security teams to investigate and + address possible threats to system integrity. +data_source: +- Linux Auditd Execve +search: '`linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where LIKE (process_exec, "%modprobe%") AND LIKE (process_exec, "%-r %") + | 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_unload_module_via_modprobe_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 unload a kernel module via the modprobe command. + mitre_attack_id: + - T1547.006 + - T1547 + 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/T1547.006/linux_auditd_modprobe_unload_module/linux_auditd_modprobe_unload_module.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_virtual_disk_file_and_directory_discovery.yml b/detections/endpoint/linux_auditd_virtual_disk_file_and_directory_discovery.yml new file mode 100644 index 0000000000..abd5c53579 --- /dev/null +++ b/detections/endpoint/linux_auditd_virtual_disk_file_and_directory_discovery.yml @@ -0,0 +1,63 @@ +name: Linux Auditd Virtual Disk File And Directory Discovery +id: eec78cef-d4c8-4b35-8f5b-6922102a4a41 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: "The following analytic detects suspicious discovery of virtual disk files and directories, which may indicate an attacker's attempt to locate and access virtualized storage environments. Virtual disks can contain sensitive data or critical system configurations, and unauthorized discovery attempts could signify preparatory actions for data exfiltration or further compromise. By monitoring for unusual or unauthorized searches for virtual disk files and directories, this analytic helps identify potential reconnaissance activities, enabling security teams to respond promptly and safeguard against unauthorized access and data breaches." +data_source: +- Linux Auditd Execve +search: ' `linux_auditd` `linux_auditd_normalized_execve_process` | rename host as + dest | where (LIKE (process_exec, "%find%") OR LIKE (process_exec, "%grep%")) AND + (LIKE (process_exec, "%.vhd%") OR LIKE (process_exec, "%.vhdx%") OR LIKE (process_exec, + "%.vmdk%")) | 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_virtual_disk_file_and_directory_discovery_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 discover virtual disk files and directories. + mitre_attack_id: + - T1083 + 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/T1083/linux_auditd_find_virtual_disk/linux_auditd_find_virtual_disk.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/linux_auditd_whoami_user_discovery.yml b/detections/endpoint/linux_auditd_whoami_user_discovery.yml new file mode 100644 index 0000000000..ae07759e24 --- /dev/null +++ b/detections/endpoint/linux_auditd_whoami_user_discovery.yml @@ -0,0 +1,72 @@ +name: Linux Auditd Whoami User Discovery +id: d1ff2e22-310d-446a-80b3-faedaa7b3b52 +version: 1 +date: '2024-09-04' +author: Teoderick Contreras, Splunk +status: production +type: Anomaly +description: The following analytic detects the suspicious use of the whoami command, + which may indicate an attacker trying to gather information about the current user + account on a compromised system. The whoami command is commonly used to verify user + privileges and identity, especially during initial stages of an attack to assess + the level of access. By monitoring for unusual or unauthorized executions of whoami, + this analytic helps in identifying potential reconnaissance activities, enabling + security teams to take action before the attacker escalates privileges or conducts + further malicious operations. +data_source: +- Linux Auditd Syscall +search: '`linux_auditd` type=SYSCALL comm=whoami OR exe= "*/whoami" | rename host + as dest | stats count min(_time) as firstTime max(_time) as lastTime by comm exe SYSCALL + UID ppid pid dest success | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| + `linux_auditd_whoami_user_discovery_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://github.com/peass-ng/PEASS-ng/tree/master/linPEAS +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 SYSCALL - [$comm$] event was executed on host - [$dest$] to discover virtual disk files and directories. + mitre_attack_id: + - T1033 + 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: 25 + security_domain: endpoint +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1033/linux_auditd_whoami/linux_auditd_whoami.log + source: /var/log/audit/audit.log + sourcetype: linux:audit diff --git a/detections/endpoint/powershell_4104_hunting.yml b/detections/endpoint/powershell_4104_hunting.yml index e02d365720..7ac3ab7592 100644 --- a/detections/endpoint/powershell_4104_hunting.yml +++ b/detections/endpoint/powershell_4104_hunting.yml @@ -66,6 +66,7 @@ tags: - Flax Typhoon - CISA AA23-347A - Data Destruction + - CISA AA24-241A asset_type: Endpoint confidence: 100 impact: 80 diff --git a/detections/endpoint/powershell_disable_security_monitoring.yml b/detections/endpoint/powershell_disable_security_monitoring.yml index 1cf9ea9210..2a3f2c4fec 100644 --- a/detections/endpoint/powershell_disable_security_monitoring.yml +++ b/detections/endpoint/powershell_disable_security_monitoring.yml @@ -41,6 +41,7 @@ tags: analytic_story: - Ransomware - Revil Ransomware + - CISA AA24-241A asset_type: Endpoint confidence: 50 impact: 50 diff --git a/detections/endpoint/randomly_generated_windows_service_name.yml b/detections/endpoint/randomly_generated_windows_service_name.yml index 386eae5efc..7357fda8ea 100644 --- a/detections/endpoint/randomly_generated_windows_service_name.yml +++ b/detections/endpoint/randomly_generated_windows_service_name.yml @@ -27,6 +27,7 @@ references: tags: analytic_story: - Active Directory Lateral Movement + - BlackSuit Ransomware asset_type: Endpoint confidence: 50 impact: 90 diff --git a/detections/endpoint/registry_keys_used_for_persistence.yml b/detections/endpoint/registry_keys_used_for_persistence.yml index c1bfa0cf48..6ee57a7b99 100644 --- a/detections/endpoint/registry_keys_used_for_persistence.yml +++ b/detections/endpoint/registry_keys_used_for_persistence.yml @@ -77,6 +77,7 @@ tags: - CISA AA23-347A - Snake Keylogger - MoonPeak + - BlackSuit Ransomware asset_type: Endpoint confidence: 95 impact: 80 diff --git a/detections/endpoint/rubeus_command_line_parameters.yml b/detections/endpoint/rubeus_command_line_parameters.yml index 73c9ac3726..507446ecb0 100644 --- a/detections/endpoint/rubeus_command_line_parameters.yml +++ b/detections/endpoint/rubeus_command_line_parameters.yml @@ -49,6 +49,7 @@ tags: - Active Directory Privilege Escalation - CISA AA23-347A - Active Directory Kerberos Attacks + - BlackSuit Ransomware asset_type: Endpoint confidence: 60 impact: 60 diff --git a/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml b/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml index 9f2a73434f..bb376bc6b4 100644 --- a/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml +++ b/detections/endpoint/rubeus_kerberos_ticket_exports_through_winlogon_access.yml @@ -37,6 +37,7 @@ tags: analytic_story: - CISA AA23-347A - Active Directory Kerberos Attacks + - BlackSuit Ransomware asset_type: Endpoint confidence: 60 impact: 60 diff --git a/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml b/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml index f1fe25961f..5463fe8080 100644 --- a/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml +++ b/detections/endpoint/rundll32_with_no_command_line_arguments_with_network.yml @@ -48,6 +48,7 @@ tags: - BlackByte Ransomware - PrintNightmare CVE-2021-34527 - Graceful Wipe Out Attack + - BlackSuit Ransomware asset_type: Endpoint confidence: 100 cve: diff --git a/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml b/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml index d54251bb8d..1cfac44126 100644 --- a/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml +++ b/detections/endpoint/scheduled_task_deleted_or_created_via_cmd.yml @@ -64,6 +64,7 @@ tags: - Phemedrone Stealer - ShrinkLocker - MoonPeak + - CISA AA24-241A asset_type: Endpoint confidence: 80 impact: 70 diff --git a/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml b/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml index 46b3ca408b..7d0fe2ce97 100644 --- a/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml +++ b/detections/endpoint/suspicious_scheduled_task_from_public_directory.yml @@ -50,6 +50,7 @@ tags: - DarkCrystal RAT - CISA AA23-347A - MoonPeak + - CISA AA24-241A asset_type: Endpoint confidence: 50 impact: 70 diff --git a/detections/endpoint/system_information_discovery_detection.yml b/detections/endpoint/system_information_discovery_detection.yml index d2fcf549d3..4c6dcab962 100644 --- a/detections/endpoint/system_information_discovery_detection.yml +++ b/detections/endpoint/system_information_discovery_detection.yml @@ -41,6 +41,7 @@ tags: analytic_story: - Windows Discovery Techniques - Gozi Malware + - BlackSuit Ransomware asset_type: Windows confidence: 50 impact: 30 diff --git a/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml b/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml index edc7472aa2..acb78c8790 100644 --- a/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml +++ b/detections/endpoint/unknown_process_using_the_kerberos_protocol.yml @@ -40,6 +40,7 @@ references: tags: analytic_story: - Active Directory Kerberos Attacks + - BlackSuit Ransomware asset_type: Endpoint confidence: 60 impact: 60 diff --git a/detections/endpoint/windows_abused_web_services.yml b/detections/endpoint/windows_abused_web_services.yml index 1095d267ba..e4c75832e0 100644 --- a/detections/endpoint/windows_abused_web_services.yml +++ b/detections/endpoint/windows_abused_web_services.yml @@ -29,6 +29,7 @@ references: tags: analytic_story: - NjRAT + - CISA AA24-241A asset_type: Endpoint confidence: 60 impact: 60 diff --git a/detections/endpoint/windows_ad_abnormal_object_access_activity.yml b/detections/endpoint/windows_ad_abnormal_object_access_activity.yml index af65815e95..dc10897e5f 100644 --- a/detections/endpoint/windows_ad_abnormal_object_access_activity.yml +++ b/detections/endpoint/windows_ad_abnormal_object_access_activity.yml @@ -35,6 +35,7 @@ references: tags: analytic_story: - Active Directory Discovery + - BlackSuit Ransomware asset_type: Endpoint confidence: 50 impact: 50 diff --git a/detections/endpoint/windows_ad_privileged_object_access_activity.yml b/detections/endpoint/windows_ad_privileged_object_access_activity.yml index fde48019ed..4d4460ae65 100644 --- a/detections/endpoint/windows_ad_privileged_object_access_activity.yml +++ b/detections/endpoint/windows_ad_privileged_object_access_activity.yml @@ -40,6 +40,7 @@ references: tags: analytic_story: - Active Directory Discovery + - BlackSuit Ransomware asset_type: Endpoint confidence: 50 impact: 80 diff --git a/detections/endpoint/windows_adfind_exe.yml b/detections/endpoint/windows_adfind_exe.yml index 396269cb15..2b826ac1f4 100644 --- a/detections/endpoint/windows_adfind_exe.yml +++ b/detections/endpoint/windows_adfind_exe.yml @@ -47,6 +47,7 @@ tags: - IcedID - NOBELIUM Group - Graceful Wipe Out Attack + - BlackSuit Ransomware asset_type: Endpoint confidence: 50 impact: 50 diff --git a/detections/endpoint/windows_alternate_datastream___base64_content.yml b/detections/endpoint/windows_alternate_datastream___base64_content.yml index 5367f1dac7..e3478f69e7 100644 --- a/detections/endpoint/windows_alternate_datastream___base64_content.yml +++ b/detections/endpoint/windows_alternate_datastream___base64_content.yml @@ -49,7 +49,7 @@ tags: role: - Victim - name: user - type: User Name + type: User role: - Victim - name: file_name diff --git a/detections/endpoint/windows_alternate_datastream___executable_content.yml b/detections/endpoint/windows_alternate_datastream___executable_content.yml index fe8f8306b1..696ace7ad2 100644 --- a/detections/endpoint/windows_alternate_datastream___executable_content.yml +++ b/detections/endpoint/windows_alternate_datastream___executable_content.yml @@ -44,7 +44,7 @@ tags: role: - Victim - name: user - type: User Name + type: User role: - Victim diff --git a/detections/endpoint/windows_alternate_datastream___process_execution.yml b/detections/endpoint/windows_alternate_datastream___process_execution.yml index 87fb3f1bde..d094e9df91 100644 --- a/detections/endpoint/windows_alternate_datastream___process_execution.yml +++ b/detections/endpoint/windows_alternate_datastream___process_execution.yml @@ -49,7 +49,7 @@ tags: role: - Victim - name: user - type: User Name + type: User role: - Victim - name: process_name diff --git a/detections/endpoint/windows_create_local_account.yml b/detections/endpoint/windows_create_local_account.yml index c50b25d2b5..9e51cef468 100644 --- a/detections/endpoint/windows_create_local_account.yml +++ b/detections/endpoint/windows_create_local_account.yml @@ -30,6 +30,7 @@ references: tags: analytic_story: - Active Directory Password Spraying + - CISA AA24-241A asset_type: Endpoint confidence: 90 impact: 20 diff --git a/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml b/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml index daf4791997..2b0d48b9a9 100644 --- a/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml +++ b/detections/endpoint/windows_disable_or_modify_tools_via_taskkill.yml @@ -48,10 +48,6 @@ tags: - T1562 - T1562.001 observable: - - name: dest - type: Endpoint - role: - - Victim - name: dest type: Endpoint role: diff --git a/detections/endpoint/windows_dism_install_powershell_web_access.yml b/detections/endpoint/windows_dism_install_powershell_web_access.yml new file mode 100644 index 0000000000..a8d8e8c986 --- /dev/null +++ b/detections/endpoint/windows_dism_install_powershell_web_access.yml @@ -0,0 +1,71 @@ +name: Windows DISM Install PowerShell Web Access +id: fa6142a7-c364-4d11-9954-895dd9efb2d4 +version: 1 +date: '2024-09-03' +author: Michael Haag, Splunk +data_sources: +- Windows Event Log Security 4688 +- Sysmon EventID 1 +type: TTP +status: production +description: The following analytic detects the installation of PowerShell Web Access using the Deployment Image Servicing and Management (DISM) tool. It leverages Sysmon Event ID 1 to identify the execution of `dism.exe` with specific parameters related to enabling the WindowsPowerShellWebAccess feature. This activity is significant because enabling PowerShell Web Access can facilitate remote execution of PowerShell commands, potentially allowing an attacker to gain unauthorized access to systems and networks. If confirmed malicious, this action could lead to further exploitation and compromise of the affected system. +search: ' | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime + from datamodel=Endpoint.Processes + where Processes.process_name=dism.exe + (Processes.process="*WindowsPowerShellWebAccess*" AND Processes.process="*/online*" AND Processes.process="*/enable-feature*") + by Processes.dest Processes.user Processes.parent_process_name Processes.process_name + Processes.original_file_name Processes.process Processes.process_id Processes.parent_process_id + | `drop_dm_object_name(Processes)` + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `windows_dism_install_powershell_web_access_filter`' +how_to_implement: The detection is based on data that originates from Endpoint Detection + and Response (EDR) agents. These agents are designed to provide security-related + telemetry from the endpoints where the agent is installed. To implement this search, + you must ingest logs that contain the process GUID, process name, and parent process. + Additionally, you must ingest complete command-line executions. These logs must + be processed using the appropriate Splunk Technology Add-ons that are specific to + the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` + data model. Use the Splunk Common Information Model (CIM) to normalize the field + names and speed up the data modeling process. +known_false_positives: Administrators using the DISM tool to update and install Windows features may cause false positives that can be filtered with `windows_dism_install_powershell_web_access_filter`. +references: +- https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-241a +- https://gist.github.com/MHaggis/7e67b659af9148fa593cf2402edebb41 +tags: + analytic_story: + - CISA AA24-241A + asset_type: Endpoint + confidence: 80 + impact: 90 + message: PowerShell Web Access has been installed on $dest$. + mitre_attack_id: + - T1548.002 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - dest + - user + - parent_process_name + - process_name + - original_file_name + - process + - process_id + - parent_process_id + risk_score: 72 + security_domain: endpoint + cve: [] +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/atomic_red_team/dism_pswa_4688_windows-security.log + sourcetype: XmlWinEventLog + source: XmlWinEventLog:Security diff --git a/detections/endpoint/windows_driver_load_non_standard_path.yml b/detections/endpoint/windows_driver_load_non_standard_path.yml index 9dd0aacff0..c6585c949d 100644 --- a/detections/endpoint/windows_driver_load_non_standard_path.yml +++ b/detections/endpoint/windows_driver_load_non_standard_path.yml @@ -35,6 +35,7 @@ tags: - CISA AA22-320A - AgentTesla - BlackByte Ransomware + - BlackSuit Ransomware asset_type: Endpoint confidence: 60 impact: 60 diff --git a/detections/endpoint/windows_enable_powershell_web_access.yml b/detections/endpoint/windows_enable_powershell_web_access.yml new file mode 100644 index 0000000000..4725b38add --- /dev/null +++ b/detections/endpoint/windows_enable_powershell_web_access.yml @@ -0,0 +1,57 @@ +name: Windows Enable PowerShell Web Access +id: 175bb2de-6227-416b-9678-9b61999cd21f +version: 1 +date: '2024-09-03' +author: Michael Haag, Splunk +data_sources: + - Powershell Script Block Logging 4104 +type: TTP +status: production +description: The following analytic detects the enabling of PowerShell Web Access via PowerShell commands. It leverages PowerShell script block logging (EventCode 4104) to identify the execution of the `Install-WindowsFeature` cmdlet with the `WindowsPowerShellWebAccess` parameter. This activity is significant because enabling PowerShell Web Access can facilitate remote execution of PowerShell commands, potentially allowing an attacker to gain unauthorized access to systems and networks. +search: '`powershell` EventCode=4104 ScriptBlockText IN ("*Install-WindowsFeature*WindowsPowerShellWebAccess*","*Install-PswaWebApplication*","*Add-PswaAuthorizationRule*UserName *ComputerName *") + | rename Computer as dest + | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText dest UserID + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `windows_enable_powershell_web_access_filter`' +how_to_implement: To successfully implement this analytic, you will need to enable + PowerShell Script Block Logging on some or all endpoints. Additional setup here + https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell. +known_false_positives: It is possible that legitimate scripts or network administrators + may enable PowerShell Web Access. Monitor and escalate as needed. +references: +- https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-241a +- https://gist.github.com/MHaggis/7e67b659af9148fa593cf2402edebb41 +tags: + analytic_story: + - CISA AA24-241A + - Malicious PowerShell + asset_type: Endpoint + confidence: 80 + impact: 90 + message: PowerShell Web Access has been enabled on $dest$. + mitre_attack_id: + - T1059.001 + observable: + - name: dest + type: Endpoint + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + required_fields: + - _time + - EventCode + - ScriptBlockText + - dest + - UserID + risk_score: 72 + security_domain: endpoint + cve: [] +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1059.001/powershell_script_block_logging/pswa_powershell.log + sourcetype: XmlWinEventLog + source: XmlWinEventLog:Microsoft-Windows-PowerShell/Operational diff --git a/detections/endpoint/windows_modify_registry_delete_firewall_rules.yml b/detections/endpoint/windows_modify_registry_delete_firewall_rules.yml index 6cd4fdb20c..b8f2bb0b9b 100644 --- a/detections/endpoint/windows_modify_registry_delete_firewall_rules.yml +++ b/detections/endpoint/windows_modify_registry_delete_firewall_rules.yml @@ -28,6 +28,7 @@ references: tags: analytic_story: - ShrinkLocker + - CISA AA24-241A asset_type: Endpoint confidence: 80 impact: 80 diff --git a/detections/endpoint/windows_modify_registry_to_add_or_modify_firewall_rule.yml b/detections/endpoint/windows_modify_registry_to_add_or_modify_firewall_rule.yml index e55a319353..7aecc13f3f 100644 --- a/detections/endpoint/windows_modify_registry_to_add_or_modify_firewall_rule.yml +++ b/detections/endpoint/windows_modify_registry_to_add_or_modify_firewall_rule.yml @@ -32,6 +32,7 @@ references: tags: analytic_story: - ShrinkLocker + - CISA AA24-241A asset_type: Endpoint confidence: 50 impact: 50 diff --git a/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml b/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml index 8b541cebe7..8bd35aefa4 100644 --- a/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml +++ b/detections/endpoint/windows_ngrok_reverse_proxy_usage.yml @@ -40,6 +40,7 @@ tags: analytic_story: - Reverse Network Proxy - CISA AA22-320A + - CISA AA24-241A asset_type: Endpoint confidence: 100 impact: 50 diff --git a/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml b/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml index 8320268295..a398762d0a 100644 --- a/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml +++ b/detections/endpoint/windows_privilege_escalation_suspicious_process_elevation.yml @@ -56,6 +56,7 @@ references: tags: analytic_story: - Windows Privilege Escalation + - BlackSuit Ransomware asset_type: Endpoint confidence: 40 impact: 100 diff --git a/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml b/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml index a879e325d8..7b8699af27 100644 --- a/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml +++ b/detections/endpoint/windows_privilege_escalation_system_process_without_system_parent.yml @@ -35,6 +35,7 @@ references: tags: analytic_story: - Windows Privilege Escalation + - BlackSuit Ransomware asset_type: Endpoint confidence: 80 impact: 100 diff --git a/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml b/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml index 801c75f46e..fb32f8c1c2 100644 --- a/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml +++ b/detections/endpoint/windows_privilege_escalation_user_process_spawn_system_process.yml @@ -50,6 +50,7 @@ references: tags: analytic_story: - Windows Privilege Escalation + - BlackSuit Ransomware asset_type: Endpoint confidence: 80 impact: 100 diff --git a/detections/endpoint/windows_remote_create_service.yml b/detections/endpoint/windows_remote_create_service.yml index 7df5ea8be0..60b313f4bd 100644 --- a/detections/endpoint/windows_remote_create_service.yml +++ b/detections/endpoint/windows_remote_create_service.yml @@ -40,6 +40,7 @@ tags: analytic_story: - Active Directory Lateral Movement - CISA AA23-347A + - BlackSuit Ransomware asset_type: Endpoint confidence: 50 impact: 50 diff --git a/detections/endpoint/windows_remote_services_rdp_enable.yml b/detections/endpoint/windows_remote_services_rdp_enable.yml index 4d62b4d31a..190d6aa77c 100644 --- a/detections/endpoint/windows_remote_services_rdp_enable.yml +++ b/detections/endpoint/windows_remote_services_rdp_enable.yml @@ -33,6 +33,7 @@ references: tags: analytic_story: - Azorult + - BlackSuit Ransomware asset_type: Endpoint confidence: 70 impact: 70 diff --git a/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml b/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml index 043391f020..36293207a7 100644 --- a/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml +++ b/detections/endpoint/windows_uac_bypass_suspicious_child_process.yml @@ -54,7 +54,7 @@ tags: role: - Victim - name: user - type: User Name + type: User role: - Victim - name: process_name diff --git a/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml b/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml index e52844bd6f..e661bb5fd5 100644 --- a/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml +++ b/detections/endpoint/windows_uac_bypass_suspicious_escalation_behavior.yml @@ -66,7 +66,7 @@ tags: role: - Victim - name: user - type: User Name + type: User role: - Victim - name: process_name diff --git a/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml b/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml index a30da724a5..88fa866077 100644 --- a/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml +++ b/detections/endpoint/winevent_windows_task_scheduler_event_action_started.yml @@ -44,6 +44,8 @@ tags: - Data Destruction - Amadey - Scheduled Tasks + - CISA AA24-241A + - BlackSuit Ransomware asset_type: Endpoint confidence: 100 impact: 80 diff --git a/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml b/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml index 2d595d3285..9e44ff5ded 100644 --- a/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml +++ b/detections/endpoint/wsmprovhost_lolbas_execution_process_spawn.yml @@ -51,6 +51,7 @@ references: tags: analytic_story: - Active Directory Lateral Movement + - CISA AA24-241A asset_type: Endpoint confidence: 60 impact: 90 diff --git a/detections/network/detect_remote_access_software_usage_dns.yml b/detections/network/detect_remote_access_software_usage_dns.yml index a48285b7ee..ca583ad547 100644 --- a/detections/network/detect_remote_access_software_usage_dns.yml +++ b/detections/network/detect_remote_access_software_usage_dns.yml @@ -36,6 +36,7 @@ tags: - Insider Threat - Command And Control - Ransomware + - CISA AA24-241A asset_type: Endpoint confidence: 20 impact: 20 diff --git a/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml b/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml index 2cb77c3b2f..e7d1485054 100644 --- a/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml +++ b/detections/network/f5_big_ip_icontrol_rest_vulnerability_cve_2022_1388.yml @@ -34,6 +34,7 @@ references: tags: analytic_story: - F5 BIG-IP Vulnerability CVE-2022-1388 + - CISA AA24-241A asset_type: Web Server confidence: 70 cve: diff --git a/detections/network/ngrok_reverse_proxy_on_network.yml b/detections/network/ngrok_reverse_proxy_on_network.yml index d1b33bc26b..a2e9843020 100644 --- a/detections/network/ngrok_reverse_proxy_on_network.yml +++ b/detections/network/ngrok_reverse_proxy_on_network.yml @@ -29,6 +29,7 @@ tags: analytic_story: - Reverse Network Proxy - CISA AA22-320A + - CISA AA24-241A asset_type: Endpoint confidence: 100 impact: 50 diff --git a/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml b/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml index 2ee10a8f52..b397568f3d 100644 --- a/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml +++ b/detections/web/access_to_vulnerable_ivanti_connect_secure_bookmark_endpoint.yml @@ -37,6 +37,7 @@ tags: - CVE-2024-21887 analytic_story: - Ivanti Connect Secure VPN Vulnerabilities + - CISA AA24-241A asset_type: VPN Appliance atomic_guid: [] confidence: 80 diff --git a/detections/web/citrix_adc_exploitation_cve_2023_3519.yml b/detections/web/citrix_adc_exploitation_cve_2023_3519.yml index a7bdea2439..1083aca874 100644 --- a/detections/web/citrix_adc_exploitation_cve_2023_3519.yml +++ b/detections/web/citrix_adc_exploitation_cve_2023_3519.yml @@ -32,6 +32,7 @@ references: tags: analytic_story: - Citrix Netscaler ADC CVE-2023-3519 + - CISA AA24-241A cve: - CVE-2023-3519 asset_type: Network diff --git a/detections/web/detect_remote_access_software_usage_url.yml b/detections/web/detect_remote_access_software_usage_url.yml index 9e20cc85a2..1b900606b3 100644 --- a/detections/web/detect_remote_access_software_usage_url.yml +++ b/detections/web/detect_remote_access_software_usage_url.yml @@ -43,6 +43,7 @@ tags: - Insider Threat - Command And Control - Ransomware + - CISA AA24-241A asset_type: Network confidence: 50 impact: 50 diff --git a/detections/web/ivanti_connect_secure_command_injection_attempts.yml b/detections/web/ivanti_connect_secure_command_injection_attempts.yml index c65d92aa41..f963215ccf 100644 --- a/detections/web/ivanti_connect_secure_command_injection_attempts.yml +++ b/detections/web/ivanti_connect_secure_command_injection_attempts.yml @@ -40,6 +40,7 @@ tags: - CVE-2024-21887 analytic_story: - Ivanti Connect Secure VPN Vulnerabilities + - CISA AA24-241A asset_type: VPN Appliance atomic_guid: [] confidence: 90 diff --git a/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml b/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml index a3724e46c5..f23dc3adc2 100644 --- a/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml +++ b/detections/web/ivanti_connect_secure_system_information_access_via_auth_bypass.yml @@ -37,6 +37,7 @@ tags: - CVE-2024-21887 analytic_story: - Ivanti Connect Secure VPN Vulnerabilities + - CISA AA24-241A asset_type: VPN Appliance atomic_guid: [] confidence: 80 diff --git a/macros/linux_auditd.yml b/macros/linux_auditd.yml new file mode 100644 index 0000000000..70ce2b76cd --- /dev/null +++ b/macros/linux_auditd.yml @@ -0,0 +1,4 @@ +definition: sourcetype="linux:audit" +description: customer specific splunk configurations(eg- index, source, sourcetype). + Replace the macro definition with configurations for your Splunk Environmnent. +name: linux_auditd \ No newline at end of file diff --git a/macros/linux_auditd_normalized_execve_process.yml b/macros/linux_auditd_normalized_execve_process.yml new file mode 100644 index 0000000000..83f885f803 --- /dev/null +++ b/macros/linux_auditd_normalized_execve_process.yml @@ -0,0 +1,4 @@ +definition: 'type=EXECVE | eval relevant_fields=if(type="EXECVE", "", relevant_fields) | foreach a* [eval relevant_fields=if(type="EXECVE", mvappend(relevant_fields, ''<>''), relevant_fields)] | eval process_exec=if(type="EXECVE", mvjoin(relevant_fields, " "), process_exec) | eval process_exec=if(type="EXECVE", trim(process_exec), process_exec)' +description: customer specific splunk configurations to normalized auditd PROCTITLE type to recover process commandline. + Replace the macro definition with configurations for your Splunk Environmnent. +name: linux_auditd_normalized_execve_process \ No newline at end of file diff --git a/macros/linux_auditd_normalized_proctitle_process.yml b/macros/linux_auditd_normalized_proctitle_process.yml new file mode 100644 index 0000000000..999b133614 --- /dev/null +++ b/macros/linux_auditd_normalized_proctitle_process.yml @@ -0,0 +1,6 @@ +definition: 'type=PROCTITLE | eval normalized_proctitle_delimiter = if(type=="PROCTITLE" AND isnotnull(proctitle), if(match(proctitle,"^[0-9A-F]+$"), replace(proctitle, "000", "020"),proctitle),null()) + | eval normalized_proctitle_delimiter = if(type=="PROCTITLE" AND isnotnull(proctitle), if(match(normalized_proctitle_delimiter,"^[0-9A-F]+$"), replace(normalized_proctitle_delimiter, "00", "20"),normalized_proctitle_delimiter),null()) + | eval process_exec = if(match(normalized_proctitle_delimiter,"^[0-9A-F]+$"),urldecode(replace(normalized_proctitle_delimiter,"([0-9A-F]{2})","%\1")),normalized_proctitle_delimiter)' +description: customer specific splunk configurations to normalized auditd PROCTITLE type to recover process commandline. + Replace the macro definition with configurations for your Splunk Environmnent. +name: linux_auditd_normalized_proctitle_process \ No newline at end of file diff --git a/stories/blacksuit_ransomware.yml b/stories/blacksuit_ransomware.yml new file mode 100644 index 0000000000..836f605316 --- /dev/null +++ b/stories/blacksuit_ransomware.yml @@ -0,0 +1,25 @@ +name: BlackSuit Ransomware +id: 4c7bef12-679f-433c-92dd-d9feccc1432b +version: 1 +date: '2024-08-26' +author: Michael Haag, Splunk +description: This analytic story covers the tactics, techniques, and procedures (TTPs) associated with BlackSuit ransomware, as observed in a December 2023 intrusion. The story encompasses the full attack lifecycle, from initial access via Cobalt Strike beacons to lateral movement, credential access, and ultimately the deployment of BlackSuit ransomware. It aims to help security teams detect and respond to similar attacks by focusing on key behaviors such as Cobalt Strike activity, use of tools like ADFind and Sharphound, and the final ransomware deployment phase. +narrative: In December 2023, a sophisticated intrusion culminating in the deployment of BlackSuit ransomware was observed. The attack began with the execution of a Cobalt Strike beacon, which initially communicated through CloudFlare to conceal the true C2 server. The threat actors leveraged various tools throughout the intrusion, including Sharphound, Rubeus, SystemBC, and ADFind, alongside built-in Windows utilities. + + The attackers conducted extensive reconnaissance and lateral movement, using techniques such as AS-REP Roasting, Kerberoasting, and accessing LSASS memory for credential theft. They deployed multiple Cobalt Strike beacons across the environment and utilized RDP for further lateral movement. SystemBC was employed on a file server, providing additional command and control capabilities and proxy functionality. + + After a period of intermittent activity spanning 15 days, the threat actors executed their final objective. They used ADFind for additional discovery, ran the Get-DataInfo.ps1 PowerShell script to gather system information, and ultimately deployed the BlackSuit ransomware. The ransomware binary (qwe.exe) was distributed via SMB to remote systems through admin shares, and executed manually via RDP sessions. Upon execution, the ransomware deleted shadow copies before encrypting files across the compromised systems. + + This analytic story provides detections for various stages of this attack, including Cobalt Strike beacon activity, use of reconnaissance tools, suspicious PowerShell executions, and indicators of ransomware deployment. By monitoring for these behaviors, security teams can potentially detect and mitigate BlackSuit ransomware attacks before they reach their final, destructive stage. + +references: + - https://thedfirreport.com/2024/08/26/blacksuit-ransomware/ +tags: + category: + - Adversary Tactics + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + usecase: Advanced Threat Detection + cve: [] \ No newline at end of file diff --git a/stories/cisa_aa24_241a.yml b/stories/cisa_aa24_241a.yml new file mode 100644 index 0000000000..63f341a44f --- /dev/null +++ b/stories/cisa_aa24_241a.yml @@ -0,0 +1,25 @@ +name: CISA AA24-241A +id: f075adb6-76a6-4476-b24a-ce9d471a1bdc +version: 1 +date: '2024-09-03' +author: Michael Haag, Splunk +description: This story covers the tactics of Iran-based cyber actors exploiting U.S. and foreign organizations across multiple sectors, as detailed in CISA Alert AA24-241A. It focuses on their methods of gaining initial access, establishing persistence, and enabling ransomware attacks through vulnerabilities in public-facing networking devices. +narrative: As of August 2024, Iran-based cyber actors continue to exploit organizations across several U.S. sectors and other countries. The FBI assesses that a significant percentage of these operations aim to obtain network access for collaboration with ransomware affiliates. The actors typically use Shodan to identify vulnerable devices, then exploit public-facing networking equipment such as Citrix Netscaler, F5 BIG-IP, and various VPNs. They deploy webshells, create local accounts, and manipulate existing ones to maintain access. Post-exploitation, they repurpose credentials, disable security software, and use remote access tools. The group collaborates with ransomware affiliates like NoEscape, Ransomhouse, and ALPHV, actively participating in network lockdowns and extortion strategies. Defenders should prioritize patching public-facing devices, monitoring for unauthorized accounts and suspicious PowerShell activity, implementing strong access controls, and regularly reviewing logs for signs of compromise. +references: + - https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-241a + - https://gist.github.com/MHaggis/7e67b659af9148fa593cf2402edebb41 +tags: + category: + - Adversary Tactics + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + usecase: Advanced Threat Detection + cve: + - CVE-2024-24919 + - CVE-2024-3400 + - CVE-2019-19781 + - CVE-2023-3519 + - CVE-2022-1388 + - CVE-2024-21887 \ No newline at end of file diff --git a/stories/compromised_linux_host.yml b/stories/compromised_linux_host.yml new file mode 100644 index 0000000000..7e2902252e --- /dev/null +++ b/stories/compromised_linux_host.yml @@ -0,0 +1,25 @@ +name: Compromised Linux Host +id: d7ea2fc0-3710-4257-b64f-f3c2a6abebd3 +version: 1 +date: '2024-06-25' +author: Teoderick Contreras, Splunk +description: Monitor for activities and techniques associated with Compromised Linux Host attacks. + These include unauthorized access attempts, unusual network traffic patterns, and the presence of + unknown or suspicious processes. Look for unexpected changes in system files, modifications to configuration files, + and the installation of unrecognized software. Pay attention to abnormal resource usage, such as high CPU or memory + consumption. Regularly review logs for signs of privilege escalation or lateral movement, and ensure integrity checks + are in place to detect tampering with critical system components. +narrative: In a tale of digital intrusion, Imagine a system administrator noticing unexpected spikes in network traffic and CPU usage. + Delving deeper, they find unknown processes running and unfamiliar software installed. System files and configurations show + unauthorized modifications, hinting at privilege escalation. Log reviews reveal attempts at lateral movement across the network. + The administrator's vigilance, combined with regular integrity checks, helps uncover and mitigate the threat. This narrative + underscores the importance of monitoring and swift action in maintaining a secure Linux environment. +references: [] +tags: + category: + - Adversary Tactics + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + usecase: Advanced Threat Detection \ No newline at end of file