admin/splunk-security_content
1
0
Fork 0
mirror of https://github.com/splunk/security_content synced 2026-06-08 17:32:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'develop' into typo-non_chrome_process_accessing_chrome_default_dir

Browse Source
This commit is contained in:
Bhavin Patel
2024-07-10 14:19:17 -07:00
committed by GitHub
parent 4d715410d0 0dda1b68d9
commit d96865b7e9
1835 changed files with 37333 additions and 59471 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/validate-and-build.yml → .github/workflows/build.yml
+7 -22
View File
@@ -1,51 +1,36 @@
name: validate-and-build
name: build
on:
push:
pull_request:
types: [opened, reopened]
types: [opened, reopened, synchronize]
jobs:
validate-and-build:
build:
#Note that the CircleCI job used a Container. The way to do this with Github Actions
#is to first start up a Virtual Machine, then we can by following:
# https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer
runs-on: ubuntu-latest
steps:
- name: Check out the repository code
uses: actions/checkout@v3
uses: actions/checkout@v4
- uses: actions/setup-python@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy
architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified
- name: Install System Packages
run: |
sudo apt update -qq
sudo apt install jq -qq
- name: Install Python Dependencies and ContentCTL and Atomic Red Team
run: |
python3.11 -m venv .venv
source .venv/bin/activate
pip install contentctl
git clone --depth=1 --single-branch --branch=master https://github.com/redcanaryco/atomic-red-team.git
- name: content_ctl validate
- name: Running build with enrichments
run: |
source .venv/bin/activate
contentctl validate
- name: contentctl generate
run: |
source .venv/bin/activate
contentctl build --enrichments
mkdir artifacts
mv dist/DA-ESS-ContentUpdate-latest.tar.gz artifacts/
- name: store_artifacts
uses: actions/upload-artifact@v3
uses: actions/upload-artifact@v4
with:
name: content-latest
path: |
.github/workflows/detection-testing.yml
-347
View File
@@ -1,347 +0,0 @@
# name: detection-testing
# on:
# push:
# pull_request:
# types: [opened, reopened]
# schedule:
# - cron: "44 4 * * *"
# jobs:
# validate-tag-if-present:
# runs-on: ubuntu-latest
# steps:
# - name: TAGGED, Validate that the tag is in the correct format
# run: |
# echo "The GITHUB_REF: $GITHUB_REF"
# #First check to see if the release is a tag
# if [[ $GITHUB_REF =~ refs/tags/* ]]; then
# #Yes, this is a tag, so we need to test to make sure that the tag
# #is in the correct format (like v1.10.20)
# if [[ $GITHUB_REF =~ refs/tags/v[0-9]+.[0-9]+.[0-9]+ ]]; then
# echo "PASS: Tagged release with good format"
# exit 0
# else
# echo "FAIL: Tagged release with bad format"
# exit 1
# fi
# else
# echo "PASS: Not a tagged release"
# exit 0
# fi
# quit-for-dependabot:
# runs-on: ubuntu-latest
# if: github.actor != 'dependabot[bot]' && github.actor != 'dependabot-preview[bot]'
# steps:
# - name: "Placeholder"
# run: |
# echo "yes it ran"
# docker-detection-testing-setup:
# runs-on: ubuntu-latest
# if: "!contains(github.ref, 'refs/tags/')" #don't run on tags - future steps won't run either since they depend on this job
# needs: [validate-tag-if-present, quit-for-dependabot]
# steps:
# - name: Get branch and PR required for detection testing main.py
# id: vars
# run: |
# echo "::set-output name=branch::${GITHUB_REF#refs/heads/}"
# - name: Checkout Repo
# uses: actions/checkout@v2
# #with:
# # ref: develop
# - uses: actions/setup-python@v2
# with:
# python-version: '3.9' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy
# architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified
# cache: 'pip'
# - name: Install Python Dependencies
# run: |
# python -m venv .venv
# source .venv/bin/activate
# python -m pip install wheel
# python -m pip install -r requirements.txt
# - name: Run the CI
# run: |
# source .venv/bin/activate
# cd bin/docker_detection_tester
# echo "github.event.issue.pull_request : [${{ github.event.issue.pull_request }}]"
# echo "github.event.pull_request.number : [${{ github.event.pull_request.number }}]"
# echo "steps.vars.outputs.branch : [${{ steps.vars.outputs.branch }}]"
# echo "github.event.pull_request.head.ref : [${{ github.event.pull_request.head.ref }}]"
# echo "github.event_name : [${{ github.event_name }}]"
# if [[ ${{ github.event_name }} == schedule ]]; then
# # Note that scheduled actions ONLY run on the default branch, so it won't run on all other branches!
# echo "Running a nightly test on all detections OR a commit was made directly to develop"
# python detection_testing_execution.py run --branch develop --mode all --mock --config_file test_config_github_actions.json
# elif [[ ! -z "${{ github.event.pull_request.head.ref }}" && ! -z "${{ github.event.pull_request.number }}" ]]; then
# echo "Pull request from source branch [${{ github.event.pull_request.head.ref }}] for PR number [${{ github.event.issue.number }}]"
# python detection_testing_execution.py run --branch ${{ github.event.pull_request.head.ref }} --pr_number ${{ github.event.pull_request.number }} --mode changes --mock --config_file test_config_github_actions.json
# else
# echo "Push from branch [${{ steps.vars.outputs.branch }}]"
# python detection_testing_execution.py run --branch ${{ steps.vars.outputs.branch }} --mode changes --mock --config_file test_config_github_actions.json
# fi
# mv *-test-run.json replicate_test.json
# - name: Upload Test Results Files
# uses: actions/upload-artifact@v2
# with:
# name: testing-results-config
# path: |
# bin/docker_detection_tester/prior_config/apps/DA-ESS-ContentUpdate-latest.tar.gz
# bin/docker_detection_tester/prior_config/config_tests_0.json
# bin/docker_detection_tester/prior_config/config_tests_1.json
# bin/docker_detection_tester/prior_config/config_tests_2.json
# bin/docker_detection_tester/prior_config/config_tests_3.json
# bin/docker_detection_tester/prior_config/config_tests_4.json
# bin/docker_detection_tester/prior_config/config_tests_5.json
# bin/docker_detection_tester/prior_config/config_tests_6.json
# bin/docker_detection_tester/prior_config/config_tests_7.json
# bin/docker_detection_tester/prior_config/config_tests_8.json
# bin/docker_detection_tester/prior_config/config_tests_9.json
# - name: Upload File to Enable Replication of the Test at a Different Time or Place
# uses: actions/upload-artifact@v2
# with:
# name: replicate_test
# path: |
# bin/docker_detection_tester/replicate_test.json
# docker-detection-testing-execution:
# runs-on: ubuntu-latest
# if: "!contains(github.ref, 'refs/tags/')" #don't run on tags - future steps won't run either since they depend on this job
# needs: [docker-detection-testing-setup]
# strategy:
# matrix:
# manifest_filename: ["config_tests_0.json",
# "config_tests_1.json",
# "config_tests_2.json",
# "config_tests_3.json",
# "config_tests_4.json",
# "config_tests_5.json",
# "config_tests_6.json",
# "config_tests_7.json",
# "config_tests_8.json",
# "config_tests_9.json"]
# steps:
# - name: Get branch and PR required for detection testing main.py
# id: vars
# run: |
# echo "::set-output name=branch::${GITHUB_REF#refs/heads/}"
# - name: Checkout Repo
# uses: actions/checkout@v2
# #with:
# # ref: develop
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: testing-results-config
# path: bin/docker_detection_tester/prior_config
# - uses: actions/setup-python@v2
# with:
# python-version: '3.9' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy
# architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified
# cache: 'pip'
# - name: Install Python Dependencies
# run: |
# python -m venv .venv
# source .venv/bin/activate
# python -m pip install wheel
# python -m pip install -r requirements.txt
# - name: Run the CI
# run: |
# source .venv/bin/activate
# cd bin/docker_detection_tester
# python detection_testing_execution.py run -c prior_config/${{ matrix.manifest_filename}}
# - name: Upload Test Results Files
# uses: actions/upload-artifact@v2
# with:
# name: ${{ matrix.manifest_filename}}.results
# path: |
# bin/docker_detection_tester/test_results/success.csv
# bin/docker_detection_tester/test_results/error.csv
# bin/docker_detection_tester/test_results/failure.csv
# bin/docker_detection_tester/test_results/combined.csv
# bin/docker_detection_tester/test_results/success.json
# bin/docker_detection_tester/test_results/error.json
# bin/docker_detection_tester/test_results/failure.json
# bin/docker_detection_tester/test_results/combined.json
# bin/docker_detection_tester/test_results/summary.json
# docker-detection-testing-execution-merge-results:
# runs-on: ubuntu-latest
# if: "!contains(github.ref, 'refs/tags/')" #don't run on tags - future steps won't run either since they depend on this job
# needs: [docker-detection-testing-setup, docker-detection-testing-execution]
# steps:
# - name: Get branch and PR required for detection testing main.py
# id: vars
# run: |
# echo "::set-output name=branch::${GITHUB_REF#refs/heads/}"
# - name: Checkout Repo
# uses: actions/checkout@v2
# #with:
# # ref: develop
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_0.json.results
# path: bin/docker_detection_tester/results_0
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_1.json.results
# path: bin/docker_detection_tester/results_1
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_2.json.results
# path: bin/docker_detection_tester/results_2
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_3.json.results
# path: bin/docker_detection_tester/results_3
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_4.json.results
# path: bin/docker_detection_tester/results_4
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_5.json.results
# path: bin/docker_detection_tester/results_5
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_6.json.results
# path: bin/docker_detection_tester/results_6
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_7.json.results
# path: bin/docker_detection_tester/results_7
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_8.json.results
# path: bin/docker_detection_tester/results_8
# - name: Download artifacts
# uses: actions/download-artifact@v2
# with:
# name: config_tests_9.json.results
# path: bin/docker_detection_tester/results_9
# - uses: actions/setup-python@v2
# with:
# python-version: '3.9' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy
# architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified
# cache: 'pip'
# - name: Install Python Dependencies
# run: |
# python -m venv .venv
# source .venv/bin/activate
# python -m pip install wheel
# python -m pip install -r requirements.txt
# - name: Merge Detections into single File
# run: |
# source .venv/bin/activate
# cd bin/docker_detection_tester
# python summarize_json.py --files results_*/summary.json --output_filename summary_test_results.json
# - name: Upload Summary Test Results JSON
# uses: actions/upload-artifact@v2
# if: always()
# with:
# name: SummaryTestResults
# path: |
# bin/docker_detection_tester/summary_test_results.json
# - name: Upload Failures Manifest on Failure
# uses: actions/upload-artifact@v2
# if: failure()
# with:
# name: DetectionFailureManifest
# path: |
# bin/docker_detection_tester/detection_failure_manifest.json
# #Always clean these up, they make the output messy
# - name: Clean up intermediate Files
# uses: geekyeggo/delete-artifact@v1
# if: always()
# with:
# name: |
# config_tests_0.json.results
# config_tests_1.json.results
# config_tests_2.json.results
# config_tests_3.json.results
# config_tests_4.json.results
# config_tests_5.json.results
# config_tests_6.json.results
# config_tests_7.json.results
# config_tests_8.json.results
# config_tests_9.json.results
# - name: Log in to S3 for Artifact Uploads
# if: ${{ github.event_name == 'schedule' }}
# uses: aws-actions/configure-aws-credentials@v1
# with:
# aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
# aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
# aws-region: us-west-2
# - name: Upload S3 Badge and Summary Artifacts for Nightly Scheduled Run
# if: ${{ github.event_name == 'schedule' }}
# run: |
# cd bin/docker_detection_tester
# python generate_detection_coverage_badge.py --input_summary_file summary_test_results.json --output_badge_file detection_coverage.svg --badge_string "Pass Rate"
# #Upload artifact (summary test results)
# aws s3 cp summary_test_results.json s3://security-content/reporting/summary_test_results.json
# #Since these reside in a public bucket, no need to explicitly mark as public
# # make the file public since it is not by default
# #aws s3api put-object-acl --bucket security-content --key reporting/summary_test_results.json --acl public-read
# #Upload artifact (test results coverage badge)
# aws s3 cp detection_coverage.svg s3://security-content/reporting/detection_coverage.svg
# #Since these reside in a public bucket, no need to explicitly mark as public
# # make the file public since it is not by default
# #aws s3api put-object-acl --bucket security-content --key reporting/detection_coverage.svg --acl public-read
.github/workflows/format_test_results.py
+67
View File
@@ -0,0 +1,67 @@
"""
A simple script formatting test_results/summary.yml to display on github actions
"""
import yaml
import re
import os
import sys
def main():
# Define the path to the YAML file
# yaml_file_path = 'summary.yml'
yaml_file_path = '/home/runner/work/security_content/security_content/test_results/summary.yml'
# Check if the YAML file exists
if not os.path.exists(yaml_file_path):
print(f"Error: The file {yaml_file_path} does not exist.")
exit(1) # Exit with an error code
# Load the YAML file
with open(yaml_file_path, 'r') as file:
data = yaml.safe_load(file)
# Extract total_fail value and debug print it
total_fail = data['summary']['total_fail']
total_detections = data['summary']['total_detections']
print("**Download the job artifacts of this run and view complete summary in test_results/summary.yml for troubleshooting failures.**\n")
print(" 📝 **Experimental or manual_test detections are not tested** 📝 **\n")
print(f"Extracted total_fail: [{total_fail}]\n")
# Print all unit test details first
print(" 🏗️⚒️ **Unit Test Details:**\n")
print(f"{'Name':<80} | {'Status':<6} | {'Test Type':<10} | {'Exception':<50}")
print(f"{'----':<80} | {'------':<6} | {'---------':<10} | {'---------':<50}")
for detection in data['tested_detections']:
for test in detection['tests']:
if test['test_type'].strip() == "unit": # Check if the test type is "unit"
name = detection['name'].strip()
status = 'PASS' if test['success'] else 'FAIL'
test_type = test['test_type'].strip()
exception = test.get('exception', 'N/A') # Get exception if exists, else 'N/A'
if status == 'FAIL':
print(f"{name:<80} | 🔴 {status:<6} | {test_type:<10} | {exception:<50}")
else:
print(f"{name:<80} | 🟢 {status:<6} | {test_type:<10} | {'-':<50}")
# Print table footer
# print(f"{'----':<80} | {'------':<6} | {'---------':<10} | {'---------':<50}")
# Check if total_fail is a valid integer and greater than or equal to one
print("\n") # Print a newline for separation
print("**Overall Status**")
print("-------------------------------")
# Continue with additional prints or other logic
if int(total_fail) >=1:
# Print the message in bold
print("🔴 - **CI Failure: There are failed tests.**\n\n")
sys.exit(1)
if int(total_fail) < 1:
print("🟢 - **CI Success: No failed tests.**\n\n")
sys.exit(0)
if int(total_detections) < 1:
print("🔵 - **CI Success: No detections to test**\n\n")
sys.exit(0)
if __name__ == "__main__":
main()
.github/workflows/unit-testing.yml
+68
View File
@@ -0,0 +1,68 @@
name: unit-testing
on:
pull_request:
types: [opened, reopened, synchronize]
jobs:
unit-testing:
runs-on: ubuntu-latest
if: "!contains(github.ref, 'refs/tags/')" #don't run on tags - future steps won't run either since they depend on this job
# needs: [validate-tag-if-present, quit-for-dependabot]
steps:
#For fork PRs, always check out security_content and the PR target in security content!
- name: Check out the repository code
uses: actions/checkout@v4
with:
repository: 'splunk/security_content' #this should be the TARGET repo of the PR. we hardcode it for now
ref: ${{ github.base_ref }}
- uses: actions/setup-python@v5
with:
python-version: '3.11' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy
architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified
- name: Install Python Dependencies and ContentCTL
run: |
python -m pip install --upgrade pip
pip install contentctl
# Running contentctl test with a few arguments, before running the command make sure you checkout into the current branch of the pull request. This step only performs unit testing on all the changes against the target-branch. In most cases this target branch will be develop
# Make sure we check out the PR, even if it actually lives in a fork
# Instructions for pulling a PR were taken from:
# https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
- name: Run ContentCTL test for changes against target branch
run: |
echo "Current Branch (Head Ref): ${{ github.head_ref }}"
echo "Target Branch (Base Ref): ${{ github.base_ref }}"
git pull > /dev/null 2>&1
git fetch origin pull/${{ github.event.pull_request.number }}/head:${{ github.head_ref }}
#We must specifically get the PR's target branch from security_content, not the one that resides in the fork PR's forked repo
git switch ${{ github.head_ref }}
#git checkout ${{ github.head_ref }}
#echo "The target branch for this PR is ${{ github.base_ref }}"
contentctl test --disable-tqdm --no-enable-integration-testing --post-test-behavior never_pause mode:changes --mode.target-branch ${{ github.base_ref }}
echo "contentctl test - COMPLETED"
continue-on-error: true
# Store test_results/summary.yml and dist/DA-ESS-ContentUpdate-latest.tar.gz to job artifact-test_summary_results.zip
- name: store_artifacts
uses: actions/upload-artifact@v4
with:
name: test_summary_results
path: |
test_results/summary.yml
dist/DA-ESS-ContentUpdate-latest.tar.gz
continue-on-error: true
# Print entire result summary so that the users can view it in the Github Actions logs
- name: Print entire test_results/summary.yml
run: cat test_results/summary.yml
continue-on-error: true
# Run a simple custom script created to pretty print results in a markdown friendly format in Github Actions Summary
- name: Check the test_results/summary.yml for pass/fail.
run: |
echo "This job will fail if there are failures in unit-testing"
python .github/workflows/format_test_results.py >> $GITHUB_STEP_SUMMARY
echo "The Unit testing is completed. See details in the unit-testing job summary UI "
app_template/default/data/ui/views/escu_summary.xml
+7 -1
View File
@@ -22,7 +22,13 @@
<row>
<panel>
<html>
<h2 style="color:red">Explore the Analytic Stories included with Splunk Security via <a href="https://www.splunk.com/en_us/resources/videos/splunk-enterprise-security-use-case-library.html">ES Use Case Library</a> or <a href="https://splunkbase.splunk.com/app/3435/">Splunk Security Essentials</a>.</h2>
<div style="background-color: #f8d7da; border: 1px solid #f5c6cb; border-radius: 5px; padding: 15px; margin-bottom: 20px;">
<h2 style="color: #721c24; margin: 0;">
<i class="icon-info-circle" style="margin-right: 10px;"></i>
Explore Splunk Security Content using
<a href="/app/SplunkEnterpriseSecuritySuite/ess_use_case_library" style="color: #721c24; text-decoration: underline;">Splunk Enterprise Security</a>
</h2>
</div>
</html>
</panel>
</row>
app_template/default/distsearch.conf
+1 -1
View File
@@ -1,5 +1,5 @@
[replicationSettings:refineConf]
replicate.analytic_stories = false
[replicationBlacklist]
[replicationDenylist]
excludeESCU = apps[/\\]DA-ESS-ContentUpdate[/\\]lookups[/\\]...
baselines/deprecated/baseline_of_excessive_aws_instances_launched_by_user___mltk.yml
+1 -1
View File
@@ -10,7 +10,7 @@ description: This search is used to build a Machine Learning Toolkit (MLTK) mode
the last 90 days of data to build the model. The model created by this search is
then used in the corresponding detection search, which identifies subsequent outliers
in the number of RunInstances performed by a user in a small time window.
search: '`cloudtrail` eventName=RunInstances errorCode=success `ec2_excessive_runinstances_mltk_input_filter`
search: '`cloudtrail` eventName=RunInstances errorCode=success
| bucket span=10m _time | stats count as instances_launched by _time src_user |
fit DensityFunction instances_launched threshold=0.0005 into ec2_excessive_runinstances_v1'
how_to_implement: 'You must install the AWS App for Splunk (version 5.1.0 or later)
baselines/deprecated/baseline_of_excessive_aws_instances_terminated_by_user___mltk.yml
+1 -1
View File
@@ -11,7 +11,7 @@ description: This search is used to build a Machine Learning Toolkit (MLTK) mode
is then used in the corresponding detection search, which identifies subsequent
outliers in the number of TerminateInstances performed by a user in a small time
window.
search: '`cloudtrail` eventName=TerminateInstances errorCode=success `ec2_excessive_terminateinstances_mltk_input_filter`
search: '`cloudtrail` eventName=TerminateInstances errorCode=success
| bucket span=10m _time | stats count as instances_terminated by _time src_user
| fit DensityFunction instances_terminated threshold=0.0005 into ec2_excessive_terminateinstances_v1'
how_to_implement: 'You must install the AWS App for Splunk (version 5.1.0 or later)
contentctl.yml
+7 -7
View File
@@ -3,7 +3,7 @@ app:
uid: 3449
title: ES Content Updates
appid: DA-ESS-ContentUpdate
version: 4.33.0
version: 4.35.0
description: Explore the Analytic Stories included with ES Content Updates.
prefix: ESCU
label: ESCU
@@ -13,7 +13,7 @@ app:
enrichments: false
build_app: true
build_api: true
build_ssa: true
build_ssa: false
build_path: dist
test_instance:
splunk_app_username: admin
@@ -47,12 +47,12 @@ apps:
version: 2.2.0
description: description of app
hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-okta-identity-cloud_220.tgz
- uid: 6176
- uid: 6652
title: Add-on for Linux Sysmon
appid: Splunk_TA_linux_sysmon
version: 1.0.4
version: 1.0.0
description: description of app
hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/add-on-for-linux-sysmon_104.tgz
hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/splunk-add-on-for-sysmon-for-linux_100.tgz
- uid: null
title: Splunk Fix XmlWinEventLog HEC Parsing
appid: Splunk_FIX_XMLWINEVENTLOG_HEC_PARSING
@@ -71,9 +71,9 @@ apps:
- uid: 5709
title: Splunk Add-on for Sysmon
appid: Splunk_TA_microsoft_sysmon
version: 4.0.0
version: 4.0.1
description: description of app
hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-sysmon_400.tgz
hardcoded_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-sysmon_401.tgz
- uid: 833
title: Splunk Add-on for Unix and Linux
appid: Splunk_TA_nix
data_sources/endpoint/Sysmon_for_Linux_EventID.yml
+1 -1
View File
@@ -2,7 +2,7 @@ name: Sysmon for Linux EventID
id: da9fc0c9-4b15-4537-aa91-19ca0cb1eba5
author: Patrick Bareiss, Splunk
source: Syslog:Linux-Sysmon/Operational
sourcetype: sysmon_linux
sourcetype: sysmon:linux
separator: EventID
supported_TA:
name: Splunk Add-on for Sysmon for Linux
data_sources/endpoint/Windows_Event_Log_Security.yml
+1 -1
View File
@@ -1,7 +1,7 @@
name: Windows Event Log Security
id: e3e44de1-57b1-462d-b57c-c7657af7ae6e
author: Patrick Bareiss, Splunk
source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
source: XmlWinEventLog:Security
sourcetype: xmlwineventlog
separator: EventCode
supported_TA:
data_sources/endpoint/event_sources/Windows_Event_Log_Security_5145.yml
+4 -2
View File
@@ -91,18 +91,20 @@ field_mappings:
AccessList: access_list
AccessMask: access_mask
AccessReason: access_result
ShareLocalPath: share_local_path
RelativeTargetName: relative_target_name
ObjectType: object_type
IpAddress: src_ip
IpPort: src_port
SubjectDomainName: user_domain
SubjectUserName: user
SubjectLogonId: user_logon_id
SubjectUserSid: user_sid
ShareName: share
- data_model: ocsf
mapping:
AccessList: access_list
AccessMask: access_mask
AccessReason: access_result
ShareLocalPath: file.path
RelativeTargetName: file.path
ObjectType: file.type
IpAddress: src_endpoint.ip
detections/application/detect_risky_spl_using_pretrained_ml_model.yml
+11 -11
View File
@@ -1,18 +1,17 @@
name: Detect Risky SPL using Pretrained ML Model
id: b4aefb5f-1037-410d-a149-1e091288ba33
version: 1
date: '2022-06-16'
version: 2
date: '2024-05-26'
author: Abhinav Mishra, Kumar Sharad, Namratha Sreekanta and Xiao Lin, Splunk
status: experimental
type: Anomaly
description: The following analytic uses a pretrained machine learning text classifier
to detect potentially risky commands. The model is trained independently and then
the model file is packaged within ESCU for usage. A command is deemed risky based
on the presence of certain trigger keywords, along with the context and the role
of the user (please see references). The model uses custom features to predict whether
a SPL is risky using text classification. The model takes as input the command text,
user and search type and outputs a risk score between [0,1]. A high score indicates
higher likelihood of a command being risky. This model is on-prem only.
description: The following analytic identifies potentially risky SPL commands executed
by users. It leverages a pretrained machine learning text classifier that analyzes
command text, user, and search type to assign a risk score between 0 and 1. This
detection is significant as it helps identify suspicious or unauthorized search
activities that could indicate malicious intent or misuse of the Splunk environment.
If confirmed malicious, such activity could lead to unauthorized data access, data
exfiltration, or further exploitation of the system.
data_source: []
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Splunk_Audit.Search_Activity where Search_Activity.search_type=adhoc
@@ -62,7 +61,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt
- data:
https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt
source: audittrail
sourcetype: audittrail
update_timestamp: true
detections/application/email_files_written_outside_of_the_outlook_directory.yml
+1 -1
View File
@@ -21,7 +21,7 @@ search: '| tstats `security_content_summariesonly` count values(Filesystem.file_
!= "C:\\Users\\*\\My Documents\\Outlook Files\\*" Filesystem.file_path!="C:\\Users\\*\\AppData\\Local\\Microsoft\\Outlook*"
by Filesystem.action Filesystem.process_id Filesystem.file_name Filesystem.dest
| `drop_dm_object_name("Filesystem")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`|
`email_files_written_outside_of_the_outlook_directory_filter` '
`email_files_written_outside_of_the_outlook_directory_filter`'
how_to_implement: To successfully implement this search, you must be ingesting data
that records the file-system activity from your hosts to populate the Endpoint.Filesystem
data model node. This is typically populated via endpoint detection-and-response
detections/application/no_windows_updates_in_a_time_frame.yml
+10 -7
View File
@@ -1,15 +1,18 @@
name: No Windows Updates in a time frame
id: 1a77c08c-2f56-409c-a2d3-7d64617edd4f
version: 1
date: '2017-09-15'
version: 2
date: '2024-05-15'
author: Bhavin Patel, Splunk
status: experimental
type: Hunting
description: This search looks for Windows endpoints that have not generated an event
indicating a successful Windows update in the last 60 days. Windows updates are
typically released monthly and applied shortly thereafter. An endpoint that has
not successfully applied an update in this time frame indicates the endpoint is
not regularly being patched for some reason.
description: The following analytic identifies Windows endpoints that have not generated
an event indicating a successful Windows update in the last 60 days. It leverages
the 'Update' data model in Splunk, specifically looking for the latest 'Installed'
status events from Microsoft Windows. This activity is significant for a SOC because
endpoints that are not regularly patched are vulnerable to known exploits and security
vulnerabilities. If confirmed malicious, this could indicate a compromised endpoint
that is intentionally being kept unpatched, potentially allowing attackers to exploit
unpatched vulnerabilities and gain unauthorized access or control.
data_source: []
search: '| tstats `security_content_summariesonly` max(_time) as lastTime from datamodel=Updates
where Updates.status=Installed Updates.vendor_product="Microsoft Windows" by Updates.dest
detections/application/okta_authentication_failed_during_mfa_challenge.yml
+26 -9
View File
@@ -1,16 +1,32 @@
name: Okta Authentication Failed During MFA Challenge
id: e2b99e7d-d956-411a-a120-2b14adfdde93
version: 1
date: '2024-03-11'
version: 2
date: '2024-05-29'
author: Bhavin Patel, Splunk
data_source: []
type: TTP
status: production
description: The following analytic identifies an authentication attempt event against
an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled.
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Authentication.app) as app values(Authentication.reason) as reason values(Authentication.signature) as signature values(Authentication.method) as method from datamodel=Authentication where Authentication.signature=user.authentication.auth_via_mfa Authentication.action = failure by _time Authentication.src Authentication.user Authentication.dest Authentication.action | `drop_dm_object_name("Authentication")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| iplocation src | `okta_authentication_failed_during_mfa_challenge_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: A user may have accidentally entered the wrong credentials during the MFA challenge. If the user is new to MFA, they may have trouble authenticating. Ensure that the user is aware of the MFA process and has the correct credentials.
description: The following analytic identifies failed authentication attempts during
the Multi-Factor Authentication (MFA) challenge in an Okta tenant. It uses the Authentication
datamodel to detect specific failed events where the authentication signature is
`user.authentication.auth_via_mfa`. This activity is significant as it may indicate
an adversary attempting to authenticate with compromised credentials on an account
with MFA enabled. If confirmed malicious, this could suggest an ongoing attempt
to bypass MFA protections, potentially leading to unauthorized access and further
compromise of the affected account.
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime values(Authentication.app) as app values(Authentication.reason) as
reason values(Authentication.signature) as signature values(Authentication.method)
as method from datamodel=Authentication where Authentication.signature=user.authentication.auth_via_mfa
Authentication.action = failure by _time Authentication.src Authentication.user
Authentication.dest Authentication.action | `drop_dm_object_name("Authentication")`
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| iplocation
src | `okta_authentication_failed_during_mfa_challenge_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: A user may have accidentally entered the wrong credentials
during the MFA challenge. If the user is new to MFA, they may have trouble authenticating.
Ensure that the user is aware of the MFA process and has the correct credentials.
references:
- https://sec.okta.com/everythingisyes
- https://splunkbase.splunk.com/app/6553
@@ -55,6 +71,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_mfa_login_failed/okta_mfa_login_failed.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_mfa_login_failed/okta_mfa_login_failed.log
source: okta_log
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_idp_lifecycle_modifications.yml
+27 -10
View File
@@ -1,16 +1,31 @@
name: Okta IDP Lifecycle Modifications
id: e0be2c83-5526-4219-a14f-c3db2e763d15
version: 1
date: '2024-03-14'
version: 2
date: '2024-05-28'
author: Bhavin Patel, Splunk
data_source: []
type: Anomaly
status: production
description: This detection identifies modifications to Okta Identity Provider (IDP) lifecycle events, such as creation, activation, deactivation, and deletion of IDP configurations. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms within an organization. By detecting unauthorized or anomalous changes, organizations can quickly respond to potential security breaches or misconfigurations, ensuring that their identity management systems remain secure and operational.
search: '`okta` eventType IN ("system.idp.lifecycle.activate","system.idp.lifecycle.create","system.idp.lifecycle.delete","system.idp.lifecycle.deactivate")
| stats count min(_time) as firstTime max(_time) as lastTime values(target{}.id) as target_id values(target{}.type) as target_modified by src dest src_user_id user user_agent command description | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_idp_lifecycle_modifications_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It's possible for legitimate administrative actions or automated processes to trigger this detection, especially if there are bulk modifications to Okta IDP lifecycle events. Review the context of the modification, such as the user making the change and the specific lifecycle event modified, to determine if it aligns with expected behavior.
description: The following analytic identifies modifications to Okta Identity Provider
(IDP) lifecycle events, including creation, activation, deactivation, and deletion
of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta
Identity Cloud. Monitoring these events is crucial for maintaining the integrity
and security of authentication mechanisms. Unauthorized or anomalous changes could
indicate potential security breaches or misconfigurations. If confirmed malicious,
attackers could manipulate authentication processes, potentially gaining unauthorized
access or disrupting identity management systems.
search: '`okta` eventType IN ("system.idp.lifecycle.activate","system.idp.lifecycle.create","system.idp.lifecycle.delete","system.idp.lifecycle.deactivate")
| stats count min(_time) as firstTime max(_time) as lastTime values(target{}.id)
as target_id values(target{}.type) as target_modified by src dest src_user_id user
user_agent command description | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `okta_idp_lifecycle_modifications_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It's possible for legitimate administrative actions or automated
processes to trigger this detection, especially if there are bulk modifications
to Okta IDP lifecycle events. Review the context of the modification, such as the
user making the change and the specific lifecycle event modified, to determine if
it aligns with expected behavior.
references:
- https://www.obsidiansecurity.com/blog/behind-the-breach-cross-tenant-impersonation-in-okta/
- https://splunkbase.splunk.com/app/6553
@@ -20,7 +35,8 @@ tags:
asset_type: Okta Tenant
confidence: 90
impact: 90
message: A user [$user$] is attempting IDP lifecycle modification - [$description$] from IP Address - [$src$]"
message: A user [$user$] is attempting IDP lifecycle modification - [$description$]
from IP Address - [$src$]"
mitre_attack_id:
- T1087.004
observable:
@@ -52,6 +68,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/okta_idp/okta.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556/okta_idp/okta.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_mfa_exhaustion_hunt.yml
+27 -20
View File
@@ -1,27 +1,33 @@
name: Okta MFA Exhaustion Hunt
id: 97e2fe57-3740-402c-988a-76b64ce04b8d
version: 2
date: '2022-09-27'
version: 3
date: '2024-05-18'
author: Michael Haag, Marissa Bower, Mauricio Velazco, Splunk
status: production
type: Hunting
description: The following analytic identifies patterns within Okta data to determine
the amount of successful and failed pushes. Based on that, eval statements determine
a finding of whether this is suspicious or not. The events are within a window of
time and may be tuned as needed.
description: The following analytic detects patterns of successful and failed Okta
MFA push attempts to identify potential MFA exhaustion attacks. It leverages Okta
event logs, specifically focusing on push verification events, and uses statistical
evaluations to determine suspicious activity. This activity is significant as it
may indicate an attacker attempting to bypass MFA by overwhelming the user with
push notifications. If confirmed malicious, this could lead to unauthorized access,
compromising the security of the affected accounts and potentially the entire environment.
data_source: []
search: '`okta` eventType=system.push.send_factor_verify_push OR ((legacyEventType=core.user.factor.attempt_success) AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) OR ((legacyEventType=core.user.factor.attempt_fail) AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH))
| stats count(eval(legacyEventType="core.user.factor.attempt_success")) as successes count(eval(legacyEventType="core.user.factor.attempt_fail")) as failures count(eval(eventType="system.push.send_factor_verify_push")) as pushes by user,_time
| stats latest(_time) as lasttime earliest(_time) as firsttime sum(successes) as successes sum(failures) as failures sum(pushes) as pushes by user
| eval seconds=lasttime-firsttime | eval lasttime=strftime(lasttime, "%c")
| search (pushes>1)
| eval totalattempts=successes+failures
| eval finding="Normal authentication pattern"
| eval finding=if(failures==pushes AND pushes>1,"Authentication attempts not successful because multiple pushes denied",finding)
| eval finding=if(totalattempts==0,"Multiple pushes sent and ignored",finding)
| eval finding=if(successes>0 AND pushes>3,"Probably should investigate. Multiple pushes sent, eventual successful authentication!",finding)
| `okta_mfa_exhaustion_hunt_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
search: '`okta` eventType=system.push.send_factor_verify_push OR ((legacyEventType=core.user.factor.attempt_success)
AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) OR ((legacyEventType=core.user.factor.attempt_fail)
AND (debugContext.debugData.factor=OKTA_VERIFY_PUSH)) | stats count(eval(legacyEventType="core.user.factor.attempt_success")) as
successes count(eval(legacyEventType="core.user.factor.attempt_fail")) as failures
count(eval(eventType="system.push.send_factor_verify_push")) as pushes by user,_time
| stats latest(_time) as lasttime earliest(_time) as firsttime sum(successes) as
successes sum(failures) as failures sum(pushes) as pushes by user | eval seconds=lasttime-firsttime
| eval lasttime=strftime(lasttime, "%c") | search (pushes>1) | eval totalattempts=successes+failures
| eval finding="Normal authentication pattern" | eval finding=if(failures==pushes
AND pushes>1,"Authentication attempts not successful because multiple pushes denied",finding)
| eval finding=if(totalattempts==0,"Multiple pushes sent and ignored",finding) |
eval finding=if(successes>0 AND pushes>3,"Probably should investigate. Multiple
pushes sent, eventual successful authentication!",finding) | `okta_mfa_exhaustion_hunt_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may be present. Tune Okta and tune the analytic
to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning
is complete.
@@ -59,6 +65,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_pushes/okta_multiple_failed_mfa_pushes.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_pushes/okta_multiple_failed_mfa_pushes.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_mismatch_between_source_and_response_for_verify_push_request.yml
+45 -63
View File
@@ -1,65 +1,46 @@
name: Okta Mismatch Between Source and Response for Verify Push Request
id: 8085b79b-9b85-4e67-ad63-351c9e9a5e9a
version: 1
date: '2023-03-17'
version: 2
date: '2024-05-19'
author: John Murphy and Jordan Ruocco, Okta, Michael Haag, Splunk
type: TTP
status: experimental
data_source: []
description: 'The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic.
For each Okta Verify Push challenge, the following two events are recorded in Okta System Log
Source of Push (Sign-In)
eventType eq \"system.push.send_factor_verify_push\"
User Push Response (Okta Verify client)
eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH"
In sequence, the logic for the analytic -
* Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push)
* Counts the total number of push events, successful authentication events, and any push sources where the client is a new device.
* Creates a ratio of successful sign-ins to pushes.
* If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session.'
search: '`okta` eventType IN (system.push.send_factor_verify_push) OR
(eventType IN (user.authentication.auth_via_mfa)
debugContext.debugData.factor="OKTA_VERIFY_PUSH")
| eval groupby="authenticationContext.externalSessionId"
| eval group_push_time=_time
| bin span=2s group_push_time
| fillnull value=NULL
| stats min(_time) as _time by authenticationContext.externalSessionId eventType
debugContext.debugData.factor outcome.result actor.alternateId client.device client.ipAddress
client.userAgent.rawUserAgent debugContext.debugData.behaviors group_push_time groupby
| iplocation client.ipAddress
| fields - lat, lon, group_push_time
| stats min(_time) as _time dc(client.ipAddress) as dc_ip
sum(eval(if(eventType="system.push.send_factor_verify_push" AND
"outcome.result"="SUCCESS",1,0))) as total_pushes
sum(eval(if(eventType="user.authentication.auth_via_mfa" AND
"outcome.result"="SUCCESS",1,0))) as total_successes
sum(eval(if(eventType="user.authentication.auth_via_mfa" AND
"outcome.result"="FAILURE",1,0))) as total_rejected
sum(eval(if(eventType="system.push.send_factor_verify_push" AND
"debugContext.debugData.behaviors" LIKE "%New Device=POSITIVE%",1,0))) as suspect_device_from_source
sum(eval(if(eventType="system.push.send_factor_verify_push" AND
"debugContext.debugData.behaviors" LIKE "%New IP=POSITIVE%",0,0))) as suspect_ip_from_source
values(eval(if(eventType="system.push.send_factor_verify_push","client.ipAddress",""))) as src
values(eval(if(eventType="user.authentication.auth_via_mfa","client.ipAddress",""))) as dest
values(*) as * by groupby
| eval ratio = round(total_successes/total_pushes,2)
| search ((ratio < 0.5 AND total_pushes > 1) OR (total_rejected > 0)) AND dc_ip > 1 AND
suspect_device_from_source > 0 AND suspect_ip_from_source > 0 | `okta_mismatch_between_source_and_response_for_verify_push_request_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may be present based on organization size and configuration of Okta. Monitor, tune and filter as needed.
description: 'The following analytic identifies discrepancies between the source and
response events for Okta Verify Push requests, indicating potential suspicious behavior.
It leverages Okta System Log events, specifically `system.push.send_factor_verify_push`
and `user.authentication.auth_via_mfa` with the factor "OKTA_VERIFY_PUSH." The detection
groups events by SessionID, calculates the ratio of successful sign-ins to push
requests, and checks for session roaming and new device/IP usage. This activity
is significant as it may indicate push spam or unauthorized access attempts. If
confirmed malicious, attackers could bypass MFA, leading to unauthorized access
to sensitive systems.'
search: '`okta` eventType IN (system.push.send_factor_verify_push) OR (eventType IN
(user.authentication.auth_via_mfa) debugContext.debugData.factor="OKTA_VERIFY_PUSH")
| eval groupby="authenticationContext.externalSessionId" | eval group_push_time=_time
| bin span=2s group_push_time | fillnull value=NULL | stats min(_time) as _time
by authenticationContext.externalSessionId eventType debugContext.debugData.factor
outcome.result actor.alternateId client.device client.ipAddress client.userAgent.rawUserAgent
debugContext.debugData.behaviors group_push_time groupby | iplocation client.ipAddress
| fields - lat, lon, group_push_time | stats min(_time) as _time dc(client.ipAddress)
as dc_ip sum(eval(if(eventType="system.push.send_factor_verify_push" AND "outcome.result"="SUCCESS",1,0)))
as total_pushes sum(eval(if(eventType="user.authentication.auth_via_mfa" AND "outcome.result"="SUCCESS",1,0)))
as total_successes sum(eval(if(eventType="user.authentication.auth_via_mfa" AND
"outcome.result"="FAILURE",1,0))) as total_rejected sum(eval(if(eventType="system.push.send_factor_verify_push"
AND "debugContext.debugData.behaviors" LIKE "%New Device=POSITIVE%",1,0))) as suspect_device_from_source
sum(eval(if(eventType="system.push.send_factor_verify_push" AND "debugContext.debugData.behaviors"
LIKE "%New IP=POSITIVE%",0,0))) as suspect_ip_from_source values(eval(if(eventType="system.push.send_factor_verify_push","client.ipAddress","")))
as src values(eval(if(eventType="user.authentication.auth_via_mfa","client.ipAddress","")))
as dest values(*) as * by groupby | eval ratio = round(total_successes/total_pushes,2)
| search ((ratio < 0.5 AND total_pushes > 1) OR (total_rejected > 0)) AND dc_ip
> 1 AND suspect_device_from_source > 0 AND suspect_ip_from_source > 0 | `okta_mismatch_between_source_and_response_for_verify_push_request_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may be present based on organization size and
configuration of Okta. Monitor, tune and filter as needed.
references:
- https://attack.mitre.org/techniques/T1621
- https://splunkbase.splunk.com/app/6553
- https://attack.mitre.org/techniques/T1621
- https://splunkbase.splunk.com/app/6553
tags:
analytic_story:
- Okta Account Takeover
@@ -67,7 +48,8 @@ tags:
asset_type: Okta Tenant
confidence: 80
impact: 80
message: A mismatch between source and response for verifying a push request has occurred for $actor.alternateId$
message: A mismatch between source and response for verifying a push request has
occurred for $actor.alternateId$
mitre_attack_id:
- T1621
observable:
@@ -81,15 +63,15 @@ tags:
- Splunk Cloud
required_fields:
- _time
- authenticationContext.externalSessionId
- authenticationContext.externalSessionId
- eventType
- debugContext.debugData.factor
- outcome.result
- actor.alternateId
- client.device
- debugContext.debugData.factor
- outcome.result
- actor.alternateId
- client.device
- client.ipAddress
- client.userAgent.rawUserAgent
- debugContext.debugData.behaviors
- client.userAgent.rawUserAgent
- debugContext.debugData.behaviors
- group_push_time
risk_score: 64
security_domain: access
detections/application/okta_multi_factor_authentication_disabled.yml
+23 -12
View File
@@ -1,20 +1,29 @@
name: Okta Multi-Factor Authentication Disabled
id: 7c0348ce-bdf9-45f6-8a57-c18b5976f00a
version: 1
date: '2024-03-11'
version: 2
date: '2024-05-13'
author: Mauricio Velazco, Splunk
data_source: []
type: TTP
status: production
description: The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users.
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime
from datamodel=Change where sourcetype="OktaIM2:log" All_Changes.object_category=User AND All_Changes.action=modified All_Changes.command=user.mfa.factor.deactivate by All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src
| `drop_dm_object_name("All_Changes")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
description: The following analytic identifies an attempt to disable multi-factor
authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when
the 'user.mfa.factor.deactivate' command is executed. This activity is significant
because disabling MFA can allow an adversary to maintain persistence within the
environment using a compromised valid account. If confirmed malicious, this action
could enable attackers to bypass additional security layers, potentially leading
to unauthorized access to sensitive information and prolonged undetected presence
in the network.
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime,
min(_time) as firstTime from datamodel=Change where sourcetype="OktaIM2:log" All_Changes.object_category=User
AND All_Changes.action=modified All_Changes.command=user.mfa.factor.deactivate by
All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src
| `drop_dm_object_name("All_Changes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `okta_multi_factor_authentication_disabled_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Legitimate use case may require for users to disable MFA. Filter lightly and monitor for any unusual activity.
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Legitimate use case may require for users to disable MFA. Filter
lightly and monitor for any unusual activity.
references:
- https://attack.mitre.org/techniques/T1556/
- https://splunkbase.splunk.com/app/6553
@@ -24,7 +33,8 @@ tags:
asset_type: Okta Tenant
confidence: 60
impact: 50
message: MFA was disabled for User [$user$] initiated by [$src$]. Investigate further to determine if this was authorized.
message: MFA was disabled for User [$user$] initiated by [$src$]. Investigate further
to determine if this was authorized.
mitre_attack_id:
- T1556
- T1556.006
@@ -55,6 +65,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/okta_mfa_method_disabled/okta_mfa_method_disabled.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1556.006/okta_mfa_method_disabled/okta_mfa_method_disabled.log
source: Okta
sourcetype: OktaIM2:log
detections/application/okta_multiple_accounts_locked_out.yml
+24 -15
View File
@@ -1,21 +1,28 @@
name: Okta Multiple Accounts Locked Out
id: a511426e-184f-4de6-8711-cfd2af29d1e1
version: 1
date: '2024-03-06'
version: 2
date: '2024-05-11'
author: Michael Haag, Mauricio Velazco, Splunk
data_source: []
type: Anomaly
status: production
description: The following analytic utilizes the user.acount.lock event to identify multiple Okta accounts locking out in a short period of time. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold set by the organization. Monitoring for multiple account lockouts can help detect potential account takeover attempts or unauthorized access to Okta accounts.
search: '| tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime values(All_Changes.user) as user
from datamodel=Change where All_Changes.change_type=AAA All_Changes.object_category=User AND All_Changes.action=lockout AND All_Changes.command=user.account.lock by _time span=5m All_Changes.result All_Changes.command sourcetype All_Changes.src
| where count > 5
| `drop_dm_object_name("All_Changes")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `okta_multiple_accounts_locked_out_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Multiple account lockouts may be also triggered by an application malfunction. Filter as needed, and monitor for any unusual activity.
description: The following analytic detects multiple Okta accounts being locked out
within a short period. It uses the user.account.lock event from Okta logs, aggregated
over a 5-minute window, to identify this behavior. This activity is significant
as it may indicate a brute force or password spraying attack, where an adversary
attempts to guess passwords, leading to account lockouts. If confirmed malicious,
this could result in potential account takeovers or unauthorized access to sensitive
Okta accounts, posing a significant security risk.
search: '| tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time)
as firstTime values(All_Changes.user) as user from datamodel=Change where All_Changes.change_type=AAA
All_Changes.object_category=User AND All_Changes.action=lockout AND All_Changes.command=user.account.lock
by _time span=5m All_Changes.result All_Changes.command sourcetype All_Changes.src
| where count > 5 | `drop_dm_object_name("All_Changes")` | `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | `okta_multiple_accounts_locked_out_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Multiple account lockouts may be also triggered by an application
malfunction. Filter as needed, and monitor for any unusual activity.
references:
- https://attack.mitre.org/techniques/T1110/
- https://splunkbase.splunk.com/app/6553
@@ -25,7 +32,8 @@ tags:
asset_type: Okta Tenant
confidence: 70
impact: 70
message: Multiple accounts locked out in Okta from [$src$]. Investigate further to determine if this was authorized.
message: Multiple accounts locked out in Okta from [$src$]. Investigate further
to determine if this was authorized.
mitre_attack_id:
- T1110
observable:
@@ -55,6 +63,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110/okta_multiple_accounts_lockout/okta_multiple_accounts_lockout.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110/okta_multiple_accounts_lockout/okta_multiple_accounts_lockout.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_multiple_failed_mfa_requests_for_user.yml
+22 -14
View File
@@ -1,21 +1,28 @@
name: Okta Multiple Failed MFA Requests For User
id: 826dbaae-a1e6-4c8c-b384-d16898956e73
version: 1
date: '2024-03-05'
version: 2
date: '2024-05-20'
author: Mauricio Velazco, Splunk
data_source: []
type: Anomaly
status: production
description: The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Okta tenant. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Okta tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
search: ' `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE debugContext.debugData.factor!=PASSWORD_AS_FACTOR
| bucket _time span=5m
| stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip) as src_ip values(debugContext.debugData.factor) by _time src_user
| where count >= 5
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
description: The following analytic identifies multiple failed multi-factor authentication
(MFA) requests for a single user within an Okta tenant. It triggers when more than
10 MFA attempts fail within 5 minutes, using Okta event logs to detect this pattern.
This activity is significant as it may indicate an adversary attempting to bypass
MFA by bombarding the user with repeated authentication requests, a technique used
by threat actors like Lapsus and APT29. If confirmed malicious, this could lead
to unauthorized access, potentially compromising sensitive information and systems.
search: ' `okta` eventType=user.authentication.auth_via_mfa outcome.result=FAILURE
debugContext.debugData.factor!=PASSWORD_AS_FACTOR | bucket _time span=5m | stats
count min(_time) as firstTime max(_time) as lastTime values(displayMessage) values(src_ip)
as src_ip values(debugContext.debugData.factor) by _time src_user | where count
>= 10 | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `okta_multiple_failed_mfa_requests_for_user_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed and monitor for any unusual activity.
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Multiple Failed MFA requests may also be a sign of authentication
or application issues. Filter as needed and monitor for any unusual activity.
references:
- https://attack.mitre.org/techniques/T1621/
tags:
@@ -24,7 +31,7 @@ tags:
asset_type: Okta Tenant
confidence: 70
impact: 60
message: Multiple failed MFA requests for user [$src_user$] from IP Address - [$src_ip$]. Investigate further to determine if this was authorized.
message: Multiple failed MFA requests for user $src_user$ from IP Address - $src_ip$
mitre_attack_id:
- T1621
observable:
@@ -53,6 +60,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_requests/okta_multiple_failed_mfa_requests.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/okta_multiple_failed_mfa_requests/okta_multiple_failed_mfa_requests.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_multiple_failed_requests_to_access_applications.yml
+47 -34
View File
@@ -1,53 +1,66 @@
name: Okta Multiple Failed Requests to Access Applications
id: 1c21fed1-7000-4a2e-9105-5aaafa437247
version: 1
date: "2023-03-17"
version: 2
date: "2024-05-30"
author: John Murphy, Okta, Michael Haag, Splunk
type: Hunting
status: experimental
data_source: []
description:
'The following analytic identifies multiple failed app requests in an attempt to identify the reuse a stolen web session cookie. The logic of the analytic is as follows:
* Retrieves policy evaluation and SSO details in events that contain the Application requested
* Formats target fields so we can aggregate specifically on Applications (AppInstances)
* Groups by User, Session and IP
* Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies
* Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps.'
search: '`okta` target{}.type=AppInstance (eventType=policy.evaluate_sign_on outcome.result=CHALLENGE) OR (eventType=user.authentication.sso outcome.result=SUCCESS) | eval targets=mvzip(''target{}.type'', ''target{}.displayName'', ": ") | eval targets=mvfilter(targets LIKE "AppInstance%") | stats count min(_time) as _time values(outcome.result) as outcome.result dc(eval(if(eventType="policy.evaluate_sign_on",targets,NULL))) as total_challenges sum(eval(if(eventType="user.authentication.sso",1,0))) as total_successes by authenticationContext.externalSessionId targets actor.alternateId client.ipAddress | search total_challenges > 0 | stats min(_time) as _time values(*) as * sum(total_challenges) as total_challenges sum(total_successes) as total_successes values(eval(if("outcome.result"="SUCCESS",targets,NULL))) as success_apps values(eval(if(":outcome.result"!="SUCCESS",targets,NULL))) as no_success_apps by authenticationContext.externalSessionId actor.alternateId client.ipAddress | fillnull | eval ratio=round(total_successes/total_challenges,2), severity="HIGH", mitre_technique_id="T1538", description="actor.alternateId". " from " . "client.ipAddress" . " seen opening " . total_challenges . " chiclets/apps with " . total_successes . " challenges successfully passed" | fields - count, targets | search ratio < 0.5 total_challenges > 2 | `okta_multiple_failed_requests_to_access_applications_filter`'
how_to_implement: This analytic is specific to Okta and requires Okta:im2 logs to be ingested.
known_false_positives: False positives may be present based on organization size and configuration of Okta.
description: 'The following analytic detects multiple failed attempts to access applications
in Okta, potentially indicating the reuse of a stolen web session cookie. It leverages
Okta logs to evaluate policy and SSO events, aggregating data by user, session,
and IP. The detection triggers when more than half of the app sign-on attempts are
unsuccessful across multiple applications. This activity is significant as it may
indicate an attempt to bypass authentication mechanisms. If confirmed malicious,
it could lead to unauthorized access to sensitive applications and data, posing
a significant security risk.'
search: '`okta` target{}.type=AppInstance (eventType=policy.evaluate_sign_on outcome.result=CHALLENGE)
OR (eventType=user.authentication.sso outcome.result=SUCCESS) | eval targets=mvzip(''target{}.type'',
''target{}.displayName'', ": ") | eval targets=mvfilter(targets LIKE "AppInstance%")
| stats count min(_time) as _time values(outcome.result) as outcome.result dc(eval(if(eventType="policy.evaluate_sign_on",targets,NULL)))
as total_challenges sum(eval(if(eventType="user.authentication.sso",1,0))) as total_successes
by authenticationContext.externalSessionId targets actor.alternateId client.ipAddress
| search total_challenges > 0 | stats min(_time) as _time values(*) as * sum(total_challenges)
as total_challenges sum(total_successes) as total_successes values(eval(if("outcome.result"="SUCCESS",targets,NULL)))
as success_apps values(eval(if(":outcome.result"!="SUCCESS",targets,NULL))) as no_success_apps
by authenticationContext.externalSessionId actor.alternateId client.ipAddress |
fillnull | eval ratio=round(total_successes/total_challenges,2), severity="HIGH",
mitre_technique_id="T1538", description="actor.alternateId". " from " . "client.ipAddress"
. " seen opening " . total_challenges . " chiclets/apps with " . total_successes
. " challenges successfully passed" | fields - count, targets | search ratio < 0.5
total_challenges > 2 | `okta_multiple_failed_requests_to_access_applications_filter`'
how_to_implement: This analytic is specific to Okta and requires Okta:im2 logs to
be ingested.
known_false_positives: False positives may be present based on organization size and
configuration of Okta.
references:
- https://attack.mitre.org/techniques/T1538
- https://attack.mitre.org/techniques/T1550/004
- https://attack.mitre.org/techniques/T1538
- https://attack.mitre.org/techniques/T1550/004
tags:
analytic_story:
- Okta Account Takeover
- Okta Account Takeover
asset_type: Okta Tenant
confidence: 70
impact: 80
message: Multiple Failed Requests to Access Applications via Okta for $actor.alternateId$.
mitre_attack_id:
- T1550.004
- T1538
- T1550.004
- T1538
observable:
- name: actor.alternateId
type: User
role:
- Victim
- name: actor.alternateId
type: User
role:
- Victim
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
required_fields:
- _time
- authenticationContext.externalSessionId
- targets
- actor.alternateId
- client.ipAddress
- eventType
- _time
- authenticationContext.externalSessionId
- targets
- actor.alternateId
- client.ipAddress
- eventType
risk_score: 56
security_domain: access
detections/application/okta_multiple_users_failing_to_authenticate_from_ip.yml
+26 -15
View File
@@ -1,21 +1,30 @@
name: Okta Multiple Users Failing To Authenticate From Ip
id: de365ffa-42f5-46b5-b43f-fa72290b8218
version: 1
date: '2024-03-06'
version: 2
date: '2024-05-28'
author: Michael Haag, Mauricio Velazco, Splunk
data_source: []
type: Anomaly
status: production
description: This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes) within an Okta tenant. Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach security by targeting multiple user accounts.
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime dc(Authentication.user) as unique_accounts values(Authentication.signature) as signature values(Authentication.user) as user values(Authentication.app) as app values(Authentication.authentication_method) as authentication_method
from datamodel=Authentication where Authentication.action="failure" AND Authentication.signature=user.session.start by _time span=5m Authentication.src sourcetype
| where unique_accounts > 9
| `drop_dm_object_name("Authentication")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `okta_multiple_users_failing_to_authenticate_from_ip_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior.
description: The following analytic identifies instances where more than 10 unique
user accounts have failed to authenticate from a single IP address within a 5-minute
window in an Okta tenant. This detection uses OktaIm2 logs ingested via the Splunk
Add-on for Okta Identity Cloud. Such activity is significant as it may indicate
brute-force attacks or password spraying attempts. If confirmed malicious, this
behavior suggests an external entity is attempting to compromise multiple user accounts,
potentially leading to unauthorized access to organizational resources and data
breaches.
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime,
min(_time) as firstTime dc(Authentication.user) as unique_accounts values(Authentication.signature)
as signature values(Authentication.user) as user values(Authentication.app) as app
values(Authentication.authentication_method) as authentication_method from datamodel=Authentication
where Authentication.action="failure" AND Authentication.signature=user.session.start
by _time span=5m Authentication.src sourcetype | where unique_accounts > 9 | `drop_dm_object_name("Authentication")`
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_multiple_users_failing_to_authenticate_from_ip_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: A source Ip failing to authenticate with multiple users in
a short period of time is not common legitimate behavior.
references:
- https://attack.mitre.org/techniques/T1110/003/
- https://splunkbase.splunk.com/app/6553
@@ -25,7 +34,8 @@ tags:
asset_type: Okta Tenant
confidence: 90
impact: 60
message: Multiple users failing to authenticate from a single source IP Address - [$src$]. Investigate further to determine if this was authorized.
message: Multiple users failing to authenticate from a single source IP Address
- [$src$]. Investigate further to determine if this was authorized.
mitre_attack_id:
- T1110.003
observable:
@@ -55,6 +65,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/okta_multiple_users_from_ip/okta_multiple_users_from_ip.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/okta_multiple_users_from_ip/okta_multiple_users_from_ip.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_new_api_token_created.yml
+22 -12
View File
@@ -1,19 +1,27 @@
name: Okta New API Token Created
id: c3d22720-35d3-4da4-bd0a-740d37192bd4
version: 2
date: '2022-09-21'
version: 3
date: '2024-05-11'
author: Michael Haag, Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts.
description: The following analytic detects the creation of a new API token within
an Okta tenant. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity
Cloud to identify events where the `system.api_token.create` command is executed.
This activity is significant because creating a new API token can indicate potential
account takeover attempts or unauthorized access, allowing an adversary to maintain
persistence. If confirmed malicious, this could enable attackers to execute API
calls, access sensitive data, and perform administrative actions within the Okta
environment.
data_source: []
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime
from datamodel=Change where All_Changes.action=created AND All_Changes.command=system.api_token.create by _time span=5m All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src All_Changes.action All_Changes.object_category
| `drop_dm_object_name("All_Changes")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime,
min(_time) as firstTime from datamodel=Change where All_Changes.action=created AND
All_Changes.command=system.api_token.create by _time span=5m All_Changes.user All_Changes.result
All_Changes.command sourcetype All_Changes.src All_Changes.action All_Changes.object_category
| `drop_dm_object_name("All_Changes")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `okta_new_api_token_created_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may be present. Tune Okta and tune the analytic
to ensure proper fidelity. Modify risk score as needed.
references:
@@ -25,7 +33,8 @@ tags:
asset_type: Okta Tenant
confidence: 80
impact: 80
message: A new API token was created in Okta by [$user$]. Investigate further to determine if this was authorized.
message: A new API token was created in Okta by [$user$]. Investigate further to
determine if this was authorized.
mitre_attack_id:
- T1078
- T1078.001
@@ -56,6 +65,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/okta_new_api_token_created/okta_new_api_token_created.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.001/okta_new_api_token_created/okta_new_api_token_created.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_new_device_enrolled_on_account.yml
+24 -14
View File
@@ -1,20 +1,28 @@
name: Okta New Device Enrolled on Account
id: bb27cbce-d4de-432c-932f-2e206e9130fb
version: 2
date: '2024-03-08'
version: 3
date: '2024-05-24'
author: Michael Haag, Mauricio Velazco, Splunk
status: production
type: TTP
description: The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts.
description: The following analytic identifies when a new device is enrolled on an
Okta account. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity
Cloud to detect the creation of new device enrollments. This activity is significant
as it may indicate a legitimate user setting up a new device or an adversary adding
a device to maintain unauthorized access. If confirmed malicious, this could lead
to potential account takeover, unauthorized access, and persistent control over
the compromised Okta account. Monitoring this behavior is crucial for detecting
and mitigating unauthorized access attempts.
data_source: []
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime, min(_time) as firstTime
from datamodel=Change where All_Changes.action=created All_Changes.command=device.enrollment.create by _time span=5m All_Changes.user All_Changes.result All_Changes.command sourcetype All_Changes.src All_Changes.action All_Changes.object_category
| `drop_dm_object_name("All_Changes")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `okta_new_device_enrolled_on_account_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It is possible that the user has legitimately added a new device to their account. Please verify this activity.
search: ' | tstats `security_content_summariesonly` count max(_time) as lastTime,
min(_time) as firstTime from datamodel=Change where All_Changes.action=created All_Changes.command=device.enrollment.create
by _time span=5m All_Changes.user All_Changes.result All_Changes.command sourcetype
All_Changes.src All_Changes.action All_Changes.object_category | `drop_dm_object_name("All_Changes")`
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `okta_new_device_enrolled_on_account_filter`'
how_to_implement: The analytic leverages Okta OktaIm2 logs to be ingested using the
Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It is possible that the user has legitimately added a new device
to their account. Please verify this activity.
references:
- https://attack.mitre.org/techniques/T1098/005/
- https://developer.okta.com/docs/reference/api/event-types/?q=device.enrollment.create
@@ -24,7 +32,8 @@ tags:
asset_type: Okta Tenant
confidence: 60
impact: 40
message: A new device was enrolled on an Okta account for user [$user$]. Investigate further to determine if this was authorized.
message: A new device was enrolled on an Okta account for user [$user$]. Investigate
further to determine if this was authorized.
mitre_attack_id:
- T1098
- T1098.005
@@ -51,6 +60,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/okta_new_device_enrolled/okta_new_device_enrolled.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/okta_new_device_enrolled/okta_new_device_enrolled.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_phishing_detection_with_fastpass_origin_check.yml
+22 -14
View File
@@ -1,20 +1,28 @@
name: Okta Phishing Detection with FastPass Origin Check
id: f4ca0057-cbf3-44f8-82ea-4e330ee901d3
version: 1
date: '2023-03-09'
version: 2
date: '2024-05-15'
author: Okta, Inc, Michael Haag, Splunk
type: TTP
status: experimental
data_source: []
description: The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies.
Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers.
search: '`okta` eventType="user.authentication.auth_via_mfa" AND result="FAILURE" AND outcome.reason="FastPass declined phishing attempt"
| stats count min(_time) as firstTime max(_time) as lastTime values(displayMessage) by user eventType client.userAgent.rawUserAgent client.userAgent.browser outcome.reason
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | `okta_phishing_detection_with_fastpass_origin_check_filter`'
how_to_implement: This search is specific to Okta and requires Okta logs to be
ingested in your Splunk deployment.
known_false_positives: Fidelity of this is high as Okta is specifying malicious infrastructure. Filter and modify as needed.
description: The following analytic identifies failed user authentication attempts
in Okta due to FastPass declining a phishing attempt. It leverages Okta logs, specifically
looking for events where multi-factor authentication (MFA) fails with the reason
"FastPass declined phishing attempt." This activity is significant as it indicates
that attackers are targeting users with real-time phishing proxies, attempting to
capture credentials. If confirmed malicious, this could lead to unauthorized access
to user accounts, potentially compromising sensitive information and furthering
lateral movement within the organization.
search: '`okta` eventType="user.authentication.auth_via_mfa" AND result="FAILURE"
AND outcome.reason="FastPass declined phishing attempt" | stats count min(_time)
as firstTime max(_time) as lastTime values(displayMessage) by user eventType client.userAgent.rawUserAgent
client.userAgent.browser outcome.reason | `security_content_ctime(firstTime)` |
`security_content_ctime(lastTime)` | `okta_phishing_detection_with_fastpass_origin_check_filter`'
how_to_implement: This search is specific to Okta and requires Okta logs to be ingested
in your Splunk deployment.
known_false_positives: Fidelity of this is high as Okta is specifying malicious infrastructure.
Filter and modify as needed.
references:
- https://sec.okta.com/fastpassphishingdetection
tags:
@@ -39,9 +47,9 @@ tags:
- Splunk Cloud
required_fields:
- _time
- eventType
- client.userAgent.rawUserAgent
- client.userAgent.browser
- eventType
- client.userAgent.rawUserAgent
- client.userAgent.browser
- outcome.reason
- displayMessage
risk_score: 100
detections/application/okta_risk_threshold_exceeded.yml
+56 -35
View File
@@ -1,57 +1,78 @@
name: Okta Risk Threshold Exceeded
id: d8b967dd-657f-4d88-93b5-c588bcd7218c
version: 2
date: "2024-04-02"
version: 3
date: "2024-05-28"
author: Michael Haag, Bhavin Patel, Splunk
status: production
type: Correlation
description:
This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user.
description: The following correlation identifies when a user exceeds a risk threshold
based on multiple suspicious Okta activities. It leverages the Risk Framework from
Enterprise Security, aggregating risk events from "Suspicious Okta Activity," "Okta
Account Takeover," and "Okta MFA Exhaustion" analytic stories. This detection is
significant as it highlights potentially compromised user accounts exhibiting multiple
tactics, techniques, and procedures (TTPs) within a 24-hour period. If confirmed
malicious, this activity could indicate a serious security breach, allowing attackers
to gain unauthorized access, escalate privileges, or persist within the environment.
data_source: []
search:
'| tstats `security_content_summariesonly` values(All_Risk.analyticstories) as analyticstories sum(All_Risk.calculated_risk_score) as risk_score, count(All_Risk.calculated_risk_score) as risk_event_count,values(All_Risk.annotations.mitre_attack.mitre_tactic_id) as annotations.mitre_attack.mitre_tactic_id, dc(All_Risk.annotations.mitre_attack.mitre_tactic_id) as mitre_tactic_id_count, values(All_Risk.annotations.mitre_attack.mitre_technique_id) as annotations.mitre_attack.mitre_technique_id, dc(All_Risk.annotations.mitre_attack.mitre_technique_id) as mitre_technique_id_count, values(All_Risk.tag) as tag, values(source) as source, dc(source) as source_count from datamodel=Risk.All_Risk where All_Risk.risk_object_type = user All_Risk.analyticstories IN ("Okta Account Takeover", "Suspicious Okta Activity","Okta MFA Exhaustion") by All_Risk.risk_object,All_Risk.risk_object_type | `drop_dm_object_name("All_Risk")` | search mitre_technique_id_count > 5 | `okta_risk_threshold_exceeded_filter`'
how_to_implement:
This search leverages the Risk Framework from Enterprise Security. Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories are enabled. TTPs may be set to Notables for point detections; anomalies should not be notables but rather risk generators. The correlation relies on risk before generating a notable. Modify the value as needed.
known_false_positives:
False positives will be limited to the number of events generated by the analytics tied to the stories. Analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization.
search: '| tstats `security_content_summariesonly` values(All_Risk.analyticstories)
as analyticstories sum(All_Risk.calculated_risk_score) as risk_score, count(All_Risk.calculated_risk_score)
as risk_event_count,values(All_Risk.annotations.mitre_attack.mitre_tactic_id) as
annotations.mitre_attack.mitre_tactic_id, dc(All_Risk.annotations.mitre_attack.mitre_tactic_id)
as mitre_tactic_id_count, values(All_Risk.annotations.mitre_attack.mitre_technique_id)
as annotations.mitre_attack.mitre_technique_id, dc(All_Risk.annotations.mitre_attack.mitre_technique_id)
as mitre_technique_id_count, values(All_Risk.tag) as tag, values(source) as source,
dc(source) as source_count from datamodel=Risk.All_Risk where All_Risk.risk_object_type
= user All_Risk.analyticstories IN ("Okta Account Takeover", "Suspicious Okta Activity","Okta
MFA Exhaustion") by All_Risk.risk_object,All_Risk.risk_object_type | `drop_dm_object_name("All_Risk")`
| search mitre_technique_id_count > 5 | `okta_risk_threshold_exceeded_filter`'
how_to_implement: This search leverages the Risk Framework from Enterprise Security.
Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion"
analytic stories are enabled. TTPs may be set to Notables for point detections;
anomalies should not be notables but rather risk generators. The correlation relies
on risk before generating a notable. Modify the value as needed.
known_false_positives: False positives will be limited to the number of events generated
by the analytics tied to the stories. Analytics will need to be tested and tuned,
and the risk score reduced as needed based on the organization.
references:
- https://developer.okta.com/docs/reference/api/event-types
- https://sec.okta.com/everythingisyes
- https://developer.okta.com/docs/reference/api/event-types
- https://sec.okta.com/everythingisyes
tags:
analytic_story:
- Okta Account Takeover
- Okta MFA Exhaustion
- Suspicious Okta Activity
- Okta Account Takeover
- Okta MFA Exhaustion
- Suspicious Okta Activity
asset_type: Okta Tenant
confidence: 80
impact: 70
message: Okta Risk threshold exceeded for user [$risk_object$]. Investigate further to determine if this was authorized.
message: Okta Risk threshold exceeded for user [$risk_object$]. Investigate further
to determine if this was authorized.
mitre_attack_id:
- T1078
- T1110
- T1078
- T1110
observable:
- name: risk_object
type: User
role:
- Victim
- name: risk_object
type: User
role:
- Victim
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
required_fields:
- All_Risk.risk_object
- All_Risk.risk_object_type
- All_Risk.analyticstories
- All_Risk.calculated_risk_score
- All_Risk.annotations.mitre_attack.mitre_tactic_id
- All_Risk.annotations.mitre_attack.mitre_technique_id
- All_Risk.tag
- _time
- All_Risk.risk_object
- All_Risk.risk_object_type
- All_Risk.analyticstories
- All_Risk.calculated_risk_score
- All_Risk.annotations.mitre_attack.mitre_tactic_id
- All_Risk.annotations.mitre_attack.mitre_technique_id
- All_Risk.tag
- _time
risk_score: 56
security_domain: access
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/okta_account_takeover_risk_events/okta_risk.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/suspicious_behaviour/okta_account_takeover_risk_events/okta_risk.log
source: risk_data
sourcetype: stash
sourcetype: stash
detections/application/okta_successful_single_factor_authentication.yml
+25 -11
View File
@@ -1,17 +1,29 @@
name: Okta Successful Single Factor Authentication
id: 98f6ad4f-4325-4096-9d69-45dc8e638e82
version: 1
date: '2024-04-08'
version: 2
date: '2024-05-26'
author: Bhavin Patel, Splunk
data_source: []
type: Anomaly
status: production
description: This analytic identifies successful authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication enabled. It specifically searches for events where "Okta Verify" is not detected during authentication. This could indicate a misconfiguration, a policy violation, or an account takeover attempt that warrants investigation. If your organization has other authenticators configured in the environment, consider excluding those from the "targets" in the detection search.
search: '`okta` action=success src_user_type = User eventType = user.authentication.verify OR eventType = user.authentication.auth_via_mfa| stats dc(eventType) values(eventType) as eventType values(target{}.displayName) as targets values(debugContext.debugData.url) min(_time) as firstTime max(_time) as lastTime values(authentication_method) by src_ip user action
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | search targets !="Okta Verify" | `okta_successful_single_factor_authentication_filter`'
how_to_implement: This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary.
description: The following analytic identifies successful single-factor authentication
events against the Okta Dashboard for accounts without Multi-Factor Authentication
(MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication
events where "Okta Verify" is not used. This behavior is significant as it may indicate
a misconfiguration, policy violation, or potential account takeover. If confirmed
malicious, an attacker could gain unauthorized access to the account, potentially
leading to data breaches or further exploitation within the environment.
search: '`okta` action=success src_user_type = User eventType = user.authentication.verify
OR eventType = user.authentication.auth_via_mfa| stats dc(eventType) values(eventType)
as eventType values(target{}.displayName) as targets values(debugContext.debugData.url)
min(_time) as firstTime max(_time) as lastTime values(authentication_method) by
src_ip user action | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| search targets !="Okta Verify" | `okta_successful_single_factor_authentication_filter`'
how_to_implement: This detection utilizes logs from Okta environments and requires
the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud
(https://splunkbase.splunk.com/app/6553).
known_false_positives: Although not recommended, certain users may be exempt from
multi-factor authentication. Adjust the filter as necessary.
references:
- https://sec.okta.com/everythingisyes
- https://attack.mitre.org/techniques/T1078/004/
@@ -21,7 +33,8 @@ tags:
asset_type: Okta Tenant
confidence: 60
impact: 80
message: A user [$user$] has successfully logged in to Okta Dashboard with single factor authentication from IP Address - [$src_ip$].
message: A user [$user$] has successfully logged in to Okta Dashboard with single
factor authentication from IP Address - [$src_ip$].
mitre_attack_id:
- T1586
- T1586.003
@@ -53,6 +66,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_single_factor_auth/okta_single_factor_auth.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_single_factor_auth/okta_single_factor_auth.log
source: okta_log
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_suspicious_use_of_a_session_cookie.yml
+28 -23
View File
@@ -1,31 +1,34 @@
name: Okta Suspicious Use of a Session Cookie
id: 71ad47d1-d6bd-4e0a-b35c-020ad9a6959e
version: 2
date: '2024-03-17'
version: 3
date: '2024-05-29'
author: Scott Dermott, Felicity Robson, Okta, Michael Haag, Bhavin Patel, Splunk
type: Anomaly
status: production
data_source: []
description: 'The following analytic looks for one or more policy evaluation events in which multiple client values (IP, User Agent, etc.) change associated to the same Device Token for a specific user. A detection opportunity arises when an adversary attempts to reuse a stolen web session cookie.
* Retrieves policy evaluation events from successful authentication events.
* Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window.
* It checks for the presence of more than one IP and whether there are multiple OS or browsers for each User/Device Token combination.'
search: '`okta` eventType IN (policy.evaluate_sign_on) outcome.result IN
(ALLOW, SUCCESS) | stats earliest(_time) as _time, values(client.ipAddress) as src_ip,
values(client.userAgent.rawUserAgent) as user_agent, values(client.userAgent.os) as
userAgentOS_list, values(client.geographicalContext.city) as city, values(client.userAgent.browser) as userAgentBrowser_list,
values(device.os_platform) as okta_device_os, dc(client.userAgent.browser) as dc_userAgentBrowser,
dc(client.userAgent.os) as dc_userAgentOS, dc(client.ipAddress) as dc_src_ip,
values(outcome.reason) as reason by debugContext.debugData.dtHash, user
| where dc_src_ip>1 AND (dc_userAgentOS>1 OR dc_userAgentBrowser>1)
| `okta_suspicious_use_of_a_session_cookie_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may occur, depending on the organization's size and the configuration of Okta.
description: 'The following analytic identifies suspicious use of a session cookie
by detecting multiple client values (IP, User Agent, etc.) changing for the same
Device Token associated with a specific user. It leverages policy evaluation events
from successful authentication logs in Okta. This activity is significant as it
may indicate an adversary attempting to reuse a stolen web session cookie, potentially
bypassing authentication mechanisms. If confirmed malicious, this could allow unauthorized
access to user accounts, leading to data breaches or further exploitation within
the environment.'
search: '`okta` eventType IN (policy.evaluate_sign_on) outcome.result IN (ALLOW, SUCCESS)
| stats earliest(_time) as _time, values(client.ipAddress) as src_ip, values(client.userAgent.rawUserAgent)
as user_agent, values(client.userAgent.os) as userAgentOS_list, values(client.geographicalContext.city)
as city, values(client.userAgent.browser) as userAgentBrowser_list, values(device.os_platform)
as okta_device_os, dc(client.userAgent.browser) as dc_userAgentBrowser, dc(client.userAgent.os)
as dc_userAgentOS, dc(client.ipAddress) as dc_src_ip, values(outcome.reason) as
reason by debugContext.debugData.dtHash, user | where dc_src_ip>1 AND (dc_userAgentOS>1
OR dc_userAgentBrowser>1) | `okta_suspicious_use_of_a_session_cookie_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM)
environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on
for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may occur, depending on the organization's
size and the configuration of Okta.
references:
- https://attack.mitre.org/techniques/T1539/
- https://attack.mitre.org/techniques/T1539/
tags:
analytic_story:
- Suspicious Okta Activity
@@ -33,7 +36,8 @@ tags:
asset_type: Okta Tenant
confidence: 70
impact: 80
message: A user [$user$] is attempting to use a session cookie from multiple IP addresses or devices. Investigate further to determine if this was authorized.
message: A user [$user$] is attempting to use a session cookie from multiple IP
addresses or devices. Investigate further to determine if this was authorized.
mitre_attack_id:
- T1539
observable:
@@ -60,6 +64,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1539/okta_web_session_multiple_ip/okta_web_session_multiple_ip.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1539/okta_web_session_multiple_ip/okta_web_session_multiple_ip.log
source: Okta
sourcetype: OktaIM2:log
detections/application/okta_threatinsight_threat_detected.yml
+24 -13
View File
@@ -1,20 +1,29 @@
name: Okta ThreatInsight Threat Detected
id: 140504ae-5fe2-4d65-b2bc-a211813fbca6
version: 2
date: '2022-09-21'
version: 3
date: '2024-05-21'
author: Michael Haag, Mauricio Velazco, Splunk
status: production
type: Anomaly
description: This anomaly is based on the identification of threats by Okta ThreatInsight. It allows for the escalation of risk based on src_ip or the addition of fields for further tracking. Possible identifications include password spraying, login failures, and login failures with a high count of unknown users.
description: The following analytic identifies threats detected by Okta ThreatInsight,
such as password spraying, login failures, and high counts of unknown user login
attempts. It leverages Okta Identity Management logs, specifically focusing on security.threat.detected
events. This activity is significant for a SOC as it highlights potential unauthorized
access attempts and credential-based attacks. If confirmed malicious, these activities
could lead to unauthorized access, data breaches, and further exploitation of compromised
accounts, posing a significant risk to the organization's security posture.
data_source: []
search: '`okta` eventType = security.threat.detected
| rename client.geographicalContext.country as country, client.geographicalContext.state as state, client.geographicalContext.city as city
| stats count min(_time) as firstTime max(_time) as lastTime by app src_ip signature eventType displayMessage client.device city state country user_agent outcome.reason outcome.result severity
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
search: '`okta` eventType = security.threat.detected | rename client.geographicalContext.country
as country, client.geographicalContext.state as state, client.geographicalContext.city
as city | stats count min(_time) as firstTime max(_time) as lastTime by app src_ip
signature eventType displayMessage client.device city state country user_agent outcome.reason
outcome.result severity | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `okta_threatinsight_threat_detected_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may occur. It is recommended to fine-tune Okta settings and the analytic to ensure high fidelity. Adjust the risk score as necessary.
how_to_implement: This detection utilizes logs from Okta Identity Management (IM)
environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on
for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: False positives may occur. It is recommended to fine-tune Okta
settings and the analytic to ensure high fidelity. Adjust the risk score as necessary.
references:
- https://developer.okta.com/docs/reference/api/event-types/?q=security.threat.detected
tags:
@@ -23,7 +32,8 @@ tags:
asset_type: Infrastructure
confidence: 50
impact: 50
message: The following $src_ip$ has been identified as a threat by Okta ThreatInsight. Investigate further to determine if this was authorized.
message: The following $src_ip$ has been identified as a threat by Okta ThreatInsight.
Investigate further to determine if this was authorized.
mitre_attack_id:
- T1078
- T1078.004
@@ -58,6 +68,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_threatinsight_threat_detected/okta_threatinsight_threat_detected.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078.004/okta_threatinsight_threat_detected/okta_threatinsight_threat_detected.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_unauthorized_access_to_application.yml
+26 -13
View File
@@ -1,19 +1,30 @@
name: Okta Unauthorized Access to Application
id: 5f661629-9750-4cb9-897c-1f05d6db8727
version: 1
date: '2024-03-07'
version: 2
date: '2024-05-12'
author: 'Bhavin Patel, Splunk'
data_source: []
type: Anomaly
status: production
description: This search detects instances where a user attempts to access an Okta application that has not been assigned to them. Such unauthorized access to applications poses a significant security risk, potentially leading to the exposure of sensitive information, disruption of services, and breaches of data protection laws. Ensuring that only authorized users have access to applications is crucial for maintaining a secure and compliant IT environment.
search: '| tstats values(Authentication.app) as app values(Authentication.action) as action values(Authentication.user) as user values(Authentication.reason) as reason from datamodel=Authentication where Authentication.signature=app.generic.unauth_app_access_attempt Authentication.action="failure" by _time Authentication.src Authentication.user
| `drop_dm_object_name("Authentication")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| iplocation src | `okta_unauthorized_access_to_application_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: There is a possibility that a user may accidentally click on the wrong application, which could trigger this event. It is advisable to verify the location from which this activity originates.
description: The following analytic identifies attempts by users to access Okta applications
that have not been assigned to them. It leverages Okta Identity Management logs,
specifically focusing on failed access attempts to unassigned applications. This
activity is significant for a SOC as it may indicate potential unauthorized access
attempts, which could lead to exposure of sensitive information or disruption of
services. If confirmed malicious, such activity could result in data breaches, non-compliance
with data protection laws, and overall compromise of the IT environment.
search: '| tstats values(Authentication.app) as app values(Authentication.action)
as action values(Authentication.user) as user values(Authentication.reason) as reason
from datamodel=Authentication where Authentication.signature=app.generic.unauth_app_access_attempt
Authentication.action="failure" by _time Authentication.src Authentication.user
| `drop_dm_object_name("Authentication")` | `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | iplocation src | `okta_unauthorized_access_to_application_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM)
environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on
for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: There is a possibility that a user may accidentally click on
the wrong application, which could trigger this event. It is advisable to verify
the location from which this activity originates.
references:
- https://attack.mitre.org/techniques/T1110/003/
tags:
@@ -22,7 +33,8 @@ tags:
asset_type: Okta Tenant
confidence: 90
impact: 90
message: A user [$user$] is attempting to access an unauthorized application from IP Address - [$src$]
message: A user [$user$] is attempting to access an unauthorized application from
IP Address - [$src$]
mitre_attack_id:
- T1087.004
observable:
@@ -53,6 +65,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.004/okta_unauth_access/okta_unauth_access.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087.004/okta_unauth_access/okta_unauth_access.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/okta_user_logins_from_multiple_cities.yml
+30 -15
View File
@@ -1,21 +1,34 @@
name: Okta User Logins from Multiple Cities
id: a3d1df37-c2a9-41d0-aa8f-59f82d6192a8
version: 1
date: '2024-03-07'
version: 2
date: '2024-05-09'
author: 'Bhavin Patel, Splunk'
data_source: []
type: Anomaly
status: production
description: This search identifies instances where the same user logs in from different cities within a 24-hour period, potentially indicating a compromised account. Such behavior may be indicative of an attacker attempting to gain unauthorized access to an Okta account from multiple locations. Investigating and responding to such incidents promptly is crucial to prevent account takeovers and data breaches.
search: '| tstats `security_content_summariesonly` values(Authentication.app) as app values(Authentication.action) as action values(Authentication.user) as user values(Authentication.reason) as reason values(Authentication.dest) as dest values(Authentication.signature) as signature values(Authentication.method) as method from datamodel=Authentication where Authentication.signature=user.session.start by _time Authentication.src
| `drop_dm_object_name("Authentication")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| iplocation src
| stats count min(_time) as firstTime max(_time) as lastTime dc(src) as distinct_src dc(City) as distinct_city values(src) as src values(City) as City values(Country) as Country values(action) as action by user
| where distinct_city > 1 | `okta_user_logins_from_multiple_cities_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It is uncommon for a user to log in from multiple cities simultaneously, which may indicate a false positive.
description: The following analytic identifies instances where the same Okta user
logs in from different cities within a 24-hour period. This detection leverages
Okta Identity Management logs, analyzing login events and their geographic locations.
Such behavior is significant as it may indicate a compromised account, with an attacker
attempting unauthorized access from multiple locations. If confirmed malicious,
this activity could lead to account takeovers and data breaches, allowing attackers
to access sensitive information and potentially escalate their privileges within
the environment.
search: '| tstats `security_content_summariesonly` values(Authentication.app) as
app values(Authentication.action) as action values(Authentication.user) as user
values(Authentication.reason) as reason values(Authentication.dest) as dest values(Authentication.signature)
as signature values(Authentication.method) as method from datamodel=Authentication
where Authentication.signature=user.session.start by _time Authentication.src |
`drop_dm_object_name("Authentication")` | `security_content_ctime(firstTime)` |
`security_content_ctime(lastTime)` | iplocation src | stats count min(_time) as
firstTime max(_time) as lastTime dc(src) as distinct_src dc(City) as distinct_city
values(src) as src values(City) as City values(Country) as Country values(action)
as action by user | where distinct_city > 1 | `okta_user_logins_from_multiple_cities_filter`'
how_to_implement: This detection utilizes logs from Okta Identity Management (IM)
environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on
for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
known_false_positives: It is uncommon for a user to log in from multiple cities simultaneously,
which may indicate a false positive.
references:
- https://attack.mitre.org/techniques/T1110/003/
tags:
@@ -24,7 +37,8 @@ tags:
asset_type: Okta Tenant
confidence: 90
impact: 90
message: A user [$user$] has logged in from multiple cities [$City$] from IP Address - [$src$]. Investigate further to determine if this was authorized.
message: A user [$user$] has logged in from multiple cities [$City$] from IP Address
- [$src$]. Investigate further to determine if this was authorized.
mitre_attack_id:
- T1586.003
observable:
@@ -55,6 +69,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1586.003/okta_multiple_city/okta_multiple_city_im2.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1586.003/okta_multiple_city/okta_multiple_city_im2.log
source: Okta
sourcetype: OktaIM2:log
sourcetype: OktaIM2:log
detections/application/path_traversal_spl_injection.yml
+13 -8
View File
@@ -1,15 +1,19 @@
name: Path traversal SPL injection
id: dfe55688-82ed-4d24-a21b-ed8f0e0fda99
version: 2
date: '2024-03-19'
version: 3
date: '2024-05-26'
author: Rod Soto, Splunk
status: production
type: TTP
description: On May 3rd, 2022, Splunk published a security advisory for a Path traversal
in search parameter that can potentiall allow SPL injection. An attacker can cause
the application to load data from incorrect endpoints, urls leading to outcomes
such as running arbitrary SPL queries.
data_source:
description: The following analytic identifies attempts at path traversal in search
parameters, which can lead to SPL injection. It detects this activity by searching
for specific patterns in the `_internal` index that indicate path traversal attempts
(e.g., "../../../../"). This activity is significant for a SOC because it can allow
an attacker to manipulate the application to load data from incorrect endpoints,
potentially running arbitrary SPL queries. If confirmed malicious, this could lead
to unauthorized data access, code execution, or further exploitation of the Splunk
environment.
data_source:
- Splunk
search: ' `path_traversal_spl_injection` | search "\/..\/..\/..\/..\/..\/..\/..\/..\/..\/" |
stats count by host status clientip method uri_path uri_query | `path_traversal_spl_injection_filter`'
@@ -57,7 +61,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/path_traversal_spl_injection.txt
- data:
https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/path_traversal_spl_injection.txt
source: splunkd_ui_access.log
sourcetype: splunkd_ui_access
custom_index: _internal
detections/application/persistent_xss_in_rapiddiag_through_user_interface_views.yml
+40 -29
View File
@@ -1,57 +1,68 @@
name: Persistent XSS in RapidDiag through User Interface Views
id: ce6e1268-e01c-4df2-a617-0f034ed49a43
version: 1
date: "2023-02-14"
version: 2
date: "2024-05-24"
author: Rod Soto, Splunk
type: TTP
status: production
data_source:
data_source:
- Splunk
description: In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it.
search:
"`audit_searches` path=/opt/splunk/etc/users/*/search/local/data/ui/views/*
description: The following analytic identifies potential persistent Cross-Site Scripting
(XSS) attacks in Splunk Enterprise 9.0 versions before 9.0.4 through user interface
views. It leverages audit logs from the `audit_searches` data source to detect actions
involving Base64-encoded images in error messages. This activity is significant
because it can allow attackers to inject malicious scripts that execute in the context
of other users, leading to unauthorized actions or data exposure. If confirmed malicious,
this could result in persistent control over the affected Splunk instance, compromising
its integrity and confidentiality.
search: "`audit_searches` path=/opt/splunk/etc/users/*/search/local/data/ui/views/*
action=* |table user action roles info roles path | dedup user action | `persistent_xss_in_rapiddiag_through_user_interface_views_filter`"
how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index
known_false_positives: This is a hunting search, it will not deobfuscate base64 payload, it provides however it will provide what user added the view artifact and what user opened it. It will require further investigation based on the information presented by this hunting search.
how_to_implement: This detection does not require you to ingest any new data. The
detection does require the ability to search the _internal index
known_false_positives: This is a hunting search, it will not deobfuscate base64 payload,
it provides however it will provide what user added the view artifact and what user
opened it. It will require further investigation based on the information presented
by this hunting search.
references:
- https://www.splunk.com/en_us/product-security.html
- https://www.splunk.com/en_us/product-security.html
tags:
analytic_story:
- Splunk Vulnerabilities
- Splunk Vulnerabilities
asset_type: Endpoint
cve:
- CVE-2023-22932
- CVE-2023-22932
confidence: 50
context:
- Source:Endpoint
- Source:Endpoint
dataset:
- https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log
- https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log
impact: 50
message: A potential XSS attempt has been detected from $user$
mitre_attack_id:
- T1189
- T1189
observable:
- name: user
type: User
role:
- Victim
- name: user
type: User
role:
- Victim
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
required_fields:
- user
- action
- roles
- info
- roles
- path
- user
- action
- roles
- info
- roles
- path
risk_score: 25
security_domain: threat
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_in_rapiddiag_through_user_interface_views_data.log
source: audittrail
sourcetype: audittrail
custom_index: _audit
custom_index: _audit
detections/application/pingid_mismatch_auth_source_and_verification_response.yml
+36 -9
View File
@@ -1,17 +1,42 @@
name: PingID Mismatch Auth Source and Verification Response
id: 15b0694e-caa2-4009-8d83-a1f98b86d086
version: 1
date: '2023-09-26'
version: 2
date: '2024-05-22'
author: Steven Dick
status: production
type: TTP
description: The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country.
description: The following analytic identifies discrepancies between the IP address
of an authentication event and the IP address of the verification response event,
focusing on differences in the originating countries. It leverages JSON logs from
PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity
is significant as it may indicate suspicious sign-in behavior, such as account compromise
or unauthorized access attempts. If confirmed malicious, this could allow attackers
to bypass authentication mechanisms, potentially leading to unauthorized access
to sensitive systems and data.
data_source:
- PingID
search: >-
`pingid` ("result.status" IN ("SUCCESS*","FAIL*","UNSUCCESSFUL*") NOT "result.message" IN ("*pair*","*create*","*delete*")) | eval user = upper('actors{}.name'), session_id = 'resources{}.websession', dest = 'resources{}.ipaddress', reason = 'result.message', object = 'resources{}.devicemodel', status = 'result.status' | join user session_id [ search `pingid` ("result.status" IN ("POLICY") AND "resources{}.ipaddress"=*) AND "result.message" IN("*Action: Authenticate*","*Action: Approve*","*Action: Allowed*") | rex field=result.message "IP Address: (?:N\/A)?(?<policy_ipaddress>.+)?\n" | rex field=result.message "Action: (?:N\/A)?(?<signature>.+)?\n" | rex field=result.message "Requested Application Name: (?:N\/A)?(?<Requested_Application_Name>.+)?\n" | rex field=result.message "Requested Application ID: (?:N\/A)?(?<Requested_Application_ID>.+)?\n" | eval user = upper('actors{}.name'), session_id = 'resources{}.websession', src = coalesce('resources{}.ipaddress',policy_ipaddress), app = coalesce(Requested_Application_ID,Requested_Application_Name) | fields app, user, session_id, src, signature ] | iplocation prefix=auth_ dest | iplocation prefix=verify_ src | stats count min(_time) as firstTime max(_time) as lastTime values(app) as app values(session_id) as session_id by user, dest, auth_Country, src, verify_Country, object, signature, status, reason | where auth_Country != verify_Country | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `pingid_mismatch_auth_source_and_verification_response_filter`
how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
known_false_positives: False positives may be generated by users working out the geographic region where the organizations services or technology is hosted.
`pingid` ("result.status" IN ("SUCCESS*","FAIL*","UNSUCCESSFUL*") NOT "result.message"
IN ("*pair*","*create*","*delete*")) | eval user = upper('actors{}.name'), session_id
= 'resources{}.websession', dest = 'resources{}.ipaddress', reason = 'result.message',
object = 'resources{}.devicemodel', status = 'result.status' | join user session_id
[ search `pingid` ("result.status" IN ("POLICY") AND "resources{}.ipaddress"=*)
AND "result.message" IN("*Action: Authenticate*","*Action: Approve*","*Action: Allowed*")
| rex field=result.message "IP Address: (?:N\/A)?(?<policy_ipaddress>.+)?\n" | rex
field=result.message "Action: (?:N\/A)?(?<signature>.+)?\n" | rex field=result.message
"Requested Application Name: (?:N\/A)?(?<Requested_Application_Name>.+)?\n" | rex
field=result.message "Requested Application ID: (?:N\/A)?(?<Requested_Application_ID>.+)?\n"
| eval user = upper('actors{}.name'), session_id = 'resources{}.websession', src
= coalesce('resources{}.ipaddress',policy_ipaddress), app = coalesce(Requested_Application_ID,Requested_Application_Name)
| fields app, user, session_id, src, signature ] | iplocation prefix=auth_ dest
| iplocation prefix=verify_ src | stats count min(_time) as firstTime max(_time)
as lastTime values(app) as app values(session_id) as session_id by user, dest, auth_Country,
src, verify_Country, object, signature, status, reason | where auth_Country != verify_Country
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `pingid_mismatch_auth_source_and_verification_response_filter`
how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne)
enterprise environment, either via Webhook or Push Subscription.
known_false_positives: False positives may be generated by users working out the geographic
region where the organizations services or technology is hosted.
references:
- https://twitter.com/jhencinski/status/1618660062352007174
- https://attack.mitre.org/techniques/T1098/005/
@@ -23,7 +48,8 @@ tags:
asset_type: Identity
confidence: 50
impact: 50
message: An authentication by [$user$] was detected from [$dest$ - $auth_Country$] and the verification was received from [$src$ - $verify_Country$].
message: An authentication by [$user$] was detected from [$dest$ - $auth_Country$]
and the verification was received from [$src$ - $verify_Country$].
mitre_attack_id:
- T1621
- T1556.006
@@ -58,7 +84,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log
source: PINGID
sourcetype: _json
update_timestamp: true
update_timestamp: true
detections/application/pingid_multiple_failed_mfa_requests_for_user.yml
+27 -12
View File
@@ -1,17 +1,30 @@
name: PingID Multiple Failed MFA Requests For User
id: c1bc706a-0025-4814-ad30-288f38865036
version: 1
date: '2023-09-26'
version: 2
date: '2024-05-29'
author: Steven Dick
status: production
type: TTP
description: The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
description: The following analytic identifies multiple failed multi-factor authentication
(MFA) requests for a single user within a PingID environment. It triggers when 10
or more MFA prompts fail within 10 minutes, using JSON logs from PingID. This activity
is significant as it may indicate an adversary attempting to bypass MFA by bombarding
the user with repeated authentication requests. If confirmed malicious, this could
lead to unauthorized access, as the user might eventually accept the fraudulent
request, compromising the security of the account and potentially the entire network.
data_source:
- PingID
search: >-
`pingid` "result.status" IN ("FAILURE,authFail","UNSUCCESSFUL_ATTEMPT") | eval time = _time, src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user = upper('actors{}.name'), object = 'resources{}.devicemodel', reason = 'result.message'| bucket span=10m _time | stats dc(_raw) AS mfa_prompts min(time) as firstTime, max(time) as lastTime values(src) as src by user, reason, _time | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | where mfa_prompts >= 10 | `pingid_multiple_failed_mfa_requests_for_user_filter`
how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
known_false_positives: False positives may be generated by normal provisioning workflows for user device registration.
`pingid` "result.status" IN ("FAILURE,authFail","UNSUCCESSFUL_ATTEMPT") | eval time
= _time, src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user
= upper('actors{}.name'), object = 'resources{}.devicemodel', reason = 'result.message'|
bucket span=10m _time | stats dc(_raw) AS mfa_prompts min(time) as firstTime, max(time)
as lastTime values(src) as src by user, reason, _time | `security_content_ctime(firstTime)`|
`security_content_ctime(lastTime)` | where mfa_prompts >= 10 | `pingid_multiple_failed_mfa_requests_for_user_filter`
how_to_implement: Target environment must ingest JSON logging from a PingID(PingOne)
enterprise environment, either via Webhook or Push Subscription.
known_false_positives: False positives may be generated by normal provisioning workflows
for user device registration.
references:
- https://therecord.media/russian-hackers-bypass-2fa-by-annoying-victims-with-repeated-push-notifications/
- https://attack.mitre.org/techniques/T1621/
@@ -24,7 +37,8 @@ tags:
asset_type: Identity
confidence: 50
impact: 100
message: Multiple Failed MFA requests $mfa_prompts$ for user $user$ between $firstTime$ and $lastTime$.
message: Multiple Failed MFA requests $mfa_prompts$ for user $user$ between $firstTime$
and $lastTime$.
mitre_attack_id:
- T1621
- T1078
@@ -48,8 +62,9 @@ tags:
risk_score: 50
security_domain: access
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log
source: PINGID
sourcetype: _json
- name: True Positive Test
attack_data:
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log
source: PINGID
sourcetype: _json
detections/application/pingid_new_mfa_method_after_credential_reset.yml
+36 -11
View File
@@ -1,17 +1,39 @@
name: PingID New MFA Method After Credential Reset
id: 2fcbce12-cffa-4c84-b70c-192604d201d0
version: 1
date: '2023-09-26'
version: 2
date: '2024-05-21'
author: Steven Dick
status: production
type: TTP
description: A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning.
description: The following analytic identifies the provisioning of a new MFA device
shortly after a password reset. It detects this activity by correlating Windows
Event Log events for password changes (EventID 4723, 4724) with PingID logs indicating
device pairing. This behavior is significant as it may indicate a social engineering
attack where a threat actor impersonates a valid user to reset credentials and add
a new MFA device. If confirmed malicious, this activity could allow an attacker
to gain persistent access to the compromised account, bypassing traditional security
measures.
data_source:
- PingID
search: >-
`pingid` "result.message" = "*Device Paired*" | rex field=result.message "Device (Unp)?(P)?aired (?<device_extract>.+)" | eval src = coalesce('resources{}.ipaddress','resources{}.devicemodel'), user = upper('actors{}.name'), reason = 'result.message' | eval object=CASE(ISNOTNULL('resources{}.devicemodel'),'resources{}.devicemodel',true(),device_extract) | eval action=CASE(match('result.message',"Device Paired*"),"created",match('result.message', "Device Unpaired*"),"deleted") | stats count min(_time) as firstTime, max(_time) as lastTime, values(reason) as reason by src,user,action,object | join type=outer user [| search `wineventlog_security` EventID IN(4723,4724) | eval PW_Change_Time = _time, user = upper(user) | fields user,src_user,EventID,PW_Change_Time] | eval timeDiffRaw = round(lastTime - PW_Change_Time) | eval timeDiff = replace(tostring(abs(timeDiffRaw) ,"duration"),"(\d*)\+*(\d+):(\d+):(\d+)","\2 hours \3 minutes") | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `security_content_ctime(PW_Change_Time)` | where timeDiffRaw > 0 AND timeDiffRaw < 3600 | `pingid_new_mfa_method_after_credential_reset_filter`
how_to_implement: Target environment must ingest Windows Event Log and PingID(PingOne) data sources. Specifically from logs from Active Directory Domain Controllers and JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
known_false_positives: False positives may be generated by normal provisioning workflows that generate a password reset followed by a device registration.
`pingid` "result.message" = "*Device Paired*" | rex field=result.message "Device
(Unp)?(P)?aired (?<device_extract>.+)" | eval src = coalesce('resources{}.ipaddress','resources{}.devicemodel'),
user = upper('actors{}.name'), reason = 'result.message' | eval object=CASE(ISNOTNULL('resources{}.devicemodel'),'resources{}.devicemodel',true(),device_extract)
| eval action=CASE(match('result.message',"Device Paired*"),"created",match('result.message',
"Device Unpaired*"),"deleted") | stats count min(_time) as firstTime, max(_time)
as lastTime, values(reason) as reason by src,user,action,object | join type=outer
user [| search `wineventlog_security` EventID IN(4723,4724) | eval PW_Change_Time
= _time, user = upper(user) | fields user,src_user,EventID,PW_Change_Time] | eval
timeDiffRaw = round(lastTime - PW_Change_Time) | eval timeDiff = replace(tostring(abs(timeDiffRaw)
,"duration"),"(\d*)\+*(\d+):(\d+):(\d+)","\2 hours \3 minutes") | `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | `security_content_ctime(PW_Change_Time)`
| where timeDiffRaw > 0 AND timeDiffRaw < 3600 | `pingid_new_mfa_method_after_credential_reset_filter`
how_to_implement: Target environment must ingest Windows Event Log and PingID(PingOne)
data sources. Specifically from logs from Active Directory Domain Controllers and
JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or
Push Subscription.
known_false_positives: False positives may be generated by normal provisioning workflows
that generate a password reset followed by a device registration.
references:
- https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/defend-your-users-from-mfa-fatigue-attacks/ba-p/2365677
- https://www.bleepingcomputer.com/news/security/mfa-fatigue-hackers-new-favorite-tactic-in-high-profile-breaches/
@@ -24,11 +46,12 @@ tags:
asset_type: Identity
confidence: 50
impact: 100
message: An MFA configuration change was detected for [$user$] within [$timeDiff$] of a password reset. The device [$object$] was $action$.
message: An MFA configuration change was detected for [$user$] within [$timeDiff$]
of a password reset. The device [$object$] was $action$.
mitre_attack_id:
- T1621
- T1556.006
- T1098.005
- T1098.005
observable:
- name: user
type: User
@@ -57,9 +80,11 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/windows_pw_reset.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/windows_pw_reset.log
source: XmlWinEventLog:Security
sourcetype: XmlWinEventLog
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/pingid/pingid.log
source: PINGID
sourcetype: _json
sourcetype: _json
detections/application/splunk_account_discovery_drilldown_dashboard_disclosure.yml
+9 -6
View File
@@ -1,14 +1,17 @@
name: Splunk Account Discovery Drilldown Dashboard Disclosure
id: f844c3f6-fd99-43a2-ba24-93e35fe84be6
version: 1
date: '2022-08-02'
version: 2
date: '2024-05-15'
author: Marissa Bower, Rod Soto, Splunk
status: experimental
type: TTP
description: Splunk drilldown vulnerability disclosure in Dashboard application that
can potentially allow exposure of tokens from privilege users. An attacker can create
dashboard and share it to privileged user (admin) and detokenize variables using
external urls within dashboards drilldown function.
description: The following analytic identifies the presence of environment variables
in Splunk dashboard drilldown URLs. It uses the REST API to query dashboards for
specific patterns in the XML data. This activity is significant because it can expose
sensitive tokens from privileged users if an attacker shares a malicious dashboard.
If confirmed malicious, this could allow an attacker to detokenize variables and
potentially gain unauthorized access to sensitive information or escalate privileges
within the Splunk environment.
data_source: []
search: '| rest splunk_server=local /servicesNS/-/-/data/ui/views | search eai:data="*$env:*"
eai:data="*url*" eai:data="*options*" | rename author AS Author eai:acl.sharing
detections/application/splunk_authentication_token_exposure_in_debug_log.yml
+21 -13
View File
@@ -1,21 +1,28 @@
name: Splunk Authentication Token Exposure in Debug Log
id: 9a67e749-d291-40dd-8376-d422e7ecf8b5
version: 1
date: '2024-03-18'
version: 2
date: '2024-05-25'
author: Rod Soto, Chase Franklin
type: TTP
status: production
data_source: []
description: This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG.
search: '`splunkd` component=JsonWebToken log_level=DEBUG eventtype="splunkd-log" event_message="Validating token:*"
| rex "Validating token: (?<token>.*)\.$"
| search token!=None
| stats count min(_time) as firstTime max(_time) as lastTime values(log_level) as log_level values(event_message) as event_message by index, sourcetype, host, token
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
description: The following analytic identifies exposed authentication tokens in debug
logs within Splunk Enterprise. It leverages logs from the `splunkd` component with
a DEBUG log level, specifically searching for event messages that validate tokens.
This activity is significant because exposed tokens can be exploited by attackers
to gain unauthorized access to the Splunk environment. If confirmed malicious, this
exposure could lead to unauthorized data access, privilege escalation, and potential
compromise of the entire Splunk infrastructure. Monitoring and addressing this vulnerability
is crucial for maintaining the security and integrity of the Splunk deployment.
search: '`splunkd` component=JsonWebToken log_level=DEBUG eventtype="splunkd-log"
event_message="Validating token:*" | rex "Validating token: (?<token>.*)\.$" | search
token!=None | stats count min(_time) as firstTime max(_time) as lastTime values(log_level)
as log_level values(event_message) as event_message by index, sourcetype, host,
token | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `splunk_authentication_token_exposure_in_debug_log_filter`'
how_to_implement: Requires access to internal Splunk indexes.
known_false_positives: Only applies to affected versions of Splunk Enterprise below 9.2.1, 9.1.4, and 9.0.9
how_to_implement: Requires access to internal Splunk indexes.
known_false_positives: Only applies to affected versions of Splunk Enterprise below
9.2.1, 9.1.4, and 9.0.9
references:
- https://advisory.splunk.com/advisories/SVD-2024-0301
tags:
@@ -41,14 +48,15 @@ tags:
- component
- log_level
- eventtype
- event_message
- event_message
- host
risk_score: 50
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1654/splunk/jsonwebtokenplaintokensvd_splunkd.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1654/splunk/jsonwebtokenplaintokensvd_splunkd.log
source: /opt/splunk/var/log/splunk/splunkd.log
sourcetype: splunkd
custom_index: _internal
detections/application/splunk_code_injection_via_custom_dashboard_leading_to_rce.yml
+12 -7
View File
@@ -1,14 +1,18 @@
name: Splunk Code Injection via custom dashboard leading to RCE
id: b06b41d7-9570-4985-8137-0784f582a1b3
version: 1
date: '2022-10-11'
version: 2
date: '2024-05-24'
author: Rod Soto
status: experimental
type: Hunting
description: This hunting search provides information about a vulnerability in Splunk
Enterprise versions below 8.2.9, 8.1.12, 9.0.2, where an authenticated user can
execute arbitrary code via the dashboard pdf generation component. Please review
events with file=export in the _internal index for the potential targets of exploitation.
description: The following analytic identifies attempts to exploit a vulnerability
in Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, where an authenticated
user can execute arbitrary code via the dashboard PDF generation component. It detects
this activity by analyzing events in the _internal index with the file=export parameter.
This behavior is significant because it indicates a potential code injection attack,
which could lead to remote code execution (RCE). If confirmed malicious, an attacker
could gain unauthorized access, execute arbitrary commands, and potentially compromise
the entire Splunk environment.
data_source: []
search: '`splunkd_ui` uri_path=*/data/ui/views/* OR uri_path=*saved/searches/* | dedup
uri_path | eval URL=urldecode("uri_path")| rex field=URL "\/saved\/searches\/(?<NAME>[^\/]*)"
@@ -56,7 +60,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_code_injection_via_custom_dashboard_leading_to_rce.txt
- data:
https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_code_injection_via_custom_dashboard_leading_to_rce.txt
source: /opt/splunk/var/log/splunk/splunkd_ui_access.log
sourcetype: splunkd_ui_access
custom_index: _internal
detections/application/splunk_command_and_scripting_interpreter_delete_usage.yml
+13 -8
View File
@@ -1,15 +1,19 @@
name: Splunk Command and Scripting Interpreter Delete Usage
id: 8d3d5d5e-ca43-42be-aa1f-bc64375f6b04
version: 1
date: '2022-05-27'
version: 2
date: '2024-05-21'
author: Michael Haag, Splunk
status: production
type: Anomaly
description: The following analytic identifies the use of the risky command - Delete
- that may be utilized in Splunk to delete some or all data queried for. In order
to use Delete in Splunk, one must be assigned the role. This is typically not used
and should generate an anomaly if it is used.
data_source:
description: The following analytic detects the use of the 'delete' command in Splunk,
which can be used to remove queried data. This detection leverages the Splunk Audit
data model, specifically monitoring ad-hoc searches containing the 'delete' command
by non-system users. This activity is significant because the 'delete' command is
rarely used and can indicate potential data tampering or unauthorized data removal.
If confirmed malicious, this activity could lead to the loss of critical log data,
hindering incident investigations and compromising the integrity of the monitoring
environment.
data_source:
- Splunk
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Splunk_Audit.Search_Activity where Search_Activity.search
@@ -59,7 +63,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
source: audittrail
sourcetype: audittrail
update_timestamp: true
detections/application/splunk_command_and_scripting_interpreter_risky_commands.yml
+13 -23
View File
@@ -1,30 +1,19 @@
name: Splunk Command and Scripting Interpreter Risky Commands
id: 1cf58ae1-9177-40b8-a26c-8966040f11ae
version: 1
date: '2022-05-23'
version: 2
date: '2024-05-19'
author: Michael Haag, Splunk
status: production
type: Hunting
description: The Splunk platform contains built-in search processing language (SPL)
safeguards to warn you when you are about to unknowingly run a search that contains
commands that might be a security risk. This warning appears when you click a link
or type a URL that loads a search that contains risky commands. The warning does
not appear when you create ad hoc searches. This warning alerts you to the possibility
of unauthorized actions by a malicious user. Unauthorized actions include - Copying
or transferring data (data exfiltration), Deleting data and Overwriting data. All
risky commands may be found here https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga.
A possible scenario when this might occur is when a malicious actor creates a search
that includes commands that exfiltrate or damage data. The malicious actor then
sends an unsuspecting user a link to the search. The URL contains a query string
(q) and a search identifier (sid), but the sid is not valid. The malicious actor
hopes the user will use the link and the search will run. During analysis, pivot
based on user name and filter any user or queries not needed. Queries ran from a
dashboard are seen as adhoc queries. When a query runs from a dashboard it will
not show in audittrail logs the source dashboard name. The query defaults to adhoc
and no Splunk system user activity. In addition, modify this query by removing key
commands that generate too much noise, or too little, and create separate queries
with higher confidence to alert on.
data_source:
description: The following analytic identifies the execution of risky commands within
the Splunk platform, such as `runshellscript`, `delete`, and `sendemail`. It leverages
the Search_Activity data model to detect ad hoc searches containing these commands,
excluding those run by the splunk-system-user. This activity is significant because
it may indicate attempts at data exfiltration, deletion, or other unauthorized actions
by a malicious user. If confirmed malicious, this could lead to data loss, unauthorized
data transfer, or system compromise, severely impacting the organization's security
posture.
data_source:
- Splunk
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Splunk_Audit.Search_Activity where Search_Activity.search
@@ -84,7 +73,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
source: audittrail
sourcetype: audittrail
update_timestamp: true
detections/application/splunk_command_and_scripting_interpreter_risky_spl_mltk.yml
+13 -11
View File
@@ -1,18 +1,19 @@
name: Splunk Command and Scripting Interpreter Risky SPL MLTK
id: 19d0146c-2eae-4e53-8d39-1198a78fa9ca
version: 1
date: '2022-05-27'
version: 2
date: '2024-05-15'
author: Abhinav Mishra, Kumar Sharad and Xiao Lin, Splunk
status: production
type: Anomaly
description: This detection utilizes machine learning model named "risky_command_abuse"
trained from "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline".
It should be scheduled to run hourly to detect whether a user has run searches containing
risky SPL from this list https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga
with abnormally long running time in the past one hour, comparing with his/her past
seven days history. This search uses the trained baseline to infer whether a search
is an outlier (isOutlier ~= 1.0) or not (isOutlier~= 0.0)
data_source:
description: The following analytic identifies the execution of risky SPL commands
with abnormally long run times by leveraging a machine learning model named "risky_command_abuse."
It uses the Splunk Audit data model to compare current search activities against
a baseline of the past seven days. This activity is significant for a SOC as it
can indicate potential misuse or abuse of powerful SPL commands, which could lead
to unauthorized data access or system manipulation. If confirmed malicious, this
activity could allow an attacker to execute arbitrary scripts, delete data, or exfiltrate
sensitive information.
data_source:
- Splunk
search: '| tstats sum(Search_Activity.total_run_time) AS run_time, values(Search_Activity.search)
as searches, count FROM datamodel=Splunk_Audit.Search_Activity WHERE (Search_Activity.user!="")
@@ -65,7 +66,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt
- data:
https://github.com/splunk/attack_data/raw/master/datasets/attack_techniques/T1203/search_activity.txt
source: audittrail
sourcetype: audittrail
update_timestamp: true
detections/application/splunk_csrf_in_the_ssg_kvstore_client_endpoint.yml
+16 -14
View File
@@ -1,20 +1,21 @@
name: Splunk csrf in the ssg kvstore client endpoint
name: Splunk CSRF in the SSG kvstore Client Endpoint
id: 4742d5f7-ce00-45ce-9c79-5e98b43b4410
version: 1
date: '2023-02-14'
version: 3
date: '2024-07-01'
author: Rod Soto
status: production
type: TTP
description: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site
request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint
allows for updating SSG KV store collections via a GET request. SSG is a Splunk
Built app included by default with Splunk Enterprise. The vulnerability affects
instances with SSG and Splunk Web enabled. This hunting search provides information
on affected server specific method and post data that may reveal exploitation of
this vulnerability.
data_source:
description: The following analytic identifies attempts to exploit a cross-site request
forgery (CSRF) vulnerability in the Splunk Secure Gateway (SSG) app's kvstore_client
endpoint. It detects GET requests to the vulnerable endpoint using internal index
data, focusing on specific URI paths and HTTP methods. This activity is significant
because it can allow unauthorized updates to SSG KV store collections, potentially
leading to data manipulation or unauthorized access. If confirmed malicious, this
could enable attackers to alter critical configurations or exfiltrate sensitive
information, compromising the integrity and security of the Splunk environment.
data_source:
- Splunk
search: '`splunkda` uri_path="/en-US/splunkd/__raw/services/ssg/kvstore_client" method="GET"
search: '`splunkda` uri_path="/*/splunkd/__raw/services/ssg/kvstore_client" method="GET"
delete_field_value="spacebridge_server" status="200" | table splunk_server status
uri delete_field_value method post_data | `splunk_csrf_in_the_ssg_kvstore_client_endpoint_filter`'
how_to_implement: Requires access to internal index.
@@ -23,7 +24,7 @@ known_false_positives: This hunting search only applies to the affected versions
it requires manual investigation after executing search. This search will produce
false positives.
references:
- https://www.splunk.com/en_us/product-security.html
- https://advisory.splunk.com/advisories/SVD-2023-0212
tags:
analytic_story:
- Splunk Vulnerabilities
@@ -56,7 +57,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_csrf_in_the_ssg_kvstore_client_endpoint_data.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_csrf_in_the_ssg_kvstore_client_endpoint_data.log
source: splunkd_access.log
sourcetype: splunkd_access
custom_index: _internal
detections/application/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.yml
+13 -9
View File
@@ -1,16 +1,19 @@
name: Splunk Data exfiltration from Analytics Workspace using sid query
id: b6d77c6c-f011-4b03-8650-8f10edb7c4a8
version: 1
date: '2022-11-01'
version: 2
date: '2024-05-25'
author: Rod Soto, Eric McGinnis
status: production
type: Hunting
description: This hunting search allows operator to discover attempts to exfiltrate
data by executing a prepositioned malicious search ID in Analytic Workspace in Splunk
Enterprise versions 8.2.9,8.1.12,9.0.2. The attack is browser-based. It requires
the attacker to compel a victim to initiate a request within their browser (phishing).
The attacker cannot exploit the vulnerability at will.
data_source:
description: The following analytic identifies attempts to exfiltrate data by executing
a prepositioned malicious search ID in Splunk's Analytic Workspace. It leverages
the `audit_searches` data source to detect suspicious `mstats` commands indicative
of injection attempts. This activity is significant as it may indicate a phishing-based
attack where an attacker compels a victim to initiate a malicious request, potentially
leading to unauthorized data access. If confirmed malicious, this could result in
significant data exfiltration, compromising sensitive information and impacting
the organization's security posture.
data_source:
- Splunk
search: '`audit_searches` info=granted search NOT ("audit_searches") search NOT ("security_content_summariesonly")
AND ((search="*mstats*[*]*" AND provenance="N/A") OR (search="*mstats*\\\"*[*]*\\\"*"))|
@@ -59,7 +62,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1567/splunk/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.txt
- data:
https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1567/splunk/splunk_data_exfiltration_from_analytics_workspace_using_sid_query.txt
source: audittrail
sourcetype: audittrail
custom_index: _audit
detections/application/splunk_digital_certificates_infrastructure_version.yml
+13 -8
View File
@@ -1,15 +1,19 @@
name: Splunk Digital Certificates Infrastructure Version
id: 3c162281-7edb-4ebc-b9a4-5087aaf28fa7
version: 1
date: '2022-05-26'
version: 2
date: '2024-05-27'
author: Lou Stella, Splunk
status: production
type: Hunting
description: This search will check the TLS validation is properly configured on the
search head it is run from as well as its search peers after Splunk version 9. Other
components such as additional search heads or anything this rest command cannot
be distributed to will need to be manually checked.
data_source:
description: The following analytic identifies improper TLS validation configuration
on Splunk search heads and peers post version 9. It leverages REST API calls to
retrieve server information and SSL configuration settings, checking fields like
`sslVerifyServerCert` and `sslVerifyServerName`. This activity is significant for
a SOC as improper TLS settings can expose the infrastructure to man-in-the-middle
attacks and data breaches. If confirmed malicious, attackers could intercept or
manipulate data, compromising the integrity and confidentiality of communications
within the Splunk environment.
data_source:
- Splunk
search: '| rest /services/server/info | table splunk_server version server_roles |
join splunk_server [| rest /servicesNS/nobody/search/configs/conf-server/ search="sslConfig"|
@@ -58,7 +62,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
source: audittrail
sourcetype: audittrail
update_timestamp: true
detections/application/splunk_digital_certificates_lack_of_encryption.yml
+12 -12
View File
@@ -1,19 +1,18 @@
name: Splunk Digital Certificates Lack of Encryption
id: 386a7ebc-737b-48cf-9ca8-5405459ed508
version: 1
date: '2022-05-26'
version: 2
date: '2024-05-18'
author: Lou Stella, Splunk
status: production
type: Anomaly
description: On June 14th, 2022, Splunk released a security advisory relating to the
authentication that happens between Universal Forwarders and Deployment Servers.
In some circumstances, an unauthenticated client can download forwarder bundles
from the Deployment Server. In other circumstances, a client may be allowed to publish
a forwarder bundle to other clients, which may allow for arbitrary code execution.
The fixes for these require upgrading to at least Splunk 9.0 on the forwarder as
well. This is a great opportunity to configure TLS across the environment. This
search looks for forwarders that are not using TLS and adds risk to those entities.
data_source:
description: The following analytic identifies Splunk forwarder connections that are
not using TLS encryption. It leverages data from the `splunkd` logs, specifically
looking for connections where the `ssl` field is set to "false". This activity is
significant because unencrypted connections can expose sensitive data and allow
unauthorized access, posing a security risk. If confirmed malicious, an attacker
could exploit this vulnerability to download or publish forwarder bundles, potentially
leading to arbitrary code execution and further compromise of the environment.
data_source:
- Splunk
search: '`splunkd` group="tcpin_connections" ssl="false" | stats values(sourceIp)
latest(fwdType) latest(version) by hostname | `splunk_digital_certificates_lack_of_encryption_filter`'
@@ -65,7 +64,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.003/splunk_fwder/splunkd.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1587.003/splunk_fwder/splunkd.log
source: /opt/splunk/var/log/splunk/metrics.log
sourcetype: splunkd
update_timestamp: false
detections/application/splunk_dos_using_malformed_saml_request.yml
+24 -13
View File
@@ -1,21 +1,31 @@
name: Splunk DoS Using Malformed SAML Request
id: 8e8a86d5-f323-4567-95be-8e817e2baee6
version: 1
date: '2023-09-05'
version: 2
date: '2024-05-29'
author: Rod Soto
status: production
type: Hunting
data_source:
data_source:
- Splunk
description: In Splunk Enterprise versions lower than 9.0.6, and 8.2.12, an attacker can send a malformed security assertion markup language SAML request to the /saml/acs REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.The SAML extensible markup language (XML) parser does not fail SAML signature validation when the attacker modifies the URI in the SAML request. Instead it attempts to access the modified URI, which causes the Splunk daemon to crash or hang.
search: '`splunkd` event_message=*error* expr=*xpointer* | stats count min(_time) as firstTime max(_time) as lastTime by component expr splunk_server event_message | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_dos_using_malformed_saml_request_filter`'
how_to_implement: To run this search, you must have access to the _internal index.
known_false_positives: This search will show false positives. The analyst must look for errors and a pointer indicating a malicious file.
description: The following analytic detects a denial of service (DoS) attempt using
a malformed SAML request targeting the /saml/acs REST endpoint in Splunk Enterprise
versions lower than 9.0.6 and 8.2.12. It leverages `splunkd` logs, specifically
looking for error messages containing "xpointer" in the `expr` field. This activity
is significant because it can cause the Splunk daemon to crash or hang, disrupting
service availability. If confirmed malicious, this attack could lead to prolonged
downtime, impacting the organization's ability to monitor and respond to security
events.
search: '`splunkd` event_message=*error* expr=*xpointer* | stats count min(_time)
as firstTime max(_time) as lastTime by component expr splunk_server event_message
| `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_dos_using_malformed_saml_request_filter`'
how_to_implement: To run this search, you must have access to the _internal index.
known_false_positives: This search will show false positives. The analyst must look
for errors and a pointer indicating a malicious file.
references:
- https://advisory.splunk.com/advisories/SVD-2023-0802
tags:
analytic_story:
- Splunk Vulnerabilities
- Splunk Vulnerabilities
asset_type: Endpoint
confidence: 30
impact: 50
@@ -34,14 +44,15 @@ tags:
risk_score: 15
required_fields:
- component
- expr
- host
- event_message
- expr
- host
- event_message
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk/splunk_dos_using_malformed_saml_request_splunkd.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk/splunk_dos_using_malformed_saml_request_splunkd.log
source: splunkd.log
sourcetype: splunkd
custom_index: _internal
custom_index: _internal
detections/application/splunk_dos_via_malformed_s2s_request.yml
+13 -8
View File
@@ -1,15 +1,19 @@
name: Splunk DoS via Malformed S2S Request
id: fc246e56-953b-40c1-8634-868f9e474cbd
version: 2
date: '2022-03-24'
version: 3
date: '2024-05-27'
author: Lou Stella, Splunk
status: production
type: TTP
description: On March 24th, 2022, Splunk published a security advisory for a possible
Denial of Service stemming from the lack of validation in a specific key-value field
in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation
in patched versions of Splunk.
data_source:
description: The following analytic identifies attempts to exploit a Denial of Service
(DoS) vulnerability in the Splunk-to-Splunk (S2S) protocol by detecting malformed
S2S requests. It leverages `splunkd` logs, specifically looking for "ERROR" level
logs from the "TcpInputProc" component with the thread name "FwdDataReceiverThread"
and the message "Invalid _meta atom." This activity is significant as it targets
a known vulnerability that could disrupt Splunk services. If confirmed malicious,
this could lead to service outages, impacting the availability and reliability of
Splunk for monitoring and analysis.
data_source:
- Splunk
search: '`splunkd` log_level="ERROR" component="TcpInputProc" thread_name="FwdDataReceiverThread"
"Invalid _meta atom" | table host, src | `splunk_dos_via_malformed_s2s_request_filter`'
@@ -55,7 +59,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk_indexer_dos/splunkd.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1498/splunk_indexer_dos/splunkd.log
source: /opt/splunk/var/log/splunk/splunkd.log
sourcetype: splunkd
update_timestamp: true
detections/application/splunk_dos_via_post_request_datamodel_endpoint.yml
+56
View File
@@ -0,0 +1,56 @@
name: Splunk DoS via POST Request Datamodel Endpoint
id: 45766810-dbb2-44d4-b889-b4ba3ee0d1f5
version: 1
status: production
date: '2024-07-01'
author: Rod Soto
type: Hunting
data_source: []
description: The following is a hunting search that allows investigation of error messages indicating Splunk HTTP engine shutdown as a result of a crafted posted request against '/datamodel/model' endpoint.
search: >-
`splunkd_webs` log_level=INFO message="ENGINE: HTTP Server cherrypy._cpwsgi_server.CPWSGIServer(('127.0.0.1', 8065)) shut down"
| stats count min(_time) as firstTime max(_time) as lastTime by splunk_server message
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_dos_via_post_request_datamodel_endpoint_filter`
how_to_implement: Need access to the internal indexes.
known_false_positives: This is a hunting search and will produce false positives as other causes can also shut down splunk HTTP engine, however this denial of service error is associated to a request to the datamodel/model endpoing which operator can research and find proximity of request and message in logs.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0710
cve:
- CVE-2024-36986
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 50
impact: 100
kill_chain_phases:
- Exploitation
message: Possible Denial of Service attack against $splunk_server$
mitre_attack_id:
- T1499
nist:
- DE.CM
observable:
- name: splunk_server
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- UPDATE
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/T1499/splunk/SVD-2024-0710_web_service_splunk_web_service.log
source: /opt/splunk/var/log/splunk/web_service.log
sourcetype: splunk_web_service
custom_index: _internal
detections/application/splunk_dos_via_printf_search_function.yml
+23 -12
View File
@@ -1,18 +1,28 @@
name: Splunk DOS via printf search function
id: 78b48d08-075c-4eac-bd07-e364c3780867
version: 1
date: '2023-08-30'
version: 2
date: '2024-05-25'
author: Rod Soto, Eric McGinnis, Splunk
status: production
type: Hunting
data_source:
data_source:
- Splunk
description: This hunting search provides information on detecting a vulnerability In Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, an attacker can use the printf SPL function to perform a denial of service against the Splunk Enterprise instance.
search: '`audit_searches` "*makeresults * eval * fieldformat *printf*" user!="splunk_system_user" search!="*audit_searches*"
| stats count by user splunk_server host search
| convert ctime(*time) |`splunk_dos_via_printf_search_function_filter`'
how_to_implement: This search requires the ability to search internal indexes.
known_false_positives: This search may produces false positives, analyst most focuse in the use of printf conversion function of eval to craft an expression that splunkd cannot interpret correctly causing it to crash.
description: The following analytic identifies the use of the `printf` SPL function
in Splunk searches, which can be exploited for a denial of service (DoS) attack.
It detects this activity by querying the `audit_searches` data source for specific
patterns involving `makeresults`, `eval`, `fieldformat`, and `printf` functions,
excluding searches by the `splunk_system_user`. This activity is significant because
it targets a known vulnerability in Splunk Enterprise versions lower than 8.1.14,
8.2.12, 9.0.6, and 9.1.1, potentially disrupting the availability of the Splunk
instance. If confirmed malicious, this could lead to service outages and impact
the monitoring and logging capabilities of the organization.
search: '`audit_searches` "*makeresults * eval * fieldformat *printf*" user!="splunk_system_user"
search!="*audit_searches*" | stats count by user splunk_server host search | convert
ctime(*time) |`splunk_dos_via_printf_search_function_filter`'
how_to_implement: This search requires the ability to search internal indexes.
known_false_positives: This search may produces false positives, analyst most focuse
in the use of printf conversion function of eval to craft an expression that splunkd
cannot interpret correctly causing it to crash.
references:
- https://advisory.splunk.com/
tags:
@@ -37,15 +47,16 @@ tags:
- Splunk Cloud
risk_score: 100
required_fields:
- user
- user
- splunk_server
- host
- search
- search
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499.004/splunk/splunk_printf_abuse.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499.004/splunk/splunk_printf_abuse.log
source: audittrail
sourcetype: audittrail
custom_index: _audit
detections/application/splunk_endpoint_denial_of_service_dos_zip_bomb.yml
+13 -11
View File
@@ -1,18 +1,19 @@
name: Splunk Endpoint Denial of Service DoS Zip Bomb
id: b237d393-2f57-4531-aad7-ad3c17c8b041
version: 1
date: '2022-08-02'
version: 2
date: '2024-05-27'
author: Marissa Bower, Rod Soto, Splunk
status: production
type: TTP
description: This search allows operator to identify Splunk search app crashes resulting
from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11
and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before
crash. This search will provide Universal Forwarder errors from uploaded binary
files (zip compression) which are used for this attack. If an analyst sees results
from this search we suggest you investigate and triage what zip file was uploaded,
zip compressed files may have different extensions.
data_source:
description: The following analytic identifies crashes in the Splunk search app caused
by specially crafted ZIP files, affecting Universal Forwarder versions 8.1.11 and
8.2 versions below 8.2.7.1. It detects this activity by monitoring Universal Forwarder
error logs for specific messages indicating invalid or binary file issues. This
activity is significant because it can disrupt Splunk operations, leading to potential
data loss or monitoring gaps. If confirmed malicious, this attack could result in
a denial of service, hindering the organization's ability to monitor and respond
to other security incidents effectively.
data_source:
- Splunk
search: '`splunkd` component=FileClassifierManager event_message=*invalid* event_message=*binary*
|stats count by host component event_message | `splunk_endpoint_denial_of_service_dos_zip_bomb_filter`'
@@ -52,7 +53,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_zip_bomb_vulnerability.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_zip_bomb_vulnerability.log
source: /opt/splunkforwarder/var/log/splunk/splunkd.log
sourcetype: splunkd
custom_index: _internal
detections/application/splunk_enterprise_kv_store_incorrect_authorization.yml
+28 -19
View File
@@ -1,20 +1,28 @@
name: Splunk Enterprise KV Store Incorrect Authorization
id: 8f0e8380-a835-4f2b-b749-9ce119364df0
version: 1
date: '2024-01-18'
version: 2
date: '2024-05-10'
author: Rod Soto, Eric McGinnis, Chase Franklin
status: production
type: Hunting
data_source:
data_source:
- Splunk
description: In Splunk Enterprise versions below 9.0.8 and 9.1.3, Splunk app key value store KV Store improperly handles permissions for users using the REST application programming interface (API). This can potentially result in the deletion of KV Store collections.
search: '`splunkda` uri=/servicesNS/nobody/search/admin/collections-conf/_reload status=2* method="POST" user=* file=_reload
| stats count min(_time) as firstTime max(_time) as lastTime values(status) as status by host clientip file method
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_enterprise_kv_store_incorrect_authorization_filter`'
how_to_implement: Requires access to internal indexes and REST API enabled instances.
known_false_positives: This is a hunting search and will produce false positives. Operator must follow results into instances where curl requests coming from actual users may indicate intent of exploitation.
description: The following analytic detects unauthorized attempts to reload Splunk
KV Store collections via the REST API. It leverages internal index logs to identify
POST requests to the `/servicesNS/nobody/search/admin/collections-conf/_reload`
endpoint, focusing on status codes starting with '2'. This activity is significant
as it may indicate improper permission handling, potentially leading to unauthorized
deletion of KV Store collections. If confirmed malicious, this could result in data
loss or unauthorized data manipulation, impacting the integrity and availability
of critical Splunk data.
search: '`splunkda` uri=/servicesNS/nobody/search/admin/collections-conf/_reload status=2*
method="POST" user=* file=_reload | stats count min(_time) as firstTime max(_time)
as lastTime values(status) as status by host clientip file method | `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | `splunk_enterprise_kv_store_incorrect_authorization_filter`'
how_to_implement: Requires access to internal indexes and REST API enabled instances.
known_false_positives: This is a hunting search and will produce false positives.
Operator must follow results into instances where curl requests coming from actual
users may indicate intent of exploitation.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0105
tags:
@@ -39,16 +47,17 @@ tags:
risk_score: 25
required_fields:
- uri
- status
- method
- file
- clientip
- host
- status
- method
- file
- clientip
- host
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/splunk/splunk_enterprise_kv_store_incorrect_authorization_splunkd_access.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/splunk/splunk_enterprise_kv_store_incorrect_authorization_splunkd_access.log
source: /opt/splunk/var/log/splunk/splunkd_access.log
sourcetype: splunkd_access
custom_index: _internal
sourcetype: splunkd_access
custom_index: _internal
detections/application/splunk_enterprise_windows_deserialization_file_partition.yml
+3 -3
View File
@@ -1,7 +1,7 @@
name: Splunk Enterprise Windows Deserialization File Partition
id: 947d4d2e-1b64-41fc-b32a-736ddb88ce97
version: 2
date: '2024-05-18'
version: 3
date: '2024-07-01'
author: Rod Soto, Eric McGinnis, Chase Franklin
status: production
type: TTP
@@ -15,7 +15,7 @@ description: The following analytic identifies attempts to exploit a deserializa
If confirmed malicious, an attacker could gain unauthorized access, execute arbitrary
code, and potentially compromise the entire Splunk environment, leading to data
breaches and further system exploitation.
search: '`splunk_python` request_path="/en-US/app/search/C:\\Program" *strings* |
search: '`splunk_python` request_path="/*/app/search/C:\\Program" *strings* |
rex "request_path=(?<file_path>[^\"]+)" | rex field=file_path "[^\"]+/(?<file_name>[^\"\''\s/\\\\]+)"
| stats min(_time) as firstTime max(_time) as lastTime values(file_path) as file_path
values(file_name) as file_name by index, sourcetype, host | `security_content_ctime(firstTime)`
detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml
+27 -15
View File
@@ -1,19 +1,30 @@
name: Splunk ES DoS Investigations Manager via Investigation Creation
id: 7f6a07bd-82ef-46b8-8eba-802278abd00e
version: 1
date: '2024-01-04'
version: 2
date: '2024-05-25'
author: Rod Soto, Eric McGinnis, Chase Franklin
status: production
type: TTP
data_source:
data_source:
- Splunk
description: In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted.
search: '`splunkd_investigation_rest_handler` method=put msg=*investigation* status=error | stats count min(_time) as firstTime max(_time) as lastTime by user host method msg
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_es_dos_investigations_manager_via_investigation_creation_filter`'
how_to_implement: This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2.
known_false_positives: The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event.
description: The following analytic detects the creation of malformed Investigations
in Splunk Enterprise Security (ES) versions lower than 7.1.2, which can lead to
a denial of service (DoS). It leverages internal Splunk logs, specifically monitoring
the `splunkd_investigation_rest_handler` with error statuses during investigation
creation. This activity is significant as it can disrupt the functionality of the
Investigations manager, hindering incident response efforts. If confirmed malicious,
this could prevent security teams from accessing critical investigation data, severely
impacting their ability to manage and respond to security incidents effectively.
search: '`splunkd_investigation_rest_handler` method=put msg=*investigation* status=error
| stats count min(_time) as firstTime max(_time) as lastTime by user host method
msg | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` |
`splunk_es_dos_investigations_manager_via_investigation_creation_filter`'
how_to_implement: This search requires access to internal indexes. Only affects Splunk
Enterprise Security versions lower than 7.1.2.
known_false_positives: The vulnerability requires an authenticated session and access
to create an Investigation. It only affects the availability of the Investigations
manager, but without the manager, the Investigations functionality becomes unusable
for most users. This search gives the exact offending event.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0102
tags:
@@ -29,7 +40,7 @@ tags:
- T1499
observable:
- name: user
type: User
type: User
role:
- Victim
- name: host
@@ -41,14 +52,15 @@ tags:
risk_score: 100
required_fields:
- method
- msg
- status
- user
- msg
- status
- user
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22165_investigation_rest_handler.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22165_investigation_rest_handler.log
source: /opt/splunk/var/log/splunk/investigation_handler.log
sourcetype: investigation_rest_handler
custom_index: _internal
detections/application/splunk_es_dos_through_investigation_attachments.yml
+30 -18
View File
@@ -1,20 +1,31 @@
name: Splunk ES DoS Through Investigation Attachments
id: bb85b25e-2d6b-4e39-bd27-50db42edcb8f
version: 1
date: '2024-01-04'
version: 2
date: '2024-05-29'
author: Rod Soto, Eric McGinnis, Chase Franklin
status: production
type: TTP
data_source:
data_source:
- Splunk
description: In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible.
search: '`splunkd_investigation_rest_handler` status=error object=investigation
| stats min(_time) as firstTime max(_time) as lastTime values(status) as status values(msg) as msg values(id) as investigation_id by user
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_es_dos_through_investigation_attachments_filter`'
how_to_implement: This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2.
known_false_positives: This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager.
description: The following analytic detects attempts to perform a denial of service
(DoS) attack through investigation attachments in Splunk Enterprise Security (ES)
versions below 7.1.2. It leverages internal Splunk logs, specifically monitoring
the `splunkd_investigation_rest_handler` for error statuses related to investigation
objects. This activity is significant because it can render the Investigation feature
inaccessible, disrupting incident response and forensic analysis. If confirmed malicious,
this attack could prevent security teams from effectively managing and investigating
security incidents, leading to prolonged exposure and potential data breaches.
search: '`splunkd_investigation_rest_handler` status=error object=investigation |
stats min(_time) as firstTime max(_time) as lastTime values(status) as status values(msg)
as msg values(id) as investigation_id by user | `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` | `splunk_es_dos_through_investigation_attachments_filter`'
how_to_implement: This search requires access to internal indexes, only affects Enterprise
Security versions below 7.1.2.
known_false_positives: This search will show the exact DoS event via error message
and investigation id. The error however does not point exactly at the uploader as
any users associated with the investigation will be affected. Operator must investigate
using investigation id the possible origin of the malicious upload. Attack only
affects specific investigation not the investigation manager.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0101
tags:
@@ -30,23 +41,24 @@ tags:
- T1499
observable:
- name: user
type: User
type: User
role:
- Victim
product:
- Splunk Enterprise Security
risk_score: 100
required_fields:
- user
- status
- msg
- id
- object
- user
- status
- msg
- id
- object
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22164_investigation_rest_handler.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22164_investigation_rest_handler.log
source: /opt/splunk/var/log/splunk/investigation_handler.log
sourcetype: investigation_rest_handler
custom_index: _internal
detections/application/splunk_http_response_splitting_via_rest_spl_command.yml
+24 -10
View File
@@ -1,21 +1,34 @@
name: Splunk HTTP Response Splitting Via Rest SPL Command
id: e615a0e1-a1b2-4196-9865-8aa646e1708c
version: 1
date: '2023-05-23'
version: 2
date: '2024-05-27'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: A low-privileged user, using a specially crafted search command, can trigger an HTTP response splitting vulnerability with the rest SPL command that lets them potentially access other REST endpoints in the system arbitrarily, including accessing restricted content such as password files. This is because the user is able to inject the rest SPL command into the q parameter of an HTTP GET web request. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will.
search: '`audit_searches` AND search IN ("*|*rest*POST*","*|*rest*PUT*","*|*rest*PATCH*","*|*rest*DELETE*") AND NOT search="*audit_searches*" | table user info has_error_msg search _time | `splunk_http_response_splitting_via_rest_spl_command_filter`'
how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This search may assist in detecting possible http response splitting exploitation attemptss.
known_false_positives: This search may have produce false positives as malformed or erroneous requests made to this endpoint may be executed willingly or erroneously by operators.
description: The following analytic identifies attempts to exploit an HTTP response
splitting vulnerability via the rest SPL command in Splunk. It detects this activity
by analyzing audit logs for specific search commands that include REST methods like
POST, PUT, PATCH, or DELETE. This behavior is significant because it indicates a
potential attempt to access restricted REST endpoints, which could lead to unauthorized
access to sensitive information. If confirmed malicious, this activity could allow
an attacker to access restricted content, such as password files, by injecting commands
into HTTP requests.
search: '`audit_searches` AND search IN ("*|*rest*POST*","*|*rest*PUT*","*|*rest*PATCH*","*|*rest*DELETE*")
AND NOT search="*audit_searches*" | table user info has_error_msg search _time |
`splunk_http_response_splitting_via_rest_spl_command_filter`'
how_to_implement: This detection does not require you to ingest any new data. The
detection does require the ability to search the _audit index. This search may assist
in detecting possible http response splitting exploitation attemptss.
known_false_positives: This search may have produce false positives as malformed or
erroneous requests made to this endpoint may be executed willingly or erroneously
by operators.
references:
- https://advisory.splunk.com/
tags:
analytic_story:
- Splunk Vulnerabilities
- Splunk Vulnerabilities
asset_type: Endpoint
atomic_guid: []
confidence: 50
@@ -33,14 +46,15 @@ tags:
risk_score: 25
required_fields:
- search
- testing_endpoint
- info
- testing_endpoint
- info
- has_error_msg
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027.006/splunk/splunk_http_response_splitting_via_rest_spl_command.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1027.006/splunk/splunk_http_response_splitting_via_rest_spl_command.log
source: audittrail
sourcetype: audittrail
custom_index: _audit
detections/application/splunk_information_disclosure_on_account_login.yml
+60
View File
@@ -0,0 +1,60 @@
name: Splunk Information Disclosure on Account Login
id: 2bae5d19-6d1b-4db0-82ab-0af5ac5f836c
version: 1
date: '2024-07-01'
author: Rod Soto
status: production
type: Hunting
data_source:
- Splunk
description: This is a composed hunting search that looks for possible user enumeration attempts when SAML is enabled on a Splunk instance by capturing different responses from server.
search: '`splunkd` component=UiAuth status=failure action=login TcpChannelThread
| stats count min(_time) as firstTime max(_time) as lastTime by user status action clientip
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_information_disclosure_on_account_login_filter`'
how_to_implement: Requires access to internal indexes _internal.
known_false_positives: This is a hunting search and requires operator to search for large number of login failures from several users indicating possible user enumeration attempts. May capture genuine login failures.
references:
- https://advisory.splunk.com/SVD-2024-0716
cve:
- CVE-2024-36996
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 50
impact: 10
kill_chain_phases:
- Exploitation
message: Possible user enumeration attack against $clientip$
mitre_attack_id:
- T1087
nist:
- DE.CM
observable:
- name: clientip
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- user
- action
- status
- clientip
- host
risk_score: 5
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1087/splunk/SVD-2024-0716_splunkd_splunkd.log
source: /opt/splunk/var/log/splunk/splunkd.log
sourcetype: splunkd
custom_index: _internal
detections/application/splunk_list_all_nonstandard_admin_accounts.yml
+10 -10
View File
@@ -1,18 +1,18 @@
name: Splunk list all nonstandard admin accounts
id: 401d689c-8596-4c6b-a710-7b6fdca296d3
version: 1
date: '2023-02-07'
version: 2
date: '2024-05-21'
author: Rod Soto
status: experimental
type: Hunting
description: 'This search will enumerate all Splunk Accounts with administrative rights
on this instance. It deliberately ignores the default admin account since this
is assumed to be present. This search may help in a detection the Cross-Site Scripting
Attack listed: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a
View allows for Cross-Site Scripting in an XML View through the ''layoutPanel''
attribute in the ''module'' tag. The vulnerability affects instances with Splunk
Web enabled.'
data_source:
description: 'The following analytic identifies nonstandard Splunk accounts with administrative
rights on the instance, excluding the default admin account. It uses REST API calls
to retrieve user data and filters for accounts with admin capabilities. This activity
is significant as unauthorized admin accounts can indicate potential security breaches
or misconfigurations. If confirmed malicious, attackers could leverage these accounts
to execute commands, escalate privileges, or persist within the environment, posing
a significant risk to the integrity and security of the Splunk instance.'
data_source:
- Splunk
search: '| rest splunk_server=local /services/authentication/users |search capabilities=admin*
OR imported_capabilities=admin* title!=admin | table title roles capabilities splunk_server
detections/application/splunk_low_privilege_user_can_view_hashed_splunk_password.yml
+29 -16
View File
@@ -1,17 +1,29 @@
name: Splunk Low Privilege User Can View Hashed Splunk Password
id: a1be424d-e59c-4583-b6f9-2dcc23be4875
version: 1
date: '2023-05-09'
version: 2
date: '2024-05-29'
author: Rod Soto, Eric McGinnis, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user who holds the user role can see the hashed version of the initial user name and password for the Splunk instance by using the rest SPL command against the conf-user-seed REST endpoint. This can lead to a privilege escalation that lets the user take over the admin account on the instance.
search: '`splunkd_web` uri="*/servicesNS/nobody/system/configs/conf-user-seed*" | stats earliest(_time) as event_time values(method) as method values(status) as
status values(clientip) as clientip values(useragent) as useragent values(file) as file by user | convert ctime(*time) | `splunk_low_privilege_user_can_view_hashed_splunk_password_filter`'
how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to discover attempts to access con-user-seed file content.
known_false_positives: This search may produce false positives as accounts with high privileges may access this file. Operator will need to investigate these actions in order to discern exploitation attempts.
description: The following analytic identifies low-privilege users attempting to view
hashed Splunk passwords by querying the conf-user-seed REST endpoint. It leverages
data from the `splunkd_web` logs, specifically monitoring access to the conf-user-seed
endpoint. This activity is significant because it can indicate an attempt to escalate
privileges by obtaining hashed credentials, potentially leading to admin account
takeover. If confirmed malicious, this could allow an attacker to gain administrative
control over the Splunk instance, compromising the entire environment's security.
search: '`splunkd_web` uri="*/servicesNS/nobody/system/configs/conf-user-seed*" |
stats earliest(_time) as event_time values(method) as method values(status) as status
values(clientip) as clientip values(useragent) as useragent values(file) as file
by user | convert ctime(*time) | `splunk_low_privilege_user_can_view_hashed_splunk_password_filter`'
how_to_implement: This detection does not require you to ingest any new data. The
detection does require the ability to search the _audit index. This detection may
assist in efforts to discover attempts to access con-user-seed file content.
known_false_positives: This search may produce false positives as accounts with high
privileges may access this file. Operator will need to investigate these actions
in order to discern exploitation attempts.
references:
- https://advisory.splunk.com/
tags:
@@ -28,23 +40,24 @@ tags:
- name: clientip
type: IP Address
role:
- Attacker
- Attacker
product:
- Splunk Enterprise
risk_score: 81
required_fields:
- _time
- clientip
- useragent
- file
- user
- method
- status
- _time
- clientip
- useragent
- file
- user
- method
- status
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1212/splunk/splunk_low_privilege_user_can_view_hashed_splunk_password.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1212/splunk/splunk_low_privilege_user_can_view_hashed_splunk_password.log
source: /opt/splunk/var/log/splunk/web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.yml
+28 -15
View File
@@ -1,23 +1,35 @@
name: Splunk Path Traversal In Splunk App For Lookup File Edit
id: 8ed58987-738d-4917-9e44-b8ef6ab948a6
version: 1
date: '2023-05-11'
version: 2
date: '2024-05-22'
author: Rod Soto, Eric McGinnis
status: production
type: Hunting
data_source:
- Splunk
description: In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user with access to the Splunk App for Lookup File Editing can, with a specially crafted web request, trigger a path traversal exploit that can then be used to read and write to restricted areas of the Splunk installation directory, including but not limited to the password hash file for the instance.
search: '`splunkda` uri_query=*lookup_file* | table clientip uri_query lookup_file owner namespace version | stats count by clientip namespace lookup_file uri_query | `splunk_path_traversal_in_splunk_app_for_lookup_file_edit_filter`'
how_to_implement: This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection is meant for on premise environments,
and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests.
known_false_positives: This search may find additional path traversal exploitation attempts or malformed requests.
description: The following analytic identifies path traversal attempts in the Splunk
App for Lookup File Editing. It detects specially crafted web requests targeting
lookup files by analyzing the `uri_query` field in the `_internal` index. This activity
is significant because it allows low-privilege users to read and write to restricted
areas of the Splunk installation directory, potentially accessing sensitive files
like password hashes. If confirmed malicious, this could lead to unauthorized access,
data breaches, and further exploitation of the Splunk environment.
search: '`splunkda` uri_query=*lookup_file* | table clientip uri_query lookup_file
owner namespace version | stats count by clientip namespace lookup_file uri_query
| `splunk_path_traversal_in_splunk_app_for_lookup_file_edit_filter`'
how_to_implement: This detection does not require you to ingest any new data. The
detection does require the ability to search the _internal index. This detection
is meant for on premise environments, and if executed on internet facing servers
without a WAF may produce a lot of results. This detection will not work against
obfuscated path traversal requests.
known_false_positives: This search may find additional path traversal exploitation
attempts or malformed requests.
references:
- https://advisory.splunk.com/
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Endpoint
asset_type: Endpoint
atomic_guid: []
confidence: 80
impact: 50
@@ -34,17 +46,18 @@ tags:
risk_score: 40
required_fields:
- clientip
- uri_query
- event_message
- lookup_file
- owner
- method
- uri_query
- event_message
- lookup_file
- owner
- method
- user
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.log
source: splunkd_access
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/splunk_path_traversal_in_splunk_app_for_lookup_file_edit.log
source: splunkd_access
sourcetype: splunkd_access
custom_index: _internal
detections/application/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.yml
+27 -13
View File
@@ -1,16 +1,29 @@
name: Splunk Persistent XSS Via URL Validation Bypass W Dashboard
id: 8a43558f-a53c-4ee4-86c1-30b1e8ef3606
version: 1
date: '2023-05-09'
version: 2
date: '2024-05-20'
author: Rod Soto
status: production
type: Hunting
data_source:
- Splunk
description: In Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13, a low-privileged user can bypass URL validation to perform a path traversal and access restricted and confidential information by targeting other users on the instance, including the admin user. The only affected version of bootstrap which shipped with Splunk was version 2.3.1, so the search is targeted at that version alone.
search: '`splunkd_web` method=GET uri_path="*bootstrap-2.3.1*" file="*.js" | table _time clientip uri_path file status | `splunk_persistent_xss_via_url_validation_bypass_w_dashboard_filter`'
how_to_implement: This search does not require additional data to be ingested. This search requires ability to search _internal index. This search helps discover access to vulnerable bootstrap versions.
known_false_positives: This search will produce numerous false positives as it shows ANY accesses to vulnerable bootstrap Javascript files. Accesses to these files occur during normal Splunk usage. To reduce or eliminate false positives, update the a version of Splunk which has addressed the vulnerability.
description: The following analytic detects attempts to bypass URL validation in Splunk
Enterprise versions below 9.0.4, 8.2.10, and 8.1.13 by targeting the vulnerable
bootstrap version 2.3.1. It leverages `splunkd_web` logs, specifically monitoring
GET requests to JavaScript files within the vulnerable bootstrap path. This activity
is significant as it can allow a low-privileged user to perform path traversal,
potentially accessing restricted and confidential information. If confirmed malicious,
this could lead to unauthorized data access and compromise of sensitive information,
including targeting admin users.
search: '`splunkd_web` method=GET uri_path="*bootstrap-2.3.1*" file="*.js" | table
_time clientip uri_path file status | `splunk_persistent_xss_via_url_validation_bypass_w_dashboard_filter`'
how_to_implement: This search does not require additional data to be ingested. This
search requires ability to search _internal index. This search helps discover access
to vulnerable bootstrap versions.
known_false_positives: This search will produce numerous false positives as it shows
ANY accesses to vulnerable bootstrap Javascript files. Accesses to these files
occur during normal Splunk usage. To reduce or eliminate false positives, update
the a version of Splunk which has addressed the vulnerability.
references:
- https://advisory.splunk.com/
tags:
@@ -20,9 +33,9 @@ tags:
atomic_guid: []
confidence: 20
impact: 80
cve:
cve:
- CVE-2019-8331
message: Attempted access to vulnerable bootstrap file by $clientip$
message: Attempted access to vulnerable bootstrap file by $clientip$
mitre_attack_id:
- T1189
observable:
@@ -34,15 +47,16 @@ tags:
- Splunk Enterprise
risk_score: 16
required_fields:
- file
- uri
- clientip
- user
- file
- uri
- clientip
- user
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_persistent_xss_via_url_validation_bypass_w_dashboard.log
source: /opt/splunk/var/log/splunk/web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_process_injection_forwarder_bundle_downloads.yml
+13 -12
View File
@@ -1,19 +1,19 @@
name: Splunk Process Injection Forwarder Bundle Downloads
id: 8ea57d78-1aac-45d2-a913-0cd603fb6e9e
version: 1
date: '2022-05-26'
version: 2
date: '2024-05-23'
author: Lou Stella, Splunk
status: production
type: Hunting
description: On June 14th, 2022, Splunk released a security advisory relating to the
authentication that happens between Universal Forwarders and Deployment Servers.
In some circumstances, an unauthenticated client can download forwarder bundles
from the Deployment Server. This hunting search pulls a full list of forwarder bundle
downloads where the peer column is the forwarder, the host column is the Deployment
Server, and then you have a list of the apps downloaded and the serverclasses in
which the peer is a member of. You should look for apps or clients that you do not
recognize as being part of your environment.
data_source:
description: The following analytic identifies unauthorized forwarder bundle downloads
from Splunk Deployment Servers. It leverages native Splunk logs, specifically the
`splunkd` component "PackageDownloadRestHandler," to detect instances where an unauthenticated
client may have downloaded forwarder bundles. This activity is significant because
it could indicate a potential security breach, allowing unauthorized access to sensitive
configurations and applications. If confirmed malicious, an attacker could gain
insights into the deployment server's environment, potentially leading to further
exploitation or lateral movement within the network.
data_source:
- Splunk
search: '`splunkd` component="PackageDownloadRestHandler" | stats values(app) values(serverclass)
by peer, host | `splunk_process_injection_forwarder_bundle_downloads_filter`'
@@ -60,7 +60,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/splunk_ds/splunkd.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1055/splunk_ds/splunkd.log
source: /opt/splunk/var/log/splunk/splunkd.log
sourcetype: splunkd
update_timestamp: false
detections/application/splunk_protocol_impersonation_weak_encryption_configuration.yml
+13 -12
View File
@@ -1,19 +1,19 @@
name: Splunk Protocol Impersonation Weak Encryption Configuration
id: 900892bf-70a9-4787-8c99-546dd98ce461
version: 1
date: '2022-05-25'
version: 2
date: '2024-05-28'
author: Lou Stella, Splunk
status: production
type: Hunting
description: On June 14th, 2022, Splunk released a security advisory relating to TLS
validation occuring within the httplib and urllib python libraries shipped with
Splunk. In addition to upgrading to Splunk Enterprise 9.0 or later, several configuration
settings need to be set. This search will check those configurations on the search
head it is run from as well as its search peers. In addition to these settings,
the PYTHONHTTPSVERIFY setting in $SPLUNK_HOME/etc/splunk-launch.conf needs to be
enabled as well. Other components such as additional search heads or anything this
rest command cannot be distributed to will need to be manually checked.
data_source:
description: The following analytic identifies weak encryption configurations in Splunk
related to TLS validation within the httplib and urllib Python libraries. It uses
REST API calls to check specific configuration settings on the search head and its
peers, ensuring compliance with security advisories. This activity is significant
for a SOC as weak encryption can be exploited for protocol impersonation attacks,
leading to unauthorized access. If confirmed malicious, attackers could intercept
and manipulate data, compromising the integrity and confidentiality of the Splunk
environment.
data_source:
- Splunk
search: '| rest /services/server/info | table splunk_server version server_roles |
join splunk_server [| rest /servicesNS/nobody/search/configs/conf-server/ search="PythonSslClientConfig"
@@ -66,7 +66,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1213/audittrail/audittrail.log
source: audittrail
sourcetype: audittrail
update_timestamp: true
detections/application/splunk_rce_pdfgen_render.yml
+57
View File
@@ -0,0 +1,57 @@
name: Splunk RCE PDFgen Render
id: bc2b7437-0400-438b-9537-21ab5b7d2d53
version: 1
date: '2024-07-01'
status: production
author: Rod Soto, Chase Franklin
type: TTP
data_source:
- Splunk
description: This is a hunting search designed to find and discover exploitation attempts against Splunk pdfgen render endpoint which results in remote
search: 'index=_internal sourcetype=splunk_pdfgen _raw IN ("*base64*", "*lambda*", "*system*")
| stats count min(_time) as firstTime max(_time) as lastTime by index, sourcetype, host, _raw
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_rce_pdfgen_render_filter`'
how_to_implement: Requires access to internal indexes.
known_false_positives: This search will hunt for exploitation attempts against Splunk PDFgen render function, and not all requests are necesarily malicious so there will be false positives.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0701
cve:
- CVE-2024-36982
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 100
impact: 80
kill_chain_phases:
- Exploitation
message: Possible exploitation against $host$
mitre_attack_id:
- T1210
nist:
- DE.CM
observable:
- name: host
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- host
risk_score: 80
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/SVD-2024-0701_pdfgen_log_splunk_pdfgen.log
source: /opt/splunk/var/log/splunk/pdfgen.log
sourcetype: splunk_pdfgen
custom_index: _internal
detections/application/splunk_rce_via_external_lookup_copybuckets.yml
+56
View File
@@ -0,0 +1,56 @@
name: Splunk RCE via External Lookup Copybuckets
id: 8598f9de-bba8-42a4-8ef0-12e1adda4131
version: 1
date: '2024-07-01'
status: production
author: Rod Soto, Chase Franklin
type: Hunting
data_source:
- Splunk
description: The following detection provides the ability to detect remote code execution attempts against a script named copybuckets present within the splunk_archiver application by calling this script as an external lookup.
search: 'index=_internal sourcetype="splunk_archiver-too_small" *.csv
| rex field=_raw "Invoking command:\s(?<command>.*)"
| stats min(_time) as firstTime max(_time) as lastTime values(command) as command values(severity) as severity by host
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_rce_via_external_lookup_copybuckets_filter`'
how_to_implement: Requires access to internal indexes
known_false_positives: An operator must identify elements indicatives of command execution requests by looking at regex data being extracted from the log. Not all the requests will be malicious.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0705
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 100
impact: 80
kill_chain_phases:
- Exploitation
message: Possible exploitation attempt against $host$
mitre_attack_id:
- T1210
nist:
- DE.CM
observable:
- name: host
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- host
risk_score: 80
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/SVD-2024-0705_splunk_archiver_splunk_archiver-too_small.log
source: /opt/splunk/var/log/splunk/splunk_archiver.log
sourcetype: splunk_archiver-too_small
update_timestamp: true
custom_index: _internal
detections/application/splunk_rce_via_serialized_session_payload.yml
+19 -16
View File
@@ -1,25 +1,26 @@
name: Splunk RCE via Serialized Session Payload
id: d1d8fda6-874a-400f-82cf-dcbb59d8e4db
version: 1
date: '2023-10-02'
version: 2
date: '2024-05-26'
author: Chase Franklin, Rod Soto, Eric McGinnis, Splunk
status: production
type: Hunting
description: In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that
they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code. The exploit requires the use
of the 'collect' SPL command which writes a file within the Splunk Enterprise installation. The attacker can then use this file to
submit a serialized payload that can result in execution of code within the payload. Please refer to the
following URL for additional information on these disclosures - https://advisory.splunk.com
data_source:
description: The following analytic detects the execution of a specially crafted query
using the 'collect' SPL command in Splunk Enterprise versions lower than 8.2.12,
9.0.6, and 9.1.1. It leverages audit logs to identify searches containing both 'makeresults'
and 'collect' commands. This activity is significant because it can indicate an
attempt to serialize untrusted data, potentially leading to arbitrary code execution.
If confirmed malicious, this could allow an attacker to execute code within the
Splunk environment, leading to unauthorized access and control over the system.
data_source:
- Splunk
search: '`audit_searches` file=* (search="*makeresults*" AND search="*collect*")
| stats count min(_time) as firstTime max(_time) as lastTime by action file user splunk_server search
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
search: '`audit_searches` file=* (search="*makeresults*" AND search="*collect*") |
stats count min(_time) as firstTime max(_time) as lastTime by action file user splunk_server
search | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `splunk_rce_via_serialized_session_payload_filter`'
how_to_implement: Requires access to the _audit index.
known_false_positives: There are numerous many uses of the 'makeresults' and 'collect' SPL commands.
Please evaluate the results of this search for potential abuse.
known_false_positives: There are numerous many uses of the 'makeresults' and 'collect'
SPL commands. Please evaluate the results of this search for potential abuse.
references:
- https://www.splunk.com/en_us/product-security.html
tags:
@@ -30,7 +31,8 @@ tags:
cve:
- CVE-2023-40595
impact: 50
message: Potential abuse of the 'collect' SPL command against $splunk_server$ by detected by $user$
message: Potential abuse of the 'collect' SPL command against $splunk_server$ by
detected by $user$
mitre_attack_id:
- T1190
observable:
@@ -57,7 +59,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/splunk_rce_via_serialized_session_payload_audittrail.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/splunk_rce_via_serialized_session_payload_audittrail.log
source: audittrail
sourcetype: audittrail
custom_index: _audit
detections/application/splunk_rce_via_splunk_secure_gateway__splunk_mobile_alerts_feature.yml
+14 -10
View File
@@ -1,16 +1,18 @@
name: Splunk RCE via Splunk Secure Gateway Splunk Mobile alerts feature
id: baa41f09-df48-4375-8991-520beea161be
version: 1
date: '2022-10-11'
version: 2
date: '2024-05-16'
author: Rod Soto
status: production
type: Hunting
description: This hunting search provides information on possible exploitation attempts
against Splunk Secure Gateway App Mobile Alerts feature in Splunk versions 9.0,
8.2.x, 8.1.x. An authenticated user can run arbitrary operating system commands
remotely through the use of specially crafted requests to the mobile alerts feature
in the Splunk Secure Gateway app.
data_source:
description: The following analytic identifies potential exploitation attempts against
the Splunk Secure Gateway App's Mobile Alerts feature in Splunk versions 9.0, 8.2.x,
and 8.1.x. It detects suspicious activity by monitoring requests to the mobile alerts
endpoint using specific URI paths and query parameters. This activity is significant
because an authenticated user could exploit this vulnerability to execute arbitrary
operating system commands remotely. If confirmed malicious, this could lead to unauthorized
code execution, compromising the integrity and security of the Splunk environment.
data_source:
- Splunk
search: '`splunkda` uri_path="/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*"
sort="notification.created_at:-1" | table clientip file host method uri_query sort
@@ -19,7 +21,8 @@ how_to_implement: This search only applies if Splunk Mobile Gateway is deployed
the vulnerable Splunk versions.
known_false_positives: This detection does not require you to ingest any new data.
The detection does require the ability to search the _internal index. Focus of this
search is "uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*"
search is
"uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*"
which is the injection point.
references:
- https://www.splunk.com/en_us/product-security.html
@@ -55,7 +58,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_rce_via_secure_gateway_splunk_mobile_alerts_feature.txt
- data:
https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1210/splunk/splunk_rce_via_secure_gateway_splunk_mobile_alerts_feature.txt
source: /opt/splunk/var/log/splunk/splunkd_access.log
sourcetype: splunkd_access
custom_index: _internal
detections/application/splunk_rce_via_user_xslt.yml
+2 -2
View File
@@ -20,8 +20,8 @@ search: '`splunkd_ui` ((uri="*NO_BINARY_CHECK=1*" AND "*input.path=*.xsl*") OR u
| stats count min(_time) as firstTime max(_time) as lastTime by clientip useragent
uri decoded_field action host | rename clientip as src, uri as dest_uri | iplocation
src | fillnull value="N/A" | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| table firstTime, lastTime src, useragent, action, count, Country, Region, City,
dest_uri, decoded_field'
| table firstTime, lastTime src, useragent, action, count, Country, Region, City, dest_uri, decoded_field
| `splunk_rce_via_user_xslt_filter`'
how_to_implement: This detection does not require you to ingest any new data. The
detection does require the ability to search the _internal index.
known_false_positives: This search will provide information for investigation and
detections/application/splunk_reflected_xss_on_app_search_table_endpoint.yml
+29 -15
View File
@@ -1,16 +1,29 @@
name: Splunk Reflected XSS on App Search Table Endpoint
id: 182f9080-4137-4629-94ac-cb1083ac981a
version: 1
date: '2023-09-05'
version: 2
date: '2024-05-23'
author: Rod Soto
status: production
type: Hunting
data_source:
data_source:
- Splunk
description: In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting XSS on the app search table web endpoint, which presents as the Create Table View page in Splunk Web. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance. A JavaScript file within this web endpoint does not properly validate input which lets an attacker insert a payload into a function.
search: '`splunkd_web` (dataset_commands="*makeresults*" AND dataset_commands="*count*" AND dataset_commands="*eval*" AND dataset_commands="*baseSPL*") | stats count min(_time) as firstTime max(_time) as lastTime by clientip status user view root uri_path | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_reflected_xss_on_app_search_table_endpoint_filter`'
how_to_implement: Need access to the internal indexes.
known_false_positives: This search will produce false positives. It is necessary to also look at uri_query parameter to determine the possible malicious intention of inserting makeresults within the uri string.
description: The following analytic identifies attempts to exploit a reflected cross-site
scripting (XSS) vulnerability on the app search table endpoint in Splunk Enterprise
versions below 9.1.1, 9.0.6, and 8.2.12. It detects this activity by analyzing web
request logs for specific dataset commands (`makeresults`, `count`, `eval`, `baseSPL`)
within the `splunkd_web` index. This activity is significant because successful
exploitation can lead to the execution of arbitrary commands on the Splunk platform,
potentially compromising the entire instance. If confirmed malicious, attackers
could gain unauthorized access, execute arbitrary code, and manipulate data within
the Splunk environment.
search: '`splunkd_web` (dataset_commands="*makeresults*" AND dataset_commands="*count*"
AND dataset_commands="*eval*" AND dataset_commands="*baseSPL*") | stats count min(_time)
as firstTime max(_time) as lastTime by clientip status user view root uri_path |
`security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `splunk_reflected_xss_on_app_search_table_endpoint_filter`'
how_to_implement: Need access to the internal indexes.
known_false_positives: This search will produce false positives. It is necessary to
also look at uri_query parameter to determine the possible malicious intention of
inserting makeresults within the uri string.
references:
- https://advisory.splunk.com/advisories/SVD-2023-0801
tags:
@@ -34,17 +47,18 @@ tags:
risk_score: 12
required_fields:
- dataset_commands
- clientip
- status
- user
- view
- root
- uri_path
- clientip
- status
- user
- view
- root
- uri_path
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_reflected_xss_on_app_search_table_endpoint_splunk_web_access.log
source: web_access.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_reflected_xss_on_app_search_table_endpoint_splunk_web_access.log
source: web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_risky_command_abuse_disclosed_february_2023.yml
+4 -3
View File
@@ -1,7 +1,7 @@
name: Splunk risky Command Abuse disclosed february 2023
id: ee69374a-d27e-4136-adac-956a96ff60fd
version: 3
date: '2024-05-05'
version: 4
date: '2024-07-01'
author: Chase Franklin, Rod Soto, Eric McGinnis, Splunk
status: production
type: Hunting
@@ -26,7 +26,7 @@ search: '| tstats fillnull_value="N/A" count min(_time) as firstTime max(_time)
how_to_implement: Requires implementation of Splunk_Audit.Search_Activity datamodel.
known_false_positives: This search encompasses many commands.
references:
- https://www.splunk.com/en_us/product-security.html
- https://advisory.splunk.com/advisories
tags:
analytic_story:
- Splunk Vulnerabilities
@@ -43,6 +43,7 @@ tags:
- CVE-2023-40598
- CVE-2023-46214
- CVE-2024-23676
- CVE-2024-36984
impact: 50
message: Use of risky splunk command $splunk_risky_command$ detected by $user$
mitre_attack_id:
detections/application/splunk_stored_xss_conf_web_settings_on_premises.yml
+57
View File
@@ -0,0 +1,57 @@
name: Splunk Stored XSS conf-web Settings on Premises
id: ed1209ef-228d-4dab-9856-be9369925a5c
version: 1
date: '2024-07-01'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: This hunting detection provides information on exploitation of stored XSS against /configs/conf-web/settings by an admin level user.
search: '`splunk_python` *script* *eval*
| stats min(_time) as firstTime max(_time) as lastTime by index, sourcetype, host
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_stored_xss_conf_web_settings_on_premises_filter`'
how_to_implement: Requires access to internal indexes.
known_false_positives: This is a hunting search and will produce false positives, operator must identify XSS elemetns in the splunk_python log related to the vulnerable endpoint.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0717
cve:
- CVE-2024-36987
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 100
impact: 20
kill_chain_phases:
- Exploitation
message: Possible XSS attack against $host$
mitre_attack_id:
- T1189
nist:
- DE.CM
observable:
- name: host
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- UPDATE
risk_score: 20
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/SVD-2024-0717_python_log_splunk_python.log
source: /opt/splunk/var/log/splunk/python.log
sourcetype: splunk_python
custom_index: _internal
detections/application/splunk_stored_xss_via_data_model_objectname_field.yml
+16 -11
View File
@@ -1,17 +1,21 @@
name: Splunk Stored XSS via Data Model objectName field
name: Splunk Stored XSS via Data Model objectName Field
id: 062bff76-5f9c-496e-a386-cb1adcf69871
version: 1
date: '2022-10-11'
version: 3
date: '2024-07-01'
author: Rod Soto
status: production
type: Hunting
description: Splunk Enterprise versions 8.1.12, 8.2.9, 9.0.2 are vulnerable to persistent
cross site scripting via Data Model object name. An authenticated user can inject
and store arbitrary scripts that can lead to persistent cross-site scripting (XSS)
in the object name Data Model.
data_source:
description: The following analytic identifies attempts to exploit a stored cross-site
scripting (XSS) vulnerability in Splunk Enterprise via the Data Model object name
field. It detects this activity by analyzing web access logs (`splunkd_webx`) for
specific URI patterns and non-null query parameters. This activity is significant
because it allows authenticated users to inject and store malicious scripts, leading
to persistent XSS attacks. If confirmed malicious, this could enable attackers to
execute arbitrary scripts in the context of other users, potentially leading to
data theft, session hijacking, or further compromise of the Splunk environment.
data_source:
- Splunk
search: '`splunkd_webx` uri=/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel/model*
search: '`splunkd_webx` uri=/*/splunkd/__raw/servicesNS/*/launcher/datamodel/model*
uri_query!=null | stats count by _time host status clientip user uri | `splunk_stored_xss_via_data_model_objectname_field_filter`'
how_to_implement: This vulnerability only affects Splunk Web enabled instances. This
detection does not require you to ingest any new data. The detection does require
@@ -21,7 +25,7 @@ known_false_positives: This search may produce false positives and does not cove
against "/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel/model" which is the
injection point.
references:
- https://www.splunk.com/en_us/product-security.html
- https://advisory.splunk.com/advisories/SVD-2022-1109
- https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
tags:
analytic_story:
@@ -56,7 +60,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_stored_xss_via_data_model_objectname_field.txt
- data:
https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_stored_xss_via_data_model_objectname_field.txt
source: /opt/splunk/var/log/splunk/web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_stored_xss_via_specially_crafted_bulletin_message.yml
+62
View File
@@ -0,0 +1,62 @@
name: Splunk Stored XSS via Specially Crafted Bulletin Message
id: fd852b27-1882-4505-9f2c-64dfb96f4fc1
version: 1
date: '2024-07-01'
author: Rod Soto
status: production
type: Hunting
data_source:
- Splunk
description: The following hunting detection provides fields related to /service/messages endpoints where specially crafted bulletin message can exploit stored XSS.
search: '| rest /services/messages
| search message="*http*"
| table id author message title
| `splunk_stored_xss_via_specially_crafted_bulletin_message_filter`'
how_to_implement: Need access to Splunk REST api data via search.
known_false_positives: Must look at messages field and find malicious suspicious characters or hyperlinks. Not all requests to this endpoint will be malicious.
references:
- https://advisory.splunk.com/SVD-2024-0713
cve:
- CVE-2024-36993
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 50
impact: 10
kill_chain_phases:
- Exploitation
message: Please investigate $message for possible XSS attack in bulletin message $message$
mitre_attack_id:
- T1189
nist:
- DE.CM
observable:
- name: message
type: Other
role:
- Other
product:
- Splunk Enterprise
required_fields:
- table
- id
- author
- message
- title
risk_score: 5
security_domain: endpoint
manual_test: This search uses a REST call against a running Splunk instance to fetch
messages that have been created on the instance. It cannot be replicated with a normal test or
attack data as this data cannot be "replayed" into a Splunk instance.
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/SVD-2024-0713_json_json.log
source: _json
sourcetype: _json
custom_index: _internal
detections/application/splunk_unauthenticated_dos_via_null_pointer_references.yml
+56
View File
@@ -0,0 +1,56 @@
name: Splunk Unauthenticated DoS via Null Pointer References
id: d67594fe-c317-41b8-9319-ec8428d5c2ea
version: 1
date: '2024-07-01'
author: Rod Soto
status: production
type: Hunting
data_source:
- Splunk
description: The following hunting search provides information on splunkd crash as a result of a Denial of Service Exploitation via null pointer references which targets 'services/cluster/config' endpoint.
search: '`splunk_crash_log` "Segmentation fault" "POST /services/cluster/config"
| stats count min(_time) as firstTime max(_time) as lastTime by host
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_unauthenticated_dos_via_null_pointer_references_filter`'
how_to_implement: Requires access to internal indexes.
known_false_positives: This is a hunting search and will produce false positives. An operator needs to find proximity and detail of requests targeting cluster config endpoint and subsequent Segmentation fault in splunk crash log.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0702
cve:
- CVE-2024-36983
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 50
impact: 100
kill_chain_phases:
- Exploitation
message: Possible exploitation attack against $host$
mitre_attack_id:
- T1499
nist:
- DE.CM
observable:
- name: host
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- sourcetype
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/T1499/splunk/SVD-2024-0702_splunkd_crash_log_splunkd_crash_log.log
source: /opt/splunk/var/log/splunk/crash-*.log
sourcetype: splunkd_crash_log
custom_index: _internal
detections/application/splunk_unauthenticated_log_injection_web_service_log.yml
+28 -16
View File
@@ -1,26 +1,37 @@
name: Splunk Unauthenticated Log Injection Web Service Log
id: de3908dc-1298-446d-84b9-fa81d37e959b
version: 1
date: '2023-07-13'
version: 2
date: '2024-05-19'
author: Rod Soto
status: production
type: Hunting
data_source:
data_source:
- Splunk
description: An attacker can use a specially crafted web URL in their browser to cause log file injection, in which the attack inserts American National Standards Institute (ANSI) escape codes into specific files using a terminal program that supports those escape codes. The attack requires a terminal program that supports the translation of ANSI escape codes and requires additional user interaction to successfully execute. This following analytic detects potential log injection attempts into the Splunk server.
search: '`splunkd_webx` uri_path IN ("*\x1B*", "*\u001b*", "*\033*", "*\0x9*", "*\0x8*") | stats count by uri_path method host status clientip | `splunk_unauthenticated_log_injection_web_service_log_filter`'
how_to_implement: This only affects web enabled Splunk instances. The detection does require the ability to search the _internal index.
known_false_positives: This hunting search will produce false positives if ANSI escape characters are included in URLs either voluntarily or by accident. This search will not detect obfuscated ANSI characters.
description: The following analytic identifies potential log injection attempts into
the Splunk server via specially crafted web URLs. It detects ANSI escape codes within
the `uri_path` field of `splunkd_webx` logs. This activity is significant as it
can lead to log file manipulation, potentially obfuscating malicious actions or
misleading analysts. If confirmed malicious, an attacker could manipulate log files
to hide their tracks or execute further attacks, compromising the integrity of the
logging system and making incident response more challenging.
search: '`splunkd_webx` uri_path IN ("*\x1B*", "*\u001b*", "*\033*", "*\0x9*", "*\0x8*")
| stats count by uri_path method host status clientip | `splunk_unauthenticated_log_injection_web_service_log_filter`'
how_to_implement: This only affects web enabled Splunk instances. The detection does
require the ability to search the _internal index.
known_false_positives: This hunting search will produce false positives if ANSI escape
characters are included in URLs either voluntarily or by accident. This search will
not detect obfuscated ANSI characters.
references:
- https://advisory.splunk.com/advisories/SVD-2023-0606
- https://advisory.splunk.com/advisories/SVD-2023-0606
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Endpoint
confidence: 30
impact: 30
message: Possible Splunk unauthenticated log injection web service log exploitation attempt against $host$ from $clientip$
cve:
message: Possible Splunk unauthenticated log injection web service log exploitation
attempt against $host$ from $clientip$
cve:
- CVE-2023-32712
mitre_attack_id:
- T1190
@@ -41,15 +52,16 @@ tags:
required_fields:
- method
- uri_path
- host
- status
- clientip
- host
- status
- clientip
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/web_access.log
attack_data:
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1190/splunk/web_access.log
source: /opt/splunk/var/log/splunk/web_access.log
custom_index: _internal
sourcetype: splunk_web_access
detections/application/splunk_unauthenticated_path_traversal_modules_messaging.yml
+57
View File
@@ -0,0 +1,57 @@
name: Splunk Unauthenticated Path Traversal Modules Messaging
id: e7c2b064-524e-4d65-8002-efce808567aa
version: 1
date: '2024-07-01'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: This hunting search provides information on exploitation attempts against /modules/messaging endpoint, the exploit can be clearly seen as the ../ which signals an attempt to traverse target directories.
search: '`splunkd_web` method=GET uri_path="/*/modules/messaging/*..*"
| stats min(_time) as firstTime max(_time) as lastTime values(method) as method values(uri_path) as uri_path by host
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_unauthenticated_path_traversal_modules_messaging_filter`'
how_to_implement: Only applies to Microsoft Windows installations of Splunk.
known_false_positives: May catch other exploitation attempts using path traversal related characters.
references:
- https://advisory.splunk.com/SVD-2024-0711
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 100
impact: 20
kill_chain_phases:
- Exploitation
message: Possible directory traversal attack against $host$
mitre_attack_id:
- T1083
nist:
- DE.CM
observable:
- name: host
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- method
- uri_path
- host
risk_score: 20
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1083/splunk/SVD-2024-0711_web_access_splunk_web_access.log
source: C:\\Program Files\\Splunk\\var\\log\\splunk\\web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_unauthorized_experimental_items_creation.yml
+60
View File
@@ -0,0 +1,60 @@
name: Splunk Unauthorized Experimental Items Creation
id: 84afda04-0cd6-466b-869e-70d6407d0a34
version: 1
date: '2024-07-01'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: This hunting search provides information on finding possible creation of unauthorized items against /experimental endpoint.
search: '`splunkda` */experimental/* method=POST
| stats count min(_time) as firstTime max(_time) as lastTime by clientip method uri_path uri status
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_unauthorized_experimental_items_creation_filter`'
how_to_implement: Requires access to internal indexes.
known_false_positives: Not all requests are going to be malicious, there will be false positives, however operator must find suspicious items that might have been created by an unauthorized user.
references:
- https://advisory.splunk.com/SVD-2024-0715
cve:
- CVE-2024-36995
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 100
impact: 5
kill_chain_phases:
- Exploitation
message: Possible unauthorized creation of experimental items from $clientip$
mitre_attack_id:
- T1189
nist:
- DE.CM
observable:
- name: clientip
type: IP Address
role:
- Attacker
product:
- Splunk Enterprise
required_fields:
- clientip
- method
- uri_path
- uri
- status
risk_score: 5
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/SVD-2024-0715_splunkd_splunkd_access.log
source: /opt/splunk/var/log/splunk/splunkd_access.log
sourcetype: splunkd_access
custom_index: _internal
detections/application/splunk_unauthorized_notification_input_by_user.yml
+56
View File
@@ -0,0 +1,56 @@
name: Splunk Unauthorized Notification Input by User
id: 4b7f368f-4322-47f8-8363-2c466f0b7030
version: 1
date: '2024-07-01'
author: Rod Soto
status: experimental
type: Hunting
data_source:
- Splunk
description: This hunting search provides information to track possible exploitation of a lower privilege user able to push notifications that may include malicious code as notifications for all users in Splunk.
search: '| rest /services/messages | table title message severity timeCreated_iso published splunk_server author | `splunk_unauthorized_notification_input_by_user_filter`'
how_to_implement: Requires access to Splunk rest data.
known_false_positives: This search will produce false positives which may include benign notifications from other Splunk entities, attention to suspicious or anomalous elements in notifications helps identify actual exploitation of this vulnerability.
references:
- https://advisory.splunk.com/advisories/SVD-2024-0709
cve:
- CVE-2023-33733
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 100
impact: 20
kill_chain_phases:
- Exploitation
message: Please review messages at $splunk_server for possible unauthorized notification input.
mitre_attack_id:
- T1548
nist:
- DE.CM
observable:
- name: splunk_server
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- message
- title
- splunk_server
- author
risk_score: 12
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548/splunk/SVD-2024-0709_json_json.json
source: _json
sourcetype: _json
custom_index: _internal
detections/application/splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads.yml
+41 -30
View File
@@ -1,56 +1,67 @@
name: Splunk unnecessary file extensions allowed by lookup table uploads
id: b7d1293f-e78f-415e-b5f6-443df3480082
version: 1
date: "2023-02-14"
version: 2
date: "2024-05-28"
author: Rod Soto, Splunk
type: TTP
status: production
data_source:
data_source:
- Splunk
description: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads.
search:
'`splunkda` method IN ("POST", "DELETE") uri_path=/servicesNS/*/ui/views/*
| eval activity = case( method=="POST" AND like( uri_path , "%/acl" ) , "Permissions Update", method=="POST" AND NOT like( uri_path , "%/acl" ) , "Edited" , method=="DELETE" , "Deleted" )
| rex field=uri_path "(?<user_and_app>.*?)\/ui\/views/(?<dashboard_encoded>.*)"
| eval dashboard = urldecode( dashboard_encoded )
| table _time, uri_path, user, dashboard, activity, uri_path
| `splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads_filter`'
description: The following analytic identifies user activity related to uploading
lookup tables with unnecessary filename extensions in Splunk Enterprise versions
below 8.1.13, 8.2.10, and 9.0.4. It detects this activity by monitoring HTTP methods
(POST, DELETE) and specific URI paths in the internal `splunkd_access` logs. This
behavior is significant because it can indicate attempts to upload potentially malicious
files disguised as lookup tables. If confirmed malicious, this activity could allow
an attacker to execute unauthorized code or manipulate data within the Splunk environment,
leading to potential data breaches or system compromise.
search: '`splunkda` method IN ("POST", "DELETE") uri_path=/servicesNS/*/ui/views/*
| eval activity = case( method=="POST" AND like( uri_path , "%/acl" ) , "Permissions
Update", method=="POST" AND NOT like( uri_path , "%/acl" ) , "Edited" , method=="DELETE"
, "Deleted" ) | rex field=uri_path "(?<user_and_app>.*?)\/ui\/views/(?<dashboard_encoded>.*)"
| eval dashboard = urldecode( dashboard_encoded ) | table _time, uri_path, user,
dashboard, activity, uri_path | `splunk_unnecessary_file_extensions_allowed_by_lookup_table_uploads_filter`'
how_to_implement: Requires access to internal splunkd_access.
known_false_positives: This is a hunting search, the search provides information on upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary after executing search. This search will produce false positives as payload cannot be directly discerned.
known_false_positives: This is a hunting search, the search provides information on
upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary
after executing search. This search will produce false positives as payload cannot
be directly discerned.
references:
- https://www.splunk.com/en_us/product-security.html
- https://www.splunk.com/en_us/product-security.html
tags:
analytic_story:
- Splunk Vulnerabilities
- Splunk Vulnerabilities
asset_type: Endpoint
cve:
- CVE-2023-22937
- CVE-2023-22937
confidence: 50
dataset:
- https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log
- https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log
impact: 50
message: Potential lookup template injection attempt from $user$ on lookup table at path $uri_path$
message: Potential lookup template injection attempt from $user$ on lookup table
at path $uri_path$
mitre_attack_id:
- T1189
- T1189
observable:
- name: user
type: User
role:
- Victim
- name: user
type: User
role:
- Victim
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
required_fields:
- user
- method
- uri_path
- user
- method
- uri_path
risk_score: 25
security_domain: threat
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_unnecesary_file_extensions_allowed_by_lookup_table_uploads.log
source: /opt/splunk/var/log/splunk/splunkd_access.log
sourcetype: splunkd_access
custom_index: _internal
custom_index: _internal
detections/application/splunk_user_enumeration_attempt.yml
+14 -10
View File
@@ -1,19 +1,22 @@
name: Splunk User Enumeration Attempt
id: 25625cb4-1c4d-4463-b0f9-7cb462699cde
version: 2
date: '2024-03-19'
version: 3
date: '2024-05-21'
author: Lou Stella, Splunk
status: production
type: TTP
description: On May 3rd, 2022, Splunk published a security advisory for username
enumeration stemming from verbose login failure messages present on some REST endpoints.
This detection will alert on attempted exploitation in patched versions of Splunk
as well as actual exploitation in unpatched version of Splunk.
data_source:
description: The following analytic identifies attempts to enumerate usernames in
Splunk by detecting multiple failed authentication attempts from the same source.
It leverages data from the `_audit` index, specifically focusing on failed authentication
events. This activity is significant for a SOC because it can indicate an attacker
trying to discover valid usernames, which is a precursor to more targeted attacks
like password spraying or brute force attempts. If confirmed malicious, this activity
could lead to unauthorized access, compromising the security of the Splunk environment
and potentially exposing sensitive data.
data_source:
- Splunk
search: ' `splunkd_failed_auths` | stats count(user) as auths by user, src | where
auths>5 | stats values(user) as user, sum(auths) as TotalFailedAuths by src |
`splunk_user_enumeration_attempt_filter`'
auths>5 | stats values(user) as user, sum(auths) as TotalFailedAuths by src | `splunk_user_enumeration_attempt_filter`'
how_to_implement: This detection does not require you to ingest any new data. The
detection does require the ability to search the _audit index. This detection may
assist in efforts to find password spraying or brute force authorization attempts
@@ -56,7 +59,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/splunkd_auth/audittrail.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/splunkd_auth/audittrail.log
source: audittrail
sourcetype: audittrail
custom_index: _audit
detections/application/splunk_xss_in_highlighted_json_events.yml
+38 -31
View File
@@ -1,28 +1,34 @@
name: Splunk XSS in Highlighted JSON Events
id: 1030bc63-0b37-4ac9-9ae0-9361c955a3cc
version: 1
date: '2023-11-16'
version: 3
date: '2024-07-01'
author: Rod Soto, Splunk
status: production
type: Hunting
data_source:
data_source:
- Splunk
description: This detection provides information about possible exploitation against affected versions of Splunk Enterprise 9.1.2.
The ability to view JSON logs in the web GUI may be abused by crafting a specific request, causing the execution of javascript
in script tags. This vulnerability can be used to execute javascript to access the API at the permission level of the
logged-in user. If user is admin it can be used to create an admin user, giving an attacker broad access to the Splunk Environment.
search: '`splunkd_ui` "/en-US/splunkd/__raw/servicesNS/nobody/search/authentication/users" status=201
| stats count min(_time) as firstTime max(_time) as lastTime by clientip, uri_path, method
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
description: The following analytic identifies potential exploitation of a Cross-Site
Scripting (XSS) vulnerability in Splunk Enterprise 9.1.2. It detects suspicious
requests to the Splunk web GUI that may execute JavaScript within script tags. This
detection leverages logs from the `splunkd_ui` data source, focusing on specific
URI paths and HTTP methods. This activity is significant as it can allow attackers
to execute arbitrary JavaScript, potentially accessing the API with the logged-in
user's permissions. If the user is an admin, the attacker could create an admin
account, leading to full control over the Splunk environment.
search: '`splunkd_ui` "/*/splunkd/__raw/servicesNS/nobody/search/authentication/users"
status=201 | stats count min(_time) as firstTime max(_time) as lastTime by clientip,
uri_path, method | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `splunk_xss_in_highlighted_json_events_filter`'
how_to_implement: This search only applies to web-GUI-enabled Splunk instances and operator must have access to internal indexes.
known_false_positives: This is a hunting search and will produce false positives as it is not possible to view contents of a request
payload. It shows the artifact resulting from a potential exploitation payload (the creation of a user with admin privileges).
how_to_implement: This search only applies to web-GUI-enabled Splunk instances and
operator must have access to internal indexes.
known_false_positives: This is a hunting search and will produce false positives as
it is not possible to view contents of a request payload. It shows the artifact
resulting from a potential exploitation payload (the creation of a user with admin
privileges).
references:
- https://advisory.splunk.com/advisories
- https://advisory.splunk.com/advisories/SVD-2023-1103
cve:
- CVE-2023-46213
- CVE-2023-46213
tags:
analytic_story:
- Splunk Vulnerabilities
@@ -31,27 +37,28 @@ tags:
impact: 30
message: Possible XSS exploitation from $clientip$
mitre_attack_id:
- T1189
- T1189
observable:
- name: clientip
type: IP Address
role:
- Attacker
- name: clientip
type: IP Address
role:
- Attacker
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
risk_score: 15
required_fields:
- clientip
- uri_path
- method
- status
- clientip
- uri_path
- method
- status
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_highlighted_json_events_splunkd_ui_access.log
source: splunkd_ui_access.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_highlighted_json_events_splunkd_ui_access.log
source: splunkd_ui_access.log
sourcetype: splunkd_ui_access
custom_index: _internal
custom_index: _internal
detections/application/splunk_xss_in_monitoring_console.yml
+11 -8
View File
@@ -1,15 +1,17 @@
name: Splunk XSS in Monitoring Console
id: b11accac-6fa3-4103-8a1a-7210f1a67087
version: 1
date: '2022-04-27'
version: 2
date: '2024-05-17'
author: Lou Stella, Splunk
status: experimental
type: TTP
description: On May 3rd, 2022, Splunk published a security advisory for a reflective
Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation
in the Distributed Monitoring Console app. This detection will alert on attempted
exploitation in patched versions of Splunk as well as actual exploitation in unpatched
version of Splunk.
description: The following analytic identifies attempts to exploit a reflective Cross-Site
Scripting (XSS) vulnerability in the Splunk Distributed Monitoring Console app.
It detects GET requests with suspicious query parameters by analyzing `splunkd_web`
logs in the _internal index. This activity is significant because it targets a known
vulnerability (CVE-2022-27183) that could allow attackers to execute arbitrary scripts
in the context of the user's browser. If confirmed malicious, this could lead to
unauthorized actions, data theft, or further compromise of the Splunk environment.
data_source: []
search: ' `splunkd_web` method="GET" uri_query="description=%3C*" | table _time host
status clientip user uri | `splunk_xss_in_monitoring_console_filter`'
@@ -52,6 +54,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/xss/splunk_web_access.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/xss/splunk_web_access.log
source: /opt/splunk/var/log/splunk/web_access.log
sourcetype: splunk_web_access
detections/application/splunk_xss_in_save_table_dialog_header_in_search_page.yml
+15 -10
View File
@@ -1,17 +1,21 @@
name: Splunk XSS in Save table dialog header in search page
id: a974d1ee-ddca-4837-b6ad-d55a8a239c20
version: 1
date: '2022-10-11'
version: 3
date: '2024-07-01'
author: Rod Soto
status: production
type: Hunting
description: This is a hunting search to find persistent cross-site scripting XSS
code that was included while inputing data in 'Save Table' dialog in Splunk Enterprise
(8.1.12,8.2.9,9.0.2). A remote user with "power" Splunk role can store this code
that can lead to persistent cross site scripting.
data_source:
description: The following analytic identifies persistent cross-site scripting (XSS)
attempts in the 'Save Table' dialog on the Splunk search page. It detects POST requests
to the endpoint `/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model`
containing potential XSS payloads. This activity is significant because it can allow
a remote user with the "power" role to inject malicious scripts, leading to persistent
XSS vulnerabilities. If confirmed malicious, this could enable attackers to execute
arbitrary scripts in the context of the affected user, potentially leading to data
theft, session hijacking, or further exploitation within the Splunk environment.
data_source:
- Splunk
search: '`splunkd_webx` method=POST uri=/en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model
search: '`splunkd_webx` method=POST uri=/*/splunkd/__raw/servicesNS/nobody/search/datamodel/model
| table _time host status clientip user uri | `splunk_xss_in_save_table_dialog_header_in_search_page_filter`'
how_to_implement: Watch for POST requests combined with XSS script strings or obfuscation
against the injection point /en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model.
@@ -20,7 +24,7 @@ known_false_positives: If host is vulnerable and XSS script strings are inputted
users create and save dashboards. This search may produce several results with non
malicious POST requests. Only affects Splunk Web enabled instances.
references:
- https://www.splunk.com/en_us/product-security.html
- https://advisory.splunk.com/advisories/SVD-2022-1101
- https://portswigger.net/web-security/cross-site-scripting
tags:
analytic_story:
@@ -55,7 +59,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_save_table_dialog_in_search_page.txt
- data:
https://raw.githubusercontent.com/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_in_save_table_dialog_in_search_page.txt
source: /opt/splunk/var/log/splunk/web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_xss_privilege_escalation_via_custom_urls_in_dashboard.yml
+72
View File
@@ -0,0 +1,72 @@
name: Splunk XSS Privilege Escalation via Custom Urls in Dashboard
id: 01e1e386-7656-4f36-a55a-52fe39b04a96
version: 1
date: '2024-07-01'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: This is a composed hunting search that looks for POST requests to splunk_internal_metrics/data/ui/views which can be used to elevate privileges on the Splunk server via custom urls. The way to find privilege escalation is by looking at created users with high privielges after payload has been executed. This search looks at POST request and then looks at created users privileges.
search: '`splunkd_ui` method=POST /*/data/ui/views*
| stats values(method) as method by _time index, sourcetype, host
| eval event="post_request"
| append
[| search `audittrail` action="edit_user" operation="create"
| rex field=_raw "object=\"(?<newUser>.*)\""
| stats count values(operation) as operation values(splunk_server) as splunk_server values(user) as user by _time index, sourcetype, host, newUser
| eval event="create_user"]
| sort - _time
| transaction host startswith=event="post_request" endswith=event="create_user" maxspan=10m
| table _time index, sourcetype, host, method, user, splunk_server, operation, event, newUser eventcount
| `splunk_xss_privilege_escalation_via_custom_urls_in_dashboard_filter`'
how_to_implement: Requires access to internal indexes _audit and _internal.
known_false_positives: This is a hunting search and requires operator to search for specific indicators of user creation in proximity to POST requests against vulnerable endpoint. It is not possible to detect payload during runtime.
references:
- https://advisory.splunk.com/
cve:
- CVE-2024-36992
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 50
impact: 10
kill_chain_phases:
- Exploitation
message: Possible XSS attack and privilege escalation via custom urls in dashboard against $host$
mitre_attack_id:
- T1189
nist:
- DE.CM
observable:
- name: host
type: Hostname
role:
- Victim
product:
- Splunk Enterprise
required_fields:
- method
- host
- action
- operation
- splunk_server
- user
risk_score: 5
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/SVD-2024-0712_splunkd_ui_access_splunk_ui_access.log
source: /opt/splunk/var/log/splunk/splunkd_ui_access.log
sourcetype: splunkd_ui_access
custom_index: _internal
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/SVD-2024-0712_audittrail_audittrail.log
source: /opt/splunk/var/log/splunk/audittrail
sourcetype: audittrail
custom_index: _audit
detections/application/splunk_xss_via_external_urls_in_dashboards_ssrf.yml
+60
View File
@@ -0,0 +1,60 @@
name: Splunk XSS Via External Urls in Dashboards SSRF
id: b0a67520-ae82-4cf6-b04e-9f6cce56830d
version: 1
date: '2024-07-01'
author: Rod Soto, Chase Franklin
status: production
type: Hunting
data_source:
- Splunk
description: This is a hunting search that provides elements to find possible dashboards created with external URL references in order to elicit Server Side Request Forgery from /data/ui/views endpoint.
search: '`splunkd_web` user=* uri_path="/*/manager/permissions/launcher/data/ui/views/*" file=*
| stats count min(_time) as firstTime max(_time) as lastTime by clientip user file host method uri_path uri_query
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `splunk_xss_via_external_urls_in_dashboards_ssrf_filter`'
how_to_implement: Requires access to internal indexes.
known_false_positives: This is a hunting search and requires an operator to search for specific indicators of Server Side Request Forgery attack against /data/ui/views.
It is not possible to grab display the payloads of such requests, so this search provides users, ip addresses, requests, files, and queries that may indicate malicious intent. There will be false positives.
references:
- https://advisory.splunk.com/SVD-2024-0714
cve:
- CVE-2024-36994
tags:
analytic_story:
- Splunk Vulnerabilities
asset_type: Splunk Server
cis20:
- CIS 3
- CIS 5
- CIS 16
confidence: 50
impact: 10
kill_chain_phases:
- Exploitation
message: Possible SSRF attack from $clientip$
mitre_attack_id:
- T1189
nist:
- DE.CM
observable:
- name: clientip
type: IP Address
role:
- Attacker
product:
- Splunk Enterprise
required_fields:
- uri_path
- user
- file
- clientip
risk_score: 5
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/SVD-2024-0714_web_access_splunk_web_access.log
source: /opt/splunk/var/log/splunk/web_access.log
sourcetype: splunk_web_access
custom_index: _internal
detections/application/splunk_xss_via_view.yml
+14 -9
View File
@@ -1,16 +1,20 @@
name: Splunk XSS via View
id: 9ac2bfea-a234-4a18-9d37-6d747e85c2e4
version: 1
date: '2023-02-07'
version: 2
date: '2024-05-13'
author: Rod Soto, Eric McGinnis, Splunk
status: production
type: Hunting
description: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View
allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute
in the 'module' tag. The vulnerability affects instances with Splunk Web enabled.
This hunting search shows users action, application and role used for creating views
related to this vulnerability.
data_source:
description: The following analytic identifies potential Cross-Site Scripting (XSS)
attempts via the 'layoutPanel' attribute in the 'module' tag within XML Views in
Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4. It leverages internal
logs from "splunk_web_service" and "splunk_python" sourcetypes, focusing on messages
containing "loadParams." This activity is significant as it can lead to unauthorized
script execution within the Splunk Web interface, potentially compromising the security
of the instance. If confirmed malicious, attackers could execute arbitrary scripts,
leading to data theft, session hijacking, or further exploitation of the Splunk
environment.
data_source:
- Splunk
search: 'index = _internal sourcetype IN ("splunk_web_service", "splunk_python") message="*loadParams*"
| `security_content_ctime(_time)` | table _time message fileName | `splunk_xss_via_view_filter`'
@@ -52,7 +56,8 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_via_view.log
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1189/splunk/splunk_xss_via_view.log
source: /opt/splunk/var/log/splunk/web_service.log
sourcetype: splunk_web_service
custom_index: _internal
detections/application/suspicious_email_attachment_extensions.yml
+4 -4
View File
@@ -1,18 +1,18 @@
name: Suspicious Email Attachment Extensions
id: 473bd65f-06ca-4dfe-a2b8-ba04ab4a0084
version: 3
date: '2023-04-14'
version: 4
date: '2024-05-29'
author: David Dorsey, Splunk
status: experimental
type: Anomaly
description: |-
The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack.
The following analytic detects emails containing attachments with suspicious file extensions. It leverages the Email data model in Splunk, using the tstats command to identify emails where the attachment filename is not empty. This detection is significant for SOC analysts as it highlights potential phishing or malware delivery attempts, which are common vectors for data breaches and malware infections. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, system compromise, or data exfiltration. Immediate review and analysis of the identified emails and attachments are crucial to mitigate these risks.
data_source: []
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Email where All_Email.file_name="*" by All_Email.src_user,
All_Email.file_name All_Email.message_id | `security_content_ctime(firstTime)` |
`security_content_ctime(lastTime)` | `drop_dm_object_name("All_Email")` | `suspicious_email_attachments`
| `suspicious_email_attachment_extensions_filter` '
| `suspicious_email_attachment_extensions_filter`'
how_to_implement: You need to ingest data from emails. Specifically, the sender's
address and the file names of any attachments must be mapped to the Email data
model.
detections/application/web_servers_executing_suspicious_processes.yml
+3 -3
View File
@@ -1,12 +1,12 @@
name: Web Servers Executing Suspicious Processes
id: ec3b7601-689a-4463-94e0-c9f45638efb9
version: 1
date: '2019-04-01'
version: 2
date: '2024-05-11'
author: David Dorsey, Splunk
status: experimental
type: TTP
description: |-
The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack.
The following analytic detects the execution of suspicious processes on systems identified as web servers. It leverages the Splunk data model "Endpoint.Processes" to search for specific process names such as "whoami", "ping", "iptables", "wget", "service", and "curl". This activity is significant because these processes are often used by attackers for reconnaissance, persistence, or data exfiltration. If confirmed malicious, this could lead to data theft, deployment of additional malware, or even ransomware attacks. Immediate investigation is required to determine the legitimacy of the activity and mitigate potential threats.
data_source:
- Sysmon Event ID 1
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
detections/cloud/abnormally_high_number_of_cloud_instances_destroyed.yml
+10 -5
View File
@@ -1,13 +1,18 @@
name: Abnormally High Number Of Cloud Instances Destroyed
id: ef629fc9-1583-4590-b62a-f2247fbf7bbf
version: 1
date: '2020-08-21'
version: 2
date: '2024-05-27'
author: David Dorsey, Splunk
status: experimental
type: Anomaly
description: This search finds for the number successfully destroyed cloud instances
for every 4 hour block. This is split up between weekdays and the weekend. It then
applies the probability densitiy model previously created and alerts on any outliers.
description: The following analytic identifies an abnormally high number of cloud
instances being destroyed within a 4-hour period. It leverages cloud infrastructure
logs and applies a probability density model to detect outliers. This activity is
significant for a SOC because a sudden spike in destroyed instances could indicate
malicious activity, such as an insider threat or a compromised account attempting
to disrupt services. If confirmed malicious, this could lead to significant operational
disruptions, data loss, and potential financial impact due to the destruction of
critical cloud resources.
data_source: []
search: '| tstats count as instances_destroyed values(All_Changes.object_id) as object_id
from datamodel=Change where All_Changes.action=deleted AND All_Changes.status=success
detections/cloud/abnormally_high_number_of_cloud_instances_launched.yml
+9 -5
View File
@@ -1,13 +1,17 @@
name: Abnormally High Number Of Cloud Instances Launched
id: f2361e9f-3928-496c-a556-120cd4223a65
version: 2
date: '2020-08-21'
version: 3
date: '2024-05-16'
author: David Dorsey, Splunk
status: experimental
type: Anomaly
description: This search finds for the number successfully created cloud instances
for every 4 hour block. This is split up between weekdays and the weekend. It then
applies the probability densitiy model previously created and alerts on any outliers.
description: The following analytic detects an abnormally high number of cloud instances
launched within a 4-hour period. It leverages cloud infrastructure logs and applies
a probability density model to identify outliers based on historical data. This
activity is significant for a SOC because a sudden spike in instance creation could
indicate unauthorized access or misuse of cloud resources. If confirmed malicious,
this behavior could lead to resource exhaustion, increased costs, or provide attackers
with additional compute resources to further their objectives.
data_source: []
search: '| tstats count as instances_launched values(All_Changes.object_id) as object_id
from datamodel=Change where (All_Changes.action=created) AND All_Changes.status=success
detections/cloud/amazon_eks_kubernetes_cluster_scan_detection.yml
+1 -1
View File
@@ -18,7 +18,7 @@ search: '`aws_cloudwatchlogs_eks` "user.username"="system:anonymous" userAgent!=
max(_time) as lastTime values(responseStatus.reason) values(source) as cluster_name
values(responseStatus.code) values(userAgent) as http_user_agent values(verb) values(requestURI)
by src_ip user.username user.groups{} | `security_content_ctime(lastTime)` | `security_content_ctime(firstTime)`
|`amazon_eks_kubernetes_cluster_scan_detection_filter` '
|`amazon_eks_kubernetes_cluster_scan_detection_filter`'
how_to_implement: You must install the AWS App for Splunk (version 5.1.0 or later)
and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudWatch
EKS Logs inputs.
detections/cloud/amazon_eks_kubernetes_pod_scan_detection.yml
+4 -4
View File
@@ -1,19 +1,19 @@
name: Amazon EKS Kubernetes Pod scan detection
id: dbfca1dd-b8e5-4ba4-be0e-e565e5d62002
version: 1
date: '2020-04-15'
version: 2
date: '2024-05-29'
author: Rod Soto, Splunk
status: experimental
type: Hunting
description: |-
The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action. Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts.
The following analytic detects unauthenticated requests made against the Kubernetes Pods API, indicating potential unauthorized access attempts. It leverages the `aws_cloudwatchlogs_eks` data source, filtering for events where `user.username` is "system:anonymous", `verb` is "list", and `objectRef.resource` is "pods", with `requestURI` set to "/api/v1/pods". This activity is significant as it may signal attempts to access sensitive resources or execute unauthorized commands within the Kubernetes environment. If confirmed malicious, such access could lead to data compromise, unauthorized command execution, or lateral movement within the cluster.
data_source: []
search: '`aws_cloudwatchlogs_eks` "user.username"="system:anonymous" verb=list objectRef.resource=pods
requestURI="/api/v1/pods" | rename source as cluster_name sourceIPs{} as src_ip
| stats count min(_time) as firstTime max(_time) as lastTime values(responseStatus.reason)
values(responseStatus.code) values(userAgent) values(verb) values(requestURI) by
src_ip cluster_name user.username user.groups{} | `security_content_ctime(lastTime)`
| `security_content_ctime(firstTime)` | `amazon_eks_kubernetes_pod_scan_detection_filter` '
| `security_content_ctime(firstTime)` | `amazon_eks_kubernetes_pod_scan_detection_filter`'
how_to_implement: You must install the AWS App for Splunk (version 5.1.0 or later)
and Splunk Add-on forAWS (version 4.4.0 or later), then configure your AWS CloudWatch
EKS Logs.Please also customize the `kubernetes_pods_aws_scan_fingerprint_detection`
detections/cloud/asl_aws_concurrent_sessions_from_different_ips.yml
+17 -17
View File
@@ -1,21 +1,19 @@
name: ASL AWS Concurrent Sessions From Different Ips
id: b3424bbe-3204-4469-887b-ec144483a336
version: 2
date: '2024-02-13'
version: 3
date: '2024-05-24'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic identifies an AWS IAM account with concurrent
sessions coming from more than one unique IP address within the span of 5 minutes.
This behavior could represent a session hijacking attack whereby an adversary has
extracted cookies from a victims browser and is using them from a different location
to access corporate online resources. When a user navigates the AWS Console after
authentication, the API call with the event name `DescribeEventAggregates` is registered
in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event
name to identify 2 concurrent sessions. The presence of this event occurring from
two different IP addresses is highly unlikely. As users may behave differently across
organizations, security teams should test and customize this detection to fit their
environments.
sessions originating from more than one unique IP address within a 5-minute span.
This detection leverages AWS CloudTrail logs, specifically the `DescribeEventAggregates`
API call, to identify multiple IP addresses associated with the same user session.
This behavior is significant as it may indicate a session hijacking attack, where
an adversary uses stolen session cookies to access AWS resources from a different
location. If confirmed malicious, this activity could allow unauthorized access
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)
@@ -24,7 +22,7 @@ search: ' `amazon_security_lake` api.operation=DescribeEventAggregates "http_req
| 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
| `aws_concurrent_sessions_from_different_ips_filter`'
| `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
@@ -43,7 +41,8 @@ tags:
asset_type: AWS Account
confidence: 60
impact: 70
message: User $user$ has concurrent sessions from more than one unique IP address in the span of 5 minutes.
message: User $user$ has concurrent sessions from more than one unique IP address
in the span of 5 minutes.
mitre_attack_id:
- T1185
observable:
@@ -61,8 +60,8 @@ tags:
- Splunk Cloud
required_fields:
- api.operation
- actor.user.account_uid
- actor.user.name
- actor.user.account_uid
- actor.user.name
- actor.user.uid
- http_request.user_agent
- src_endpoint.ip
@@ -73,6 +72,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/aws_concurrent_sessions_from_different_ips/asl_ocsf_cloudtrail.json
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1185/aws_concurrent_sessions_from_different_ips/asl_ocsf_cloudtrail.json
sourcetype: aws:cloudtrail:lake
source: aws_asl
detections/cloud/asl_aws_defense_evasion_delete_cloudtrail.yml
+24 -19
View File
@@ -1,26 +1,30 @@
name: ASL AWS Defense Evasion Delete Cloudtrail
id: 1f0b47e5-0134-43eb-851c-e3258638945e
version: 3
date: '2024-02-12'
version: 4
date: '2024-05-29'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects the deletion of AWS CloudTrail logs, a critical event that could indicate
an adversary's attempt to evade detection. By identifying `DeleteTrail` events within CloudTrail logs, this analytic helps
in uncovering efforts to impair defense mechanisms by preventing the logging of malicious activities. Such actions allow adversaries
to operate undetected within a compromised AWS environment. Recognizing these deletion events is crucial for a
Security Operations Center (SOC) as it signals a potential compromise and the attacker's intent to hide their tracks,
making it a significant threat to the integrity and security of cloud environments. The impact of this attack is substantial,
as it can lead to a complete loss of visibility into the activities within the environment, hindering incident response and forensics efforts.
description: The following analytic detects AWS `DeleteTrail` events within CloudTrail
logs. It leverages Amazon Security Lake logs parsed in the Open Cybersecurity Schema
Framework (OCSF) format to identify when a CloudTrail is deleted. This activity
is significant because adversaries may delete CloudTrail logs to evade detection
and operate with stealth. If confirmed malicious, this action could allow attackers
to cover their tracks, making it difficult to trace their activities and investigate
other potential compromises within the AWS environment.
data_source: []
search: '`amazon_security_lake` api.operation=DeleteTrail | fillnull
| stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`|
search: '`amazon_security_lake` api.operation=DeleteTrail | fillnull | stats count
min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid
actor.user.uid http_request.user_agent src_endpoint.ip cloud.region | rename actor.user.uid
as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent
as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`|
`security_content_ctime(lastTime)`| `asl_aws_defense_evasion_delete_cloudtrail_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
the Federated Analytics App.
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 the Federated Analytics App.
known_false_positives: While this search has no known false positives, it is possible
that an AWS admin has stopped cloudTrail logging. Please investigate this activity.
references:
@@ -50,8 +54,8 @@ tags:
- Splunk Cloud
required_fields:
- api.operation
- actor.user.account_uid
- actor.user.name
- actor.user.account_uid
- actor.user.name
- actor.user.uid
- http_request.user_agent
- src_endpoint.ip
@@ -61,6 +65,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/asl_ocsf_cloudtrail.json
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/stop_delete_cloudtrail/asl_ocsf_cloudtrail.json
sourcetype: aws:cloudtrail:lake
source: aws_asl
detections/cloud/asl_aws_defense_evasion_delete_cloudwatch_log_group.yml
+25 -19
View File
@@ -1,26 +1,31 @@
name: ASL AWS Defense Evasion Delete CloudWatch Log Group
id: 0f701b38-a0fb-43fd-a83d-d12265f71f33
version: 2
date: '2024-02-12'
version: 3
date: '2024-05-25'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects the deletion of CloudWatch Log Groups within AWS CloudTrail logs.
This action is indicative of an attacker's attempt to evade detection by disrupting the logging and monitoring capabilities of CloudWatch.
By identifying and analyzing `DeleteLogGroup` events, this analytic helps in uncovering efforts to obscure malicious activities within a
compromised AWS environment. Such evasion tactics are critical for a Security Operations Center (SOC) to identify as they signal an
attacker's intent to operate undetected, posing a significant threat to the integrity and security of cloud environments.
The impact of this attack is substantial, as it can lead to a loss of visibility into potentially malicious activities,
hindering incident response and forensics efforts.
description: The following analytic detects the deletion of CloudWatch log groups
in AWS, identified through `DeleteLogGroup` events in CloudTrail logs. This method
leverages Amazon Security Lake logs parsed in the OCSF format. The activity is significant
because attackers may delete log groups to evade detection and disrupt logging capabilities,
hindering incident response efforts. If confirmed malicious, this action could allow
attackers to cover their tracks, making it difficult to trace their activities and
potentially leading to undetected data breaches or further malicious actions within
the compromised AWS environment.
data_source: []
search: '`amazon_security_lake` api.operation=DeleteLogGroup | fillnull
| stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`|
search: '`amazon_security_lake` api.operation=DeleteLogGroup | fillnull | stats count
min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid
actor.user.uid http_request.user_agent src_endpoint.ip cloud.region | rename actor.user.uid
as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent
as user_agent, actor.user.account_uid as aws_account_id | `security_content_ctime(firstTime)`|
`security_content_ctime(lastTime)`| `asl_aws_defense_evasion_delete_cloudwatch_log_group_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
the Federated Analytics App.
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 the Federated Analytics App.
known_false_positives: While this search has no known false positives, it is possible
that an AWS admin has deleted CloudWatch logging. Please investigate this activity.
references:
@@ -50,8 +55,8 @@ tags:
- Splunk Cloud
required_fields:
- api.operation
- actor.user.account_uid
- actor.user.name
- actor.user.account_uid
- actor.user.name
- actor.user.uid
- http_request.user_agent
- src_endpoint.ip
@@ -61,6 +66,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/delete_cloudwatch_log_group/asl_ocsf_cloudtrail.json
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/delete_cloudwatch_log_group/asl_ocsf_cloudtrail.json
source: aws_asl
sourcetype: aws:cloudtrail:lake
detections/cloud/asl_aws_defense_evasion_impair_security_services.yml
+26 -21
View File
@@ -1,27 +1,31 @@
name: ASL AWS Defense Evasion Impair Security Services
id: 5029b681-0462-47b7-82e7-f7e3d37f5a2d
version: 2
date: '2024-02-12'
version: 3
date: '2024-05-13'
author: Patrick Bareiss, Bhavin Patel, Gowthamaraj Rajendran, Splunk
status: production
type: Hunting
description: The following analytic detects the deletion of critical AWS Security Services configurations through specific API calls
to services like CloudWatch, GuardDuty, and Web Application Firewalls. By monitoring for these deletion actions, the analytic aims
to identify attempts by adversaries to undermine security defenses, such as erasing logging configurations or removing detection mechanisms.
This behavior is crucial for a Security Operations Center (SOC) to identify as it can indicate an attacker's intent to operate
undetected by eliminating evidence of their presence and activities. The impact of such attacks is significant, potentially leaving
the environment vulnerable to further exploitation without any traceable logs or alerts.
description: The following analytic detects the deletion of critical AWS Security
Services configurations, such as CloudWatch alarms, GuardDuty detectors, and Web
Application Firewall rules. It leverages Amazon Security Lake logs to identify specific
API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant
because adversaries often use these actions to disable security monitoring and evade
detection. If confirmed malicious, this could allow attackers to operate undetected,
leading to potential data breaches, unauthorized access, and prolonged persistence
within the AWS environment.
data_source: []
search: '`amazon_security_lake` api.operation IN ("DeleteLogStream","DeleteDetector","DeleteIPSet","DeleteWebACL","DeleteRule","DeleteRuleGroup","DeleteLoggingConfiguration","DeleteAlarms") | fillnull
| stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `asl_aws_defense_evasion_impair_security_services_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
the Federated Analytics App.
search: '`amazon_security_lake` api.operation IN ("DeleteLogStream","DeleteDetector","DeleteIPSet","DeleteWebACL","DeleteRule","DeleteRuleGroup","DeleteLoggingConfiguration","DeleteAlarms")
| fillnull | stats count min(_time) as firstTime max(_time) as lastTime by api.operation
actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region,
http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_defense_evasion_impair_security_services_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 the Federated Analytics App.
known_false_positives: While this search has no known false positives, it is possible
that it is a legitimate admin activity. Please consider filtering out these noisy
events using userAgent, user_arn field names.
@@ -55,8 +59,8 @@ tags:
- Splunk Cloud
required_fields:
- api.operation
- actor.user.account_uid
- actor.user.name
- actor.user.account_uid
- actor.user.name
- actor.user.uid
- http_request.user_agent
- src_endpoint.ip
@@ -66,6 +70,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_delete_security_services/asl_ocsf_cloudtrail.json
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562.008/aws_delete_security_services/asl_ocsf_cloudtrail.json
sourcetype: aws:cloudtrail:lake
source: aws_asl
detections/cloud/asl_aws_iam_delete_policy.yml
+23 -17
View File
@@ -1,24 +1,29 @@
name: ASL AWS IAM Delete Policy
id: 609ced68-d420-4ff7-8164-ae98b4b4018c
version: 2
date: '2024-02-13'
version: 3
date: '2024-05-22'
author: Patrick Bareiss, Splunk
status: production
type: Hunting
description: The following analytic detects the deletion of an AWS policy, a critical action that could indicate an attempt to alter permissions
or reduce security controls. By monitoring AWS logs for `DeletePolicy` events, this analytic identifies both successful and attempted deletions,
providing insights into potentially malicious activities. Identifying such behavior is crucial for a Security Operations Center (SOC) as it may
signal an adversary's effort to escalate privileges or evade detection. The impact of unauthorized policy deletion is significant,
potentially leading to compromised accounts or data exposure.
description: The following analytic identifies when a policy is deleted in AWS. It
leverages Amazon Security Lake logs to detect the DeletePolicy API operation. Monitoring
policy deletions is crucial as it can indicate unauthorized attempts to weaken security
controls. If confirmed malicious, this activity could allow an attacker to remove
critical security policies, potentially leading to privilege escalation or unauthorized
access to sensitive resources.
data_source: []
search: '`amazon_security_lake` api.operation=DeletePolicy | fillnull
| stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.name actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.name as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id
search: '`amazon_security_lake` api.operation=DeletePolicy | fillnull | stats count
min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid
actor.user.name actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.name as user, src_endpoint.ip as src_ip, cloud.region as region,
http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_iam_delete_policy_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
the Federated Analytics App.
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 the Federated Analytics App.
known_false_positives: This detection will require tuning to provide high fidelity
detection capabilties. Tune based on src addresses (corporate offices, VPN terminations)
or by groups of users. Not every user with AWS access should have permission to
@@ -51,8 +56,8 @@ tags:
- Splunk Cloud
required_fields:
- api.operation
- actor.user.account_uid
- actor.user.name
- actor.user.account_uid
- actor.user.name
- actor.user.uid
- http_request.user_agent
- src_endpoint.ip
@@ -62,6 +67,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_delete_policy/asl_ocsf_cloudtrail.json
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098/aws_iam_delete_policy/asl_ocsf_cloudtrail.json
sourcetype: aws:cloudtrail:lake
source: aws_asl
detections/cloud/asl_aws_multi_factor_authentication_disabled.yml
+26 -20
View File
@@ -1,26 +1,31 @@
name: ASL AWS Multi-Factor Authentication Disabled
id: 4d2df5e0-1092-4817-88a8-79c7fa054668
version: 2
date: '2024-02-13'
version: 3
date: '2024-05-22'
author: Patrick Bareiss, Splunk
status: production
type: TTP
description: The following analytic detects when multi-factor authentication (MFA) is disabled for an AWS IAM user. It operates by monitoring for
specific API calls that deactivate MFA, signaling a potential unauthorized attempt to weaken account security. This behavior is critical for a
Security Operations Center (SOC) to identify, as disabling MFA removes a significant barrier against unauthorized access, making accounts more
vulnerable to compromise. The impact of such an attack is substantial, as it allows adversaries to maintain access within the environment with
less risk of detection, facilitating further malicious activities.
description: The following analytic detects attempts to disable multi-factor authentication
(MFA) for an AWS IAM user. It leverages Amazon Security Lake logs, specifically
monitoring for `DeleteVirtualMFADevice` or `DeactivateMFADevice` API operations.
This activity is significant as disabling MFA can indicate an adversary attempting
to weaken account security to maintain persistence using a compromised account.
If confirmed malicious, this action could allow attackers to retain access to the
AWS environment without detection, potentially leading to unauthorized access to
sensitive resources and prolonged compromise.
data_source: []
search: '`amazon_security_lake` (api.operation=DeleteVirtualMFADevice OR api.operation=DeactivateMFADevice) | fillnull
| stats count min(_time) as firstTime max(_time) as lastTime by api.operation actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region, http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `asl_aws_multi_factor_authentication_disabled_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
the Federated Analytics App.
search: '`amazon_security_lake` (api.operation=DeleteVirtualMFADevice OR api.operation=DeactivateMFADevice)
| fillnull | stats count min(_time) as firstTime max(_time) as lastTime by api.operation
actor.user.account_uid actor.user.uid http_request.user_agent src_endpoint.ip cloud.region
| rename actor.user.uid as user, src_endpoint.ip as src_ip, cloud.region as region,
http_request.user_agent as user_agent, actor.user.account_uid as aws_account_id
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `asl_aws_multi_factor_authentication_disabled_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 the Federated Analytics App.
known_false_positives: AWS Administrators may disable MFA but it is highly unlikely
for this event to occur without prior notice to the company
references:
@@ -54,8 +59,8 @@ tags:
- Splunk Cloud
required_fields:
- api.operation
- actor.user.account_uid
- actor.user.name
- actor.user.account_uid
- actor.user.name
- actor.user.uid
- http_request.user_agent
- src_endpoint.ip
@@ -65,6 +70,7 @@ tags:
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_mfa_disabled/asl_ocsf_cloudtrail.json
- data:
https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/aws_mfa_disabled/asl_ocsf_cloudtrail.json
sourcetype: aws:cloudtrail:lake
source: aws_asl

Some files were not shown because too many files have changed in this diff Show More