From 3e1a60c1b01b1d02ab7e7be9c1908b6fb80c1232 Mon Sep 17 00:00:00 2001 From: elastic-vault-github-plugin-prod Date: Mon, 7 Jul 2025 18:33:02 +0000 Subject: [PATCH 01/13] Add .buildkite and .ci to backport branch: backport-security_detection_engine-9.0 from the main branch --- .buildkite/hooks/pre-command | 18 ------------------ .buildkite/pipeline.backport.yml | 5 +++++ .buildkite/pipeline.schedule-daily.yml | 6 +++--- .buildkite/pipeline.schedule-weekly.yml | 4 ++-- .buildkite/pipeline.serverless.yml | 2 ++ .buildkite/pipeline.yml | 4 ++++ .buildkite/pull-requests.json | 12 +++++++++++- .buildkite/scripts/common.sh | 2 +- 8 files changed, 28 insertions(+), 25 deletions(-) diff --git a/.buildkite/hooks/pre-command b/.buildkite/hooks/pre-command index 8b42bba0039..6952e4e04ce 100755 --- a/.buildkite/hooks/pre-command +++ b/.buildkite/hooks/pre-command @@ -100,8 +100,6 @@ if [[ "${BUILDKITE_PIPELINE_SLUG}" =~ ^(integrations|integrations-test-stack)$ ] if [[ "${BUILDKITE_STEP_KEY}" == "publish-benchmarks" ]]; then BUILDKITE_API_TOKEN=$(retry 5 vault kv get -field buildkite_token "${BUILDKITE_API_TOKEN_PATH}") export BUILDKITE_API_TOKEN - GITHUB_TOKEN=$VAULT_GITHUB_TOKEN - export GITHUB_TOKEN fi if [[ "${BUILDKITE_STEP_KEY}" =~ ^test-integrations- ]]; then @@ -120,19 +118,3 @@ if [[ "${BUILDKITE_PIPELINE_SLUG}" == "integrations-serverless" ]]; then export EC_REGION_SECRET fi fi - -if [[ "$BUILDKITE_PIPELINE_SLUG" == "integrations-backport" ]]; then - if [[ "$BUILDKITE_STEP_KEY" == "create-backport-branch" ]]; then - GITHUB_USERNAME="elastic-vault-github-plugin-prod" - GITHUB_EMAIL="elasticmachine@elastic.co" - GITHUB_TOKEN=$VAULT_GITHUB_TOKEN - export GITHUB_TOKEN GITHUB_EMAIL GITHUB_USERNAME - fi -fi - -if [[ "$BUILDKITE_PIPELINE_SLUG" == "integrations" || "$BUILDKITE_PIPELINE_SLUG" == "integrations-serverless" ]]; then - if [[ "$BUILDKITE_STEP_KEY" == "report-failed-tests" ]]; then - export GITHUB_TOKEN="${VAULT_GITHUB_TOKEN}" - fi -fi - diff --git a/.buildkite/pipeline.backport.yml b/.buildkite/pipeline.backport.yml index f25b2d2ead2..15e93c8bc26 100644 --- a/.buildkite/pipeline.backport.yml +++ b/.buildkite/pipeline.backport.yml @@ -53,6 +53,11 @@ steps: command: ".buildkite/scripts/backport_branch.sh" agents: image: "${LINUX_AGENT_IMAGE}" + env: + GITHUB_EMAIL: "elasticmachine@elastic.co" + GITHUB_USERNAME: "elastic-vault-github-plugin-prod" + plugins: + - elastic/vault-github-token#v0.1.0: depends_on: - step: "input-variables" allow_failure: false diff --git a/.buildkite/pipeline.schedule-daily.yml b/.buildkite/pipeline.schedule-daily.yml index fea43a0b41f..d866a3939c3 100644 --- a/.buildkite/pipeline.schedule-daily.yml +++ b/.buildkite/pipeline.schedule-daily.yml @@ -21,7 +21,7 @@ steps: env: SERVERLESS: "false" FORCE_CHECK_ALL: "true" - STACK_VERSION: 7.17.28 + STACK_VERSION: 7.17.29 depends_on: - step: "check" allow_failure: false @@ -86,13 +86,13 @@ steps: if: | build.env('TEST_PACKAGES_BASIC_SUBSCRIPTION') == "true" - - label: "Check integrations local stacks - Stack Version v9.1" + - label: "Check integrations local stacks - Stack Version v9.2" trigger: "integrations" build: env: SERVERLESS: "false" FORCE_CHECK_ALL: "true" - STACK_VERSION: 9.1.0-SNAPSHOT + STACK_VERSION: 9.2.0-SNAPSHOT PUBLISH_COVERAGE_REPORTS: "false" depends_on: - step: "check" diff --git a/.buildkite/pipeline.schedule-weekly.yml b/.buildkite/pipeline.schedule-weekly.yml index a929ef0feed..a7c7d865ae6 100644 --- a/.buildkite/pipeline.schedule-weekly.yml +++ b/.buildkite/pipeline.schedule-weekly.yml @@ -28,13 +28,13 @@ steps: - step: "check" allow_failure: false - - label: "Check integrations local stacks and non-wolfi images for Elastic Agent - Stack Version v9.1" + - label: "Check integrations local stacks and non-wolfi images for Elastic Agent - Stack Version v9.2" trigger: "integrations" build: env: SERVERLESS: "false" FORCE_CHECK_ALL: "true" - STACK_VERSION: 9.1.0-SNAPSHOT + STACK_VERSION: 9.2.0-SNAPSHOT PUBLISH_COVERAGE_REPORTS: "false" ELASTIC_PACKAGE_DISABLE_ELASTIC_AGENT_WOLFI: "true" depends_on: diff --git a/.buildkite/pipeline.serverless.yml b/.buildkite/pipeline.serverless.yml index fb38464bd41..47f91bb78d3 100644 --- a/.buildkite/pipeline.serverless.yml +++ b/.buildkite/pipeline.serverless.yml @@ -110,6 +110,8 @@ steps: image: "${LINUX_AGENT_IMAGE}" cpu: "8" memory: "4G" + plugins: + - elastic/vault-github-token#v0.1.0: # not fail build if this step fails soft_fail: true # run this step when if it is triggered by the daily job diff --git a/.buildkite/pipeline.yml b/.buildkite/pipeline.yml index d531e884ece..fb97e6c451f 100644 --- a/.buildkite/pipeline.yml +++ b/.buildkite/pipeline.yml @@ -70,6 +70,8 @@ steps: image: "${LINUX_AGENT_IMAGE}" cpu: "8" memory: "4G" + plugins: + - elastic/vault-github-token#v0.1.0: if: | build.env('BUILDKITE_PULL_REQUEST') != "false" && build.env('BUILDKITE_PIPELINE_SLUG') == "integrations" @@ -108,6 +110,8 @@ steps: image: "${LINUX_AGENT_IMAGE}" cpu: "8" memory: "4G" + plugins: + - elastic/vault-github-token#v0.1.0: # not fail build if this step fails soft_fail: true # run this step when if it is triggered by the daily job diff --git a/.buildkite/pull-requests.json b/.buildkite/pull-requests.json index ff3459d620f..618212f0d59 100644 --- a/.buildkite/pull-requests.json +++ b/.buildkite/pull-requests.json @@ -13,7 +13,17 @@ "always_trigger_comment_regex": "^(?:(?:buildkite\\W+)?(?:build|test)\\W+(?:this|it))|^/test$|^/test benchmark fullreport$", "skip_ci_labels": [], "skip_target_branches": [], - "skip_ci_on_only_changed": ["^.github/workflows/", "^.github/dependabot.yml$", "^.github/ISSUE_TEMPLATE/", "^docs/", "^catalog-info.yaml$", "^.buildkite/pull-requests.json$"], + "skip_ci_on_only_changed": [ + "^.github/workflows/", + "^.github/dependabot.yml$", + "^.github/ISSUE_TEMPLATE/", + "^docs/", + "^catalog-info.yaml$", + "^.buildkite/pipeline.schedule-daily.yml$", + "^.buildkite/pipeline.schedule-weekly.yml$", + "^.buildkite/pipeline.backport.yml$", + "^.buildkite/pull-requests.json$" + ], "always_require_ci_on_changed": [] }, { diff --git a/.buildkite/scripts/common.sh b/.buildkite/scripts/common.sh index 2d477165737..eb4eb74eacf 100755 --- a/.buildkite/scripts/common.sh +++ b/.buildkite/scripts/common.sh @@ -746,7 +746,7 @@ is_pr_affected() { # Example: # https://buildkite.com/elastic/integrations/builds/25606 # https://github.com/elastic/integrations/pull/13810 - if git diff --name-only "${commit_merge}" "${to}" | grep -E -v '^(packages/|\.github/(CODEOWNERS|ISSUE_TEMPLATE|PULL_REQUEST_TEMPLATE)|README\.md|docs/|catalog-info\.yaml|\.buildkite/pull-requests\.json)' > /dev/null; then + if git diff --name-only "${commit_merge}" "${to}" | grep -E -v '^(packages/|\.github/(CODEOWNERS|ISSUE_TEMPLATE|PULL_REQUEST_TEMPLATE)|README\.md|docs/|catalog-info\.yaml|\.buildkite/(pull-requests\.json|pipeline\.schedule-daily\.yml|pipeline\.schedule-weekly\.yml|pipeline\.backport\.yml))' > /dev/null; then echo "[${package}] PR is affected: found non-package files" return 0 fi From 5ae9b4903de99542d490b025bd4be817b995484d Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 8 Jul 2025 06:29:28 -0400 Subject: [PATCH 02/13] [Security Rules] Update security rules package to v9.0.8-beta.1 (#14446) --- .../security_detection_engine/changelog.yml | 5 + ...2b4420d-eda2-4529-9e46-4a60eccb7e2d_4.json | 71 ++++ ...889c4-2686-4583-a7df-67f89c292f2c_213.json | 113 ------- ...1ef73-1fde-4a49-a34a-5dd40011b076_316.json | 142 ++++++++ ...83383af-b9a4-42b7-a463-29c40efe7797_2.json | 81 +++++ ...fe2290a-2664-4c9c-8263-b88904f12f0d_1.json | 100 ++++++ ...2f15d-597e-4334-88ff-38a02cb1330b_207.json | 93 ++++++ ...bf709-69e8-4055-94f9-24314385c27e_208.json | 109 +++++++ ...811c-d60f-11ec-9fd7-f661ea17fbce_208.json} | 27 +- ...600f9e2-5be6-4742-8593-1ba50cd94069_2.json | 89 ++++++ ...78770e0-5c20-4246-b430-e216a2888b23_4.json | 66 ++++ ...4dd64-7e6c-4bad-ac73-a5014ee37042_118.json | 174 ---------- ...4dd64-7e6c-4bad-ac73-a5014ee37042_119.json | 174 ---------- ...4dd64-7e6c-4bad-ac73-a5014ee37042_120.json | 174 ---------- ...d0027d4-6717-4a37-bad8-531d8e9fe53f_2.json | 124 +++++++ ...a3f7c-21e7-4bb1-98c7-2036612fb1be_213.json | 302 ++++++++++++++++++ ...388c687-cb2c-4b7b-be8f-6864a2385048_1.json | 120 +++++++ ...64c641e-c202-11ef-993e-f661ea17fbce_2.json | 111 ------- ...88a198e-9b9b-11ef-a0a8-f661ea17fbcd_5.json | 143 +++++++++ ...8f6f34b-8e16-487a-b5fd-9d22eb903db8_6.json | 113 ------- ...da169-416b-4bb3-9a6b-f8d239fd78ba_208.json | 108 +++++++ ...9e96a-b67c-455a-afe4-de6183431d0d_216.json | 144 +++++++++ ...6e1bc-867a-11ee-b13e-f661ea17fbcd_305.json | 63 ++++ ...278313c-d6cd-4d49-aa24-644e1da6623c_4.json | 71 ++++ ...3c27b4e-8ec6-406f-b8e5-345dc024aa97_1.json | 88 +++++ ...b3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json | 81 +++++ ...f0dd8-092d-4a83-88c1-5151a804f31b_316.json | 124 ------- ...6188365-f88f-4f70-8c1d-0b9554186b9c_2.json | 64 ++++ ...211e8-4e2f-440f-86d8-06cc8f158cfa_214.json | 117 +++++++ ...44f38-5284-4f8e-a2ae-e3fd628d90b0_207.json | 92 ------ ...aff6ab1-18bd-427e-9d4c-c5732110c261_2.json | 131 ++++++++ ...0e60816-5122-11f0-9caa-f661ea17fbcd_1.json | 166 ++++++++++ ...182e486-fc61-11ee-a05d-f661ea17fbce_3.json | 56 ---- ...0d948-40d4-4cef-ac69-4002e29bc3db_319.json | 158 +++++++++ ...19484-9826-4083-9eba-1da74cd0eaf2_111.json | 126 ++++++++ ...b77d382-b78e-4aae-85a0-8841b80e4fc4_1.json | 73 +++++ ...d4cda2b-9aad-4702-a0a2-75952bd6a77c_2.json | 77 +++++ ...0a2bdea-9876-11ef-89db-f661ea17fbcd_5.json | 116 +++++++ ...2bf58-2a39-4c58-a384-c8b1978153c2_216.json | 118 +++++++ ...6d9cf6c-46ea-4019-9c7f-b1fdb855fee3_2.json | 115 +++++++ ...c05204-339a-11ed-a261-0242ac120002_10.json | 99 ++++++ ...3c056a0-339a-11ed-a261-0242ac120002_9.json | 77 +++++ ...c057cc-339a-11ed-a261-0242ac120002_10.json | 90 ++++++ ...4f17c52-6c6e-479e-ba72-236f3df18f3d_3.json | 81 +++++ ...505e02e-28dd-41cd-b18f-64e649caa4e2_2.json | 111 +++++++ ...5613f5e-0d48-4b55-ad61-2fb9567cb1ad_2.json | 157 +++++++++ ...56739a8-2786-402b-8ee1-22e0762b63ba_2.json | 111 +++++++ ...9bccd-510b-40df-8263-334f03174fed_207.json | 89 ++++++ ...8e90a9b-0eab-425e-be3b-902b0cd1fe9c_2.json | 94 ++++++ ...ddb6c33-00ce-4acd-832a-24b251512023_3.json | 81 +++++ ...a2cc4-d260-11ed-8829-f661ea17fbcc_113.json | 118 +++++++ ...e2355cc-c60a-4d92-a80c-e54a45ad2400_2.json | 121 ------- ...eb862bb-013d-4d4f-a14b-341433ca1a1f_2.json | 96 ++++++ ...947e9-de7e-4281-a55d-09289bdf947e_112.json | 112 +++++++ ...0089609-c41a-438e-b132-5b3b43c5fc07_2.json | 103 ++++++ ...164081a-3930-11ed-a261-0242ac120002_9.json | 110 +++++++ ...ccb61-e19b-452f-b104-79a60e546a95_320.json | 121 +++++++ ...2c91fc0-4ac0-11f0-811f-f661ea17fbcd_1.json | 141 ++++++++ ...4e5241e-c1a1-4e70-844e-84ee3d73eb7d_1.json | 100 ++++++ ...51b0329-7295-4682-b9c7-4473b99add69_4.json | 70 ++++ ...c8437-a581-4537-8060-1fdb0e92c92d_208.json | 109 +++++++ ...fc95782-4bd1-11f0-9838-f661ea17fbcd_1.json | 146 +++++++++ ...167c5ae-3310-439a-8a58-be60f55023d2_2.json | 122 +++++++ ...446517c-f789-11ee-8ad0-f661ea17fbce_4.json | 100 ------ ...5e2d45e-a3df-4acf-83d3-21805f564ff4_2.json | 81 +++++ ...3535c-1e17-44e1-aa97-7a0699c3037d_207.json | 98 ------ ...77cc04a-3320-411d-bbe9-53266fa5e107_1.json | 120 +++++++ ...d696bd0-5756-11f0-8e3b-f661ea17fbcd_1.json | 102 ++++++ ...0efea04-5675-11f0-8f80-f661ea17fbcd_1.json | 117 +++++++ ...75852-b0f5-4b8b-89c3-a226efae5726_213.json | 146 +++++++++ ...5fd2c-9947-4472-86ef-4aceb2f7e872_209.json | 96 ------ ...563dace-5822-11f0-b1d3-f661ea17fbcd_1.json | 113 +++++++ ...6f29282-ffcc-4ce7-834b-b17aee905568_2.json | 120 +++++++ ...8ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_1.json | 95 ++++++ ...d7407-0bd5-5817-cda0-3fcc33113a56_209.json | 84 ----- ...a6f5d74-c7e7-4a8b-945e-462c102daee4_2.json | 105 ++++++ ...edd1804-83c7-4e48-b97d-c776b4c97564_2.json | 81 +++++ ...f432a8b-9588-4550-838e-1f77285580d3_3.json | 81 +++++ ...cb68e-7c93-48d1-93b2-2c39023308eb_115.json | 102 ++++++ ...7473a-5cb4-4bc1-9d06-e4a75adbc494_112.json | 126 ++++++++ ...326d7-dca7-4fb7-93eb-1ca03a1febbd_210.json | 97 ------ ...a2759-5c34-440a-b0c4-51fe674611d6_202.json | 125 -------- ...f1e36fe-0abd-4463-b5ec-4e276dec0b26_2.json | 91 ++++++ ...0c98cfb-0745-4513-b6f9-08dddb033490_2.json | 81 +++++ ...11116fd-023c-4718-aeb8-fa9d283fc53b_2.json | 122 +++++++ ...a13c6-ba45-4bab-a534-df53d0cfed6a_319.json | 118 +++++++ ...53f1d73-150d-484d-8f02-222abeb5d5fa_1.json | 123 +++++++ ...946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_6.json | 59 ++++ ...d18f4a3-c4c6-43b9-a1e4-b05e09998110_2.json | 98 ++++++ ...e70614d-4295-473c-a953-582aef41c865_2.json | 97 ++++++ ...1e79a70-fa6f-11ee-8bc8-f661ea17fbce_3.json | 122 ------- ...6655282-6c79-11ef-bbb5-f661ea17fbcc_1.json | 57 ---- ...08cac-337a-4f38-b50d-5eeb78bdb531_208.json | 108 +++++++ ...ca64114-fb8b-11ef-86e2-f661ea17fbce_2.json | 81 +++++ ...d82e3d6-1346-4afd-8f22-38388bbf34cb_4.json | 110 ------- ...1bafa-9f01-4f43-a872-605b678968b0_214.json | 106 ------ ...e73954b-a0a4-4f05-b67b-294c500dac77_2.json | 112 +++++++ ...121f0a8-4875-11f0-bb2b-f661ea17fbcd_1.json | 106 ++++++ ...19a2399-f8e2-4b10-80d8-a561ce9d24d1_2.json | 108 +++++++ ...43f2b43-02a1-4219-8ce9-10929a32a618_2.json | 81 +++++ ...fda76-c92b-4943-bc68-04460a5ea5ba_208.json | 109 +++++++ ...f042e-c590-4e82-8e05-41e81bd822ad_320.json | 156 +++++++++ ...8f3f6-7c4c-45bb-846a-053738b3fe5d_110.json | 108 +++++++ ...31051-ee01-4307-a6ee-b21b186958f4_211.json | 144 +++++++++ ...903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json | 81 +++++ ...c81962e-4bc8-48e6-bfb0-545fc97d8f6a_1.json | 75 +++++ ...ef9f8b5-48ec-44b5-b8bd-7b9b7d71853c_1.json | 104 ++++++ ...f395dff-be12-4a6e-8919-d87d627c2174_2.json | 107 +++++++ ...38633f4-3b31-4c80-b13d-e77c70ce8254_2.json | 81 +++++ ...6d8c743-0916-4483-8333-3c6f107e0caa_3.json | 81 +++++ ...9abcddc-a05d-4345-a81d-000b79aa5525_3.json | 81 +++++ ...a6052-58fa-4397-93c3-4795249ccfa2_423.json | 220 +++++++++++++ .../security_detection_engine/manifest.yml | 2 +- 113 files changed, 9737 insertions(+), 2259 deletions(-) create mode 100644 packages/security_detection_engine/kibana/security_rule/02b4420d-eda2-4529-9e46-4a60eccb7e2d_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/035889c4-2686-4583-a7df-67f89c292f2c_213.json create mode 100644 packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_316.json create mode 100644 packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0fe2290a-2664-4c9c-8263-b88904f12f0d_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_207.json create mode 100644 packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_208.json rename packages/security_detection_engine/kibana/security_rule/{14de811c-d60f-11ec-9fd7-f661ea17fbce_204.json => 14de811c-d60f-11ec-9fd7-f661ea17fbce_208.json} (90%) create mode 100644 packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/178770e0-5c20-4246-b430-e216a2888b23_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_118.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_119.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_120.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_213.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2388c687-cb2c-4b7b-be8f-6864a2385048_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_5.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/28f6f34b-8e16-487a-b5fd-9d22eb903db8_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_208.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_216.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_305.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3278313c-d6cd-4d49-aa24-644e1da6623c_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/33c27b4e-8ec6-406f-b8e5-345dc024aa97_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/35df0dd8-092d-4a83-88c1-5151a804f31b_316.json create mode 100644 packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_214.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/39144f38-5284-4f8e-a2ae-e3fd628d90b0_207.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/40e60816-5122-11f0-9caa-f661ea17fbcd_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_319.json create mode 100644 packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_111.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4b77d382-b78e-4aae-85a0-8841b80e4fc4_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4d4cda2b-9aad-4702-a0a2-75952bd6a77c_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_216.json create mode 100644 packages/security_detection_engine/kibana/security_rule/56d9cf6c-46ea-4019-9c7f-b1fdb855fee3_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_10.json create mode 100644 packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_9.json create mode 100644 packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_10.json create mode 100644 packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6505e02e-28dd-41cd-b18f-64e649caa4e2_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_207.json create mode 100644 packages/security_detection_engine/kibana/security_rule/68e90a9b-0eab-425e-be3b-902b0cd1fe9c_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_113.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6e2355cc-c60a-4d92-a80c-e54a45ad2400_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6eb862bb-013d-4d4f-a14b-341433ca1a1f_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_112.json create mode 100644 packages/security_detection_engine/kibana/security_rule/70089609-c41a-438e-b132-5b3b43c5fc07_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_9.json create mode 100644 packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_320.json create mode 100644 packages/security_detection_engine/kibana/security_rule/72c91fc0-4ac0-11f0-811f-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/751b0329-7295-4682-b9c7-4473b99add69_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_208.json create mode 100644 packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/8446517c-f789-11ee-8ad0-f661ea17fbce_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/8623535c-1e17-44e1-aa97-7a0699c3037d_207.json create mode 100644 packages/security_detection_engine/kibana/security_rule/877cc04a-3320-411d-bbe9-53266fa5e107_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8d696bd0-5756-11f0-8e3b-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_213.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/9395fd2c-9947-4472-86ef-4aceb2f7e872_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9563dace-5822-11f0-b1d3-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/96f29282-ffcc-4ce7-834b-b17aee905568_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9a6f5d74-c7e7-4a8b-945e-462c102daee4_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_115.json create mode 100644 packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_112.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_210.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/ac5a2759-5c34-440a-b0c4-51fe674611d6_202.json create mode 100644 packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b11116fd-023c-4718-aeb8-fa9d283fc53b_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_319.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b53f1d73-150d-484d-8f02-222abeb5d5fa_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/bd18f4a3-c4c6-43b9-a1e4-b05e09998110_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_208.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/cd82e3d6-1346-4afd-8f22-38388bbf34cb_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_214.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ce73954b-a0a4-4f05-b67b-294c500dac77_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d121f0a8-4875-11f0-bb2b-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d19a2399-f8e2-4b10-80d8-a561ce9d24d1_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_208.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_320.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_110.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_211.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ec81962e-4bc8-48e6-bfb0-545fc97d8f6a_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_423.json diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index d83db141484..83a87ce31ff 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.8-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14446 - version: 9.0.7 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/02b4420d-eda2-4529-9e46-4a60eccb7e2d_4.json b/packages/security_detection_engine/kibana/security_rule/02b4420d-eda2-4529-9e46-4a60eccb7e2d_4.json new file mode 100644 index 00000000000..b020b724716 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/02b4420d-eda2-4529-9e46-4a60eccb7e2d_4.json @@ -0,0 +1,71 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity. Attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence.", + "from": "now-3h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "pad_okta_spike_in_group_privilege_changes", + "name": "Spike in Group Privilege Change Events", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Spike in Group Privilege Change Events\n\nIn environments using Okta, group privilege changes are crucial for managing access. Adversaries may exploit this by adding themselves to privileged groups, gaining unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential privilege escalation attempts, thus aiding in early threat detection and response.\n\n### Possible investigation steps\n\n- Review the specific group privilege change events identified by the machine learning job to determine which accounts were added to privileged groups.\n- Cross-reference the accounts involved in the privilege changes with recent login activity to identify any unusual or suspicious access patterns.\n- Check the history of privilege changes for the affected groups to see if there is a pattern of unauthorized access or if this is an isolated incident.\n- Investigate the source IP addresses and locations associated with the privilege change events to identify any anomalies or unexpected geolocations.\n- Examine any recent changes to the accounts involved, such as password resets or multi-factor authentication (MFA) modifications, to assess if they have been compromised.\n- Collaborate with the affected users or their managers to verify if the privilege changes were authorized and legitimate.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger spikes in group privilege changes. Regularly scheduled audits or updates to group memberships should be documented and excluded from alerts.\n- Automated scripts or tools that manage user access can cause frequent changes. Identify these scripts and create exceptions for their activity to prevent false positives.\n- Organizational restructuring or mergers often lead to bulk updates in group privileges. During these periods, temporarily adjust the sensitivity of the detection rule or whitelist specific activities.\n- Onboarding or offboarding processes can result in a high volume of legitimate group changes. Coordinate with HR and IT to anticipate these events and adjust monitoring accordingly.\n- Changes in security policies or compliance requirements might necessitate widespread privilege adjustments. Ensure these policy-driven changes are communicated to the security team to avoid unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected accounts by removing them from any high-privilege groups to prevent further unauthorized access.\n- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized privilege escalations.\n- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise.\n- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further suspicious activity is detected.\n- Implement additional monitoring on the affected accounts and privileged groups to detect any further unauthorized changes or access attempts.\n- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future privilege escalation.\n- Document the incident, including all actions taken, to improve response strategies and inform future security measures.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/pad" + ], + "related_integrations": [ + { + "package": "pad", + "version": "^0.0.1" + }, + { + "package": "okta", + "version": "^3.5.0" + } + ], + "risk_score": 21, + "rule_id": "02b4420d-eda2-4529-9e46-4a60eccb7e2d", + "setup": "## Setup\n\nThe rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.\n\n### Privileged Access Detection Setup\nThe Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Privileged Access Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.\n- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.\n\n#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Privileged Access Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1068", + "name": "Exploitation for Privilege Escalation", + "reference": "https://attack.mitre.org/techniques/T1068/" + }, + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "type": "machine_learning", + "version": 4 + }, + "id": "02b4420d-eda2-4529-9e46-4a60eccb7e2d_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/035889c4-2686-4583-a7df-67f89c292f2c_213.json b/packages/security_detection_engine/kibana/security_rule/035889c4-2686-4583-a7df-67f89c292f2c_213.json deleted file mode 100644 index ab3459792eb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/035889c4-2686-4583-a7df-67f89c292f2c_213.json +++ /dev/null @@ -1,113 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule identifies a high number (10) of process terminations (stop, delete, or suspend) from the same host within a short time period.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-endpoint.events.process-*", - "logs-system.security*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "High Number of Process and/or Service Terminations", - "note": "## Triage and analysis\n\n### Investigating High Number of Process and/or Service Terminations\n\nAttackers can stop services and kill processes for a variety of purposes. For example, they can stop services associated with business applications and databases to release the lock on files used by these applications so they may be encrypted, or stop security and backup solutions, etc.\n\nThis rule identifies a high number (10) of service and/or process terminations (stop, delete, or suspend) from the same host within a short time period.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check if any files on the host machine have been encrypted.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Reimage the host operating system or restore it to the operational state.\n- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "event.category:process and host.os.type:windows and event.type:start and process.name:(net.exe or sc.exe or taskkill.exe) and\n process.args:(stop or pause or delete or \"/PID\" or \"/IM\" or \"/T\" or \"/F\" or \"/t\" or \"/f\" or \"/im\" or \"/pid\") and\n not process.parent.name:osquerybeat.exe\n", - "references": [ - "https://www.elastic.co/security-labs/luna-ransomware-attack-pattern" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "system", - "version": "^1.6.4" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "035889c4-2686-4583-a7df-67f89c292f2c", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Impact", - "Resources: Investigation Guide", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Data Source: Windows Security Event Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1489", - "name": "Service Stop", - "reference": "https://attack.mitre.org/techniques/T1489/" - } - ] - } - ], - "threshold": { - "field": [ - "host.id" - ], - "value": 10 - }, - "timestamp_override": "event.ingested", - "type": "threshold", - "version": 213 - }, - "id": "035889c4-2686-4583-a7df-67f89c292f2c_213", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_316.json b/packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_316.json new file mode 100644 index 00000000000..b55a8028514 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_316.json @@ -0,0 +1,142 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies registry modification to the LocalAccountTokenFilterPolicy policy. If this value exists (which doesn't by default) and is set to 1, then remote connections from all local members of Administrators are granted full high-integrity tokens during negotiation.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-m365_defender.event-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Local Account TokenFilter Policy Disabled", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Local Account TokenFilter Policy Disabled\n\nThe LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses.\n\n### Possible investigation steps\n\n- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is \"LocalAccountTokenFilterPolicy\" and registry.data.strings is \"1\" or \"0x00000001\".\n- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information.\n- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement.\n- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity.\n- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and assess the scope of the potential threat.\n- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change.\n\n### False positive analysis\n\n- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes.\n- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign.\n- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts.\n- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.\n- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization.\n- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes.\n- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials.\n- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings.\n- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign.\n- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats.", + "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.value : \"LocalAccountTokenFilterPolicy\" and\n registry.path : (\n \"HKLM\\\\*\\\\LocalAccountTokenFilterPolicy\",\n \"\\\\REGISTRY\\\\MACHINE\\\\*\\\\LocalAccountTokenFilterPolicy\",\n \"MACHINE\\\\*\\\\LocalAccountTokenFilterPolicy\"\n ) and registry.data.strings : (\"1\", \"0x00000001\") and\n not process.executable : (\n /* Intune */\n \"C:\\\\Windows\\\\system32\\\\deviceenroller.exe\",\n \"C:\\\\Windows\\\\system32\\\\omadmclient.exe\"\n )\n", + "references": [ + "https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2014-04-02/finding/V-36439", + "https://posts.specterops.io/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy-506c25a7c167", + "https://www.welivesecurity.com/wp-content/uploads/2018/01/ESET_Turla_Mosquito.pdf" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "07b1ef73-1fde-4a49-a34a-5dd40011b076", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Lateral Movement", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + }, + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.002", + "name": "Pass the Hash", + "reference": "https://attack.mitre.org/techniques/T1550/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 316 + }, + "id": "07b1ef73-1fde-4a49-a34a-5dd40011b076_316", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_2.json b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_2.json new file mode 100644 index 00000000000..af96a0219c2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating commands to evade detection, often using concatenated strings in dynamic invocations. This detection rule identifies such obfuscation by analyzing script patterns, specifically looking for concatenated strings within dynamic command invocations, which are indicative of attempts to bypass security measures like AMSI. By counting these patterns, the rule effectively flags suspicious scripts, aiding in the identification of potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content and purpose of the script, focusing on the concatenated strings and dynamic command invocations.\n- Check the `host.name` and `user.id` fields to identify the machine and user account associated with the execution of the suspicious script, which can help determine if the activity is expected or anomalous.\n- Analyze the `file.path` field to locate the script's source or storage location, which may provide additional context or indicate if the script is part of a known application or process.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related PowerShell activities, which might reveal a broader pattern of behavior.\n- Assess the `agent.id` field to determine the specific endpoint agent involved, which can assist in further endpoint-specific investigations or actions.\n\n### False positive analysis\n\n- Scripts with legitimate concatenated strings for dynamic command execution may trigger the rule. Review the script context to determine if the concatenation serves a valid administrative purpose.\n- Automated scripts from trusted sources that use concatenation for modularity or readability might be flagged. Consider adding these scripts to an allowlist if they are verified as safe.\n- Development or testing environments where PowerShell scripts are frequently modified and tested could generate false positives. Implement exceptions for known development hosts or user accounts.\n- Security tools or monitoring solutions that use PowerShell for legitimate operations may inadvertently match the pattern. Identify these tools and exclude their operations from the rule.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated commands.\n- Conduct a thorough review of the script block text and associated script block ID to understand the intent and potential impact of the obfuscated commands.\n- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and signed.\n- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that all data integrity checks are performed.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems have been compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques, leveraging insights from the MITRE ATT&CK framework.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\" and powershell.file.script_block_text LIKE \"*+*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[.&]\\(\\s*(['\"][A-Za-z0-9.-]+['\"]\\s*\\+\\s*)+['\"][A-Za-z0-9.-]+['\"]\\s*\\)\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "083383af-b9a4-42b7-a463-29c40efe7797", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "083383af-b9a4-42b7-a463-29c40efe7797_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0fe2290a-2664-4c9c-8263-b88904f12f0d_1.json b/packages/security_detection_engine/kibana/security_rule/0fe2290a-2664-4c9c-8263-b88904f12f0d_1.json new file mode 100644 index 00000000000..2aa6c07f9a3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0fe2290a-2664-4c9c-8263-b88904f12f0d_1.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation or modification of sensitive Kubernetes configuration files on Linux systems. These files include Kubernetes manifests, PKI files, and configuration files that are critical for the operation of Kubernetes clusters. Monitoring these files helps identify potential unauthorized changes or misconfigurations that could lead to security vulnerabilities in Kubernetes environments. Attackers may attempt to modify these files to gain persistence or to deploy malicious containers within the Kubernetes cluster.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.file*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubernetes Sensitive Configuration File Activity", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Sensitive Configuration File Activity\n\nKubernetes relies on configuration files to manage cluster operations, including manifests and PKI files. These files are crucial for defining the desired state and security of the cluster. Adversaries may exploit these files to gain persistence or deploy unauthorized containers. The detection rule monitors for unauthorized changes to these files, excluding legitimate processes, to identify potential security threats.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific file path that triggered the alert, focusing on paths like \"/etc/kubernetes/manifests/*\", \"/etc/kubernetes/pki/*\", or \"/etc/kubernetes/*.conf\".\n- Check the process that attempted to modify the file by examining the process name and compare it against the list of excluded legitimate processes (\"kubeadm\", \"kubelet\", \"dpkg\", \"sed\") to determine if it is suspicious.\n- Investigate the user account associated with the process that made the change to assess if the account has the necessary permissions and if it has been compromised.\n- Analyze recent activity on the host to identify any other unusual or unauthorized actions that might correlate with the file modification, such as unexpected network connections or process executions.\n- Review the history of changes to the affected file to determine if there have been other unauthorized modifications or if this is an isolated incident.\n- Consult Kubernetes audit logs, if available, to gather additional context on the actions performed around the time of the alert, focusing on any anomalies or unauthorized access attempts.\n\n### False positive analysis\n\n- Routine updates or maintenance activities by system administrators can trigger alerts. To manage this, consider excluding processes or users known to perform regular maintenance from the rule.\n- Automated scripts or configuration management tools like Ansible or Puppet may modify configuration files as part of their normal operation. Identify these tools and add them to the exclusion list to prevent unnecessary alerts.\n- Scheduled backups or system snapshots might access or modify configuration files. Ensure that these processes are recognized and excluded if they are part of a regular, non-threatening operation.\n- Legitimate software updates or patches may alter configuration files. Monitor update schedules and exclude these processes during known update windows to reduce false positives.\n- Custom scripts developed in-house for cluster management might not be recognized by default. Review these scripts and add them to the exclusion list if they are verified as safe and necessary for operations.\n\n### Response and remediation\n\n- Immediately isolate the affected node or container to prevent further unauthorized access or changes to the Kubernetes configuration files.\n- Review the modified configuration files to identify unauthorized changes and revert them to their last known good state using backups or version control systems.\n- Conduct a thorough investigation to identify the source of the unauthorized changes, focusing on process names and user accounts involved in the modification.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems or nodes have been compromised.\n- Implement additional access controls and monitoring on the affected systems to prevent recurrence, such as restricting write permissions to sensitive directories and files.\n- Update and patch the Kubernetes environment and related components to address any vulnerabilities that may have been exploited.\n- Enhance detection capabilities by ensuring that alerts are configured to notify the security team of any future unauthorized changes to critical Kubernetes configuration files.\n", + "query": "file where host.os.type == \"linux\" and event.type != \"deletion\" and file.path like (\n \"/etc/kubernetes/manifests/*\",\n \"/etc/kubernetes/pki/*\",\n \"/etc/kubernetes/*.conf\"\n) and not process.name in (\"kubeadm\", \"kubelet\", \"dpkg\", \"sed\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0fe2290a-2664-4c9c-8263-b88904f12f0d", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "Domain: Kubernetes", + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/", + "subtechnique": [ + { + "id": "T1543.005", + "name": "Container Service", + "reference": "https://attack.mitre.org/techniques/T1543/005/" + } + ] + }, + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.007", + "name": "Container Orchestration Job", + "reference": "https://attack.mitre.org/techniques/T1053/007/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "0fe2290a-2664-4c9c-8263-b88904f12f0d_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_207.json b/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_207.json new file mode 100644 index 00000000000..6ef33b7fbfa --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_207.json @@ -0,0 +1,93 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster.", + "false_positives": [ + "An administrator may submit this request as an \"impersonatedUser\" to determine what privileges a particular service account has been granted. However, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account." + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Suspicious Self-Subject Review", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Suspicious Self-Subject Review\n\nKubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields.\n- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews.\n- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source.\n- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior.\n- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered.\n- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise.\n\n### False positive analysis\n\n- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls.\n- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule.\n- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts.\n- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors.\n\n### Response and remediation\n\n- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster.\n- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts.\n- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely.\n- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.\n- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts.\n- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb:\"create\"\n and kubernetes.audit.objectRef.resource:(\"selfsubjectaccessreviews\" or \"selfsubjectrulesreviews\")\n and (kubernetes.audit.user.username:(system\\:serviceaccount\\:* or system\\:node\\:*)\n or kubernetes.audit.impersonatedUser.username:(system\\:serviceaccount\\:* or system\\:node\\:*))\n", + "references": [ + "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms", + "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access", + "https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.impersonatedUser.username", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.user.username", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "12a2f15d-597e-4334-88ff-38a02cb1330b", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 207 + }, + "id": "12a2f15d-597e-4334-88ff-38a02cb1330b_207", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_208.json b/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_208.json new file mode 100644 index 00000000000..08ba7204e7a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_208.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.", + "false_positives": [ + "An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Pod Created With HostNetwork", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod Created With HostNetwork\n\nKubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.\n- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like \"docker.elastic.co/beats/elastic-agent:8.4.0\".\n- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.\n- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.\n- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.\n\n### False positive analysis\n\n- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.\n- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.\n- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.\n- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.\n- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.\n- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.\n- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.\n- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.\n- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.\n- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostNetwork:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", + "references": [ + "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", + "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", + "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.image", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.hostNetwork", + "type": "boolean" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "12cbf709-69e8-4055-94f9-24314385c27e", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 208 + }, + "id": "12cbf709-69e8-4055-94f9-24314385c27e_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_204.json b/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_208.json similarity index 90% rename from packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_204.json rename to packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_208.json index 4d20ffa6563..25daf8b6810 100644 --- a/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_204.json +++ b/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_208.json @@ -8,13 +8,13 @@ "An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra -- sh" ], "index": [ - "logs-kubernetes.*" + "logs-kubernetes.audit_logs-*" ], - "language": "kuery", + "language": "eql", "license": "Elastic License v2", "name": "Kubernetes User Exec into Pod", "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes User Exec into Pod\n\nKubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for \"kubernetes.audit_logs\".\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access.\n- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource.\n- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access.\n- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address.\n- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment.\n\n### False positive analysis\n\n- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly.\n- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses.\n- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows.\n- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod.\n- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized.\n- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege.\n- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod.\n- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised.\n- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb:\"create\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.objectRef.subresource:\"exec\"\n", + "query": "any where host.os.type == \"linux\" and event.dataset == \"kubernetes.audit_logs\" and\nkubernetes.audit.verb in (\"get\", \"create\") and kubernetes.audit.objectRef.subresource == \"exec\" and\nkubernetes.audit.stage == \"ResponseComplete\" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == \"allow\"\n", "references": [ "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/", "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/" @@ -22,28 +22,33 @@ "related_integrations": [ { "package": "kubernetes", - "version": "^1.4.1" + "version": "^1.80.0" } ], "required_fields": [ + { + "ecs": false, + "name": "`kubernetes.audit.annotations.authorization_k8s_io/decision`", + "type": "unknown" + }, { "ecs": true, "name": "event.dataset", "type": "keyword" }, { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "ecs": true, + "name": "host.os.type", "type": "keyword" }, { "ecs": false, - "name": "kubernetes.audit.objectRef.resource", + "name": "kubernetes.audit.objectRef.subresource", "type": "keyword" }, { "ecs": false, - "name": "kubernetes.audit.objectRef.subresource", + "name": "kubernetes.audit.stage", "type": "keyword" }, { @@ -79,9 +84,9 @@ } ], "timestamp_override": "event.ingested", - "type": "query", - "version": 204 + "type": "eql", + "version": 208 }, - "id": "14de811c-d60f-11ec-9fd7-f661ea17fbce_204", + "id": "14de811c-d60f-11ec-9fd7-f661ea17fbce_208", "type": "security-rule" } \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_2.json b/packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_2.json new file mode 100644 index 00000000000..2da43fbc18f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_2.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of the \"kubectl auth --can-i\" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Permission Discovery", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubectl Permission Discovery\n\nKubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the \"kubectl auth can-i\" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux systems, flagging potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process execution details to confirm the use of the \"kubectl auth can-i\" command, focusing on the process name \"kubectl\" and arguments \"auth\" and \"can-i\".\n- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.\n- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior.\n- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment.\n- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts.\n- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern.\n\n### False positive analysis\n\n- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties.\n- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts.\n- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts.\n- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.\n- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse.\n- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations.\n- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access.\n- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions.\n- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected.\n- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\nprocess.name == \"kubectl\" and process.args == \"auth\" and process.args == \"can-i\"\n", + "references": [ + "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "1600f9e2-5be6-4742-8593-1ba50cd94069", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "1600f9e2-5be6-4742-8593-1ba50cd94069_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/178770e0-5c20-4246-b430-e216a2888b23_4.json b/packages/security_detection_engine/kibana/security_rule/178770e0-5c20-4246-b430-e216a2888b23_4.json new file mode 100644 index 00000000000..dcd9067a172 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/178770e0-5c20-4246-b430-e216a2888b23_4.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist within the environment.", + "from": "now-3h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "pad_okta_spike_in_user_lifecycle_management_changes", + "name": "Spike in User Lifecycle Management Change Events", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Spike in User Lifecycle Management Change Events\n\nUser lifecycle management in environments like Okta involves creating, modifying, and deleting user accounts. Adversaries may exploit this by manipulating accounts to escalate privileges or maintain access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on anomalies, it aids in early detection of privilege escalation tactics.\n\n### Possible investigation steps\n\n- Review the specific user accounts involved in the lifecycle management change events to identify any patterns or anomalies, such as multiple changes in a short period or changes made by unusual sources.\n- Check the timestamps of the change events to determine if they align with normal business hours or if they occurred during unusual times, which might indicate suspicious activity.\n- Investigate the source IP addresses and locations associated with the change events to identify any unusual or unauthorized access points.\n- Examine the types of changes made to the user accounts, such as privilege escalations or role modifications, to assess if they align with legitimate business needs.\n- Cross-reference the user accounts involved with recent security alerts or incidents to determine if they have been previously flagged for suspicious activity.\n- Consult with the account owners or relevant department heads to verify if the changes were authorized and necessary for business operations.\n\n### False positive analysis\n\n- Routine administrative tasks such as bulk user account updates or scheduled maintenance can trigger spikes in user lifecycle management events. To manage this, create exceptions for known maintenance windows or bulk operations.\n- Automated processes or scripts that regularly modify user accounts may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts.\n- Onboarding or offboarding periods with high user account activity can lead to spikes. Adjust the detection thresholds temporarily during these periods or exclude specific user groups involved in these activities.\n- Integration with third-party applications that frequently update user attributes might result in false positives. Review and whitelist these applications to reduce noise in the detection system.\n\n### Response and remediation\n\n- Immediately isolate the affected user accounts to prevent further unauthorized access or privilege escalation. This can be done by disabling the accounts or changing their passwords.\n- Review and revoke any unauthorized permissions or roles that were assigned during the spike in user lifecycle management change events. Ensure that only legitimate access rights are restored.\n- Conduct a thorough audit of recent user account changes to identify any additional accounts that may have been manipulated. Pay special attention to accounts with elevated privileges.\n- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response.\n- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access.\n- Escalate the incident to higher-level security management if the scope of the breach is extensive or if sensitive data may have been compromised.\n- Review and update access management policies and procedures to prevent similar incidents in the future, ensuring that changes to user accounts are logged and regularly reviewed.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/pad" + ], + "related_integrations": [ + { + "package": "pad", + "version": "^0.0.1" + }, + { + "package": "okta", + "version": "^3.5.0" + } + ], + "risk_score": 21, + "rule_id": "178770e0-5c20-4246-b430-e216a2888b23", + "setup": "## Setup\n\nThe rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.\n\n### Privileged Access Detection Setup\nThe Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Privileged Access Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.\n- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.\n\n#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Privileged Access Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "type": "machine_learning", + "version": 4 + }, + "id": "178770e0-5c20-4246-b430-e216a2888b23_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_118.json b/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_118.json deleted file mode 100644 index 7db16aac295..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_118.json +++ /dev/null @@ -1,174 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the manual creation of files in specific etc directories, via user root, used by Linux malware to persist and elevate privileges on compromised systems. File creation in these directories should not be entirely common and could indicate a malicious binary or script installing persistence mechanisms for long term access.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-endpoint.events.file*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Deprecated - Suspicious File Creation in /etc for Persistence", - "note": "## Triage and analysis\n\n### Investigating Deprecated - Suspicious File Creation in /etc for Persistence\n\nThe /etc/ directory in Linux is used to store system-wide configuration files and scripts.\n\nBy creating or modifying specific system-wide configuration files, attackers can leverage system services to execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities.\n\nThis rule monitors for the creation of the most common system-wide configuration files and scripts abused by attackers for persistence. \n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n#### Possible Investigation Steps\n\n- Investigate the file that was created or modified.\n- Investigate whether any other files in any of the commonly abused directories have been altered through OSQuery.\n - !{osquery{\"label\":\"Osquery - Retrieve File Listing Information\",\"query\":\"SELECT * FROM file WHERE ( path LIKE '/etc/ld.so.conf.d/%' OR path LIKE '/etc/cron.d/%' OR path LIKE '/etc/sudoers.d/%'\\nOR path LIKE '/etc/rc%.d/%' OR path LIKE '/etc/init.d/%' OR path LIKE '/etc/systemd/system/%' OR path LIKE\\n'/usr/lib/systemd/system/%' )\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Additional File Listing Information\",\"query\":\"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/ld.so.conf.d/%' OR path LIKE\\n'/etc/cron.d/%' OR path LIKE '/etc/sudoers.d/%' OR path LIKE '/etc/rc%.d/%' OR path LIKE '/etc/init.d/%' OR path LIKE\\n'/etc/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' )\\n\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. \n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n - Cron jobs, services and other persistence mechanisms.\n - !{osquery{\"label\":\"Osquery - Retrieve Crontab Information\",\"query\":\"SELECT * FROM crontab\"}}\n- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.\n - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n\n### False Positive Analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\n\n### Related Rules\n\n- Cron Job Created or Changed by Previously Unknown Process - ff10d4d8-fea7-422d-afb1-e5a2702369a9\n- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f\n- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b\n- New Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c\n- New Systemd Service Created by Previously Unknown Process - 17b0a495-4d9f-414c-8ad0-92f018b8e001\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Delete the service/timer or restore its original configuration.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "file where host.os.type == \"linux\" and event.type in (\"creation\", \"file_create_event\") and user.id == \"0\" and\nfile.path : (\"/etc/ld.so.conf.d/*\", \"/etc/cron.d/*\", \"/etc/sudoers.d/*\", \"/etc/init.d/*\", \"/etc/systemd/system/*\",\n\"/usr/lib/systemd/system/*\") and not (\n (process.name : (\n \"chef-client\", \"ruby\", \"pacman\", \"packagekitd\", \"python*\", \"platform-python\", \"dpkg\", \"yum\", \"apt\", \"dnf\", \"rpm\",\n \"systemd\", \"snapd\", \"dnf-automatic\", \"yum-cron\", \"elastic-agent\", \"dnfdaemon-system\", \"dockerd\", \"executor\",\n \"rhn_check\"\n )\n ) or \n (file.extension in (\"swp\", \"swpx\", \"tmp\"))\n)\n", - "references": [ - "https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/", - "https://www.intezer.com/blog/research/lightning-framework-new-linux-threat/", - "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms", - "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "1c84dd64-7e6c-4bad-ac73-a5014ee37042", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Threat: Orbit", - "Threat: Lightning Framework", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1037", - "name": "Boot or Logon Initialization Scripts", - "reference": "https://attack.mitre.org/techniques/T1037/", - "subtechnique": [ - { - "id": "T1037.004", - "name": "RC Scripts", - "reference": "https://attack.mitre.org/techniques/T1037/004/" - } - ] - }, - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.002", - "name": "Systemd Service", - "reference": "https://attack.mitre.org/techniques/T1543/002/" - } - ] - }, - { - "id": "T1574", - "name": "Hijack Execution Flow", - "reference": "https://attack.mitre.org/techniques/T1574/", - "subtechnique": [ - { - "id": "T1574.006", - "name": "Dynamic Linker Hijacking", - "reference": "https://attack.mitre.org/techniques/T1574/006/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1053", - "name": "Scheduled Task/Job", - "reference": "https://attack.mitre.org/techniques/T1053/", - "subtechnique": [ - { - "id": "T1053.003", - "name": "Cron", - "reference": "https://attack.mitre.org/techniques/T1053/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/", - "subtechnique": [ - { - "id": "T1548.003", - "name": "Sudo and Sudo Caching", - "reference": "https://attack.mitre.org/techniques/T1548/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 118 - }, - "id": "1c84dd64-7e6c-4bad-ac73-a5014ee37042_118", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_119.json b/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_119.json deleted file mode 100644 index 26323330d24..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_119.json +++ /dev/null @@ -1,174 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the manual creation of files in specific etc directories, via user root, used by Linux malware to persist and elevate privileges on compromised systems. File creation in these directories should not be entirely common and could indicate a malicious binary or script installing persistence mechanisms for long term access.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-endpoint.events.file*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Deprecated - Suspicious File Creation in /etc for Persistence", - "note": "## Triage and analysis\n\n### Investigating Deprecated - Suspicious File Creation in /etc for Persistence\n\nThe /etc/ directory in Linux is used to store system-wide configuration files and scripts.\n\nBy creating or modifying specific system-wide configuration files, attackers can leverage system services to execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities.\n\nThis rule monitors for the creation of the most common system-wide configuration files and scripts abused by attackers for persistence. \n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n#### Possible Investigation Steps\n\n- Investigate the file that was created or modified.\n- Investigate whether any other files in any of the commonly abused directories have been altered through OSQuery.\n - !{osquery{\"label\":\"Osquery - Retrieve File Listing Information\",\"query\":\"SELECT * FROM file WHERE ( path LIKE '/etc/ld.so.conf.d/%' OR path LIKE '/etc/cron.d/%' OR path LIKE '/etc/sudoers.d/%'\\nOR path LIKE '/etc/rc%.d/%' OR path LIKE '/etc/init.d/%' OR path LIKE '/etc/systemd/system/%' OR path LIKE\\n'/usr/lib/systemd/system/%' )\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Additional File Listing Information\",\"query\":\"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/ld.so.conf.d/%' OR path LIKE\\n'/etc/cron.d/%' OR path LIKE '/etc/sudoers.d/%' OR path LIKE '/etc/rc%.d/%' OR path LIKE '/etc/init.d/%' OR path LIKE\\n'/etc/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' )\\n\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. \n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n - Cron jobs, services and other persistence mechanisms.\n - !{osquery{\"label\":\"Osquery - Retrieve Crontab Information\",\"query\":\"SELECT * FROM crontab\"}}\n- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.\n - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n\n### False Positive Analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\n\n### Related Rules\n\n- Cron Job Created or Changed by Previously Unknown Process - ff10d4d8-fea7-422d-afb1-e5a2702369a9\n- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f\n- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b\n- New Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c\n- New Systemd Service Created by Previously Unknown Process - 17b0a495-4d9f-414c-8ad0-92f018b8e001\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Delete the service/timer or restore its original configuration.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "file where host.os.type == \"linux\" and event.type in (\"creation\", \"file_create_event\") and user.id == \"0\" and\nfile.path : (\"/etc/ld.so.conf.d/*\", \"/etc/cron.d/*\", \"/etc/sudoers.d/*\", \"/etc/init.d/*\", \"/etc/systemd/system/*\",\n\"/usr/lib/systemd/system/*\") and not (\n (process.name : (\n \"chef-client\", \"ruby\", \"pacman\", \"packagekitd\", \"python*\", \"platform-python\", \"dpkg\", \"yum\", \"apt\", \"dnf\", \"rpm\",\n \"systemd\", \"snapd\", \"dnf-automatic\", \"yum-cron\", \"elastic-agent\", \"dnfdaemon-system\", \"dockerd\", \"executor\",\n \"rhn_check\"\n )\n ) or \n (file.extension in (\"swp\", \"swpx\", \"tmp\"))\n)\n", - "references": [ - "https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/", - "https://www.intezer.com/blog/research/lightning-framework-new-linux-threat/", - "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms", - "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "1c84dd64-7e6c-4bad-ac73-a5014ee37042", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Threat: Orbit", - "Threat: Lightning Framework", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1037", - "name": "Boot or Logon Initialization Scripts", - "reference": "https://attack.mitre.org/techniques/T1037/", - "subtechnique": [ - { - "id": "T1037.004", - "name": "RC Scripts", - "reference": "https://attack.mitre.org/techniques/T1037/004/" - } - ] - }, - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.002", - "name": "Systemd Service", - "reference": "https://attack.mitre.org/techniques/T1543/002/" - } - ] - }, - { - "id": "T1574", - "name": "Hijack Execution Flow", - "reference": "https://attack.mitre.org/techniques/T1574/", - "subtechnique": [ - { - "id": "T1574.006", - "name": "Dynamic Linker Hijacking", - "reference": "https://attack.mitre.org/techniques/T1574/006/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1053", - "name": "Scheduled Task/Job", - "reference": "https://attack.mitre.org/techniques/T1053/", - "subtechnique": [ - { - "id": "T1053.003", - "name": "Cron", - "reference": "https://attack.mitre.org/techniques/T1053/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/", - "subtechnique": [ - { - "id": "T1548.003", - "name": "Sudo and Sudo Caching", - "reference": "https://attack.mitre.org/techniques/T1548/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 119 - }, - "id": "1c84dd64-7e6c-4bad-ac73-a5014ee37042_119", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_120.json b/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_120.json deleted file mode 100644 index 1a627659cdd..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1c84dd64-7e6c-4bad-ac73-a5014ee37042_120.json +++ /dev/null @@ -1,174 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the manual creation of files in specific etc directories, via user root, used by Linux malware to persist and elevate privileges on compromised systems. File creation in these directories should not be entirely common and could indicate a malicious binary or script installing persistence mechanisms for long term access.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-endpoint.events.file*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Deprecated - Suspicious File Creation in /etc for Persistence", - "note": "## Triage and analysis\n\n### Investigating Deprecated - Suspicious File Creation in /etc for Persistence\n\nThe /etc/ directory in Linux is used to store system-wide configuration files and scripts.\n\nBy creating or modifying specific system-wide configuration files, attackers can leverage system services to execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities.\n\nThis rule monitors for the creation of the most common system-wide configuration files and scripts abused by attackers for persistence. \n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n#### Possible Investigation Steps\n\n- Investigate the file that was created or modified.\n- Investigate whether any other files in any of the commonly abused directories have been altered through OSQuery.\n - !{osquery{\"label\":\"Osquery - Retrieve File Listing Information\",\"query\":\"SELECT * FROM file WHERE ( path LIKE '/etc/ld.so.conf.d/%' OR path LIKE '/etc/cron.d/%' OR path LIKE '/etc/sudoers.d/%'\\nOR path LIKE '/etc/rc%.d/%' OR path LIKE '/etc/init.d/%' OR path LIKE '/etc/systemd/system/%' OR path LIKE\\n'/usr/lib/systemd/system/%' )\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Additional File Listing Information\",\"query\":\"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/ld.so.conf.d/%' OR path LIKE\\n'/etc/cron.d/%' OR path LIKE '/etc/sudoers.d/%' OR path LIKE '/etc/rc%.d/%' OR path LIKE '/etc/init.d/%' OR path LIKE\\n'/etc/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' )\\n\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. \n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n - Cron jobs, services and other persistence mechanisms.\n - !{osquery{\"label\":\"Osquery - Retrieve Crontab Information\",\"query\":\"SELECT * FROM crontab\"}}\n- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.\n - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n\n### False Positive Analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\n\n### Related Rules\n\n- Cron Job Created or Changed by Previously Unknown Process - ff10d4d8-fea7-422d-afb1-e5a2702369a9\n- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f\n- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b\n- New Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c\n- New Systemd Service Created by Previously Unknown Process - 17b0a495-4d9f-414c-8ad0-92f018b8e001\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Delete the service/timer or restore its original configuration.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "file where host.os.type == \"linux\" and event.type in (\"creation\", \"file_create_event\") and user.id == \"0\" and\nfile.path : (\"/etc/ld.so.conf.d/*\", \"/etc/cron.d/*\", \"/etc/sudoers.d/*\", \"/etc/init.d/*\", \"/etc/systemd/system/*\",\n\"/usr/lib/systemd/system/*\") and not (\n (process.name : (\n \"chef-client\", \"ruby\", \"pacman\", \"packagekitd\", \"python*\", \"platform-python\", \"dpkg\", \"yum\", \"apt\", \"dnf\", \"rpm\",\n \"systemd\", \"snapd\", \"dnf-automatic\", \"yum-cron\", \"elastic-agent\", \"dnfdaemon-system\", \"dockerd\", \"executor\",\n \"rhn_check\"\n )\n ) or \n (file.extension in (\"swp\", \"swpx\", \"tmp\"))\n)\n", - "references": [ - "https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/", - "https://www.intezer.com/blog/research/lightning-framework-new-linux-threat/", - "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms", - "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "1c84dd64-7e6c-4bad-ac73-a5014ee37042", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Threat: Orbit", - "Threat: Lightning Framework", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1037", - "name": "Boot or Logon Initialization Scripts", - "reference": "https://attack.mitre.org/techniques/T1037/", - "subtechnique": [ - { - "id": "T1037.004", - "name": "RC Scripts", - "reference": "https://attack.mitre.org/techniques/T1037/004/" - } - ] - }, - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.002", - "name": "Systemd Service", - "reference": "https://attack.mitre.org/techniques/T1543/002/" - } - ] - }, - { - "id": "T1574", - "name": "Hijack Execution Flow", - "reference": "https://attack.mitre.org/techniques/T1574/", - "subtechnique": [ - { - "id": "T1574.006", - "name": "Dynamic Linker Hijacking", - "reference": "https://attack.mitre.org/techniques/T1574/006/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1053", - "name": "Scheduled Task/Job", - "reference": "https://attack.mitre.org/techniques/T1053/", - "subtechnique": [ - { - "id": "T1053.003", - "name": "Cron", - "reference": "https://attack.mitre.org/techniques/T1053/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/", - "subtechnique": [ - { - "id": "T1548.003", - "name": "Sudo and Sudo Caching", - "reference": "https://attack.mitre.org/techniques/T1548/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 120 - }, - "id": "1c84dd64-7e6c-4bad-ac73-a5014ee37042_120", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_2.json b/packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_2.json new file mode 100644 index 00000000000..46051c5631d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_2.json @@ -0,0 +1,124 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Hex Payload Execution via Command-Line", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Hex Payload Execution via Command-Line\n\nIn Linux environments, command-line interfaces are pivotal for executing processes and scripts. Adversaries exploit this by embedding payloads in hexadecimal format to obfuscate their actions, evading detection. The detection rule identifies processes with lengthy command lines containing multiple hex patterns, signaling potential obfuscation. This approach targets defense evasion tactics, leveraging Elastic Defend to flag suspicious executions.\n\n### Possible investigation steps\n\n- Review the process.command_line field to identify the specific hexadecimal patterns and assess if they correspond to known malicious payloads or commands.\n- Examine the process.parent.executable to determine the parent process that initiated the execution, which may provide context on whether the execution is expected or suspicious.\n- Check the user account associated with the process execution to verify if the activity aligns with typical user behavior or if it indicates potential compromise.\n- Investigate the host where the alert was triggered to identify any other related suspicious activities or anomalies that might indicate a broader compromise.\n- Correlate the event with other logs or alerts from the same host or user to identify patterns or repeated attempts at obfuscation and execution.\n\n### False positive analysis\n\n- Legitimate software installations or updates may use hexadecimal encoding in command lines for legitimate purposes. Users can create exceptions for known software update processes by identifying their parent executable paths and excluding them from the rule.\n- System administration scripts or tools that utilize hexadecimal encoding for configuration or data processing might trigger the rule. Review and whitelist these scripts by verifying their source and purpose, then exclude them based on their command line patterns or parent processes.\n- Security tools or monitoring software that perform regular scans or data collection using hexadecimal encoding could be flagged. Confirm these tools' legitimacy and add them to an exception list by specifying their executable paths or command line characteristics.\n- Custom applications developed in-house that use hexadecimal encoding for data handling or communication may be mistakenly identified. Document these applications and exclude them by their unique command line signatures or parent process identifiers.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.\n- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious execution.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as modified files or unauthorized user accounts.\n- Remove any identified malicious files or scripts from the system to ensure the threat is eradicated.\n- Restore the system from a known good backup if any critical system files or configurations have been altered.\n- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\nprocess.parent.executable != null and\nprocess.command_line : \"*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\" and\nlength(process.command_line) > 50\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "1d0027d4-6717-4a37-bad8-531d8e9fe53f", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + }, + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "1d0027d4-6717-4a37-bad8-531d8e9fe53f_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_213.json b/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_213.json new file mode 100644 index 00000000000..22ad7bcfa8d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_213.json @@ -0,0 +1,302 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\*.ps?1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Microsoft Azure AD Sync\\\\Extensions\\\\AADConnector.psm1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "*ServiceNow MID Server*\\\\agent\\\\scripts\\\\PowerShell\\\\*.psm1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\IMECache\\\\HealthScripts\\\\*\\\\detect.ps1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\TEMP\\\\SDIAG*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Temp\\\\SDIAG*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\SDIAG*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Microsoft Monitoring Agent\\\\Agent\\\\Health Service State\\\\Monitoring Host Temporary Files*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-119m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "interval": "60m", + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Discovery Capabilities", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (\n \"Get-ADDefaultDomainPasswordPolicy\" or\n \"Get-ADDomain\" or \"Get-ComputerInfo\" or\n \"Get-Disk\" or \"Get-DnsClientCache\" or\n \"Get-GPOReport\" or \"Get-HotFix\" or\n \"Get-LocalUser\" or \"Get-NetFirewallProfile\" or\n \"get-nettcpconnection\" or \"Get-NetAdapter\" or\n \"Get-PhysicalDisk\" or \"Get-Process\" or\n \"Get-PSDrive\" or \"Get-Service\" or\n \"Get-SmbShare\" or \"Get-WinEvent\"\n ) or\n (\n (\"Get-WmiObject\" or \"gwmi\" or \"Get-CimInstance\" or\n \"gcim\" or \"Management.ManagementObjectSearcher\" or\n \"System.Management.ManagementClass\" or\n \"[WmiClass]\") and\n (\n \"AntiVirusProduct\" or \"CIM_BIOSElement\" or \"CIM_ComputerSystem\" or \"CIM_Product\" or \"CIM_DiskDrive\" or\n \"CIM_LogicalDisk\" or \"CIM_NetworkAdapter\" or \"CIM_StorageVolume\" or \"CIM_OperatingSystem\" or\n \"CIM_Process\" or \"CIM_Service\" or \"MSFT_DNSClientCache\" or \"Win32_BIOS\" or \"Win32_ComputerSystem\" or\n \"Win32_ComputerSystemProduct\" or \"Win32_DiskDrive\" or \"win32_environment\" or \"Win32_Group\" or\n \"Win32_groupuser\" or \"Win32_IP4RouteTable\" or \"Win32_logicaldisk\" or \"Win32_MappedLogicalDisk\" or\n \"Win32_NetworkAdapterConfiguration\" or \"win32_ntdomain\" or \"Win32_OperatingSystem\" or\n \"Win32_PnPEntity\" or \"Win32_Process\" or \"Win32_Product\" or \"Win32_quickfixengineering\" or\n \"win32_service\" or \"Win32_Share\" or \"Win32_UserAccount\"\n )\n ) or\n (\n (\"ADSI\" and \"WinNT\") or\n (\"Get-ChildItem\" and \"sysmondrv.sys\") or\n (\"::GetIPGlobalProperties()\" and \"GetActiveTcpConnections()\") or\n (\"ServiceProcess.ServiceController\" and \"::GetServices\") or\n (\"Diagnostics.Process\" and \"::GetProcesses\") or\n (\"DirectoryServices.Protocols.GroupPolicy\" and \".GetGPOReport()\") or\n (\"DirectoryServices.AccountManagement\" and \"PrincipalSearcher\") or\n (\"NetFwTypeLib.NetFwMgr\" and \"CurrentProfile\") or\n (\"NetworkInformation.NetworkInterface\" and \"GetAllNetworkInterfaces\") or\n (\"Automation.PSDriveInfo\") or\n (\"Microsoft.Win32.RegistryHive\")\n ) or\n (\n \"Get-ItemProperty\" and\n (\n \"\\Control\\SecurityProviders\\WDigest\" or\n \"\\microsoft\\windows\\currentversion\\explorer\\runmru\" or\n \"\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Kerberos\\Parameters\" or\n \"\\Microsoft\\Windows\\CurrentVersion\\Uninstall\" or\n \"\\Microsoft\\Windows\\WindowsUpdate\" or\n \"Policies\\Microsoft\\Windows\\Installer\" or\n \"Software\\Microsoft\\Windows\\CurrentVersion\\Policies\" or\n (\"\\Services\\SharedAccess\\Parameters\\FirewallPolicy\" and \"EnableFirewall\") or\n (\"Microsoft\\Windows\\CurrentVersion\\Internet Settings\" and \"proxyEnable\")\n )\n ) or\n (\n (\"Directoryservices.Activedirectory\" or\n \"DirectoryServices.AccountManagement\") and \n (\n \"Domain Admins\" or \"DomainControllers\" or\n \"FindAllGlobalCatalogs\" or \"GetAllTrustRelationships\" or\n \"GetCurrentDomain\" or \"GetCurrentForest\"\n ) or\n \"DirectoryServices.DirectorySearcher\" and\n (\n \"samAccountType=805306368\" or\n \"samAccountType=805306369\" or\n \"objectCategory=group\" or\n \"objectCategory=groupPolicyContainer\" or\n \"objectCategory=site\" or\n \"objectCategory=subnet\" or\n \"objectClass=trustedDomain\"\n )\n ) or\n (\n \"Get-Process\" and\n (\n \"mcshield\" or \"windefend\" or \"savservice\" or\n \"TMCCSF\" or \"symantec antivirus\" or\n \"CSFalcon\" or \"TmPfw\" or \"kvoop\"\n )\n )\n ) and\n not powershell.file.script_block_text : (\n (\n \"__cmdletization_BindCommonParameters\" and\n \"Microsoft.PowerShell.Core\\Export-ModuleMember\" and\n \"Microsoft.PowerShell.Cmdletization.Cim.CimCmdletAdapter\"\n ) or\n \"CmdletsToExport=@(\\\"Add-Content\\\",\" or\n (\"cmdletization\" and \"cdxml-Help.xml\")\n ) and\n not user.id : (\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\")\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Collection", + "Tactic: Discovery", + "Data Source: PowerShell Logs", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1007", + "name": "System Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1007/" + }, + { + "id": "T1012", + "name": "Query Registry", + "reference": "https://attack.mitre.org/techniques/T1012/" + }, + { + "id": "T1049", + "name": "System Network Connections Discovery", + "reference": "https://attack.mitre.org/techniques/T1049/" + }, + { + "id": "T1057", + "name": "Process Discovery", + "reference": "https://attack.mitre.org/techniques/T1057/" + }, + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + }, + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + }, + { + "id": "T1083", + "name": "File and Directory Discovery", + "reference": "https://attack.mitre.org/techniques/T1083/" + }, + { + "id": "T1087", + "name": "Account Discovery", + "reference": "https://attack.mitre.org/techniques/T1087/", + "subtechnique": [ + { + "id": "T1087.001", + "name": "Local Account", + "reference": "https://attack.mitre.org/techniques/T1087/001/" + }, + { + "id": "T1087.002", + "name": "Domain Account", + "reference": "https://attack.mitre.org/techniques/T1087/002/" + } + ] + }, + { + "id": "T1135", + "name": "Network Share Discovery", + "reference": "https://attack.mitre.org/techniques/T1135/" + }, + { + "id": "T1201", + "name": "Password Policy Discovery", + "reference": "https://attack.mitre.org/techniques/T1201/" + }, + { + "id": "T1482", + "name": "Domain Trust Discovery", + "reference": "https://attack.mitre.org/techniques/T1482/" + }, + { + "id": "T1518", + "name": "Software Discovery", + "reference": "https://attack.mitre.org/techniques/T1518/", + "subtechnique": [ + { + "id": "T1518.001", + "name": "Security Software Discovery", + "reference": "https://attack.mitre.org/techniques/T1518/001/" + } + ] + }, + { + "id": "T1615", + "name": "Group Policy Discovery", + "reference": "https://attack.mitre.org/techniques/T1615/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 213 + }, + "id": "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2388c687-cb2c-4b7b-be8f-6864a2385048_1.json b/packages/security_detection_engine/kibana/security_rule/2388c687-cb2c-4b7b-be8f-6864a2385048_1.json new file mode 100644 index 00000000000..375e0f1c5b2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2388c687-cb2c-4b7b-be8f-6864a2385048_1.json @@ -0,0 +1,120 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential kubectl masquerading activity by monitoring for process events where the process name is not \"kubectl\" but the command line arguments include kubectl-related commands. This could indicate an adversary attempting to masquerade as legitimate kubectl activity to evade detection. This rule covers evasion gaps introduced by renaming the kubectl binary, or placing it in an unusual directory.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Kubectl Masquerading via Unexpected Process", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Kubectl Masquerading via Unexpected Process\n\nKubectl is a command-line tool for interacting with Kubernetes clusters, crucial for managing containerized applications. Adversaries may exploit this by renaming the kubectl binary or placing it in unusual directories to mimic legitimate activity and evade detection. The detection rule identifies such masquerading by monitoring for non-standard process names executing kubectl-related commands, thus highlighting potential evasion attempts.\n\n### Possible investigation steps\n\n- Review the process executable path to determine if it is located in a non-standard directory such as /tmp, /var/tmp, /dev/shm, or other specified paths in the query.\n- Examine the process name to check if it deviates from the expected \"kubectl\" name, which could indicate an attempt to masquerade the process.\n- Analyze the command line arguments used in the process to identify any kubectl-related commands, such as \"get\", \"describe\", \"exec\", \"port-forward\", or authentication commands, which may suggest unauthorized access or activity.\n- Investigate the user account associated with the process to determine if it has legitimate access to execute kubectl commands or if it might be compromised.\n- Check for any recent changes or anomalies in the Kubernetes cluster that could correlate with the suspicious process activity, such as unauthorized deployments or configuration changes.\n- Review system logs and other security alerts around the time of the event to identify any additional indicators of compromise or related suspicious activities.\n- If possible, capture and analyze network traffic associated with the process to detect any unusual or unauthorized communication with the Kubernetes API server or other cluster components.\n\n### False positive analysis\n\n- Processes running in development or testing environments may trigger alerts if kubectl is executed from non-standard directories. To manage this, create exceptions for known development paths where kubectl is legitimately used.\n- Automated scripts or CI/CD pipelines that use kubectl from custom directories might be flagged. Identify these scripts and exclude their specific paths or process names from the rule.\n- Some legitimate applications might wrap kubectl commands for functionality, leading to unexpected process names. Review these applications and add their process names to the exclusion list if they are verified as non-threatening.\n- Users with custom kubectl installations in home directories could cause false positives. Verify these installations and exclude the specific user paths if they are deemed safe.\n- Temporary or experimental setups where kubectl is renamed for testing purposes might be mistakenly flagged. Document these setups and apply temporary exclusions during the testing phase.\n\n### Response and remediation\n\n- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network.\n- Terminate any suspicious processes identified by the detection rule that are masquerading as kubectl to halt potential malicious activity.\n- Conduct a thorough review of the affected system's logs and command history to identify any unauthorized kubectl commands executed and assess the scope of the compromise.\n- Revoke any potentially compromised credentials or access tokens associated with the Kubernetes cluster to prevent further unauthorized access.\n- Restore any altered or deleted Kubernetes resources from backups, ensuring the integrity and availability of the cluster's services.\n- Implement stricter access controls and monitoring on the Kubernetes cluster, such as enforcing the principle of least privilege and enabling audit logging for kubectl commands.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"executed\", \"process_started\") and\n(\n process.executable like~ (\"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/root/*\", \"/var/www/*\", \"./kubectl\", \"/home/*/kubectl\") or\n process.name like \".*\"\n) and\nprocess.command_line like~ (\n\n // get and describe commands\n \"*get po*\", \"*get deploy*\", \"*get node*\", \"*get svc*\", \"*get service*\", \"*get secret*\", \"*get clusterrole*\", \"*get ingress*\",\n \"*get configmap*\", \"*describe po*\", \"*describe deploy*\", \"*describe node*\", \"*describe svc*\", \"*describe service*\",\n \"*describe secret*\", \"*describe configmap*\", \"*describe clusterrole*\", \"*describe ingress*\",\n \n // exec commands\n \"*exec -it*\", \"*exec --stdin*\", \"*exec --tty*\",\n \n // networking commands\n \"*port-forward* \", \"*proxy --port*\", \"*run --image=*\", \"*expose*\",\n\n // authentication/impersonation commands\n \"*auth can-i*\", \"*--kubeconfig*\", \"*--as *\", \"*--as=*\", \"*--as-group*\", \"*--as-uid*\"\n) and not (\n process.executable like \"/tmp/newroot/*\" or\n process.name == \".flatpak-wrapped\"\n)\n", + "references": [ + "https://kubernetes.io/docs/reference/kubectl/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "2388c687-cb2c-4b7b-be8f-6864a2385048", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1036", + "name": "Masquerading", + "reference": "https://attack.mitre.org/techniques/T1036/", + "subtechnique": [ + { + "id": "T1036.003", + "name": "Rename Legitimate Utilities", + "reference": "https://attack.mitre.org/techniques/T1036/003/" + } + ] + }, + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "2388c687-cb2c-4b7b-be8f-6864a2385048_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_2.json deleted file mode 100644 index a0f3087a0f7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_2.json +++ /dev/null @@ -1,111 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary whom is looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicate breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks.", - "false_positives": [ - "Legitimate use of deprecated AMIs for testing or development purposes.", - "Automated tools or scripts that query for deprecated AMIs as part of a security assessment.", - "Misconfigured applications or services that rely on deprecated AMIs for compatibility reasons.", - "Administrators or developers who are unaware of the deprecation status of AMIs they are using." - ], - "from": "now-9m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.user_identity.access_key_id", - "source.ip", - "cloud.account.id", - "cloud.region", - "user_agent.original", - "event.action" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Deprecated AMI Discovery", - "note": "## Triage and analysis\n\n## Investigating AWS EC2 Deprecated AMI Discovery\n\nThis rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations.\n\n### Possible Investigation Steps\n\n1. **Identify the User Performing the Query**:\n - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request.\n - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity).\n - Investigate the `related.user` field for additional user context.\n\n2. **Analyze the Source of the Request**:\n - Review the `source.ip` field to determine the IP address of the source making the request.\n - Check `source.geo` for the geographic location of the IP address.\n - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK).\n\n3. **Review the Request Details**:\n - Inspect the `aws.cloudtrail.flattened.request_parameters` field for query parameters, such as `includeDeprecated=true`.\n - Confirm that the request explicitly includes deprecated AMIs (`includeDeprecated=true`) and is tied to specific owners via the `ownersSet` field.\n - Verify the `event.action` is `DescribeImages` and the `event.outcome` is `success`.\n\n4. **Validate the Query Context**:\n - Determine if the request is part of legitimate activity, such as:\n - Security assessments or vulnerability scans.\n - Maintenance or testing of legacy systems.\n - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services.\n\n5. **Correlate with Other Events**:\n - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation.\n - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call).\n\n6. **Assess Security Risks**:\n - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities.\n - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats.\n\n### False Positive Analysis\n\n- **Legitimate Use**: Users may query for deprecated AMIs for testing or compatibility purposes.\n- **Automated Tools**: Security or compliance tools might query deprecated AMIs as part of regular assessments.\n- **Misconfigured Services**: Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Verify the intent of the user querying for deprecated AMIs.\n - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs.\n\n2. **Mitigation Steps**:\n - Identify and replace deprecated AMIs in use with supported and updated AMIs.\n - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future queries involving deprecated AMIs or other unusual API activity.\n - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior.\n\n4. **Security Audits**:\n - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images.\n - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing.\n\n5. **Add Rule Exceptions**:\n - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs.\n - Document and communicate the exceptions to relevant teams to avoid future alerts.\n\n### Additional Resources\n\n- [AWS Documentation: AMI Lifecycle Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)\n- [AWS Documentation: Deprecated AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html)\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action: \"DescribeImages\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.includeDeprecated: \"true\"\n and aws.cloudtrail.request_parameters: *owner=*\n", - "references": [ - "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.includeDeprecated", - "type": "unknown" - }, - { - "ecs": false, - "name": "aws.cloudtrail.request_parameters", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "264c641e-c202-11ef-993e-f661ea17fbce", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: AWS EC2", - "Resources: Investigation Guide", - "Use Case: Threat Detection", - "Tactic: Discovery" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 2 - }, - "id": "264c641e-c202-11ef-993e-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_5.json b/packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_5.json new file mode 100644 index 00000000000..692d84b5377 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_5.json @@ -0,0 +1,143 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment.", + "false_positives": [ + "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes. Applications integrated with AWS might assume roles to access AWS resources. Automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments." + ], + "from": "now-6m", + "history_window_start": "now-10d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "aws.cloudtrail.flattened.request_parameters.roleSessionName", + "aws.cloudtrail.flattened.response_elements.credentials.accessKeyId", + "cloud.region", + "cloud.account.id", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS STS Role Assumption by User", + "new_terms_fields": [ + "cloud.account.id", + "user.name", + "aws.cloudtrail.resources.arn" + ], + "note": "## Triage and analysis\n\n### Investigating AWS STS Role Assumption by User\n\nThis rule detects when a user assumes a role in AWS Security Token Service (STS), receiving temporary credentials to access AWS resources. While often used for legitimate purposes, this action can be leveraged by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.\n\n#### Possible Investigation Steps\n\n- **Identify the User and Assumed Role**:\n - **User Identity**: Check `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` for details about the initiator of the `AssumeRole` action.\n - **Role Assumed**: Review `aws.cloudtrail.resources.arn` to confirm the role assumed and ensure it aligns with the user\u2019s standard permissions.\n - **Session Name**: Note `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the purpose of the session.\n - **Expiration Time**: Use `aws.cloudtrail.flattened.response_elements.credentials.expiration` to confirm the credential expiration.\n\n- **Inspect User Agent and Source Information**:\n - **User Agent**: Analyze the `user_agent.original` field to identify if specific tooling or SDKs like AWS CLI, Boto3, or custom agents were used.\n - **Source IP and Geolocation**: Examine `source.ip` and `source.geo` fields to determine the origin of the request, confirming if it aligns with expected locations.\n\n- **Correlate with Related Events**:\n - **Identify Patterns**: Review related CloudTrail events for unusual access patterns, such as resource access or sensitive actions following this `AssumeRole` action.\n - **Filter High-Volume Roles**: If this role or user has a high volume of access, evaluate `roleArn` or `user_agent` values for common patterns and add trusted entities as exceptions.\n\n- **Review the Privileges of the Assumed Role**:\n - **Permissions**: Examine permissions associated with the `roleArn` to assess its access scope.\n - **Authorized Usage**: Confirm if the role is used frequently for administrative purposes and if this aligns with the user\u2019s regular responsibilities.\n\n### False Positive Analysis\n\n- **Automated Processes and Applications**: Applications or scheduled tasks may assume roles regularly for operational purposes. Validate the consistency of the `user_agent` or `roleArn` with known automated workflows.\n- **Standard IAM Policy Usage**: Confirm if the user or application routinely assumes new roles for normal operations by reviewing historical activity.\n\n### Response and Remediation\n\n- **Terminate Unauthorized Sessions**: If the role assumption is deemed unauthorized, revoke the session by modifying IAM policies or the permissions associated with the assumed role.\n- **Strengthen Monitoring and Alerts**: Implement additional monitoring for specific high-risk roles, especially those with elevated permissions.\n- **Regularly Manage Exceptions**: Regularly review high-volume roles and user agent patterns to refine alerts, minimizing noise by adding trusted patterns as exceptions.\n- **Incident Response**: If confirmed as malicious, follow incident response protocols for containment, investigation, and remediation.\n\n### Additional Information\n\nFor more details on managing and securing AWS STS in your environment, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html).\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"sts.amazonaws.com\"\n and event.action: \"AssumeRole\"\n and event.outcome: \"success\"\n and aws.cloudtrail.user_identity.type: (\"AssumedRole\" or \"IAMUser\")\n", + "references": [ + "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "288a198e-9b9b-11ef-a0a8-f661ea17fbcd", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS STS", + "Resources: Investigation Guide", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Lateral Movement" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 5 + }, + "id": "288a198e-9b9b-11ef-a0a8-f661ea17fbcd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/28f6f34b-8e16-487a-b5fd-9d22eb903db8_6.json b/packages/security_detection_engine/kibana/security_rule/28f6f34b-8e16-487a-b5fd-9d22eb903db8_6.json deleted file mode 100644 index 4d4013404dd..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/28f6f34b-8e16-487a-b5fd-9d22eb903db8_6.json +++ /dev/null @@ -1,113 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule monitors the creation/alteration of a shell configuration file. Unix systems use shell configuration files to set environment variables, create aliases, and customize the user's environment. Adversaries may modify or add a shell configuration file to execute malicious code and gain persistence in the system. This behavior is consistent with the Kaiji malware family.", - "false_positives": [ - "Legitimate user shell modification activity." - ], - "from": "now-9m", - "index": [ - "logs-endpoint.events.file*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Shell Configuration Creation or Modification", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Shell Configuration Creation or Modification\n\nShell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution.\n\n### Possible investigation steps\n\n- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query.\n- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose.\n- Check the modification or creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change.\n- Examine the contents of the modified or newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands.\n- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if the account may have been compromised.\n- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.\n\n### False positive analysis\n\n- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts.\n- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client.\n- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios.\n- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives.\n- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code.\n- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure.\n- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.\n- Monitor the system and network for any signs of re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future.", - "query": "file where host.os.type == \"linux\" and event.action in (\"rename\", \"creation\") and file.path : (\n // system-wide configurations\n \"/etc/profile\", \"/etc/profile.d/*\", \"/etc/bash.bashrc\", \"/etc/bash.bash_logout\", \"/etc/zsh/*\",\n \"/etc/csh.cshrc\", \"/etc/csh.login\", \"/etc/fish/config.fish\", \"/etc/ksh.kshrc\",\n // root and user configurations\n \"/home/*/.profile\", \"/home/*/.bashrc\", \"/home/*/.bash_login\", \"/home/*/.bash_logout\", \"/home/*/.bash_profile\",\n \"/root/.profile\", \"/root/.bashrc\", \"/root/.bash_login\", \"/root/.bash_logout\", \"/root/.bash_profile\",\n \"/home/*/.zprofile\", \"/home/*/.zshrc\", \"/root/.zprofile\", \"/root/.zshrc\",\n \"/home/*/.cshrc\", \"/home/*/.login\", \"/home/*/.logout\", \"/root/.cshrc\", \"/root/.login\", \"/root/.logout\",\n \"/home/*/.config/fish/config.fish\", \"/root/.config/fish/config.fish\",\n \"/home/*/.kshrc\", \"/root/.kshrc\"\n) and not (\n process.executable in (\n \"/bin/dpkg\", \"/usr/bin/dpkg\", \"/bin/dockerd\", \"/usr/bin/dockerd\", \"/usr/sbin/dockerd\", \"/bin/microdnf\",\n \"/usr/bin/microdnf\", \"/bin/rpm\", \"/usr/bin/rpm\", \"/bin/snapd\", \"/usr/bin/snapd\", \"/bin/yum\", \"/usr/bin/yum\",\n \"/bin/dnf\", \"/usr/bin/dnf\", \"/bin/podman\", \"/usr/bin/podman\", \"/bin/dnf-automatic\", \"/usr/bin/dnf-automatic\",\n \"/bin/pacman\", \"/usr/bin/pacman\", \"/usr/bin/dpkg-divert\", \"/bin/dpkg-divert\", \"/sbin/apk\", \"/usr/sbin/apk\",\n \"/usr/local/sbin/apk\", \"/usr/bin/apt\", \"/usr/sbin/pacman\", \"/bin/podman\", \"/usr/bin/podman\", \"/usr/bin/puppet\",\n \"/bin/puppet\", \"/opt/puppetlabs/puppet/bin/puppet\", \"/usr/bin/chef-client\", \"/bin/chef-client\",\n \"/bin/autossl_check\", \"/usr/bin/autossl_check\", \"/proc/self/exe\", \"/dev/fd/*\", \"/usr/bin/pamac-daemon\",\n \"/bin/pamac-daemon\", \"/usr/lib/snapd/snapd\", \"/usr/sbin/adduser\", \"/usr/sbin/useradd\", \"/usr/local/bin/dockerd\",\n \"/usr/sbin/gdm\", \"/usr/bin/unzip\", \"/usr/bin/gnome-shell\", \"/sbin/mkhomedir_helper\", \"/usr/sbin/sshd\",\n \"/opt/puppetlabs/puppet/bin/ruby\", \"/usr/bin/xfce4-session\", \"/usr/libexec/oddjob/mkhomedir\", \"/sbin/useradd\",\n \"/usr/lib/systemd/systemd\", \"/usr/sbin/crond\", \"/usr/bin/pamac-daemon\", \"/usr/sbin/mkhomedir_helper\",\n \"/opt/pbis/sbin/lwsmd\", \"/usr/sbin/oddjobd\"\n ) or\n file.extension in (\"swp\", \"swpx\", \"swx\", \"dpkg-remove\") or\n file.Ext.original.extension == \"dpkg-new\" or\n process.executable : (\n \"/nix/store/*\", \"/var/lib/dpkg/*\", \"/tmp/vmis.*\", \"/snap/*\", \"/dev/fd/*\", \"/usr/lib/virtualbox/*\",\n \"/usr/libexec/platform-python*\"\n ) or\n process.executable == null or\n process.name in (\"adclient\", \"mkhomedir_helper\", \"teleport\", \"mkhomedir\", \"adduser\", \"desktopDaemon\", \"executor\", \"crio\") or\n (process.name == \"sed\" and file.name : \"sed*\") or\n (process.name == \"perl\" and file.name : \"e2scrub_all.tmp*\")\n)\n", - "references": [ - "https://intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/", - "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": false, - "name": "file.Ext.original.extension", - "type": "unknown" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "28f6f34b-8e16-487a-b5fd-9d22eb903db8", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1546", - "name": "Event Triggered Execution", - "reference": "https://attack.mitre.org/techniques/T1546/", - "subtechnique": [ - { - "id": "T1546.004", - "name": "Unix Shell Configuration Modification", - "reference": "https://attack.mitre.org/techniques/T1546/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 6 - }, - "id": "28f6f34b-8e16-487a-b5fd-9d22eb903db8_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_208.json b/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_208.json new file mode 100644 index 00000000000..28b1d288f55 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_208.json @@ -0,0 +1,108 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.", + "false_positives": [ + "An administrator may need to attach a hostPath volume for a legitimate reason. This alert should be investigated for legitimacy by determining if the kuberenetes.audit.requestObject.spec.volumes.hostPath.path triggered is one needed by its target container/pod. For example, when the fleet managed elastic agent is deployed as a daemonset it creates several hostPath volume mounts, some of which are sensitive host directories like /proc, /etc/kubernetes, and /var/log. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Pod created with a Sensitive hostPath Volume", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod created with a Sensitive hostPath Volume\n\nKubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value \"kubernetes.audit_logs\".\n- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path.\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision.\n- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories.\n- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment.\n- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data.\n\n### False positive analysis\n\n- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads.\n- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image.\n- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening.\n- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods.\n- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources.\n- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise.\n- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image.\n- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod.\n- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities.\n- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.volumes.hostPath.path:\n (\"/\" or\n \"/proc\" or\n \"/root\" or\n \"/var\" or\n \"/var/run\" or\n \"/var/run/docker.sock\" or\n \"/var/run/crio/crio.sock\" or\n \"/var/run/cri-dockerd.sock\" or\n \"/var/lib/kubelet\" or\n \"/var/lib/kubelet/pki\" or\n \"/var/lib/docker/overlay2\" or\n \"/etc\" or\n \"/etc/kubernetes\" or\n \"/etc/kubernetes/manifests\" or\n \"/etc/kubernetes/pki\" or\n \"/home/admin\")\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", + "references": [ + "https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216", + "https://kubernetes.io/docs/concepts/storage/volumes/#hostpath" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.image", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.volumes.hostPath.path", + "type": "unknown" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "2abda169-416b-4bb3-9a6b-f8d239fd78ba", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 208 + }, + "id": "2abda169-416b-4bb3-9a6b-f8d239fd78ba_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_216.json b/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_216.json new file mode 100644 index 00000000000..c9d3dfbe3a0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_216.json @@ -0,0 +1,144 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the use of Windows API functions that are commonly abused by malware and security tools to load malicious code or inject it into remote processes.", + "false_positives": [ + "Legitimate PowerShell scripts that make use of these functions." + ], + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential Process Injection via PowerShell", + "note": "## Triage and analysis\n\n### Investigating Potential Process Injection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nPowerShell also has solid capabilities to make the interaction with the Win32 API in an uncomplicated and reliable way, like the execution of inline C# code, PSReflect, Get-ProcAddress, etc.\n\nRed Team tooling and malware developers take advantage of these capabilities to develop stagers and loaders that inject payloads directly into the memory without touching the disk to circumvent file-based security protections.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Check if the imported function was executed and which process it targeted.\n- Check if the injected code can be retrieved (hardcoded in the script or on command line logs).\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or\n LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and\n (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or\n SuspendThread or ResumeThread or GetDelegateForFunctionPointer)\n ) and not \n file.directory: (\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\SenseCM\" or\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\"\n )\n", + "references": [ + "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1", + "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-ReflectivePEInjection.ps1", + "https://github.com/BC-SECURITY/Empire/blob/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1", + "https://www.elastic.co/security-labs/detect-credential-access" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "2e29e96a-b67c-455a-afe4-de6183431d0d", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1055", + "name": "Process Injection", + "reference": "https://attack.mitre.org/techniques/T1055/", + "subtechnique": [ + { + "id": "T1055.001", + "name": "Dynamic-link Library Injection", + "reference": "https://attack.mitre.org/techniques/T1055/001/" + }, + { + "id": "T1055.002", + "name": "Portable Executable Injection", + "reference": "https://attack.mitre.org/techniques/T1055/002/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + }, + { + "id": "T1106", + "name": "Native API", + "reference": "https://attack.mitre.org/techniques/T1106/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 216 + }, + "id": "2e29e96a-b67c-455a-afe4-de6183431d0d_216", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_305.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_305.json new file mode 100644 index 00000000000..e2e51c0604e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_305.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", + "from": "now-30m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Okta User Sessions Started from Different Geolocations", + "note": "## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.security_context.is_proxy != true and okta.actor.id != \"unknown\"\n AND event.outcome == \"success\"\n| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id\n| STATS\n geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)\n BY okta.actor.id, okta.actor.alternate_id\n| WHERE\n geo_auth_counts >= 2\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 47, + "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 305 + }, + "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_305", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3278313c-d6cd-4d49-aa24-644e1da6623c_4.json b/packages/security_detection_engine/kibana/security_rule/3278313c-d6cd-4d49-aa24-644e1da6623c_4.json new file mode 100644 index 00000000000..d5075685afe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3278313c-d6cd-4d49-aa24-644e1da6623c_4.json @@ -0,0 +1,71 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating potential privileged access activity. Threat actors might be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement within an organization\u2019s environment.", + "from": "now-3h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "pad_okta_spike_in_group_application_assignment_changes", + "name": "Spike in Group Application Assignment Change Events", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Spike in Group Application Assignment Change Events\n\nIn modern environments, identity and access management systems like Okta manage user access to applications. Adversaries may exploit these systems by altering group application assignments to gain unauthorized access or escalate privileges. The detection rule leverages machine learning to identify unusual spikes in these changes, signaling potential misuse and enabling timely investigation of privilege escalation activities.\n\n### Possible investigation steps\n\n- Review the specific group application assignment change events that triggered the alert to identify which groups and applications were involved.\n- Analyze the timeline of the changes to determine if there is a pattern or specific time frame when the spike occurred.\n- Investigate the user accounts associated with the changes to assess if they have a history of suspicious activity or if they belong to high-risk roles.\n- Check for any recent changes in group membership or application access policies that could explain the spike in assignment changes.\n- Correlate the events with other security alerts or logs to identify any concurrent suspicious activities, such as failed login attempts or unusual access patterns.\n- Consult with the IT or security team to verify if there were any legitimate administrative activities or changes that could have caused the spike.\n\n### False positive analysis\n\n- Routine administrative changes in group application assignments can trigger false positives. Regularly review and document these changes to differentiate them from suspicious activities.\n- Automated processes or scripts that frequently update group assignments may cause spikes. Identify and whitelist these processes to prevent unnecessary alerts.\n- Organizational restructuring or onboarding/offboarding activities can lead to increased group assignment changes. Temporarily adjust the detection thresholds or exclude these events during known periods of high activity.\n- Changes related to application updates or migrations might be flagged. Coordinate with IT teams to schedule these changes and exclude them from monitoring during the update window.\n- Frequent changes by trusted users or administrators can be excluded by creating exceptions for specific user accounts or roles, ensuring that only unexpected changes trigger alerts.\n\n### Response and remediation\n\n- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation.\n- Revert any unauthorized group application assignments to their previous state to mitigate potential misuse.\n- Conduct a thorough review of recent changes in group application assignments to identify any additional unauthorized modifications.\n- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised.\n- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activity.\n- Review and update access controls and group assignment policies to prevent similar unauthorized changes in the future.\n- Coordinate with the IT and security teams to ensure that all affected systems and applications are patched and secured against known vulnerabilities.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/pad" + ], + "related_integrations": [ + { + "package": "pad", + "version": "^0.0.1" + }, + { + "package": "okta", + "version": "^3.5.0" + } + ], + "risk_score": 21, + "rule_id": "3278313c-d6cd-4d49-aa24-644e1da6623c", + "setup": "## Setup\n\nThe rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.\n\n### Privileged Access Detection Setup\nThe Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Privileged Access Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.\n- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.\n\n#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Privileged Access Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1068", + "name": "Exploitation for Privilege Escalation", + "reference": "https://attack.mitre.org/techniques/T1068/" + }, + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "type": "machine_learning", + "version": 4 + }, + "id": "3278313c-d6cd-4d49-aa24-644e1da6623c_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/33c27b4e-8ec6-406f-b8e5-345dc024aa97_1.json b/packages/security_detection_engine/kibana/security_rule/33c27b4e-8ec6-406f-b8e5-345dc024aa97_1.json new file mode 100644 index 00000000000..357a3ebaabe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/33c27b4e-8ec6-406f-b8e5-345dc024aa97_1.json @@ -0,0 +1,88 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents.", + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubernetes Events Deleted", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Events Deleted\nKubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further.\n\n### Possible investigation steps\n\n- Review the audit logs to identify the source of the deletion request by examining the `kubernetes.audit.user.username` field to determine which user or service account initiated the delete action.\n- Check the `kubernetes.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access.\n- Investigate the `kubernetes.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services.\n- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `kubernetes.audit.verb` values to identify any suspicious activities or patterns.\n- Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation.\n- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration.\n\n### False positive analysis\n\n- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.\n- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses.\n- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions.\n- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs.\n- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation.\n- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events.\n- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time.\n- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected.\n- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur.\n- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK.\n", + "query": "any where host.os.type == \"linux\" and event.dataset == \"kubernetes.audit_logs\" and kubernetes.audit.verb == \"delete\" and\nkubernetes.audit.objectRef.resource == \"events\" and kubernetes.audit.stage == \"ResponseComplete\"\n", + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.stage", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "33c27b4e-8ec6-406f-b8e5-345dc024aa97", + "severity": "low", + "tags": [ + "Data Source: Kubernetes", + "Domain: Kubernetes", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1070", + "name": "Indicator Removal", + "reference": "https://attack.mitre.org/techniques/T1070/", + "subtechnique": [ + { + "id": "T1070.004", + "name": "File Deletion", + "reference": "https://attack.mitre.org/techniques/T1070/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "33c27b4e-8ec6-406f-b8e5-345dc024aa97_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json new file mode 100644 index 00000000000..622391e12fc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft 365 Brute Force via Entra ID Sign-Ins", + "note": "## Triage and analysis\n\n### Investigating Microsoft 365 Brute Force via Entra ID Sign-Ins\n\nIdentifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage.\n\n### Possible investigation steps\n\n- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`).\n- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities?\n- Review `login_errors`: Multiple identical errors (e.g., `\"Invalid grant...\"`) suggest automated abuse or tooling.\n- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure.\n- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts.\n- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction.\n- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious.\n- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode.\n- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts.\n- Check `conditional_access_status`: If \"notApplied\", determine whether conditional access is properly scoped.\n- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse.\n\n### False positive analysis\n\n- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures.\n- Red team exercises or pentesting can resemble brute-force patterns.\n- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session.\n\n### Response and remediation\n\n- Notify identity or security operations teams to investigate further.\n- Lock or reset affected user accounts if compromise is suspected.\n- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.\n- Review tenant-wide MFA and conditional access enforcement.\n- Audit targeted accounts for password reuse across systems or tenants.\n- Enable lockout or throttling policies for repeated failed login attempts.\n", + "query": "FROM logs-azure.signinlogs*\n\n| EVAL\n time_window = DATE_TRUNC(15 minutes, @timestamp),\n user_id = TO_LOWER(azure.signinlogs.properties.user_principal_name),\n ip = source.ip,\n login_error = azure.signinlogs.result_description,\n error_code = azure.signinlogs.properties.status.error_code,\n request_type = TO_LOWER(azure.signinlogs.properties.incoming_token_type),\n app_name = TO_LOWER(azure.signinlogs.properties.app_display_name),\n asn_org = source.`as`.organization.name,\n country = source.geo.country_name,\n user_agent = user_agent.original,\n event_time = @timestamp\n\n| WHERE event.dataset == \"azure.signinlogs\"\n AND event.category == \"authentication\"\n AND azure.signinlogs.category IN (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n AND azure.signinlogs.properties.resource_display_name RLIKE \"(.*)365|SharePoint|Exchange|Teams|Office(.*)\"\n AND event.outcome == \"failure\"\n AND error_code != 50053\n AND azure.signinlogs.properties.status.error_code IN (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n AND user_id IS NOT NULL AND user_id != \"\"\n AND user_agent != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n\n| STATS\n authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n client_app_id = VALUES(azure.signinlogs.properties.app_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n target_resource_id = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id),\n device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n user_id = VALUES(azure.signinlogs.properties.user_id),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n result_description = VALUES(azure.signinlogs.result_description),\n result_signature = VALUES(azure.signinlogs.result_signature),\n result_type = VALUES(azure.signinlogs.result_type),\n\n unique_users = COUNT_DISTINCT(user_id),\n user_id_list = VALUES(user_id),\n login_errors = VALUES(login_error),\n unique_login_errors = COUNT_DISTINCT(login_error),\n error_codes = VALUES(error_code),\n unique_error_codes = COUNT_DISTINCT(error_code),\n request_types = VALUES(request_type),\n app_names = VALUES(app_name),\n ip_list = VALUES(ip),\n unique_ips = COUNT_DISTINCT(ip),\n source_orgs = VALUES(asn_org),\n countries = VALUES(country),\n unique_country_count = COUNT_DISTINCT(country),\n unique_asn_orgs = COUNT_DISTINCT(asn_org),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_attempts = COUNT()\nBY time_window\n\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen),\n bf_type = CASE(\n // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many),\n // and happens quickly. Often bots using leaked credentials.\n unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3\n AND unique_ips >= 5\n AND duration_seconds <= 600\n AND unique_users > unique_ips,\n \"credential_stuffing\",\n\n // One password against many users. Single error (e.g., \"InvalidPassword\"), not necessarily fast.\n unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800,\n \"password_spraying\",\n\n // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs.\n (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300)\n OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100),\n \"password_guessing\",\n\n // everything else\n \"other\"\n )\n\n| KEEP\n time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen,\n unique_users, user_id_list, login_errors, unique_login_errors,\n unique_error_codes, error_codes, request_types, app_names,\n ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs,\n authentication_requirement, client_app_id, client_app_display_name,\n target_resource_id, target_resource_display_name, conditional_access_status,\n device_detail_browser, device_detail_device_id, device_detail_operating_system,\n incoming_token_type, risk_state, session_id, user_id,\n user_principal_name, result_description, result_signature, result_type\n\n| WHERE bf_type != \"other\"\n", + "references": [ + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 105 + }, + "id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35df0dd8-092d-4a83-88c1-5151a804f31b_316.json b/packages/security_detection_engine/kibana/security_rule/35df0dd8-092d-4a83-88c1-5151a804f31b_316.json deleted file mode 100644 index 704bf2d6de0..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/35df0dd8-092d-4a83-88c1-5151a804f31b_316.json +++ /dev/null @@ -1,124 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-crowdstrike.fdr*", - "logs-endpoint.events.process-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*", - "logs-system.security*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Unusual Parent-Child Relationship", - "note": "## Triage and analysis\n\n### Investigating Unusual Parent-Child Relationship\n\nWindows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these characteristics is parent-child relationships. These relationships can be used to baseline the typical behavior of the system and then alert on occurrences that don't comply with the baseline.\n\nThis rule uses this information to spot suspicious parent and child processes.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\nprocess.parent.name != null and\n (\n /* suspicious parent processes */\n (process.name:\"autochk.exe\" and not process.parent.name:\"smss.exe\") or\n (process.name:(\"fontdrvhost.exe\", \"dwm.exe\") and not process.parent.name:(\"wininit.exe\", \"winlogon.exe\")) or\n (process.name:(\"consent.exe\", \"RuntimeBroker.exe\", \"TiWorker.exe\") and not process.parent.name:\"svchost.exe\") or\n (process.name:\"SearchIndexer.exe\" and not process.parent.name:\"services.exe\") or\n (process.name:\"SearchProtocolHost.exe\" and not process.parent.name:(\"SearchIndexer.exe\", \"dllhost.exe\")) or\n (process.name:\"dllhost.exe\" and not process.parent.name:(\"services.exe\", \"svchost.exe\")) or\n (process.name:\"smss.exe\" and not process.parent.name:(\"System\", \"smss.exe\")) or\n (process.name:\"csrss.exe\" and not process.parent.name:(\"smss.exe\", \"svchost.exe\")) or\n (process.name:\"wininit.exe\" and not process.parent.name:\"smss.exe\") or\n (process.name:\"winlogon.exe\" and not process.parent.name:\"smss.exe\") or\n (process.name:(\"lsass.exe\", \"LsaIso.exe\") and not process.parent.name:\"wininit.exe\") or\n (process.name:\"LogonUI.exe\" and not process.parent.name:(\"wininit.exe\", \"winlogon.exe\")) or\n (process.name:\"services.exe\" and not process.parent.name:\"wininit.exe\") or\n (process.name:\"svchost.exe\" and not process.parent.name:(\"MsMpEng.exe\", \"services.exe\", \"svchost.exe\")) or\n (process.name:\"spoolsv.exe\" and not process.parent.name:\"services.exe\") or\n (process.name:\"taskhost.exe\" and not process.parent.name:(\"services.exe\", \"svchost.exe\", \"ngentask.exe\")) or\n (process.name:\"taskhostw.exe\" and not process.parent.name:(\"services.exe\", \"svchost.exe\")) or\n (process.name:\"userinit.exe\" and not process.parent.name:(\"dwm.exe\", \"winlogon.exe\")) or\n (process.name:(\"wmiprvse.exe\", \"wsmprovhost.exe\", \"winrshost.exe\") and not process.parent.name:\"svchost.exe\") or\n /* suspicious child processes */\n (process.parent.name:(\"SearchProtocolHost.exe\", \"taskhost.exe\", \"csrss.exe\") and not process.name:(\"werfault.exe\", \"wermgr.exe\", \"WerFaultSecure.exe\", \"conhost.exe\")) or\n (process.parent.name:\"autochk.exe\" and not process.name:(\"chkdsk.exe\", \"doskey.exe\", \"WerFault.exe\")) or\n (process.parent.name:\"smss.exe\" and not process.name:(\"autochk.exe\", \"smss.exe\", \"csrss.exe\", \"wininit.exe\", \"winlogon.exe\", \"setupcl.exe\", \"WerFault.exe\")) or\n (process.parent.name:\"wermgr.exe\" and not process.name:(\"WerFaultSecure.exe\", \"wermgr.exe\", \"WerFault.exe\")) or\n (process.parent.name:\"conhost.exe\" and not process.name:(\"mscorsvw.exe\", \"wermgr.exe\", \"WerFault.exe\", \"WerFaultSecure.exe\"))\n )\n", - "references": [ - "https://github.com/sbousseaden/Slides/blob/master/Hunting%20MindMaps/PNG/Windows%20Processes%20TH.map.png", - "https://www.andreafortuna.org/2017/06/15/standard-windows-processes-a-brief-reference/", - "https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "m365_defender", - "version": "^2.0.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - }, - { - "package": "crowdstrike", - "version": "^1.1.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "35df0dd8-092d-4a83-88c1-5151a804f31b", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Windows Security Event Logs", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Sysmon", - "Data Source: SentinelOne", - "Data Source: Crowdstrike" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1055", - "name": "Process Injection", - "reference": "https://attack.mitre.org/techniques/T1055/", - "subtechnique": [ - { - "id": "T1055.012", - "name": "Process Hollowing", - "reference": "https://attack.mitre.org/techniques/T1055/012/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 316 - }, - "id": "35df0dd8-092d-4a83-88c1-5151a804f31b_316", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json new file mode 100644 index 00000000000..29b8009fca9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json @@ -0,0 +1,64 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token.", + "from": "now-60m", + "interval": "59m", + "language": "esql", + "license": "Elastic License v2", + "name": "Suspicious Microsoft 365 UserLoggedIn via OAuth Code", + "note": "## Triage and analysis\n\n### Investigating Suspicious Microsoft 365 UserLoggedIn via OAuth Code\n\n### Possible Investigation Steps:\n\n- `o365.audit.UserId`: The identity value the application is acting on behalf of principal user.\n- `unique_ips`: Analyze the list of unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers, or anonymizing infrastructure (e.g., Tor or VPNs).\n- `target_time_window`: Use the truncated time window to pivot into raw events to reconstruct the full sequence of resource access events, including exact timestamps and service targets.\n- `azure.auditlogs` to check for device join or registration events around the same timeframe.\n- `azure.identityprotection` to identify correlated risk detections, such as anonymized IP access or token replay.\n- Any additional sign-ins from the `ips` involved, even outside the broker, to determine if tokens have been reused elsewhere.\n\n### False Positive Analysis\n\n- Developers or IT administrators working across environments may also produce similar behavior.\n\n### Response and Remediation\n\n- If confirmed unauthorized, revoke all refresh tokens for the affected user and remove any devices registered during this session.\n- Notify the user and determine whether the device join or authentication activity was expected.\n- Audit Conditional Access and broker permissions (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure policies enforce strict access controls.\n- Consider blocking token-based reauthentication to Microsoft Graph and DRS from suspicious locations or user agents.\n- Continue monitoring for follow-on activity like lateral movement or privilege escalation.\n", + "query": "from logs-o365.audit-*\n| WHERE event.dataset == \"o365.audit\" and event.action == \"UserLoggedIn\" and\n\n // ensure source, application and user are not null\n source.ip is not null and\n o365.audit.UserId is not null and\n o365.audit.ApplicationId is not null and\n\n // filter for user principals that are not service accounts\n o365.audit.UserType in (\"0\", \"2\", \"3\", \"10\") and\n\n // filter for successful logon to Microsoft Graph and from the Microsoft Authentication Broker or Visual Studio Code\n o365.audit.ApplicationId in (\"aebc6443-996d-45c2-90f0-388ff96faa56\", \"29d9ed98-a469-4536-ade2-f981bc1d605e\") and\n o365.audit.ObjectId in (\"00000003-0000-0000-c000-000000000000\")\n\n// keep relevant fields only\n| keep @timestamp, o365.audit.UserId, source.ip, o365.audit.ApplicationId, o365.audit.ObjectId, o365.audit.ExtendedProperties.RequestType, source.as.organization.name, o365.audit.ExtendedProperties.ResultStatusDetail\n\n// case statements to track which are OAuth2 authorization request via redirect and which are related to OAuth2 code to token conversion\n| eval\n oauth_authorize = case(o365.audit.ExtendedProperties.RequestType == \"OAuth2:Authorize\" and o365.audit.ExtendedProperties.ResultStatusDetail == \"Redirect\", o365.audit.UserId, null),\n oauth_token = case(o365.audit.ExtendedProperties.RequestType == \"OAuth2:Token\", o365.audit.UserId, null)\n\n// split time to 30 minutes intervals\n| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)\n\n// aggregate by principal, applicationId, objectId and time window\n| stats\n unique_ips = COUNT_DISTINCT(source.ip),\n source_ips = VALUES(source.ip),\n appIds = VALUES(o365.audit.ApplicationId),\n asn = values(`source.as.organization.name`),\n is_oauth_token = COUNT_DISTINCT(oauth_token),\n is_oauth_authorize = COUNT_DISTINCT(oauth_authorize)\nby o365.audit.UserId, target_time_window, o365.audit.ApplicationId, o365.audit.ObjectId\n\n// filter for cases where the same appId is used by the same principal user to access the same object and from multiple addresses via OAuth2 token\n| where unique_ips >= 2 and is_oauth_authorize > 0 and is_oauth_token > 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/" + ], + "risk_score": 73, + "rule_id": "36188365-f88f-4f70-8c1d-0b9554186b9c", + "setup": "## Setup\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Email", + "Domain: Identity", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "36188365-f88f-4f70-8c1d-0b9554186b9c_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_214.json b/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_214.json new file mode 100644 index 00000000000..ba573ca8077 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_214.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role.", + "false_positives": [ + "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "history_window_start": "now-7d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS SSM `SendCommand` Execution by Rare User", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": "## Triage and analysis\n\n### Investigating AWS SSM `SendCommand` Execution by Rare User\n\nThis rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceIds` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM.\n - **Document Used**: Check the `aws.cloudtrail.flattened.request_parameters.documentName` field, which specifies the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access.\n - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior.\n\n- **Analyze Command Parameters**:\n - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities.\n - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack.\n\n- **Check User Agent and Source IP**:\n - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually.\n - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries.\n\n- **Evaluate for Persistence Indicators**:\n - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access.\n - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions.\n\n- **Correlate with Other CloudTrail Events**:\n - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.\n - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.\n\n### False Positive Analysis\n\n- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.\n- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances.\n\n### Response and Remediation\n\n- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.\n- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.\n- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.\n- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.\n\n### Additional Information\n\nFor further details on managing AWS SSM and security best practices for EC2 instances, refer to the [AWS Systems Manager Documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) and AWS best practices.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: \"SendCommand\"\n and event.outcome: \"success\"\n and not source.address: (\n \"ssm-guiconnect.amazonaws.com\" or\n \"ssm.amazonaws.com\" or\n \"inspector2.amazonaws.com\"\n )\n", + "references": [ + "https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS SSM", + "Data Source: AWS Systems Manager", + "Use Case: Log Auditing", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1651", + "name": "Cloud Administration Command", + "reference": "https://attack.mitre.org/techniques/T1651/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 214 + }, + "id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa_214", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/39144f38-5284-4f8e-a2ae-e3fd628d90b0_207.json b/packages/security_detection_engine/kibana/security_rule/39144f38-5284-4f8e-a2ae-e3fd628d90b0_207.json deleted file mode 100644 index 9de14ca23bc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/39144f38-5284-4f8e-a2ae-e3fd628d90b0_207.json +++ /dev/null @@ -1,92 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the creation of an AWS Elastic Compute Cloud (EC2) network access control list (ACL) or an entry in a network ACL with a specified rule number.", - "false_positives": [ - "Network ACL's may be created by a network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Network ACL creations by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Network Access Control List Creation", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS EC2 Network Access Control List Creation\n\nAWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential unauthorized modifications that align with persistence tactics, aiding in early threat identification.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role (event.user) that initiated the CreateNetworkAcl or CreateNetworkAclEntry actions.\n- Examine the event.provider:ec2.amazonaws.com logs to determine the IP addresses and locations associated with the request to assess if they are expected or suspicious.\n- Check the event.action details to understand the specific rules created in the Network ACL, focusing on any overly permissive rules that could indicate a security risk.\n- Investigate the event.outcome:success entries to confirm the successful creation of the ACL or ACL entry and correlate with any other suspicious activities in the AWS environment.\n- Cross-reference the event with other security alerts or logs to identify any patterns or anomalies that could suggest malicious intent or unauthorized access.\n- Assess the impact of the new ACL rules on the network security posture, ensuring they do not inadvertently allow unauthorized access or data exfiltration.\n\n### False positive analysis\n\n- Routine infrastructure updates or deployments may trigger the creation of new network ACLs or entries. To manage this, establish a baseline of expected changes during scheduled maintenance windows and exclude these from alerts.\n- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation can create network ACLs as part of normal operations. Identify and whitelist these automated processes to prevent unnecessary alerts.\n- Changes made by trusted administrators or security teams for legitimate purposes can be mistaken for suspicious activity. Implement a process to log and review approved changes, allowing you to exclude these from detection.\n- Temporary ACLs created for troubleshooting or testing purposes can generate alerts. Document and track these activities, and use tags or naming conventions to easily identify and exclude them from monitoring.\n- Third-party services or integrations that require specific network configurations might create ACLs. Review and validate these services, and if deemed safe, add them to an exception list to reduce false positives.\n\n### Response and remediation\n\n- Immediately review the AWS CloudTrail logs to confirm the creation of the Network ACL or entry and identify the IAM user or role responsible for the action. This helps determine if the action was authorized or potentially malicious.\n- Revoke any suspicious or unauthorized IAM credentials associated with the creation of the Network ACL or entry to prevent further unauthorized access.\n- Modify or delete the newly created Network ACL or entry if it is determined to be unauthorized or overly permissive, ensuring that it aligns with your organization's security policies.\n- Conduct a security review of the affected AWS environment to identify any other unauthorized changes or indicators of compromise, focusing on persistence mechanisms.\n- Implement additional monitoring and alerting for changes to Network ACLs and other critical AWS resources to enhance detection of similar threats in the future.\n- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional containment or remediation actions are necessary.\n- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized changes to network configurations.", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(CreateNetworkAcl or CreateNetworkAclEntry) and event.outcome:success\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-network-acl.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAcl.html", - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-network-acl-entry.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAclEntry.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "39144f38-5284-4f8e-a2ae-e3fd628d90b0", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS EC2", - "Use Case: Network Security Monitoring", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1133", - "name": "External Remote Services", - "reference": "https://attack.mitre.org/techniques/T1133/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 207 - }, - "id": "39144f38-5284-4f8e-a2ae-e3fd628d90b0_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_2.json b/packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_2.json new file mode 100644 index 00000000000..d5dc04949c0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_2.json @@ -0,0 +1,131 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Kernel Feature Activity", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Kernel Feature Activity\n\nKernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent.\n\n### Possible investigation steps\n\n- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope.\n- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes.\n- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user.\n- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings.\n- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise.\n- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident.\n\n### False positive analysis\n\n- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions.\n- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns.\n- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines.\n- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule.\n- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.\n- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files.\n- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files.\n- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated.\n- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response.\n- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network.\n- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\nprocess.command_line : (\n \"*/etc/sysctl.conf*\", \"*/etc/sysctl.d/*\", \"*/proc/sys/kernel/nmi_watchdog*\",\n \"*/proc/sys/vm/nr_hugepages*\", \"*/proc/sys/kernel/yama/ptrace_scope*\",\n \"*/proc/sys/kernel/randomize_va_space*\", \"*/proc/sys/vm/drop_caches*\",\n \"*/proc/sys/kernel/sysrq*\", \"*grsecurity*\", \"*exec-shield*\",\n \"*kernel.randomize_va_space*\", \"*kernel.yama.ptrace_scope*\",\n \"*kernel.nmi_watchdog*\", \"*vm.nr_hugepages*\", \"*vm.drop_caches*\",\n \"*kernel.sysrq*\"\n) and\nprocess.parent.executable != null and \n(\n (process.name == \"tee\" and process.args like \"-*a*\") or // also detects --append\n (process.name == \"cat\" and not process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")) or\n (process.name == \"grep\" and process.args_count == 3 and not process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")) or\n (process.name == \"sysctl\" and process.args like (\"*-w*\", \"*--write*\", \"*=*\")) or\n (process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and process.args : \"*echo *\")\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "3aff6ab1-18bd-427e-9d4c-c5732110c261", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.006", + "name": "Indicator Blocking", + "reference": "https://attack.mitre.org/techniques/T1562/006/" + } + ] + }, + { + "id": "T1553", + "name": "Subvert Trust Controls", + "reference": "https://attack.mitre.org/techniques/T1553/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "3aff6ab1-18bd-427e-9d4c-c5732110c261_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/40e60816-5122-11f0-9caa-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/40e60816-5122-11f0-9caa-f661ea17fbcd_1.json new file mode 100644 index 00000000000..19f6f61fd5b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/40e60816-5122-11f0-9caa-f661ea17fbcd_1.json @@ -0,0 +1,166 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint.", + "from": "now-60m", + "index": [ + "filebeat-*", + "logs-azure.signinlogs-*" + ], + "interval": "30m", + "investigation_fields": { + "field_names": [ + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.device_detail.device_id", + "azure.signinlogs.properties.incoming_token_type", + "azure.signinlogs.properties.resource_display_name", + "azure.signinlogs.properties.token_protection_status_details.sign_in_session_status", + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.device_detail.trust_type", + "source.geo.country_name", + "source.geo.city_name", + "source.address", + "event.outcome", + "event.category" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "Entra ID RT to PRT Transition from Same User and Device", + "note": "## Triage and analysis\n\n### Investigating Entra ID RT to PRT Transition from Same User and Device\n\nThis rule identifies a sequence where a Microsoft Entra ID user signs in using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by a sign-in using a Primary Refresh Token (PRT) from the same device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has obtained device trust and is now using the PRT to impersonate a fully compliant user+device pair.\n\n### Possible investigation steps\n- Identify the user principal and device from `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.device_detail.device_id`.\n- Confirm the first sign-in event came from the Microsoft Auth Broker (`app_id`) with `incoming_token_type: refreshToken`.\n- Ensure the device has a `trust_type` of \"Azure AD joined\" and that the `sign_in_session_status` is \"unbound\".\n- Confirm the second sign-in used `incoming_token_type: primaryRefreshToken` and that the `resource_display_name` is not \"Device Registration Service\".\n- Investigate any Microsoft Graph, Outlook, or SharePoint access occurring shortly after.\n- Review conditional access policy outcomes and determine whether MFA or device compliance was bypassed.\n\n### False positive analysis\n- Legitimate device onboarding and sign-ins using hybrid-joined endpoints may trigger this rule.\n- Rapid device provisioning in enterprise environments using MAB could generate similar token behavior.\n- Use supporting signals, such as IP address changes, geolocation, or user agent anomalies, to reduce noise.\n\n### Response and remediation\n- Investigate other sign-in patterns and assess whether token abuse has occurred.\n- Revoke PRT sessions via Microsoft Entra ID or Conditional Access.\n- Remove or quarantine the suspicious device registration.\n- Require password reset and enforce MFA.\n- Audit and tighten device trust and conditional access configurations.\n", + "query": "sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1h\n [authentication where\n event.dataset == \"azure.signinlogs\" and\n azure.signinlogs.category == \"NonInteractiveUserSignInLogs\" and\n azure.signinlogs.properties.app_id == \"29d9ed98-a469-4536-ade2-f981bc1d605e\" and\n azure.signinlogs.properties.incoming_token_type == \"refreshToken\" and\n azure.signinlogs.properties.device_detail.trust_type == \"Azure AD joined\" and\n azure.signinlogs.properties.device_detail.device_id != null and\n azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == \"unbound\" and\n azure.signinlogs.properties.user_type == \"Member\" and\n azure.signinlogs.result_signature == \"SUCCESS\"\n ]\n [authentication where\n event.dataset == \"azure.signinlogs\" and\n azure.signinlogs.properties.incoming_token_type == \"primaryRefreshToken\" and\n azure.signinlogs.properties.resource_display_name != \"Device Registration Service\" and\n azure.signinlogs.result_signature == \"SUCCESS\"\n ]\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.app_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.device_detail.device_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.device_detail.trust_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.incoming_token_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.resource_display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.token_protection_status_details.sign_in_session_status", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.result_signature", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "40e60816-5122-11f0-9caa-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Use Case: Threat Detection", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Tactic: Persistence", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.005", + "name": "Device Registration", + "reference": "https://attack.mitre.org/techniques/T1098/005/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "40e60816-5122-11f0-9caa-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_3.json deleted file mode 100644 index d02546371d8..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_3.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the snapshot into an environment they control, to access the data.", - "false_positives": [ - "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS EC2 EBS Snapshot Shared or Made Public", - "note": "\n## Triage and Analysis\n\n### Investigating AWS EC2 EBS Snapshot Shared or Made Public\n\nThis rule detects when an AWS EC2 EBS snapshot is shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this to copy the snapshot into an environment they control to access the data. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Review UserID**: Check the `userId` field to identify the AWS account with which the snapshot was shared. Verify if this account is authorized to access the data or if it belongs to a known third party. If this value is `all`, the snapshot is made public.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions.\n- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing EBS snapshots and securing AWS environments, refer to the [AWS EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security:\n- [AWS EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)\n- [AWS API ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)\n- [AWS EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"ec2.amazonaws.com\" and event.action == \"ModifySnapshotAttribute\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?snapshotId}=%{snapshotId},%{?attributeType}=%{attributeType},%{?createVolumePermission}={%{operationType}={%{?items}=[{%{?userId}=%{userId}}]}}}\"\n| where operationType == \"add\" and cloud.account.id != userId\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, snapshotId, attributeType, operationType, userId\n", - "references": [ - "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html", - "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump", - "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" - ], - "risk_score": 21, - "rule_id": "4182e486-fc61-11ee-a05d-f661ea17fbce", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS EC2", - "Use Case: Threat Detection", - "Tactic: Exfiltration" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "4182e486-fc61-11ee-a05d-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_319.json b/packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_319.json new file mode 100644 index 00000000000..aa63c7d32a7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_319.json @@ -0,0 +1,158 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Adding Hidden File Attribute via Attrib", + "note": "## Triage and analysis\n\n### Investigating Adding Hidden File Attribute via Attrib\n\nThe `Hidden` attribute is a file or folder attribute that makes the file or folder invisible to regular directory listings when the attribute is set. \n\nAttackers can use this attribute to conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it.\n\nThis rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Examine the command line to identify the target file or folder.\n - Examine the file, which process created it, header, etc.\n - If suspicious, retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Observe and collect information about the following activities in the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n (process.name : \"attrib.exe\" or ?process.pe.original_file_name == \"ATTRIB.EXE\") and process.args : \"+h\" and\n not (process.parent.name: \"cmd.exe\" and process.command_line: \"attrib +R +H +S +A *.cui\") and\n\n not (\n process.parent.name: \"draw.io.exe\" and\n (\n process.command_line : (\"*drawio.bkp*\", \"*drawio.dtmp*\")\n )\n )\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pe.original_file_name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "4630d948-40d4-4cef-ac69-4002e29bc3db", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Persistence", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1222", + "name": "File and Directory Permissions Modification", + "reference": "https://attack.mitre.org/techniques/T1222/", + "subtechnique": [ + { + "id": "T1222.001", + "name": "Windows File and Directory Permissions Modification", + "reference": "https://attack.mitre.org/techniques/T1222/001/" + } + ] + }, + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/", + "subtechnique": [ + { + "id": "T1564.001", + "name": "Hidden Files and Directories", + "reference": "https://attack.mitre.org/techniques/T1564/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [] + } + ], + "timeline_id": "e70679c2-6cde-4510-9764-4823df18f7db", + "timeline_title": "Comprehensive Process Timeline", + "timestamp_override": "event.ingested", + "type": "eql", + "version": 319 + }, + "id": "4630d948-40d4-4cef-ac69-4002e29bc3db_319", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_111.json b/packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_111.json new file mode 100644 index 00000000000..9eefc8aafbc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_111.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion.", + "false_positives": [ + "User using a new mail client or mobile application to access their mailbox.", + "Users accessing their mailboxes using custom or third-party applications that are authorized by the organization, such as CRM or ERP systems.", + "Users accessing their mailboxes using first-party Microsoft applications that are not typically used by the user, such as Outlook on the web or Outlook mobile app." + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-o365.audit-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious Microsoft 365 Mail Access by Unusual ClientAppId", + "new_terms_fields": [ + "o365.audit.ClientAppId" + ], + "note": "## Triage and Analysis\n\n### Investigating Suspicious Microsoft 365 Mail Access by Unusual ClientAppId\n\nThis rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion.\n\n### Possible investigation steps\n- Review the `o365.audit.UserId` field to identify the user associated with the mailbox access.\n- Check the `o365.audit.ClientAppId` field to determine which client application was used for the mailbox access. Look for unusual or unexpected applications or determine which first-party Microsoft applications are being abused.\n- Review `o365.audit.ClientInfoString` to gather additional information about the client application used for the mailbox access.\n- Examine `o365.audit.Folders.Path` to identify the specific mailbox folders accessed by the client application. This can help determine if sensitive information was accessed or if the access was legitimate.\n- Ensure that `o365.audit.MailboxOwnerUPN` matches the `o365.audit.UserId` to confirm that the mailbox accessed belongs to the user identified in the `o365.audit.UserId` field.\n- Review geolocation information to identify the location from which the mailbox access occurred. Look for any anomalies or unexpected locations that may indicate suspicious activity.\n- Examine `o365.audit.Folders.FolderItems.Id` to identify the specific items accessed within the mailbox folders. This can help determine if sensitive information was accessed or if the access was legitimate.\n\n### False positive analysis\n- Legitimate users may access their mailboxes using new or different client applications, such as when switching to a new email client or using a mobile application. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or client applications.\n- Users may access their mailboxes using custom or third-party applications that are authorized by the organization, such as CRM or ERP systems. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications.\n\n### Response and remediation\n- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.\n- Disable the user account temporarily to prevent any potential compromise or unauthorized access.\n- Examine the sensitivity of the mailbox data accessed and determine if any sensitive information was compromised.\n- Rotate the user's credentials and enforce multi-factor authentication (MFA) to prevent further unauthorized access.\n- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.\n", + "query": "event.dataset: \"o365.audit\" and\n event.provider: \"Exchange\" and\n event.category: \"web\" and\n event.action: \"MailItemsAccessed\" and\n event.outcome: \"success\" and\n o365.audit.LogonType: (\"0\" or \"1\" or \"6\") and\n o365.audit.UserType: (\"0\" or \"2\" or \"3\" or \"10\") and\n o365.audit.OperationProperties.Value: \"Bind\" and\n not o365.audit.ClientAppId : (\n \"00000002-0000-0000-c000-000000000000\" or \"00000002-0000-0ff1-ce00-000000000000\" or\n \"00000003-0000-0ff1-ce00-000000000000\" or \"00000004-0000-0ff1-ce00-000000000000\" or\n \"00000005-0000-0ff1-ce00-000000000000\" or \"00000006-0000-0ff1-ce00-000000000000\" or\n \"00000007-0000-0000-c000-000000000000\" or \"00000007-0000-0ff1-ce00-000000000000\" or\n \"00000009-0000-0000-c000-000000000000\" or \"0000000c-0000-0000-c000-000000000000\" or\n \"00000012-0000-0000-c000-000000000000\" or \"00000015-0000-0000-c000-000000000000\" or\n \"0000001a-0000-0000-c000-000000000000\" or \"00b41c95-dab0-4487-9791-b9d2c32c80f2\" or\n \"022907d3-0f1b-48f7-badc-1ba6abab6d66\" or \"04b07795-8ddb-461a-bbee-02f9e1bf7b46\" or\n \"08543e9e-5b1f-4af5-8228-cb5a5c9d4e24\" or \"08e18876-6177-487e-b8b5-cf950c1e598c\" or\n \"0cb7b9ec-5336-483b-bc31-b15b5788de71\" or \"0cd196ee-71bf-4fd6-a57c-b491ffd4fb1e\" or\n \"0f698dd4-f011-4d23-a33e-b36416dcb1e6\" or \"1150aefc-07de-4228-b2b2-042a536703c0\" or\n \"11ba4a52-3159-44e1-93cd-d18e9443e3ef\" or \"13937bba-652e-4c46-b222-3003f4d1ff97\" or\n \"13937bba-652e-4c46-b222-3003f4d1ff97\" or \"13937bba-652e-4c46-b222-3003f4d1ff97\" or\n \"14d82eec-204b-4c2f-b7e8-296a70dab67e\" or \"157cdfbf-7398-4a56-96c3-e93e9ab309b5\" or\n \"16aeb910-ce68-41d1-9ac3-9e1673ac9575\" or \"1786c5ed-9644-47b2-8aa0-7201292175b6\" or\n \"17d5e35f-655b-4fb0-8ae6-86356e9a49f5\" or \"18fbca16-2224-45f6-85b0-f7bf2b39b3f3\" or\n \"1950a258-227b-4e31-a9cf-717495945fc2\" or \"1b3c667f-cde3-4090-b60b-3d2abd0117f0\" or\n \"1fec8e78-bce4-4aaf-ab1b-5451cc387264\" or \"1fec8e78-bce4-4aaf-ab1b-5451cc387264\" or\n \"20a11fe0-faa8-4df5-baf2-f965f8f9972e\" or \"23523755-3a2b-41ca-9315-f81f3f566a95\" or\n \"243c63a3-247d-41c5-9d83-7788c43f1c43\" or \"268761a2-03f3-40df-8a8b-c3db24145b6b\" or\n \"26a7ee05-5602-4d76-a7ba-eae8b7b67941\" or \"26a7ee05-5602-4d76-a7ba-eae8b7b67941\" or\n \"26abc9a8-24f0-4b11-8234-e86ede698878\" or \"27922004-5251-4030-b22d-91ecd9a37ea4\" or\n \"27922004-5251-4030-b22d-91ecd9a37ea4\" or \"27b9c0f2-3d8e-4a1c-8b6f-5d7a0c6e1f2b\" or\n \"28b567f6-162c-4f54-99a0-6887f387bbcc\" or \"29d9ed98-a469-4536-ade2-f981bc1d605e\" or\n \"2abdc806-e091-4495-9b10-b04d93c3f040\" or \"2cee05de-2b8f-45a2-8289-2a06ca32c4c8\" or\n \"2d4d3d8e-2be3-4bef-9f87-7875a61c29de\" or \"2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8\" or\n \"2fd64745-b008-3e7d-4903-15d43e60f62a\" or \"3090ab82-f1c1-4cdf-af2c-5d7a6f3e2cc7\" or\n \"35d54a08-36c9-4847-9018-93934c62740c\" or \"37182072-3c9c-4f6a-a4b3-b3f91cacffce\" or\n \"38049638-cc2c-4cde-abe4-4479d721ed44\" or \"3c896ded-22c5-450f-91f6-3d1ef0848f6e\" or\n \"43375d74-c6a5-4d4e-a0a3-de139860ea75\" or \"4345a7b9-9a63-4910-a426-35363201d503\" or\n \"45a330b1-b1ec-4cc1-9161-9f03992aa49f\" or \"464e0e4d-676a-4c3b-9f81-2ed9b2a9acd2\" or\n \"4765445b-32c6-49b0-83e6-1d93765276ca\" or \"497effe9-df71-4043-a8bb-14cf78c4b63b\" or\n \"4b233688-031c-404b-9a80-a4f3f2351f90\" or \"4d5c2d63-cf83-4365-853c-925fd1a64357\" or\n \"51be292c-a17e-4f17-9a7e-4b661fb16dd2\" or \"5572c4c0-d078-44ce-b81c-6cbf8d3ed39e\" or\n \"5d661950-3475-41cd-a2c3-d671a3162bc1\" or \"5e3ce6c0-2b1f-4285-8d4b-75ee78787346\" or\n \"60c8bde5-3167-4f92-8fdb-059f6176dc0f\" or \"61109738-7d2b-4a0b-9fe3-660b1ff83505\" or\n \"62256cef-54c0-4cb4-bcac-4c67989bdc40\" or \"6253bca8-faf2-4587-8f2f-b056d80998a7\" or\n \"6326e366-9d6d-4c70-b22a-34c7ea72d73d\" or \"65d91a3d-ab74-42e6-8a2f-0add61688c74\" or\n \"66a88757-258c-4c72-893c-3e8bed4d6899\" or \"67e3df25-268a-4324-a550-0de1c7f97287\" or\n \"69893ee3-dd10-4b1c-832d-4870354be3d8\" or \"74658136-14ec-4630-ad9b-26e160ff0fc6\" or\n \"74bcdadc-2fdc-4bb3-8459-76d06952a0e9\" or \"75efb5bc-18a1-4e7b-8a66-2ad2503d79c6\" or\n \"75f31797-37c9-498e-8dc9-53c16a36afca\" or \"797f4846-ba00-4fd7-ba43-dac1f8f63013\" or\n \"7ab7862c-4c57-491e-8a45-d52a7e023983\" or \"7ae974c5-1af7-4923-af3a-fb1fd14dcb7e\" or\n \"7b7531ad-5926-4f2d-8a1d-38495ad33e17\" or \"7fba38f4-ec1f-458d-906c-f4e3c4f41335\" or\n \"80ccca67-54bd-44ab-8625-4b79c4dc7775\" or \"82d8ab62-be52-a567-14ea-1616c4ee06c4\" or\n \"835b2a73-6e10-4aa5-a979-21dfda45231c\" or \"871c010f-5e61-4fb1-83ac-98610a7e9110\" or\n \"89bee1f7-5e6e-4d8a-9f3d-ecd601259da7\" or \"8acd33ea-7197-4a96-bc33-d7cc7101262f\" or\n \"8edd93e1-2103-40b4-bd70-6e34e586362d\" or \"905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba\" or\n \"9199bf20-a13f-4107-85dc-02114787ef48\" or \"9199bf20-a13f-4107-85dc-02114787ef48\" or\n \"91ca2ca5-3b3e-41dd-ab65-809fa3dffffa\" or \"93625bc8-bfe2-437a-97e0-3d0060024faa\" or\n \"93d53678-613d-4013-afc1-62e9e444a0a5\" or \"944f0bd1-117b-4b1c-af26-804ed95e767e\" or\n \"94c63fef-13a3-47bc-8074-75af8c65887a\" or \"95de633a-083e-42f5-b444-a4295d8e9314\" or\n \"97cb1f73-50df-47d1-8fb0-0271f2728514\" or \"98db8bd6-0cc0-4e67-9de5-f187f1cd1b41\" or\n \"99b904fd-a1fe-455c-b86c-2f9fb1da7687\" or \"9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7\" or\n \"9fd38622-d9b4-4401-b1b9-1ce14c5e435a\" or \"a3475900-ccec-4a69-98f5-a65cd5dc5306\" or\n \"a3883eba-fbe9-48bd-9ed3-dca3e0e84250\" or \"a3883eba-fbe9-48bd-9ed3-dca3e0e84250\" or\n \"a3b79187-70b2-4139-83f9-6016c58cd27b\" or \"a40d7d7d-59aa-447e-a655-679a4107e548\" or\n \"a57aca87-cbc0-4f3c-8b9e-dc095fdc8978\" or \"a970bac6-63fe-4ec5-8884-8536862c42d4\" or\n \"a9b49b65-0a12-430b-9540-c80b3332c127\" or \"ab9b8c07-8f02-4f72-87fa-80105867a763\" or\n \"ae8e128e-080f-4086-b0e3-4c19301ada69\" or \"b23dd4db-9142-4734-867f-3577f640ad0c\" or\n \"b4bddae8-ab25-483e-8670-df09b9f1d0ea\" or \"b669c6ea-1adf-453f-b8bc-6d526592b419\" or\n \"b6e69c34-5f1f-4c34-8cdf-7fea120b8670\" or \"bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4\" or\n \"bdd48c81-3a58-4ea9-849c-ebea7f6b6360\" or \"c1c74fed-04c9-4704-80dc-9f79a2e515cb\" or\n \"c35cb2ba-f88b-4d15-aa9d-37bd443522e1\" or \"c44b4083-3bb0-49c1-b47d-974e53cbdf3c\" or\n \"c9a559d2-7aab-4f13-a6ed-e7e9c52aec87\" or \"cc15fd57-2c6c-4117-a88c-83b1d56b4bbe\" or\n \"cf36b471-5b44-428c-9ce7-313bf84528de\" or \"cf53fce8-def6-4aeb-8d30-b158e7b1cf83\" or\n \"d176f6e7-38e5-40c9-8a78-3998aab820e7\" or \"d34dcd43-8519-44e4-827c-de79b767da47\" or\n \"d3590ed6-52b3-4102-aeff-aad2292ab01c\" or \"d3590ed6-52b3-4102-aeff-aad2292ab01c\" or\n \"d3590ed6-52b3-4102-aeff-aad2292ab01c\" or \"d396de1f-10d4-4023-aae2-5bb3d724ba9a\" or\n \"d71dfe16-1070-48f3-bd3a-c3ec919d34e7\" or \"d73f4b35-55c9-48c7-8b10-651f6f2acb2e\" or\n \"d9b8ec3a-1e4e-4e08-b3c2-5baf00c0fcb0\" or \"de8bc8b5-d9f9-48b1-a8ad-b748da725064\" or\n \"dfe74da8-9279-44ec-8fb2-2aed9e1c73d0\" or \"e1ef36fd-b883-4dbf-97f0-9ece4b576fc6\" or\n \"e64aa8bc-8eb4-40e2-898b-cf261a25954f\" or \"e9b154d0-7658-433b-bb25-6b8e0a8a7c59\" or\n \"e9f49c6b-5ce5-44c8-925d-015017e9f7ad\" or \"ee272b19-4411-433f-8f28-5c13cb6fd407\" or\n \"eed83176-464d-48c7-a887-cc5cc534c7b8\" or \"f5eaa862-7f08-448c-9c4e-f4047d4d4521\" or\n \"f8d98a96-0999-43f5-8af3-69971c7bb423\" or \"fb78d390-0c51-40cd-8e17-fdbfab77341b\" or\n \"fc0f3af4-6835-4174-b806-f7db311fd2f3\" or \"fdf9885b-dd37-42bf-82e5-c3129ef5a302\" or\n \"ffcb16e8-f789-467c-8ce9-f826a080d987\"\n )\n", + "references": [ + "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a", + "https://trustedsec.com/blog/mailitemsaccessed-woes-m365-investigation-challenges", + "https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.11.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ClientAppId", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.LogonType", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.OperationProperties.Value", + "type": "unknown" + }, + { + "ecs": false, + "name": "o365.audit.UserType", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "48819484-9826-4083-9eba-1da74cd0eaf2", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Email", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1114", + "name": "Email Collection", + "reference": "https://attack.mitre.org/techniques/T1114/", + "subtechnique": [ + { + "id": "T1114.002", + "name": "Remote Email Collection", + "reference": "https://attack.mitre.org/techniques/T1114/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 111 + }, + "id": "48819484-9826-4083-9eba-1da74cd0eaf2_111", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4b77d382-b78e-4aae-85a0-8841b80e4fc4_1.json b/packages/security_detection_engine/kibana/security_rule/4b77d382-b78e-4aae-85a0-8841b80e4fc4_1.json new file mode 100644 index 00000000000..a454e90e636 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4b77d382-b78e-4aae-85a0-8841b80e4fc4_1.json @@ -0,0 +1,73 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster.", + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Forbidden Request from Unusual User Agent in Kubernetes", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Forbidden Request from Unusual User Agent in Kubernetes\n\nKubernetes, a container orchestration platform, manages applications across clusters. It uses APIs for communication, which can be targeted by adversaries using atypical user agents to mask malicious activities. These agents may attempt unauthorized actions, exploiting vulnerabilities. The detection rule identifies such anomalies by flagging forbidden requests from non-standard user agents, indicating potential threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the source IP address and user associated with the forbidden request. This can help determine if the request originated from a known or unknown entity.\n- Analyze the user agent string in the audit logs to understand its origin and purpose. Cross-reference it with known legitimate user agents to assess its legitimacy.\n- Check for any recent changes or deployments in the Kubernetes environment that might have introduced new user agents or configurations, potentially leading to the forbidden request.\n- Investigate the specific resource or API endpoint that was targeted by the forbidden request to understand what the adversary might have been attempting to access or exploit.\n- Correlate the event with other security logs and alerts to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort.\n- Assess the current security posture and configurations of the Kubernetes cluster to identify any vulnerabilities or misconfigurations that could be exploited by adversaries using unusual user agents.\n\n### False positive analysis\n\n- Legitimate internal tools or scripts may use non-standard user agents that are not included in the exclusion list. Review and identify these tools, then update the exclusion list to prevent them from being flagged.\n- Automated processes or third-party integrations might use unique user agents that trigger the rule. Verify these processes and consider adding their user agents to the exclusion list if they are deemed safe.\n- Development or testing environments often use custom user agents for API interactions. Ensure these environments are accounted for by excluding their user agents to avoid unnecessary alerts.\n- Regularly review and update the exclusion list to reflect changes in legitimate user agents used within your organization, ensuring that only truly unusual and potentially malicious agents are flagged.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary.\n- Revoke any suspicious or unauthorized credentials or tokens that may have been used in the forbidden request to ensure they cannot be reused.\n- Conduct a thorough review of the Kubernetes audit logs to identify any additional unauthorized or suspicious activities that may have occurred around the time of the alert.\n- Patch any identified vulnerabilities or misconfigurations in the Kubernetes environment that may have been exploited, ensuring all components are up to date with the latest security patches.\n- Implement stricter access controls and user agent validation to prevent non-standard user agents from interacting with the Kubernetes API unless explicitly allowed.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.\n- Enhance monitoring and alerting for similar activities by tuning detection systems to recognize patterns associated with this type of threat, ensuring rapid response to future incidents.\n", + "query": "any where host.os.type == \"linux\" and event.dataset == \"kubernetes.audit_logs\" and\nkubernetes.audit.stage == \"ResponseComplete\" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == \"forbid\" and\nnot user_agent.original like~ (\n \"/\", \"karpenter\", \"csi-secrets-store/*\", \"elastic-agent/*\", \"agentbeat/*\", \"insights-operator*\", \"oc/*\", \"cloud-defend/*\",\n \"OpenAPI-Generator/*\", \"local-storage-operator/*\", \"falcon-client/*\", \"nginx-ingress-controller/*\", \"config-translator/*\",\n \"kwatch/*\", \"PrometheusOperator/*\", \"kube*\"\n)\n", + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "`kubernetes.audit.annotations.authorization_k8s_io/decision`", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.stage", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "4b77d382-b78e-4aae-85a0-8841b80e4fc4", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "4b77d382-b78e-4aae-85a0-8841b80e4fc4_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4d4cda2b-9aad-4702-a0a2-75952bd6a77c_2.json b/packages/security_detection_engine/kibana/security_rule/4d4cda2b-9aad-4702-a0a2-75952bd6a77c_2.json new file mode 100644 index 00000000000..63e2547f88d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4d4cda2b-9aad-4702-a0a2-75952bd6a77c_2.json @@ -0,0 +1,77 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation of files named release_agent or notify_on_release, which are commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host from within a container.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.file*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Docker Release File Creation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Docker Release File Creation\n\nIn Linux, cgroups manage resources for processes, and the release_agent file can execute scripts when a cgroup is released. In containerized environments like Docker, adversaries may exploit this to escalate privileges, executing code on the host. The detection rule identifies the creation of files like release_agent, signaling potential misuse of cgroup release mechanisms for privilege escalation.\n\n### Possible investigation steps\n\n- Review the alert details to confirm the file creation event occurred on a Linux host, as specified by the query field host.os.type == \"linux\".\n- Identify the specific file name created, either release_agent or notify_on_release, to understand the potential method of exploitation.\n- Investigate the process that created the file by examining process logs or using process monitoring tools to determine if it was initiated by a legitimate application or a suspicious process.\n- Check for any recent container activity on the host, such as new container deployments or changes, to identify potential sources of the file creation.\n- Analyze user activity logs to determine if any unauthorized or unusual user actions correlate with the file creation event.\n- Look for any additional indicators of compromise or related alerts on the host that might suggest a broader attack or exploitation attempt.\n- Assess the system for any signs of privilege escalation or unauthorized access to determine if the release_agent or notify_on_release file creation was part of a successful attack.\n\n### False positive analysis\n\n- System administrators or automated scripts may create release_agent or notify_on_release files for legitimate resource management tasks in containerized environments.\n- Regularly scheduled maintenance scripts might trigger the rule if they involve creating or modifying cgroup release files as part of their operations.\n- Developers testing container features might inadvertently create these files during the development process.\n- To handle these false positives, users can create exceptions for known scripts or processes that routinely create these files by whitelisting their specific paths or process names.\n- Implement monitoring to differentiate between expected and unexpected file creation events, focusing on unusual patterns or contexts that deviate from normal operations.\n\n### Response and remediation\n\n- Immediately isolate the affected container to prevent further exploitation or lateral movement. This can be done by stopping the container or disconnecting it from the network.\n- Investigate the container's logs and processes to identify any unauthorized or suspicious activity that may have occurred as a result of the release_agent or notify_on_release file creation.\n- Remove any unauthorized files or scripts that were executed as a result of the cgroup release mechanism exploitation. Ensure that the release_agent and notify_on_release files are deleted if they were created maliciously.\n- Patch the host system and all containers to address known vulnerabilities such as CVE-2022-0492. Ensure that all security updates are applied to prevent similar exploits.\n- Review and tighten the security configurations of Docker and the host system, including setting appropriate cgroup permissions and limiting container capabilities to the minimum necessary.\n- Monitor for any further attempts to exploit cgroup release mechanisms by setting up alerts for the creation of release_agent and notify_on_release files.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems may have been affected or if there is a broader security incident underway.\n", + "query": "file where host.os.type == \"linux\" and event.type == \"creation\" and file.name in (\"release_agent\", \"notify_on_release\")\n", + "references": [ + "https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "4d4cda2b-9aad-4702-a0a2-75952bd6a77c", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "4d4cda2b-9aad-4702-a0a2-75952bd6a77c_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_5.json b/packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_5.json new file mode 100644 index 00000000000..3c9bc8a2911 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_5.json @@ -0,0 +1,116 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more.", + "false_positives": [ + "Legitimate users may create SSM command documents for legitimate purposes. Ensure that the document is authorized and the user is known before taking action." + ], + "from": "now-6m", + "history_window_start": "now-10d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS SSM Command Document Created by Rare User", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": "## Triage and analysis\n\n### Investigating AWS SSM Command Document Created by Rare User\n\nThis rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration.\n\n#### Possible Investigation Steps\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action.\n- **Analyze the Document Details**:\n - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose.\n - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console.\n- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.ip`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances.\n- **Check Document Status and Metadata**:\n - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress.\n - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist.\n\n### False Positive Analysis\n\n- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel.\n- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage.\n\n### Response and Remediation\n\n- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently.\n- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users.\n- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation.\n- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation.\n\n### Additional Information\n\nFor further guidance on managing and securing AWS Systems Manager in your environment, refer to the [AWS SSM documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) and AWS security best practices.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: \"CreateDocument\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.response_elements.documentDescription.documentType: \"Command\"\n", + "references": [ + "https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html", + "https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.response_elements.documentDescription.documentType", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "50a2bdea-9876-11ef-89db-f661ea17fbcd", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS SSM", + "Data Source: AWS Systems Manager", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Execution" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1651", + "name": "Cloud Administration Command", + "reference": "https://attack.mitre.org/techniques/T1651/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 5 + }, + "id": "50a2bdea-9876-11ef-89db-f661ea17fbcd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_216.json b/packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_216.json new file mode 100644 index 00000000000..63ce8a4a485 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_216.json @@ -0,0 +1,118 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Windows Service Installed via an Unusual Client", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Windows Service Installed via an Unusual Client\n\nWindows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations initiated by atypical processes, excluding known legitimate services. This helps in spotting potential privilege escalation attempts by monitoring unusual client activity.\n\n### Possible investigation steps\n\n- Review the event logs to identify the specific client process that initiated the service installation by examining the winlog.event_data.ClientProcessId and winlog.event_data.ParentProcessId fields.\n- Investigate the parent process associated with the unusual client process to determine if it is a known legitimate application or potentially malicious.\n- Check the winlog.event_data.ServiceFileName to verify the path and name of the service file, ensuring it is not a known legitimate service excluded in the query.\n- Analyze the timeline of events around the service installation to identify any preceding suspicious activities or related alerts that might indicate a broader attack.\n- Conduct a reputation check on the client process and service file using threat intelligence sources to assess if they are associated with known malicious activities.\n- Examine the system for any additional indicators of compromise, such as unexpected network connections or changes to critical system files, that may suggest privilege escalation or lateral movement attempts.\n\n### False positive analysis\n\n- Legitimate software installations or updates may trigger the rule if they create services using unusual client processes. To manage this, identify and whitelist these processes in the detection rule to prevent unnecessary alerts.\n- System management tools like Veeam and PDQ Inventory are already excluded, but other similar tools might not be. Regularly review and update the exclusion list to include any additional legitimate tools used in your environment.\n- Custom scripts or administrative tools that create services for maintenance or monitoring purposes can also cause false positives. Document these scripts and consider adding them to the exclusion list if they are verified as safe.\n- Temporary or one-time service installations for troubleshooting or testing can be mistaken for threats. Ensure that such activities are logged and communicated to the security team to avoid confusion and unnecessary alerts.\n- Changes in system configurations or updates to existing software might alter the behavior of legitimate processes, causing them to be flagged. Regularly review and adjust the detection rule to accommodate these changes while maintaining security integrity.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate the suspicious service and any associated processes identified by the alert to stop potential privilege escalation or malicious activity.\n- Conduct a thorough review of the service's configuration and associated files to identify any unauthorized changes or malicious code.\n- Restore any altered or compromised system files from a known good backup to ensure system integrity.\n- Change all administrator and SYSTEM account passwords on the affected system and any connected systems to prevent further unauthorized access.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.\n- Implement additional monitoring and logging on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities.", + "query": "configuration where host.os.type == \"windows\" and\n event.action == \"service-installed\" and\n (winlog.event_data.ClientProcessId == \"0\" or winlog.event_data.ParentProcessId == \"0\") and\n startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == \"LocalSystem\" and \n not winlog.event_data.ServiceFileName : (\n \"?:\\\\Windows\\\\VeeamVssSupport\\\\VeeamGuestHelper.exe\",\n \"?:\\\\Windows\\\\VeeamLogShipper\\\\VeeamLogShipper.exe\",\n \"%SystemRoot%\\\\system32\\\\Drivers\\\\Crowdstrike\\\\*-CsInstallerService.exe\",\n \"\\\"%windir%\\\\AdminArsenal\\\\PDQInventory-Scanner\\\\service-1\\\\PDQInventory-Scanner-1.exe\\\" \"\n )\n", + "references": [ + "https://www.x86matthew.com/view_post?id=create_svc_rpc", + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697", + "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md", + "https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.domain", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ClientProcessId", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.ParentProcessId", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.ServiceAccount", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.ServiceFileName", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "55c2bf58-2a39-4c58-a384-c8b1978153c2", + "setup": "## Setup\n\nThe 'Audit Security System Extension' logging policy must be configured for (Success)\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nSystem >\nAudit Security System Extension (Success)\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/", + "subtechnique": [ + { + "id": "T1543.003", + "name": "Windows Service", + "reference": "https://attack.mitre.org/techniques/T1543/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 216 + }, + "id": "55c2bf58-2a39-4c58-a384-c8b1978153c2_216", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/56d9cf6c-46ea-4019-9c7f-b1fdb855fee3_2.json b/packages/security_detection_engine/kibana/security_rule/56d9cf6c-46ea-4019-9c7f-b1fdb855fee3_2.json new file mode 100644 index 00000000000..4866a4ea547 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/56d9cf6c-46ea-4019-9c7f-b1fdb855fee3_2.json @@ -0,0 +1,115 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies Windows sanfbox processes indicating the start of a new container with sensitive configurations like write access to the host file system, network connection and automatic execution via logon command. Malware may abuse the sandbox feature to evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process-*", + "winlogbeat-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Windows Sandbox with Sensitive Configuration", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Windows Sandbox with Sensitive Configuration\n\nWindows Sandbox is a lightweight virtual environment designed to safely run untrusted applications. It isolates processes from the host system, preventing permanent changes. However, adversaries can exploit this by configuring the sandbox to access host resources, enabling network connections, or executing commands at startup. The detection rule identifies such misuse by monitoring specific process activities and configurations indicative of potential abuse, such as unauthorized file system access or network enablement, helping analysts spot and mitigate threats effectively.\n\n### Possible investigation steps\n\n- Review the process details for \"wsb.exe\" or \"WindowsSandboxClient.exe\" to confirm the start of a new container and check for any unusual command-line arguments that match the query criteria, such as \"Enable\" or \"true>\".\n- Investigate any file system access attempts by the sandbox, particularly focusing on write access to the host file system indicated by \"C:\\false\". Determine if any unauthorized or suspicious files have been modified or created.\n- Examine network activity associated with the sandbox process to identify any unexpected or unauthorized connections, especially if \"true>\" is present in the command line.\n- Check for any logon commands executed by the sandbox process using \"\" in the command line to identify potential persistence mechanisms or automated tasks that could indicate malicious intent.\n- Correlate the sandbox activity with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify any related suspicious activities.\n\n### False positive analysis\n\n- Legitimate software installations or updates may configure the Windows Sandbox to enable network connections or access host resources. Users can create exceptions for known software update processes to prevent unnecessary alerts.\n- Developers and IT administrators might use Windows Sandbox for testing purposes, which could involve enabling network connections or accessing host files. Establishing a list of approved users or processes that frequently perform these actions can help reduce false positives.\n- Automated scripts or tools that configure the sandbox for legitimate purposes, such as testing or development, may trigger the rule. Identifying and excluding these scripts from monitoring can minimize false alerts.\n- Security tools or system management software might use sandbox features for legitimate operations. Users should verify and whitelist these tools to avoid misidentification as threats.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any suspicious processes identified by the detection rule, specifically those related to Windows Sandbox misuse, such as \"wsb.exe\" or \"WindowsSandboxClient.exe\".\n- Conduct a thorough review of the system's file system and network logs to identify any unauthorized access or data transfers that may have occurred.\n- Remove any unauthorized configurations or scripts found within the Windows Sandbox environment that enable network connections or host file system access.\n- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process creation and command-line parameters related to Windows Sandbox configurations.\n", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : (\"wsb.exe\", \"WindowsSandboxClient.exe\") and\n process.command_line : (\"*Enable*\",\n \"*C:\\\\*false*\",\n \"**\",\n \"*true*\")\n", + "references": [ + "https://blog-en.itochuci.co.jp/entry/2025/03/12/140000" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "56d9cf6c-46ea-4019-9c7f-b1fdb855fee3", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/", + "subtechnique": [ + { + "id": "T1564.006", + "name": "Run Virtual Instance", + "reference": "https://attack.mitre.org/techniques/T1564/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "56d9cf6c-46ea-4019-9c7f-b1fdb855fee3_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_10.json b/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_10.json new file mode 100644 index 00000000000..0eb2184fdeb --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_10.json @@ -0,0 +1,99 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control.", + "false_positives": [ + "Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few legitimate use-cases and should result in very few false positives." + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Suspicious Assignment of Controller Service Account", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Suspicious Assignment of Controller Service Account\n\nKubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the audit logs to confirm the presence of a \"create\" event for a pod in the \"kube-system\" namespace with a service account name containing \"controller\".\n- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.\n- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.\n- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.\n- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.\n- Review recent changes or deployments in the \"kube-system\" namespace to identify any unauthorized modifications or anomalies.\n\n### False positive analysis\n\n- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.\n- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.\n- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.\n- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.\n- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.\n\n### Response and remediation\n\n- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.\n- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.\n- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.\n- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.\n- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.\n- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb : \"create\"\n and kubernetes.audit.objectRef.resource : \"pods\"\n and kubernetes.audit.objectRef.namespace : \"kube-system\"\n and kubernetes.audit.requestObject.spec.serviceAccountName:*controller\n", + "references": [ + "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.namespace", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.serviceAccountName", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "63c05204-339a-11ed-a261-0242ac120002", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.001", + "name": "Default Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 10 + }, + "id": "63c05204-339a-11ed-a261-0242ac120002_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_9.json b/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_9.json new file mode 100644 index 00000000000..4467144d3bd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_9.json @@ -0,0 +1,77 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster.", + "false_positives": [ + "Unauthorized requests from service accounts are highly abnormal and more indicative of human behavior or a serious problem within the cluster. This behavior should be investigated further." + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Denied Service Account Request", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Denied Service Account Request\n\nKubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations.\n\n### Possible investigation steps\n\n- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used.\n- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request.\n- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated.\n- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior.\n- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations.\n- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request.\n\n### False positive analysis\n\n- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use.\n- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities.\n- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions.\n- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities.\n- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior.\n\n### Response and remediation\n\n- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests.\n- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account.\n- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation.\n- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required.\n- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents.\n- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future.", + "query": "event.dataset: \"kubernetes.audit_logs\"\n and kubernetes.audit.user.username: system\\:serviceaccount\\:*\n and kubernetes.audit.annotations.authorization_k8s_io/decision: \"forbid\"\n", + "references": [ + "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", + "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.user.username", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "63c056a0-339a-11ed-a261-0242ac120002", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 9 + }, + "id": "63c056a0-339a-11ed-a261-0242ac120002_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_10.json b/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_10.json new file mode 100644 index 00000000000..4168e7c27e0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_10.json @@ -0,0 +1,90 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.", + "false_positives": [ + "Anonymous access to the API server is a dangerous setting enabled by default. Common anonymous connections (e.g., health checks) have been excluded from this rule. All other instances of authorized anonymous requests should be investigated." + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Anonymous Request Authorized", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Anonymous Request Authorized\n\nKubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.\n- Examine the kubernetes.audit.user.username field to confirm if the request was made by \"system:anonymous\" or \"system:unauthenticated\" and assess the potential risk associated with these accounts.\n- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.\n- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.\n- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.\n\n### False positive analysis\n\n- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.\n- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.\n- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.\n- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.\n- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.\n- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.\n- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.\n- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.\n- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.\n- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.", + "query": "event.dataset:kubernetes.audit_logs\n and kubernetes.audit.annotations.authorization_k8s_io/decision:allow\n and kubernetes.audit.user.username:(\"system:anonymous\" or \"system:unauthenticated\" or not *)\n and not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz*)\n", + "references": [ + "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestURI", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.user.username", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "63c057cc-339a-11ed-a261-0242ac120002", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Initial Access", + "Tactic: Defense Evasion", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.001", + "name": "Default Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 10 + }, + "id": "63c057cc-339a-11ed-a261-0242ac120002_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_3.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_3.json new file mode 100644 index 00000000000..c298d1d0f44 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Invalid Escape Sequences", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Invalid Escape Sequences\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques to evade detection. By inserting invalid escape sequences, attackers can obscure malicious scripts, bypassing static analysis and security tools like AMSI. The detection rule identifies such obfuscation by analyzing script patterns, specifically targeting unusual backtick usage, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script block that triggered the alert. Look for patterns of invalid escape sequences and assess whether they appear intentionally obfuscated.\n- Examine the `file.name` and `file.path` fields to determine the origin and location of the script. This can help identify whether the script is part of a legitimate application or potentially malicious.\n- Check the `host.name` and `agent.id` fields to identify the affected system and the agent responsible for logging the event. This information is crucial for understanding the scope of the potential threat.\n- Analyze the `user.id` field to ascertain which user executed the script. This can provide insights into whether the user has a history of executing suspicious scripts or if their account may be compromised.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related script blocks, which may reveal additional obfuscation or malicious activity.\n- Assess the `count` field to evaluate the extent of obfuscation detected. A higher count may indicate more aggressive obfuscation techniques, warranting further scrutiny.\n\n### False positive analysis\n\n- Scripts from Visual Studio Code's PowerShell extension may trigger false positives due to its shell integration. To handle this, exclude scripts containing the pattern \"$([char]0x1b)]633\" from detection.\n- PowerShell modules with names starting with \"TSS_\" may be flagged incorrectly. Exclude these by adding a condition to ignore files matching the pattern \"TSS_*.psm1\".\n- Legitimate scripts that use backticks for formatting or other non-obfuscation purposes might be detected. Review such scripts and, if verified as safe, add them to an exception list based on their script block ID or file path.\n- Regularly update the exclusion list to reflect changes in legitimate script usage patterns, ensuring that new false positives are addressed promptly.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. Disconnect the host from the network and disable remote access.\n\n- Analyze the script block text and file path to identify the source and nature of the obfuscated script. Determine if the script is part of a larger attack or if other systems are affected.\n\n- Remove or quarantine the identified malicious script and any associated files from the host. Ensure that all remnants of the obfuscated code are eliminated to prevent re-execution.\n\n- Conduct a thorough scan of the host using updated antivirus and antimalware tools to detect and remove any additional threats or indicators of compromise.\n\n- Review and update PowerShell execution policies and security settings to restrict the execution of scripts with invalid escape sequences. Implement stricter controls to prevent similar obfuscation techniques.\n\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and monitoring. Provide detailed logs and findings to assist in understanding the scope and impact of the threat.\n\n- Implement enhanced logging and monitoring for PowerShell activities across the network to detect and respond to similar obfuscation attempts promptly. Use the identified patterns to refine detection capabilities.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\" and powershell.file.script_block_text LIKE \"*`*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.name, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 10\n\n// Filter FPs, and due to the behavior of the LIKE operator, allow null values\n| WHERE (file.name NOT LIKE \"TSS_*.psm1\" or file.name IS NULL)\n\n| WHERE\n // VSCode Shell integration\n NOT powershell.file.script_block_text LIKE \"*$([char]0x1b)]633*\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6505e02e-28dd-41cd-b18f-64e649caa4e2_2.json b/packages/security_detection_engine/kibana/security_rule/6505e02e-28dd-41cd-b18f-64e649caa4e2_2.json new file mode 100644 index 00000000000..c00af2582fe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6505e02e-28dd-41cd-b18f-64e649caa4e2_2.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory of a process, potentially extracting sensitive information such as credentials or encryption keys.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Manual Memory Dumping via Proc Filesystem", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Manual Memory Dumping via Proc Filesystem\n\nThe proc filesystem in Linux is a virtual interface providing detailed insights into system processes and their memory. Adversaries exploit this by manually dumping memory from processes to extract sensitive data like credentials. The detection rule identifies suspicious activities by monitoring process executions that access memory files within the proc directory, flagging potential credential access attempts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific process name and command line that triggered the rule, focusing on processes like \"cat\", \"grep\", \"tail\", \"less\", \"more\", \"egrep\", or \"fgrep\" accessing \"/proc/*/mem\".\n- Examine the process execution context, including the parent process and user account associated with the suspicious activity, to determine if the activity is expected or potentially malicious.\n- Check the system logs and historical data for any previous occurrences of similar activities involving the same process names and command lines to assess if this is part of a pattern or anomaly.\n- Investigate the user account's recent activities and permissions to determine if there are any signs of compromise or unauthorized access that could explain the memory dumping attempt.\n- Analyze network traffic and connections from the host to identify any potential data exfiltration attempts or communications with known malicious IP addresses or domains.\n- If necessary, isolate the affected system to prevent further potential data leakage and conduct a deeper forensic analysis to uncover any additional indicators of compromise.\n\n### False positive analysis\n\n- System administrators or automated scripts may legitimately access the proc filesystem for monitoring or debugging purposes. To handle this, identify and whitelist known scripts or administrative tools that frequently access memory files.\n- Security tools or monitoring solutions might access the proc filesystem as part of their regular operations. Review and exclude these processes from the rule to prevent unnecessary alerts.\n- Developers or testers might use commands like cat or grep on proc files during application debugging. Establish a list of approved users or groups who are allowed to perform these actions and exclude their activities from triggering alerts.\n- Backup or system maintenance processes could involve accessing proc files. Document these processes and create exceptions for them to avoid false positives.\n- Regular system health checks might involve accessing memory files. Identify these checks and configure the rule to ignore them by specifying the associated process names or command patterns.\n\n### Response and remediation\n\n- Immediately isolate the affected system to prevent further unauthorized access or data exfiltration. Disconnect the network connection and disable remote access capabilities.\n- Terminate any suspicious processes identified by the detection rule, specifically those accessing memory files within the proc directory using commands like \"cat\", \"grep\", \"tail\", \"less\", \"more\", \"egrep\", or \"fgrep\".\n- Conduct a memory analysis on the isolated system to identify any extracted sensitive data, such as credentials or encryption keys, and assess the extent of the compromise.\n- Change all potentially compromised credentials and encryption keys immediately, prioritizing those associated with critical systems and services.\n- Review and enhance system logging and monitoring configurations to ensure comprehensive visibility into process activities, particularly those involving the proc filesystem.\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign.\n- Implement additional security controls, such as restricting access to the proc filesystem and employing application whitelisting, to prevent unauthorized memory dumping activities in the future.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\nprocess.name in (\"cat\", \"grep\", \"tail\", \"less\", \"more\", \"egrep\", \"fgrep\") and process.command_line like \"/proc/*/mem\"\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "6505e02e-28dd-41cd-b18f-64e649caa4e2", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Use Case: Vulnerability", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/", + "subtechnique": [ + { + "id": "T1003.007", + "name": "Proc Filesystem", + "reference": "https://attack.mitre.org/techniques/T1003/007/" + } + ] + }, + { + "id": "T1212", + "name": "Exploitation for Credential Access", + "reference": "https://attack.mitre.org/techniques/T1212/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "6505e02e-28dd-41cd-b18f-64e649caa4e2_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_2.json b/packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_2.json new file mode 100644 index 00000000000..0d7dc3dfb28 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_2.json @@ -0,0 +1,157 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments", + "new_terms_fields": [ + "process.parent.name", + "process.command_line", + "host.id" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments\n\nLD_PRELOAD and LD_LIBRARY_PATH are environment variables in Linux that influence dynamic linking by specifying libraries to load before others. Adversaries exploit these to hijack execution flow, evade defenses, or escalate privileges. The detection rule identifies suspicious use of these variables in shell commands, excluding benign processes, signaling potential misuse for persistence or defense evasion.\n\n### Possible investigation steps\n\n- Review the process command line to identify the specific libraries being loaded via LD_PRELOAD or LD_LIBRARY_PATH and assess their legitimacy.\n- Examine the parent process name to determine if the process is expected to use these environment variables, considering the exclusion list provided in the query.\n- Investigate the user account associated with the process to check for any signs of compromise or unusual activity.\n- Analyze the process execution context, including the timestamp and host details, to identify any patterns or correlations with other suspicious activities.\n- Check system logs and other security tools for related alerts or events that might indicate broader malicious activity or attempts to evade defenses.\n\n### False positive analysis\n\n- Development and testing environments often use LD_PRELOAD and LD_LIBRARY_PATH for legitimate purposes such as testing new libraries or debugging. Consider excluding processes associated with these environments if they are known and trusted.\n- Some software installations or updates may temporarily use these environment variables to ensure compatibility or to load specific libraries. Monitor installation logs and exclude these processes if they are verified as part of legitimate software management.\n- System administration scripts or automation tools might use these variables to manage library paths dynamically. Review and whitelist these scripts if they are part of routine maintenance and have been vetted for security.\n- Certain applications, like custom-built software or legacy systems, may rely on these variables for normal operation. Document these applications and exclude them from the rule if they are essential and secure.\n- Security tools or monitoring agents might use these variables to hook into processes for legitimate monitoring purposes. Verify the behavior of these tools and exclude them if they are part of your security infrastructure.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.\n- Terminate any suspicious processes identified with unusual LD_PRELOAD or LD_LIBRARY_PATH usage to halt potential exploitation.\n- Conduct a thorough review of the affected system's environment variables and remove any unauthorized or suspicious entries.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n- Implement stricter access controls and monitoring on the affected system to prevent unauthorized changes to environment variables.\n- Update and enhance detection rules to include additional indicators of compromise related to LD_PRELOAD and LD_LIBRARY_PATH misuse, ensuring future attempts are identified promptly.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:exec and\nprocess.parent.name:(* and not (\n awk or bwrap or cylancesvc or dbus-run-session or java or julia or make or matlab_helper or ninja or noproc_sandbox or\n nxrunner or nxserver or perl or rear or sapcontrol or setsid or spoold or sshd or steam or su or sudo or titanagent or\n vls_agent or zabbix_agentd\n)) and\nprocess.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and\nprocess.args:-c and process.command_line:(*LD_LIBRARY_PATH=* or *LD_PRELOAD=*)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "65613f5e-0d48-4b55-ad61-2fb9567cb1ad", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.006", + "name": "Dynamic Linker Hijacking", + "reference": "https://attack.mitre.org/techniques/T1574/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.006", + "name": "Dynamic Linker Hijacking", + "reference": "https://attack.mitre.org/techniques/T1574/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.006", + "name": "Dynamic Linker Hijacking", + "reference": "https://attack.mitre.org/techniques/T1574/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "65613f5e-0d48-4b55-ad61-2fb9567cb1ad_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_2.json b/packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_2.json new file mode 100644 index 00000000000..f8933464c3b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_2.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process.", + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual Execution from Kernel Thread (kthreadd) Parent", + "new_terms_fields": [ + "process.name", + "host.id" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Execution from Kernel Thread (kthreadd) Parent\n\nThe kernel thread (kthreadd) is a fundamental component in Linux systems responsible for managing kernel-level processes. Adversaries may exploit kthreadd to execute payloads from kernel space, thereby evading detection due to its trusted status. The detection rule identifies suspicious child processes initiated by kthreadd, focusing on unusual executable paths and command lines indicative of malicious activity, while filtering out known benign processes.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific child process name and executable path that triggered the rule. Focus on paths like /dev/shm, /tmp, /var/tmp, and /var/www, which are commonly used for storing temporary or potentially malicious files.\n- Examine the command line arguments associated with the suspicious process. Look for indicators of compromise such as references to sensitive files or directories like /etc/shadow, /etc/sudoers, or ~/.ssh, as well as suspicious commands like base64 or cron.\n- Check the parent process details to confirm it is indeed kthreadd. Investigate any unusual behavior or anomalies in the parent process that might suggest exploitation or manipulation.\n- Investigate the network activity of the host to identify any connections to suspicious IP addresses or domains, especially if the command line includes references to /dev/tcp or other network-related paths.\n- Analyze the system logs and historical data to determine if similar alerts have been triggered in the past, which might indicate a persistent threat or repeated exploitation attempts.\n- Assess the risk and impact of the detected activity by correlating it with other security events or alerts on the host, considering the medium severity and risk score of 47 associated with this rule.\n\n### False positive analysis\n\n- Legitimate system maintenance tasks may trigger this rule, such as automated scripts running from temporary directories. Users can create exceptions for specific scripts or processes that are verified as safe.\n- Development or testing environments often use temporary directories for executing scripts. Exclude known development tools or scripts from these environments to reduce noise.\n- Some monitoring or backup tools might use command lines or executables that match the rule's criteria. Identify these tools and add them to the exclusion list to prevent false alerts.\n- Custom administrative scripts that perform routine checks or updates might inadvertently match the rule. Review these scripts and exclude them if they are part of regular operations.\n- If certain processes are consistently flagged but are known to be benign, consider adjusting the rule to exclude these specific processes or command lines to improve detection accuracy.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network.\n- Terminate any suspicious processes identified as child processes of kthreadd that match the alert criteria, ensuring to log the process details for further analysis.\n- Conduct a thorough review of the file paths and command lines flagged in the alert to identify any unauthorized or malicious files or scripts. Remove or quarantine these files as necessary.\n- Check for unauthorized modifications in critical system files and directories such as /etc/init.d, /etc/ssh, and /root/.ssh. Restore any altered files from a known good backup.\n- Escalate the incident to the security operations team for a deeper forensic investigation to determine the root cause and entry point of the threat.\n- Implement additional monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on the specific indicators identified in the alert.\n- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that may have been exploited by the adversary.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.parent.name:kthreadd and (\n process.executable:(/dev/shm/* or /tmp/* or /var/tmp/* or /var/www/*) or\n process.name:(bash or csh or curl or dash or fish or id or ksh or nohup or setsid or sh or tcsh or wget or whoami or zsh)\n) and\nprocess.command_line:(\n */dev/shm/* or */dev/tcp/* or */etc/init.d* or */etc/ld.so* or */etc/profile* or */etc/rc.local* or */etc/shadow* or */etc/ssh* or\n */etc/sudoers* or */home/*/.ssh/* or */root/.ssh* or */tmp/* or */var/log/* or */var/run/* or */var/tmp/* or */var/www/* or\n *base64* or *cron* or *xxd* or *~/.ssh/*\n) and not (\n process.name:(true or cifs.upcall or dpkg or flock or gdbus or getopt or grep or mount or touch or umount or uname) or\n process.command_line:(\n \"sh -c /bin/true\" or */bin/ps* or */usr/bin/find* or */usr/bin/grep* or *ds_agent* or *gitlabrunner* or *nagios* or\n *omsagent* or *pgrep*\n ) or\n process.executable:(\n /lib/systemd/systemd-cgroups-agent or /proc/self/exe or /usr/local/axs-haproxy-monitoring/haproxy_stats.sh or /tmp/newroot/* or\n /var/lib/docker/overlay2/* or /vz/root/*\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "656739a8-2786-402b-8ee1-22e0762b63ba", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\n\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "656739a8-2786-402b-8ee1-22e0762b63ba_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_207.json b/packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_207.json new file mode 100644 index 00000000000..049e1bf51c9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_207.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster.", + "false_positives": [ + "Developers may have a legitimate use for NodePorts. For frontend parts of an application you may want to expose a Service onto an external IP address without using cloud specific Loadbalancers. NodePort can be used to expose the Service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort Service from outside the cluster, by requesting :. NodePort unlike Loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by Kubernetes, or even to expose one or more node's IPs directly." + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Exposed Service Created With Type NodePort", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Exposed Service Created With Type NodePort\n\nKubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is \"services\" and kubernetes.audit.verb is \"create\", \"update\", or \"patch\".\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized.\n- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name.\n- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally.\n- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception.\n- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent.\n\n### False positive analysis\n\n- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly.\n- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters.\n- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts.\n- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms.\n- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period.\n\n### Response and remediation\n\n- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception.\n- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service.\n- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service.\n- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed.\n- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture.\n- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited.\n- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"services\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.type:\"NodePort\"\n", + "references": [ + "https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types", + "https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport", + "https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "65f9bccd-510b-40df-8263-334f03174fed", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1133", + "name": "External Remote Services", + "reference": "https://attack.mitre.org/techniques/T1133/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 207 + }, + "id": "65f9bccd-510b-40df-8263-334f03174fed_207", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/68e90a9b-0eab-425e-be3b-902b0cd1fe9c_2.json b/packages/security_detection_engine/kibana/security_rule/68e90a9b-0eab-425e-be3b-902b0cd1fe9c_2.json new file mode 100644 index 00000000000..ad1c857a91a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/68e90a9b-0eab-425e-be3b-902b0cd1fe9c_2.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or persistence.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Path Mounted", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Path Mounted\n\nIn Linux environments, the mount command integrates filesystems, enabling access to storage devices. Adversaries exploit this by mounting malicious filesystems in sensitive directories like /tmp or /dev/shm to exfiltrate data or maintain persistence. The detection rule identifies such activities by monitoring the execution of the mount command in unusual paths, excluding legitimate parent processes, thus highlighting potential threats.\n\n### Possible investigation steps\n\n- Review the process details to confirm the execution of the mount command, focusing on the process.name and process.args fields to identify the specific path being mounted.\n- Examine the process.parent.executable field to determine the parent process that initiated the mount command, ensuring it is not a known legitimate process.\n- Investigate the user account associated with the process to determine if it is a privileged account or if there are any signs of compromise.\n- Check for any recent changes or anomalies in the mounted directories, such as unexpected files or modifications, to assess potential data exfiltration or persistence activities.\n- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack.\n\n### False positive analysis\n\n- System maintenance scripts may trigger the rule if they mount filesystems in monitored paths. Review and whitelist these scripts by adding their parent executable paths to the exclusion list.\n- Backup processes that temporarily mount directories for data transfer can be mistaken for suspicious activity. Identify these processes and exclude their parent executables to prevent false alerts.\n- Software installations or updates that require mounting filesystems in user directories might be flagged. Verify these activities and add the responsible parent executables to the exclusion criteria.\n- Development tools that use temporary mounts for testing purposes can generate false positives. Recognize these tools and exclude their parent executables to reduce noise.\n- Custom administrative scripts that perform legitimate mounting operations should be reviewed and, if deemed safe, their parent executables should be added to the exclusion list.\n\n### Response and remediation\n\n- Immediately isolate the affected system to prevent further data exfiltration or persistence by disconnecting it from the network.\n- Terminate any suspicious mount processes identified in the alert to halt potential malicious activity.\n- Conduct a thorough review of mounted filesystems and directories to identify and unmount any unauthorized or suspicious mounts.\n- Restore any compromised files or directories from backups, ensuring they are clean and free from malicious modifications.\n- Implement stricter access controls and permissions on sensitive directories like /tmp, /var/tmp, /dev/shm, /home, and /root to prevent unauthorized mounting.\n- Escalate the incident to the security operations team for further investigation and to assess the scope of the threat, including potential lateral movement or additional compromised systems.\n- Enhance monitoring and detection capabilities by configuring alerts for unusual mount activities and integrating threat intelligence feeds to identify similar tactics used by adversaries.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.name == \"mount\" and \nprocess.args like (\"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/home/*\", \"/root/*\", \"/mount\") and process.parent.executable != null and\nnot (\n process.parent.executable like (\"/bin/*\", \"/usr/bin/*\", \"/usr/local/bin/*\", \"/sbin/*\", \"/usr/sbin/*\", \"/usr/local/sbin/*\", \"/usr/libexec/*\") or\n process.parent.name == \"snapd\"\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "68e90a9b-0eab-425e-be3b-902b0cd1fe9c", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "68e90a9b-0eab-425e-be3b-902b0cd1fe9c_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_3.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_3.json new file mode 100644 index 00000000000..824d743a645 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Special Character Overuse", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Special Character Overuse\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's flexibility to obfuscate scripts, using excessive special characters to evade detection. The detection rule identifies scripts with high special character density, indicating potential obfuscation, by analyzing script length and character patterns, thus aiding in uncovering malicious activities.\n\n### Possible investigation steps\n\n- Review the dedup_space_script_block field to understand the script's structure and identify any suspicious patterns or keywords that might indicate obfuscation techniques.\n- Analyze the replaced_with_fire field to assess the density and distribution of special characters, which can provide insights into the obfuscation methods used.\n- Examine the file.path and host.name fields to determine the origin and context of the script execution, which can help identify if the script was run on a critical system or by a privileged user.\n- Check the user.id and agent.id fields to verify the identity of the user or agent executing the script, which can help assess if the activity aligns with expected behavior or if it might be unauthorized.\n- Correlate the powershell.file.script_block_id with other logs or alerts to identify if similar scripts have been executed elsewhere in the environment, indicating a broader attack pattern.\n\n### False positive analysis\n\n- Scripts with legitimate use of special characters for formatting or encoding may trigger false positives. Review the script's purpose and context to determine if the use of special characters is justified.\n- Automated scripts that heavily rely on string manipulation or dynamic content generation might be flagged. Consider adding exceptions for known scripts or trusted sources to reduce unnecessary alerts.\n- PowerShell scripts used in development or testing environments often contain high special character density. Implement environment-based exclusions to prevent these from being flagged in non-production settings.\n- Scripts utilizing SecureString or other security-related encoding methods may appear obfuscated. Verify the script's origin and purpose, and whitelist these methods if they are part of standard security practices.\n- Regularly update the detection rule to refine the pattern matching and reduce false positives by incorporating feedback from security analysts and system administrators.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated metadata to understand the intent and potential impact of the obfuscated script.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Replace repeated spaces used for formatting after a new line with a single space to reduce FPs\n| EVAL dedup_space_script_block = REPLACE(powershell.file.script_block_text, \"\"\"\\n\\s+\"\"\", \"\\n \")\n\n// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(dedup_space_script_block)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(dedup_space_script_block, \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\.]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of numbers and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, dedup_space_script_block, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 75%+ proportion of numbers\n| WHERE proportion > 0.75\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "6ddb6c33-00ce-4acd-832a-24b251512023", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "6ddb6c33-00ce-4acd-832a-24b251512023_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_113.json b/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_113.json new file mode 100644 index 00000000000..8b36c410dd5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_113.json @@ -0,0 +1,118 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Adversaries may install legitimate remote access tools (RAT) to compromised endpoints for further command-and-control (C2). Adversaries can rely on installed RATs for persistence, execution of native commands and more. This rule detects when a process is started whose name or code signature resembles commonly abused RATs. This is a New Terms rule type indicating the host has not seen this RAT process started before within the last 30 days.", + "from": "now-9m", + "history_window_start": "now-15d", + "index": [ + "logs-endpoint.events.process-*", + "endgame-*", + "winlogbeat-*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "logs-system.security*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "First Time Seen Commonly Abused Remote Access Tool Execution", + "new_terms_fields": [ + "host.id" + ], + "note": "## Triage and analysis\n\n### Investigating First Time Seen Commonly Abused Remote Access Tool Execution\n\nRemote access software is a class of tools commonly used by IT departments to provide support by connecting securely to users' computers. Remote access is an ever-growing market where new companies constantly offer new ways of quickly accessing remote systems.\n\nAt the same pace as IT departments adopt these tools, the attackers also adopt them as part of their workflow to connect into an interactive session, maintain access with legitimate software as a persistence mechanism, drop malicious software, etc.\n\nThis rule detects when a remote access tool is seen in the environment for the first time in the last 15 days, enabling analysts to investigate and enforce the correct usage of such tools.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Check if the execution of the remote access tool is approved by the organization's IT department.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n - If the tool is not approved for use in the organization, the employee could have been tricked into installing it and providing access to a malicious third party. Investigate whether this third party could be attempting to scam the end-user or gain access to the environment through social engineering.\n- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.\n\n### False positive analysis\n\n- If an authorized support person or administrator used the tool to conduct legitimate support or remote access, consider reinforcing that only tooling approved by the IT policy should be used. The analyst can dismiss the alert if no other suspicious behavior is observed involving the host or users.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Run a full scan using the antimalware tool in place. This scan can reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- If an unauthorized third party did the access via social engineering, consider improvements to the security awareness program.\n- Enforce that only tooling approved by the IT policy should be used for remote access purposes and only by authorized staff.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "host.os.type: \"windows\" and\n\n event.category: \"process\" and event.type : \"start\" and\n\n (\n process.code_signature.subject_name : (\n \"Action1 Corporation\" or\n \"AeroAdmin LLC\" or\n \"Ammyy LLC\" or\n \"Atera Networks Ltd\" or\n \"AWERAY PTE. LTD.\" or\n \"BeamYourScreen GmbH\" or\n \"Bomgar Corporation\" or\n \"DUC FABULOUS CO.,LTD\" or\n \"DOMOTZ INC.\" or\n \"DWSNET O\u00dc\" or\n \"FleetDeck Inc\" or\n \"GlavSoft LLC\" or\n \"GlavSoft LLC.\" or\n \"Hefei Pingbo Network Technology Co. Ltd\" or\n \"IDrive, Inc.\" or\n \"IMPERO SOLUTIONS LIMITED\" or\n \"Instant Housecall\" or\n \"ISL Online Ltd.\" or\n \"LogMeIn, Inc.\" or\n \"Monitoring Client\" or\n \"MMSOFT Design Ltd.\" or\n \"Nanosystems S.r.l.\" or\n \"NetSupport Ltd\" or \n\t \"NetSupport Ltd.\" or \n\t \"NETSUPPORT LTD.\" or \n \"NinjaRMM, LLC\" or\n \"Parallels International GmbH\" or\n \"philandro Software GmbH\" or\n \"Pro Softnet Corporation\" or\n \"RealVNC\" or\n \"RealVNC Limited\" or\n \"BreakingSecurity.net\" or\n \"Remote Utilities LLC\" or\n \"Rocket Software, Inc.\" or\n \"SAFIB\" or\n \"Servably, Inc.\" or\n \"ShowMyPC INC\" or\n \"Splashtop Inc.\" or\n \"Superops Inc.\" or\n \"TeamViewer\" or\n \"TeamViewer GmbH\" or\n \"TeamViewer Germany GmbH\" or\n \"Techinline Limited\" or\n \"uvnc bvba\" or\n \"Yakhnovets Denis Aleksandrovich IP\" or\n \"Zhou Huabing\"\n ) or\n\n process.name.caseless : (\n AA_v*.exe or\n \"AeroAdmin.exe\" or\n \"AnyDesk.exe\" or\n \"apc_Admin.exe\" or\n \"apc_host.exe\" or\n \"AteraAgent.exe\" or\n aweray_remote*.exe or\n \"AweSun.exe\" or\n \"B4-Service.exe\" or\n \"BASupSrvc.exe\" or\n \"bomgar-scc.exe\" or\n \"domotzagent.exe\" or\n \"domotz-windows-x64-10.exe\" or\n \"dwagsvc.exe\" or\n \"DWRCC.exe\" or\n \"ImperoClientSVC.exe\" or\n \"ImperoServerSVC.exe\" or\n \"ISLLight.exe\" or\n \"ISLLightClient.exe\" or\n fleetdeck_commander*.exe or\n \"getscreen.exe\" or\n \"LMIIgnition.exe\" or\n \"LogMeIn.exe\" or\n \"ManageEngine_Remote_Access_Plus.exe\" or\n \"Mikogo-Service.exe\" or\n \"NinjaRMMAgent.exe\" or\n \"NinjaRMMAgenPatcher.exe\" or\n \"ninjarmm-cli.exe\" or\n \"r_server.exe\" or\n \"radmin.exe\" or\n \"radmin3.exe\" or\n \"RCClient.exe\" or\n \"RCService.exe\" or\n \"RemoteDesktopManager.exe\" or\n \"RemotePC.exe\" or\n \"RemotePCDesktop.exe\" or\n \"RemotePCService.exe\" or\n \"rfusclient.exe\" or\n \"ROMServer.exe\" or\n \"ROMViewer.exe\" or\n \"RPCSuite.exe\" or\n \"rserver3.exe\" or\n \"rustdesk.exe\" or\n \"rutserv.exe\" or\n \"rutview.exe\" or\n \"saazapsc.exe\" or\n ScreenConnect*.exe or\n \"smpcview.exe\" or\n \"spclink.exe\" or\n \"Splashtop-streamer.exe\" or\n \"SRService.exe\" or\n \"strwinclt.exe\" or\n \"Supremo.exe\" or\n \"SupremoService.exe\" or\n \"teamviewer.exe\" or\n \"TiClientCore.exe\" or\n \"TSClient.exe\" or\n \"tvn.exe\" or\n \"tvnserver.exe\" or\n \"tvnviewer.exe\" or\n UltraVNC*.exe or\n UltraViewer*.exe or\n \"vncserver.exe\" or\n \"vncviewer.exe\" or\n \"winvnc.exe\" or\n \"winwvc.exe\" or\n \"Zaservice.exe\" or\n \"ZohoURS.exe\"\n ) or\n process.name : (\n AA_v*.exe or\n \"AeroAdmin.exe\" or\n \"AnyDesk.exe\" or\n \"apc_Admin.exe\" or\n \"apc_host.exe\" or\n \"AteraAgent.exe\" or\n aweray_remote*.exe or\n \"AweSun.exe\" or\n \"B4-Service.exe\" or\n \"BASupSrvc.exe\" or\n \"bomgar-scc.exe\" or\n \"domotzagent.exe\" or\n \"domotz-windows-x64-10.exe\" or\n \"dwagsvc.exe\" or\n \"DWRCC.exe\" or\n \"ImperoClientSVC.exe\" or\n \"ImperoServerSVC.exe\" or\n \"ISLLight.exe\" or\n \"ISLLightClient.exe\" or\n fleetdeck_commander*.exe or\n \"getscreen.exe\" or\n \"LMIIgnition.exe\" or\n \"LogMeIn.exe\" or\n \"ManageEngine_Remote_Access_Plus.exe\" or\n \"Mikogo-Service.exe\" or\n \"NinjaRMMAgent.exe\" or\n \"NinjaRMMAgenPatcher.exe\" or\n \"ninjarmm-cli.exe\" or\n \"r_server.exe\" or\n \"radmin.exe\" or\n \"radmin3.exe\" or\n \"RCClient.exe\" or\n \"RCService.exe\" or\n \"RemoteDesktopManager.exe\" or\n \"RemotePC.exe\" or\n \"RemotePCDesktop.exe\" or\n \"RemotePCService.exe\" or\n \"rfusclient.exe\" or\n \"ROMServer.exe\" or\n \"ROMViewer.exe\" or\n \"RPCSuite.exe\" or\n \"rserver3.exe\" or\n \"rustdesk.exe\" or\n \"rutserv.exe\" or\n \"rutview.exe\" or\n \"saazapsc.exe\" or\n ScreenConnect*.exe or\n \"smpcview.exe\" or\n \"spclink.exe\" or\n \"Splashtop-streamer.exe\" or\n \"SRService.exe\" or\n \"strwinclt.exe\" or\n \"Supremo.exe\" or\n \"SupremoService.exe\" or\n \"teamviewer.exe\" or\n \"TiClientCore.exe\" or\n \"TSClient.exe\" or\n \"tvn.exe\" or\n \"tvnserver.exe\" or\n \"tvnviewer.exe\" or\n UltraVNC*.exe or\n UltraViewer*.exe or\n \"vncserver.exe\" or\n \"vncviewer.exe\" or\n \"winvnc.exe\" or\n \"winwvc.exe\" or\n \"Zaservice.exe\" or\n \"ZohoURS.exe\"\n )\n\t) and\n\n\tnot (process.pe.original_file_name : (\"G2M.exe\" or \"Updater.exe\" or \"powershell.exe\") and process.code_signature.subject_name : \"LogMeIn, Inc.\")\n", + "references": [ + "https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/", + "https://attack.mitre.org/techniques/T1219/", + "https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.subject_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "process.name.caseless", + "type": "unknown" + }, + { + "ecs": true, + "name": "process.pe.original_file_name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6e1a2cc4-d260-11ed-8829-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Windows Security Event Logs", + "Data Source: Sysmon" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1219", + "name": "Remote Access Tools", + "reference": "https://attack.mitre.org/techniques/T1219/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 113 + }, + "id": "6e1a2cc4-d260-11ed-8829-f661ea17fbcc_113", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e2355cc-c60a-4d92-a80c-e54a45ad2400_2.json b/packages/security_detection_engine/kibana/security_rule/6e2355cc-c60a-4d92-a80c-e54a45ad2400_2.json deleted file mode 100644 index 0192c5b29d5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6e2355cc-c60a-4d92-a80c-e54a45ad2400_2.json +++ /dev/null @@ -1,121 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects the creation of Loadable Kernel Module (LKM) configuration files. Attackers may create or modify these files to allow their LKMs to be loaded upon reboot, ensuring persistence on a compromised system.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.file*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Loadable Kernel Module Configuration File Creation", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Loadable Kernel Module Configuration File Creation\n\nLoadable Kernel Modules (LKMs) are components that can be dynamically loaded into the Linux kernel to extend its functionality without rebooting. Adversaries exploit this by creating or altering LKM configuration files to ensure their malicious modules load at startup, achieving persistence. The detection rule identifies suspicious file creation or renaming activities in key directories, excluding benign processes, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the file path and name to determine if it matches any known or expected LKM configuration files, focusing on paths like /etc/modules, /etc/modprobe.d/*, and others specified in the query.\n- Examine the process executable responsible for the file creation or renaming to identify if it is a known or trusted application, especially if it is not in the list of excluded executables.\n- Check the process name and executable path for any anomalies or signs of masquerading, particularly if they are not in the list of excluded names or paths.\n- Investigate the user account associated with the process to determine if it has legitimate access or if it might be compromised.\n- Correlate the event with other recent system activities to identify any patterns or additional suspicious behavior, such as other file modifications or network connections.\n- Review system logs for any related entries that might provide additional context or evidence of malicious activity.\n- Assess the risk and impact of the detected activity on the system's security posture and determine if further containment or remediation actions are necessary.\n\n### False positive analysis\n\n- System package managers like dpkg, rpm, and yum may trigger false positives when they update or install legitimate kernel modules. To handle this, exclude these processes by adding them to the exception list in the detection rule.\n- Automated system management tools such as Puppet, Chef, and Ansible can create or modify LKM configuration files during routine operations. Exclude these processes by specifying their executables in the exception criteria.\n- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for suspicious activity. Exclude these file extensions to reduce false positives.\n- Processes running from specific directories like /nix/store or /snap may be part of legitimate software installations. Add these paths to the exclusion list to prevent unnecessary alerts.\n- Scheduled tasks or cron jobs that involve file operations in the monitored directories might be flagged. Identify and exclude these processes by their names or paths to minimize false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further propagation of the malicious loadable kernel module.\n- Terminate any suspicious processes identified in the alert that are associated with the creation or modification of LKM configuration files.\n- Remove or revert any unauthorized changes to LKM configuration files in the specified directories to prevent the malicious module from loading on reboot.\n- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components.\n- Review system logs and the history of executed commands to identify the initial vector of compromise and any other affected systems.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.\n- Implement additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents.", - "query": "file where host.os.type == \"linux\" and event.action in (\"rename\", \"creation\") and process.executable != null and\nfile.path like~ (\n \"/etc/modules\", \"/etc/modprobe.d/*\", \"/usr/lib/modprobe.d/*\", \"/etc/modules-load.d/*\",\n \"/run/modules-load.d/*\", \"/usr/local/lib/modules-load.d/*\", \"/usr/lib/modules-load.d/*\"\n) and not (\n process.executable in (\n \"/bin/dpkg\", \"/usr/bin/dpkg\", \"/bin/dockerd\", \"/usr/bin/dockerd\", \"/usr/sbin/dockerd\", \"/bin/microdnf\",\n \"/usr/bin/microdnf\", \"/bin/rpm\", \"/usr/bin/rpm\", \"/bin/snapd\", \"/usr/bin/snapd\", \"/bin/yum\", \"/usr/bin/yum\",\n \"/bin/dnf\", \"/usr/bin/dnf\", \"/bin/podman\", \"/usr/bin/podman\", \"/bin/dnf-automatic\", \"/usr/bin/dnf-automatic\",\n \"/bin/pacman\", \"/usr/bin/pacman\", \"/usr/bin/dpkg-divert\", \"/bin/dpkg-divert\", \"/sbin/apk\", \"/usr/sbin/apk\",\n \"/usr/local/sbin/apk\", \"/usr/bin/apt\", \"/usr/sbin/pacman\", \"/bin/podman\", \"/usr/bin/podman\", \"/usr/bin/puppet\",\n \"/bin/puppet\", \"/opt/puppetlabs/puppet/bin/puppet\", \"/usr/bin/chef-client\", \"/bin/chef-client\",\n \"/bin/autossl_check\", \"/usr/bin/autossl_check\", \"/proc/self/exe\", \"/dev/fd/*\", \"/usr/bin/pamac-daemon\",\n \"/bin/pamac-daemon\", \"/usr/local/bin/dockerd\", \"/opt/elasticbeanstalk/bin/platform-engine\",\n \"/opt/puppetlabs/puppet/bin/ruby\", \"/usr/libexec/platform-python\", \"/opt/imunify360/venv/bin/python3\",\n \"/opt/eset/efs/lib/utild\", \"/usr/sbin/anacron\", \"/usr/bin/podman\", \"/kaniko/kaniko-executor\", \"/usr/bin/prime-select\"\n ) or\n file.extension in (\"swp\", \"swpx\", \"swx\", \"dpkg-remove\") or\n file.Ext.original.extension == \"dpkg-new\" or\n process.executable like (\n \"/nix/store/*\", \"/var/lib/dpkg/info/kmod.postinst\", \"/tmp/vmis.*\", \"/snap/*\", \"/dev/fd/*\",\n \"/usr/libexec/platform-python*\"\n ) or\n process.executable == null or\n process.name in (\n \"crond\", \"executor\", \"puppet\", \"droplet-agent.postinst\", \"cf-agent\", \"schedd\", \"imunify-notifier\", \"perl\",\n \"jumpcloud-agent\", \"crio\", \"dnf_install\", \"utild\"\n ) or\n (process.name == \"sed\" and file.name : \"sed*\") or\n (process.name == \"perl\" and file.name : \"e2scrub_all.tmp*\")\n)\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": false, - "name": "file.Ext.original.extension", - "type": "unknown" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "6e2355cc-c60a-4d92-a80c-e54a45ad2400", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1547", - "name": "Boot or Logon Autostart Execution", - "reference": "https://attack.mitre.org/techniques/T1547/", - "subtechnique": [ - { - "id": "T1547.006", - "name": "Kernel Modules and Extensions", - "reference": "https://attack.mitre.org/techniques/T1547/006/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1014", - "name": "Rootkit", - "reference": "https://attack.mitre.org/techniques/T1014/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 2 - }, - "id": "6e2355cc-c60a-4d92-a80c-e54a45ad2400_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6eb862bb-013d-4d4f-a14b-341433ca1a1f_2.json b/packages/security_detection_engine/kibana/security_rule/6eb862bb-013d-4d4f-a14b-341433ca1a1f_2.json new file mode 100644 index 00000000000..2248a1f89a4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6eb862bb-013d-4d4f-a14b-341433ca1a1f_2.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the execution of unusual commands via a descendant process of exim4. Attackers may use descendant processes of exim4 to evade detection and establish persistence or execute post-exploitation commands on a target system.", + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual Exim4 Child Process", + "new_terms_fields": [ + "process.executable" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Exim4 Child Process\n\nExim4 is a widely used mail transfer agent on Linux systems, responsible for routing and delivering email. Adversaries may exploit Exim4 by spawning unexpected child processes to execute malicious commands, thereby evading detection and maintaining persistence. The detection rule identifies suspicious child processes initiated by Exim4, excluding known legitimate processes, to flag potential misuse.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific unusual child process name and command line arguments that were executed under the parent process exim4.\n- Examine the process tree to understand the hierarchy and context of the spawned process, including any sibling or child processes that may indicate further malicious activity.\n- Check the user account associated with the exim4 process to determine if it aligns with expected usage patterns or if it might be compromised.\n- Investigate the source and destination of any network connections initiated by the unusual child process to identify potential data exfiltration or command and control activity.\n- Analyze system logs around the time of the alert to identify any related events or anomalies that could provide additional context or evidence of compromise.\n- Correlate the findings with other alerts or incidents in the environment to determine if this activity is part of a broader attack campaign.\n\n### False positive analysis\n\n- Development tools like cmake, gcc, and cppcheck may trigger false positives if they are used in environments where Exim4 is installed. To mitigate this, ensure these tools are included in the exclusion list if they are part of regular development activities.\n- System maintenance scripts that utilize commands such as readlink, grep, and stat might be flagged. Review these scripts and add them to the exclusion list if they are verified as part of routine system operations.\n- Automated deployment or configuration management tools that invoke systemctl or update-exim4.conf can be mistaken for suspicious activity. Confirm these processes are legitimate and add them to the exclusion list to prevent unnecessary alerts.\n- If Exim4 is used in conjunction with SSH services, processes like sshd may appear as child processes. Verify the legitimacy of these connections and exclude them if they are part of expected behavior.\n- Regularly review and update the exclusion list to reflect changes in system operations or new legitimate processes that may arise, ensuring the rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious child processes of Exim4 that are not recognized as legitimate, using process management tools like `kill` or `pkill`.\n- Conduct a thorough review of the Exim4 configuration files and scripts to identify unauthorized modifications or additions, and restore them from a known good backup if necessary.\n- Scan the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts found.\n- Apply security patches and updates to Exim4 and the operating system to mitigate known vulnerabilities that could be exploited by attackers.\n- Monitor the system for any recurrence of unusual Exim4 child processes and adjust logging and alerting to capture detailed information for further analysis.\n- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems in the network may be affected.\n", + "query": "host.os.type:linux and event.type:start and event.action:exec and process.parent.name:exim4 and\nnot process.name:(\n exim4 or start-stop-daemon or run-parts or systemctl or update-exim4.conf or install or plymouth or\n readlink or grep or stat or cmake or gcc or cppcheck or sort or sshd\n)\n", + "references": [ + "https://www.qualys.com/2021/05/04/21nails/21nails.txt", + "https://blog.qualys.com/vulnerabilities-threat-research/2021/05/04/21nails-multiple-vulnerabilities-in-exim-mail-server" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "6eb862bb-013d-4d4f-a14b-341433ca1a1f", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1037", + "name": "Boot or Logon Initialization Scripts", + "reference": "https://attack.mitre.org/techniques/T1037/" + }, + { + "id": "T1554", + "name": "Compromise Host Software Binary", + "reference": "https://attack.mitre.org/techniques/T1554/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "6eb862bb-013d-4d4f-a14b-341433ca1a1f_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_112.json b/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_112.json new file mode 100644 index 00000000000..f3c1d9252b5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_112.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Linux Tunneling and/or Port Forwarding", + "note": "## Triage and analysis\n\n### Investigating Potential Linux Tunneling and/or Port Forwarding\n\nAttackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems.\n\nThis rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. \n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n#### Possible investigation steps\n\n- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior.\n - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Process Info\",\"query\":\"SELECT name, cmdline, parent, path, uid FROM processes\"}}\n- Investigate other alerts associated with the user/host during the past 48 hours.\n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n\n### Related rules\n\n- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd\n- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f\n- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769\n- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4\n- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37\n\n### False positive analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and (\n (\n // gost & pivotnacci - spawned without process.parent.name\n (process.name == \"gost\" and process.args : (\"-L*\", \"-C*\", \"-R*\")) or (process.name == \"pivotnacci\")) or (\n // ssh\n (process.name == \"ssh\" and (process.args in (\"-R\", \"-L\", \"-D\", \"-w\") and process.args_count >= 4 and \n not process.args : \"chmod\")) or\n // sshuttle\n (process.name == \"sshuttle\" and process.args in (\"-r\", \"--remote\", \"-l\", \"--listen\") and process.args_count >= 4) or\n // socat\n (process.name == \"socat\" and process.args : (\"TCP4-LISTEN:*\", \"SOCKS*\") and process.args_count >= 3) or\n // chisel\n (process.name : \"chisel*\" and process.args in (\"client\", \"server\")) or\n // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok \n (process.name in (\"iodine\", \"iodined\", \"dnscat\", \"hans\", \"hans-ubuntu\", \"ptunnel-ng\", \"ssf\", \"3proxy\", \"ngrok\"))\n ) and process.parent.name in (\"bash\", \"dash\", \"ash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")\n)\n", + "references": [ + "https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform", + "https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6ee947e9-de7e-4281-a55d-09289bdf947e", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1572", + "name": "Protocol Tunneling", + "reference": "https://attack.mitre.org/techniques/T1572/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 112 + }, + "id": "6ee947e9-de7e-4281-a55d-09289bdf947e_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/70089609-c41a-438e-b132-5b3b43c5fc07_2.json b/packages/security_detection_engine/kibana/security_rule/70089609-c41a-438e-b132-5b3b43c5fc07_2.json new file mode 100644 index 00000000000..a744305970b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/70089609-c41a-438e-b132-5b3b43c5fc07_2.json @@ -0,0 +1,103 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of git to clone a repository or download files from GitHub using wget or curl, followed by the creation of files in suspicious directories such as /tmp, /var/tmp, or /dev/shm. This behavior may indicate an attempt to download a payload, exploit or tool.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Git Repository or File Download to Suspicious Directory", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Git Repository or File Download to Suspicious Directory\n\nGit, wget, and curl are essential tools for managing and transferring files in Linux environments. Adversaries exploit these tools to download malicious payloads into temporary directories like /tmp, /var/tmp, or /dev/shm, which are often overlooked. The detection rule identifies this behavior by monitoring for git clone commands or GitHub downloads followed by file creation in these directories, signaling potential threats.\n\n### Possible investigation steps\n\n- Review the process details, including process.entity_id and process.name, to confirm the execution of git, wget, or curl commands and verify if they align with expected usage patterns.\n- Examine the process.command_line field to identify the specific GitHub URL or repository being accessed, and assess whether it is known or potentially malicious.\n- Check the file creation event details, focusing on the file.path to determine the exact location and nature of the files created in /tmp, /var/tmp, or /dev/shm directories.\n- Investigate the host.id and host.os.type to gather additional context about the affected system, including its role and any recent changes or anomalies.\n- Correlate the timing of the process start and file creation events to understand the sequence of actions and identify any potential patterns or anomalies.\n- Consult threat intelligence sources to determine if the accessed GitHub repository or downloaded files are associated with known threats or malicious activity.\n\n### False positive analysis\n\n- Development activities may trigger this rule when developers clone repositories or download files from GitHub into temporary directories for testing purposes. To manage this, create exceptions for specific user accounts or processes that are known to perform legitimate development tasks.\n- Automated scripts or cron jobs that regularly update or download files from GitHub into temporary directories can also cause false positives. Identify these scripts and exclude their process IDs or command patterns from the rule.\n- System maintenance tasks that involve downloading updates or patches into temporary directories might be flagged. Coordinate with system administrators to identify these tasks and whitelist the associated processes or directories.\n- Security tools or monitoring solutions that download threat intelligence feeds or other data into temporary directories could be mistakenly identified. Verify these tools and exclude their activities from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system to prevent further potential malicious activity and lateral movement within the network.\n- Terminate any suspicious processes related to git, wget, or curl that are actively running and associated with the creation of files in the /tmp, /var/tmp, or /dev/shm directories.\n- Conduct a thorough examination of the files created in these directories to identify and remove any malicious payloads or tools.\n- Restore any compromised files or systems from clean backups to ensure the integrity of the affected system.\n- Implement network monitoring to detect and block any unauthorized outbound connections to suspicious domains, particularly those related to GitHub or other code repositories.\n- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected.\n- Update endpoint protection and intrusion detection systems to enhance detection capabilities for similar threats, focusing on the specific indicators of compromise identified in this alert.\n", + "query": "sequence by process.entity_id, host.id with maxspan=10s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n (process.name == \"git\" and process.args == \"clone\") or\n (process.name in (\"wget\", \"curl\") and process.command_line like~ \"*github*\")\n )]\n [file where host.os.type == \"linux\" and event.type == \"creation\" and file.path like (\"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\")]\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "70089609-c41a-438e-b132-5b3b43c5fc07", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\nElastic Defend integration does not collect environment variable logging by default.\nIn order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.\n #### To set up environment variable capture for an Elastic Agent policy:\n- Go to \u201cSecurity \u2192 Manage \u2192 Policies\u201d.\n- Select an \u201cElastic Agent policy\u201d.\n- Click \u201cShow advanced settings\u201d.\n- Scroll down or search for \u201clinux.advanced.capture_env_vars\u201d.\n- Enter the names of environment variables you want to capture, separated by commas.\n- For this rule the linux.advanced.capture_env_vars variable should be set to \"HTTP_PROXY,HTTPS_PROXY,ALL_PROXY\".\n- Click \u201cSave\u201d.\nAfter saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.\nFor more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "type": "eql", + "version": 2 + }, + "id": "70089609-c41a-438e-b132-5b3b43c5fc07_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_9.json b/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_9.json new file mode 100644 index 00000000000..5ef44f0dde0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_9.json @@ -0,0 +1,110 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine.", + "false_positives": [ + "Some container images require the addition of privileged capabilities. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image." + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Container Created with Excessive Linux Capabilities", + "note": "## Triage and analysis\n\n### Investigating Kubernetes Container Created with Excessive Linux Capabilities\n\nLinux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change\ncore processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques:\n\nBPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.\nDAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks.\nNET_ADMIN - Perform various network-related operations.\nSYS_ADMIN - Perform a range of system administration operations.\nSYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.\nSYS_MODULE - Load and unload kernel modules.\nSYS_PTRACE - Trace arbitrary processes using ptrace(2).\nSYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)).\nSYSLOG - Perform privileged syslog(2) operations.\n\n### False positive analysis\n\n- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image.", + "query": "event.dataset: kubernetes.audit_logs\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb: create\n and kubernetes.audit.objectRef.resource: pods\n and kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: (\"BPF\" or \"DAC_READ_SEARCH\" or \"NET_ADMIN\" or \"SYS_ADMIN\" or \"SYS_BOOT\" or \"SYS_MODULE\" or \"SYS_PTRACE\" or \"SYS_RAWIO\" or \"SYSLOG\")\n and not kubernetes.audit.requestObject.spec.containers.image : (\"docker.elastic.co/beats/elastic-agent:8.4.0\" or \"rancher/klipper-lb:v0.3.5\" or \"\")\n", + "references": [ + "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container", + "https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities", + "https://man7.org/linux/man-pages/man7/capabilities.7.html", + "https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.image", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "7164081a-3930-11ed-a261-0242ac120002", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 9 + }, + "id": "7164081a-3930-11ed-a261-0242ac120002_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_320.json b/packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_320.json new file mode 100644 index 00000000000..2ece1fbf406 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_320.json @@ -0,0 +1,121 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies suspicious creation of Alternate Data Streams on highly targeted files. This is uncommon for legitimate files and sometimes done by adversaries to hide malware.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.file-*", + "logs-windows.sysmon_operational-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "endgame-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Unusual File Creation - Alternate Data Stream", + "note": "## Triage and analysis\n\n### Investigating Unusual File Creation - Alternate Data Stream\n\nAlternate Data Streams (ADS) are file attributes only found on the NTFS file system. In this file system, files are built up from a couple of attributes; one of them is $Data, also known as the data attribute.\n\nThe regular data stream, also referred to as the unnamed data stream since the name string of this attribute is empty, contains the data inside the file. So any data stream that has a name is considered an alternate data stream.\n\nAttackers can abuse these alternate data streams to hide malicious files, string payloads, etc. This rule detects the creation of alternate data streams on highly targeted file types.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Retrieve the contents of the alternate data stream, and analyze it for potential maliciousness. Analysts can use the following PowerShell cmdlet to accomplish this:\n - `Get-Content C:\\Path\\To\\file.exe -stream SampleAlternateDataStreamName`\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- If this activity is expected and noisy in your environment, consider adding exceptions \u2014 preferably with a combination of process executable and file conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "file where host.os.type == \"windows\" and event.type == \"creation\" and\n\n file.path : \"C:\\\\*:*\" and file.extension in~ (\n \"pdf\", \"dll\", \"exe\", \"dat\", \"com\", \"bat\", \"cmd\", \"sys\", \"vbs\", \"ps1\", \"hta\", \"txt\", \"vbe\", \"js\",\n \"wsh\", \"docx\", \"doc\", \"xlsx\", \"xls\", \"pptx\", \"ppt\", \"rtf\", \"gif\", \"jpg\", \"png\", \"bmp\", \"img\", \"iso\"\n ) and\n\n not file.path : \n (\"C:\\\\*:zone.identifier*\",\n \"C:\\\\users\\\\*\\\\appdata\\\\roaming\\\\microsoft\\\\teams\\\\old_weblogs_*:$DATA\",\n \"C:\\\\Windows\\\\CSC\\\\*:CscBitmapStream\") and\n\n not process.executable : (\n \"?:\\\\Program Files (x86)\\\\Dropbox\\\\Client\\\\Dropbox.exe\",\n \"?:\\\\Program Files (x86)\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\EXCEL.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\OUTLOOK.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\POWERPNT.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\WINWORD.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft\\\\Edge\\\\Application\\\\msedge.exe\",\n \"?:\\\\Program Files\\\\ExpressConnect\\\\ExpressConnectNetworkService.exe\",\n \"?:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\EXCEL.EXE\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\OUTLOOK.EXE\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\POWERPNT.EXE\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\WINWORD.EXE\",\n \"?:\\\\Program Files\\\\Mozilla Firefox\\\\firefox.exe\",\n \"?:\\\\Program Files\\\\Windows Defender Advanced Threat Protection\\\\MsSense.exe\",\n \"?:\\\\Program Files\\\\Rivet Networks\\\\SmartByte\\\\SmartByteNetworkService.exe\",\n \"?:\\\\Windows\\\\explorer.exe\",\n \"?:\\\\Windows\\\\System32\\\\DataExchangeHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\drivers\\\\Intel\\\\ICPS\\\\IntelConnectivityNetworkService.exe\",\n \"?:\\\\Windows\\\\System32\\\\drivers\\\\RivetNetworks\\\\Killer\\\\KillerNetworkService.exe\",\n \"?:\\\\Windows\\\\System32\\\\inetsrv\\\\w3wp.exe\",\n \"?:\\\\Windows\\\\System32\\\\PickerHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\RuntimeBroker.exe\",\n \"?:\\\\Windows\\\\System32\\\\SearchProtocolHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\sihost.exe\",\n \"?:\\\\windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\WFS.exe\"\n ) and\n \n not (\n ?process.code_signature.trusted == true and\n file.name : \"*:sec.endpointdlp:$DATA\"\n )\n\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.extension", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.trusted", + "type": "boolean" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "71bccb61-e19b-452f-b104-79a60e546a95", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Data Source: Elastic Endgame" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/", + "subtechnique": [ + { + "id": "T1564.004", + "name": "NTFS File Attributes", + "reference": "https://attack.mitre.org/techniques/T1564/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 320 + }, + "id": "71bccb61-e19b-452f-b104-79a60e546a95_320", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/72c91fc0-4ac0-11f0-811f-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/72c91fc0-4ac0-11f0-811f-f661ea17fbcd_1.json new file mode 100644 index 00000000000..e71ce6f870c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/72c91fc0-4ac0-11f0-811f-f661ea17fbcd_1.json @@ -0,0 +1,141 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "filebeat-*", + "logs-azure.signinlogs-*" + ], + "investigation_fields": { + "field_names": [ + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.device_detail.device_id", + "azure.signinlogs.properties.incoming_token_type", + "azure.signinlogs.category", + "source.geo.country_name", + "source.geo.city_name", + "source.address", + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.resource_id", + "azure.signinlogs.properties.risk_level", + "azure.signinlogs.properties.risk_detail" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Entra ID User Signed In from Unusual Device", + "new_terms_fields": [ + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.device_detail.device_id" + ], + "note": "## Triage and analysis\n\n### Investigating Entra ID User Signed In from Unusual Device\n\nThis rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access.\n\n### Possible investigation steps\n- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user associated with the sign-in.\n- Check the `azure.signinlogs.properties.device_detail.device_id` field to identify the device used for the sign-in.\n- Review `azure.signinlogs.properties.incoming_token_type` to determine what tpe of security token was used for the sign-in, such as a Primary Refresh Token (PRT).\n- Examine `azure.signinlogs.category` to determine if these were non-interactive or interactive sign-ins.\n- Check the geolocation of the sign-in by reviewing `source.geo.country_name` and `source.geo.city_name` to identify the location of the device used for the sign-in. If these are unusual for the user, it may indicate a potential compromise.\n- Review `azure.signinlogs.properties.app_id` to determine which client application was used for the sign-in. If the application is not recognized or expected, it may indicate unauthorized access. Adversaries use first-party client IDs to blend in with legitimate traffic.\n- Examine `azure.signinlogs.properties.resource_id` to determine what resource the security token has in scope and/or is requesting access to. If the resource is not recognized or expected, it may indicate unauthorized access. Excessive access to Graph API is common post-compromise behavior.\n- Review the identity protection risk status by checking `azure.signinlogs.properties.risk_level` and `azure.signinlogs.properties.risk_detail` to determine if the sign-in was flagged as risky by Entra ID Protection.\n\n### False positive analysis\n- Legitimate users may sign in from new devices, such as when using a new laptop or mobile device. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or device IDs.\n- Environments where users frequently change devices, such as in a corporate setting with rotating hardware, may generate false positives.\n- Users may use both an endpoint and mobile device for sign-ins, which could trigger this rule.\n\n### Response and remediation\n- If the sign-in is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.\n- Disable the user account temporarily to prevent any potential compromise or unauthorized access.\n- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.\n- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.\n- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.\n- Identify the registered Entra ID device by reviewing `azure.signinlogs.properties.device_detail.display_name` and confirm it is expected for the user or organization. If it is not expected, consider removing the device registration.\n- Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives.\n", + "query": "event.dataset: \"azure.signinlogs\" and\n event.category: \"authentication\" and\n azure.signinlogs.properties.user_type: \"Member\" and\n azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: \"unbound\" and\n not azure.signinlogs.properties.device_detail.device_id: \"\" and\n azure.signinlogs.properties.user_principal_name: *\n", + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.properties.device_detail.device_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.token_protection_status_details.sign_in_session_status", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_principal_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "72c91fc0-4ac0-11f0-811f-f661ea17fbcd", + "setup": "#### Required Microsoft Entra ID Sign-In Logs\nThis rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub.\n", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-in Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.005", + "name": "Device Registration", + "reference": "https://attack.mitre.org/techniques/T1098/005/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "72c91fc0-4ac0-11f0-811f-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_1.json b/packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_1.json new file mode 100644 index 00000000000..ff0f4b6d650 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_1.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule detects the execution of kubectl commands that are commonly used for workload and cluster discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query cluster information, such as namespaces, nodes, pods, deployments, and other resources. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Workload and Cluster Discovery", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\") and\nprocess.name == \"kubectl\" and (\n (process.args in (\"cluster-info\", \"api-resources\", \"api-versions\", \"version\")) or\n (process.args in (\"get\", \"describe\") and process.args in (\n \"namespaces\", \"nodes\", \"pods\", \"pod\", \"deployments\", \"deployment\",\n \"replicasets\", \"statefulsets\", \"daemonsets\", \"services\", \"service\",\n \"ingress\", \"ingresses\", \"endpoints\", \"configmaps\", \"events\", \"svc\",\n \"roles\", \"rolebindings\", \"clusterroles\", \"clusterrolebindings\"\n )\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "auditd_manager", + "version": "^1.18.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "74e5241e-c1a1-4e70-844e-84ee3d73eb7d", + "severity": "low", + "tags": [ + "Domain: Container", + "Domain: Endpoint", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + }, + { + "id": "T1069", + "name": "Permission Groups Discovery", + "reference": "https://attack.mitre.org/techniques/T1069/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "74e5241e-c1a1-4e70-844e-84ee3d73eb7d_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/751b0329-7295-4682-b9c7-4473b99add69_4.json b/packages/security_detection_engine/kibana/security_rule/751b0329-7295-4682-b9c7-4473b99add69_4.json new file mode 100644 index 00000000000..931c298b498 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/751b0329-7295-4682-b9c7-4473b99add69_4.json @@ -0,0 +1,70 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job has identified a spike in group management events for a user, indicating potential privileged access activity. The machine learning has flagged an abnormal rise in group management actions (such as adding or removing users from privileged groups), which could point to an attempt to escalate privileges or unauthorized modifications to group memberships.", + "from": "now-3h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "pad_windows_high_count_group_management_events", + "name": "Spike in Group Management Events", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Spike in Group Management Events\n\nThe detection of spikes in group management events leverages machine learning to monitor and identify unusual patterns in user activities related to group memberships. Adversaries may exploit this by adding or removing users from privileged groups to escalate privileges or alter access controls. The detection rule identifies these anomalies, flagging potential unauthorized modifications indicative of privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the specific user account associated with the spike in group management events to determine if the activity aligns with their typical behavior or role.\n- Check the timeline of the group management events to identify any patterns or sequences that might suggest unauthorized access or privilege escalation attempts.\n- Investigate the source IP addresses and devices used during the group management events to verify if they are consistent with the user's usual access points or if they indicate potential compromise.\n- Examine recent changes to privileged groups, focusing on additions or removals of users, to assess if these modifications were authorized and necessary.\n- Cross-reference the flagged events with any recent support tickets or change requests to confirm if the actions were legitimate and documented.\n- Look for any other related alerts or anomalies in the same timeframe that might indicate a broader security incident or coordinated attack.\n\n### False positive analysis\n\n- Routine administrative tasks can trigger spikes in group management events, such as scheduled user onboarding or offboarding. To manage this, create exceptions for known periods of increased activity.\n- Automated scripts or tools that manage group memberships might cause false positives. Identify these scripts and exclude their activities from the rule's monitoring.\n- Changes in organizational structure, like department mergers, can lead to legitimate spikes. Document these changes and adjust the rule's sensitivity temporarily.\n- Regular audits or compliance checks that involve group membership reviews may appear as anomalies. Schedule these activities and inform the monitoring team to prevent false alerts.\n- High turnover rates in certain departments can result in frequent group changes. Monitor these departments separately and adjust thresholds accordingly.\n\n### Response and remediation\n\n- Immediately isolate the affected user account by disabling it to prevent further unauthorized group management activities.\n- Review and audit recent changes to group memberships, focusing on privileged groups, to identify any unauthorized additions or removals.\n- Revert any unauthorized changes to group memberships to restore the intended access controls.\n- Conduct a thorough investigation to determine the source of the anomaly, including checking for compromised credentials or insider threats.\n- Reset the password for the affected user account and enforce multi-factor authentication to enhance security.\n- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.\n- Implement additional monitoring on the affected account and related privileged groups to detect any further suspicious activities.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/pad" + ], + "related_integrations": [ + { + "package": "pad", + "version": "^0.0.1" + }, + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "751b0329-7295-4682-b9c7-4473b99add69", + "setup": "## Setup\n\nThe rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows.\n\n### Privileged Access Detection Setup\nThe Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Privileged Access Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.\n\n#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Privileged Access Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "type": "machine_learning", + "version": 4 + }, + "id": "751b0329-7295-4682-b9c7-4473b99add69_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_208.json b/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_208.json new file mode 100644 index 00000000000..ed4de38738e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_208.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.", + "false_positives": [ + "An administrator or developer may want to use a pod that runs as root and shares the host's IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Pod Created With HostIPC", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod Created With HostIPC\n\nKubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value \"kubernetes.audit_logs\".\n- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request.\n- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation.\n- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list.\n- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk.\n- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited.\n\n### False positive analysis\n\n- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function.\n- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening.\n- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts.\n- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process.\n- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications.\n- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification.\n- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms.\n- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred.\n- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved.\n- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostIPC:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", + "references": [ + "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", + "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", + "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.image", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.hostIPC", + "type": "boolean" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "764c8437-a581-4537-8060-1fdb0e92c92d", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 208 + }, + "id": "764c8437-a581-4537-8060-1fdb0e92c92d_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_1.json new file mode 100644 index 00000000000..fdeddca21a5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_1.json @@ -0,0 +1,146 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold.", + "false_positives": [ + "Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups." + ], + "from": "now-9m", + "index": [ + "filebeat-*", + "logs-o365.audit-*" + ], + "investigation_fields": { + "field_names": [ + "user.id", + "user.name", + "user.email", + "user.domain", + "event.id", + "event.action", + "event.outcome", + "event.provider", + "source.ip", + "related.ip", + "related.user", + "o365.audit.ClientAppId", + "o365.audit.AppId", + "o365.audit.AppAccessContext.UniqueTokenId", + "o365.audit.OperationCount", + "o365.audit.MailboxOwnerUPN", + "o365.audit.MailboxOwnerSid", + "o365.audit.MailboxGuid", + "o365.audit.UserKey", + "o365.audit.LogonUserSid", + "o365.audit.TokenTenantId", + "o365.audit.OriginatingServer", + "o365.audit.ClientInfoString", + "o365.audit.CreationTime", + "o365.audit.ResultStatus", + "source.geo.country_iso_code", + "source.geo.country_name", + "source.geo.continent_name", + "source.geo.location", + "cloud.account.id", + "cloud.provider", + "cloud.region", + "cloud.service.name" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Excessive Microsoft 365 Mailbox Items Accessed", + "note": "## Triage and analysis\n\n### Investigating Excessive Microsoft 365 Mailbox Items Accessed\n\nIdentifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold.\n\n### Possible investigation steps\n- Review `host.name` to identify the tenant where the mailbox access occurred.\n- Review `o365.audit.UserId` or `o365.audit.MailboxOwnerUPN` to identify the user associated with the mailbox access.\n- Examine `o365.audit.ExternalAccess` to determine if the mailbox access was performed by an external user or application.\n- Check the geolocation data to identify the location from which the mailbox access occurred. Is this an expected location for the user?\n- Check `o365.audit.ClientAppId` to identify the application used for mailbox access. Look for any unusual or unexpected applications but be aware that some legitimate applications may also trigger this rule if OAuth phishing was used.\n- Review `o365.audit.Folders.Path` and `o365.audit.Folders.FolderItems.Id` to identify the specific folders and items accessed within the mailbox. Look for any sensitive or high-value folders that may indicate targeted access.\n- For specific items accessed, examine `o365.audit.Folders.FolderItems.Id` to gather more context on the accessed mailbox items.\n- User types can be identified by checking `o365.audit.UserType`. Review if the mailbox of the user is a member, admin or delegate.\n- If Entra ID logs are available, checking the risk status via `azure.signinlogs.properties.risk_state` and `azure.signinlogs.properties.risk_level` can provide additional context on the user's risk status during the mailbox access.\n\n### False positive analysis\n- Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups.\n- Automated processes or scripts that access mailbox items may also trigger this rule. If these processes are legitimate and necessary, consider adding exceptions for the specific applications or users involved.\n- Users with high email activity, such as helpdesk or support roles, may trigger this rule due to their job responsibilities. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups.\n\n### Response and remediation\n- Investigate the user account associated with the excessive mailbox access to determine if it has been compromised or if the activity is expected behavior.\n- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.\n- Disable the user account temporarily to prevent any potential compromise or unauthorized access.\n- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.\n- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.\n- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.\n- Examine how the mailbox access was performed. If it was done via a third-party application, review the permissions granted to that application and consider revoking them if they are not necessary.\n", + "query": "event.dataset: \"o365.audit\" and\n event.provider: \"Exchange\" and\n event.action: \"MailItemsAccessed\" and\n event.code: \"ExchangeItemAggregated\" and\n (\n (\n o365.audit.OperationProperties.Name: \"IsThrottled\" and\n o365.audit.OperationProperties.Value: \"True\"\n ) or o365.audit.OperationCount >= 100\n )\n", + "references": [ + "https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts#use-mailitemsaccessed-audit-records-for-forensic-investigations", + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.11.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.OperationCount", + "type": "unknown" + }, + { + "ecs": false, + "name": "o365.audit.OperationProperties.Name", + "type": "unknown" + }, + { + "ecs": false, + "name": "o365.audit.OperationProperties.Value", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "7fc95782-4bd1-11f0-9838-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Email", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1114", + "name": "Email Collection", + "reference": "https://attack.mitre.org/techniques/T1114/", + "subtechnique": [ + { + "id": "T1114.002", + "name": "Remote Email Collection", + "reference": "https://attack.mitre.org/techniques/T1114/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "7fc95782-4bd1-11f0-9838-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_2.json b/packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_2.json new file mode 100644 index 00000000000..0ce6c604fbc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_2.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious Named Pipe Creation", + "new_terms_fields": [ + "host.id", + "process.command_line" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Named Pipe Creation\n\nNamed pipes, or FIFOs, are a form of inter-process communication in Linux environments, allowing data transfer between processes. Adversaries exploit this by creating named pipes in common directories like /tmp to stealthily execute commands or maintain persistence. The detection rule identifies unusual named pipe creation by monitoring the `mkfifo` command, especially when initiated by common shell processes, to flag potential malicious activity.\n\n### Possible investigation steps\n\n- Review the process command line arguments to identify the exact named pipe path and any associated commands or scripts that might have been executed using the named pipe.\n- Investigate the parent process (bash, csh, dash, fish, ksh, sh, tcsh, or zsh) to determine the origin of the mkfifo command, checking for any unusual or unexpected scripts or commands that might have initiated it.\n- Examine the user account associated with the mkfifo process to determine if it is a legitimate user or if the account might have been compromised.\n- Check for any other suspicious activities or processes running under the same user account or originating from the same parent process to identify potential lateral movement or further malicious actions.\n- Analyze the system logs around the time of the named pipe creation for any other indicators of compromise, such as unauthorized access attempts or unusual network connections.\n- If possible, capture and review the contents of the named pipe to understand the data being transferred and assess whether it is part of a malicious operation.\n\n### False positive analysis\n\n- Named pipes created by legitimate applications for inter-process communication can trigger this rule. Users should identify and whitelist these applications by adding exceptions for specific process command lines that are known to be safe.\n- System maintenance scripts or backup processes that use named pipes in directories like /tmp or /var/tmp may cause false positives. Review these scripts and exclude them from the rule if they are verified as non-malicious.\n- Development environments or testing frameworks that frequently create and delete named pipes during their operations might be flagged. Users can mitigate this by excluding these environments from monitoring or by specifying exceptions for known development tools.\n- Automated deployment tools that use named pipes for configuration management or orchestration tasks can also be a source of false positives. Ensure these tools are recognized and excluded from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.\n- Terminate any suspicious processes associated with the mkfifo command, especially those originating from common shell processes like bash or sh.\n- Delete any named pipes created in directories such as /tmp, /dev/shm, or /var/tmp that do not follow expected naming conventions or are not part of legitimate applications.\n- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.\n- Restore the system from a known good backup if any unauthorized changes or persistence mechanisms are detected.\n- Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands.\n- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:mkfifo and\nprocess.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and\nprocess.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "8167c5ae-3310-439a-8a58-be60f55023d2", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "8167c5ae-3310-439a-8a58-be60f55023d2_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8446517c-f789-11ee-8ad0-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/8446517c-f789-11ee-8ad0-f661ea17fbce_4.json deleted file mode 100644 index b16d4ebe6db..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8446517c-f789-11ee-8ad0-f661ea17fbce_4.json +++ /dev/null @@ -1,100 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the first occurrence of a user identity in AWS using `GetPassword` for the administrator password of an EC2 instance with an assumed role. Adversaries may use this API call to escalate privileges or move laterally within EC2 instances.", - "from": "now-9m", - "history_window_start": "now-7d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Admin Credential Fetch via Assumed Role", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.session_context.session_issuer.arn" - ], - "note": "## Triage and analysis\n\n### Investigating AWS EC2 Admin Credential Fetch via Assumed Role\n\nThis rule detects the first occurrence of a user identity using the `GetPasswordData` API call in AWS, which retrieves the administrator password of an EC2 instance. This can be an indicator of an adversary attempting to escalate privileges or move laterally within EC2 instances.\n\nThis is a New Terms rule, which means it will only trigger once for each unique value of the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field that has not been seen making this API request within the last 7 days. This field contains the Amazon Resource Name (ARN) of the assumed role that triggered the API call.\n\n#### Possible Investigation Steps\n\n- **Identify the User Identity and Role**: Examine the AWS CloudTrail logs to determine the user identity that made the `GetPasswordData` request. Pay special attention to the role and permissions associated with the user.\n- **Review Request and Response Parameters**: Analyze the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields to understand the context of the API call and the retrieved password.\n- **Contextualize with User Behavior**: Compare this activity against the user's typical behavior patterns. Look for unusual login times, IP addresses, or other anomalous actions taken by the user or role prior to and following the incident.\n- **Review EC2 Instance Details**: Check the details of the EC2 instance from which the password was retrieved. Assess the criticality and sensitivity of the applications running on this instance.\n- **Examine Related CloudTrail Events**: Search for other API calls made by the same user identity, especially those modifying security groups, network access controls, or instance metadata.\n- **Check for Lateral Movement**: Look for evidence that the obtained credentials have been used to access other resources or services within AWS.\n- **Investigate the Origin of the API Call**: Analyze the IP address and geographical location from which the request originated. Determine if it aligns with expected locations for legitimate administrative activity.\n\n### False Positive Analysis\n\n- **Legitimate Administrative Actions**: Ensure that the activity was not part of legitimate administrative tasks such as system maintenance or updates.\n- **Automation Scripts**: Verify if the activity was generated by automation or deployment scripts that are authorized to use `GetPasswordData` for legitimate purposes.\n\n### Response and Remediation\n\n- **Immediate Isolation**: If suspicious, isolate the affected instance to prevent any potential lateral movement or further unauthorized actions.\n- **Credential Rotation**: Rotate credentials of the affected instance or assumed role and any other potentially compromised credentials.\n- **User Account Review**: Review the permissions of the implicated user identity. Apply the principle of least privilege by adjusting permissions to prevent misuse.\n- **Enhanced Monitoring**: Increase monitoring on the user identity that triggered the rule and similar EC2 instances.\n- **Incident Response**: If malicious intent is confirmed, initiate the incident response protocol. This includes further investigation, containment of the threat, eradication of any threat actor presence, and recovery of affected systems.\n- **Preventative Measures**: Implement or enhance security measures such as multi-factor authentication and continuous audits of sensitive operations like `GetPasswordData`.\n\n### Additional Information\n\nRefer to resources like [AWS privilege escalation methods](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc) and the MITRE ATT&CK technique [T1552.005 - Cloud Instance Metadata API](https://attack.mitre.org/techniques/T1552/005/) for more details on potential vulnerabilities and mitigation strategies.\n\n", - "query": "event.dataset:\"aws.cloudtrail\"\n and event.provider:\"ec2.amazonaws.com\" and event.action:\"GetPasswordData\"\n and aws.cloudtrail.user_identity.type:\"AssumedRole\" and aws.cloudtrail.error_code:\"Client.UnauthorizedOperation\"\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.error_code", - "type": "keyword" - }, - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "8446517c-f789-11ee-8ad0-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: Amazon EC2", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1552", - "name": "Unsecured Credentials", - "reference": "https://attack.mitre.org/techniques/T1552/", - "subtechnique": [ - { - "id": "T1552.005", - "name": "Cloud Instance Metadata API", - "reference": "https://attack.mitre.org/techniques/T1552/005/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 4 - }, - "id": "8446517c-f789-11ee-8ad0-f661ea17fbce_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_2.json b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_2.json new file mode 100644 index 00000000000..ff9633d6672 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Character Array Reconstruction", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Character Array Reconstruction\n\nPowerShell, a powerful scripting language, is often targeted by adversaries for obfuscation to bypass security measures. By reconstructing strings from character arrays, attackers evade static analysis and detection. The detection rule identifies scripts using such obfuscation by searching for patterns indicative of character array manipulation, thus flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on the obfuscated parts indicated by the presence of the \"char\" keyword and the \ud83d\udd25 character.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context about the environment and potential risk.\n- Check the user.id and agent.id fields to identify the user and agent responsible for executing the script, which can help assess whether the activity is expected or suspicious.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related script blocks, providing a broader view of the script's behavior.\n- Investigate the count field to assess the extent of obfuscation, as a higher count may indicate more complex or extensive obfuscation techniques being used.\n\n### False positive analysis\n\n- Scripts used for legitimate administrative tasks may use character arrays for performance optimization or to handle special characters. Review the script's purpose and context to determine if it aligns with known administrative functions.\n- PowerShell scripts from trusted sources or vendors might use character arrays for legitimate obfuscation to protect intellectual property. Verify the script's origin and check for digital signatures or hashes to confirm authenticity.\n- Automated scripts generated by development tools or frameworks could include character array manipulation as part of their standard output. Identify and whitelist these tools if they are commonly used in your environment.\n- Security tools or monitoring solutions might use character arrays in their scripts for legitimate purposes. Cross-reference with known security software and consider excluding these from the detection rule if they are verified as safe.\n- Regularly update the exclusion list to include new trusted scripts or tools as they are introduced into the environment, ensuring that legitimate activities are not flagged as false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the script block text and associated logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential credential compromise.\n- Update endpoint protection and ensure that AMSI and other security features are fully enabled and configured to detect similar threats.\n- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Filter for scripts that contain the \"char\" keyword using MATCH, boosts the query performance\n| WHERE powershell.file.script_block_text : \"char\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(char\\[\\]\\]\\(\\d+,\\d+[^)]+|(\\s?\\(\\[char\\]\\d+\\s?\\)\\+){2,})\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "85e2d45e-a3df-4acf-83d3-21805f564ff4", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "85e2d45e-a3df-4acf-83d3-21805f564ff4_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8623535c-1e17-44e1-aa97-7a0699c3037d_207.json b/packages/security_detection_engine/kibana/security_rule/8623535c-1e17-44e1-aa97-7a0699c3037d_207.json deleted file mode 100644 index 72f01e0e037..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8623535c-1e17-44e1-aa97-7a0699c3037d_207.json +++ /dev/null @@ -1,98 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries.", - "false_positives": [ - "Network ACL's may be deleted by a network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Network ACL deletions by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Network Access Control List Deletion", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS EC2 Network Access Control List Deletion\n\nAWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs to identify the specific user or role associated with the deletion event by examining the user identity information in the logs.\n- Check the time and date of the deletion event to determine if it coincides with any other suspicious activities or known maintenance windows.\n- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous.\n- Examine the AWS account activity around the time of the event to identify any other unusual actions or changes, such as the creation of new resources or modifications to existing ones.\n- Assess the impact of the deleted Network ACL or entries by identifying the affected subnets and evaluating the potential exposure or risk to the network.\n- Review any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to users or services, allowing them to delete Network ACLs.\n\n### False positive analysis\n\n- Routine maintenance or updates by authorized personnel may trigger deletion events. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.\n- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation might delete and recreate ACLs as part of normal operations. Identify these tools and exclude their actions from triggering alerts.\n- Changes in network architecture or security policy updates can lead to legitimate ACL deletions. Document these changes and adjust the detection rule to ignore such planned modifications.\n- Ensure that the AWS accounts involved in the deletion events are recognized and trusted. Exclude actions from these accounts if they are part of regular administrative tasks.\n- Collaborate with the security team to establish a baseline of normal ACL deletion activities and refine the detection rule to minimize false positives based on this baseline.\n\n### Response and remediation\n\n- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration. This can be done by applying a restrictive security group or temporarily removing the subnet from the VPC.\n- Review AWS CloudTrail logs to identify the source of the deletion event, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger compromise.\n- Recreate the deleted Network ACL or its entries using the most recent backup or configuration documentation to restore intended security controls.\n- Implement a temporary monitoring solution to track any further unauthorized changes to network ACLs or related security configurations.\n- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, including potential lateral movement or data exfiltration.\n- Revoke or rotate credentials for any compromised IAM users or roles involved in the deletion event to prevent further unauthorized actions.\n- Enhance detection capabilities by configuring alerts for any future unauthorized changes to network ACLs, ensuring rapid response to similar threats.", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(DeleteNetworkAcl or DeleteNetworkAclEntry) and event.outcome:success\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAcl.html", - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl-entry.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAclEntry.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "8623535c-1e17-44e1-aa97-7a0699c3037d", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Network Security Monitoring", - "Tactic: Defense Evasion", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1562", - "name": "Impair Defenses", - "reference": "https://attack.mitre.org/techniques/T1562/", - "subtechnique": [ - { - "id": "T1562.001", - "name": "Disable or Modify Tools", - "reference": "https://attack.mitre.org/techniques/T1562/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 207 - }, - "id": "8623535c-1e17-44e1-aa97-7a0699c3037d_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/877cc04a-3320-411d-bbe9-53266fa5e107_1.json b/packages/security_detection_engine/kibana/security_rule/877cc04a-3320-411d-bbe9-53266fa5e107_1.json new file mode 100644 index 00000000000..f255f518a4d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/877cc04a-3320-411d-bbe9-53266fa5e107_1.json @@ -0,0 +1,120 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as establishing unauthorized access or exfiltrating data.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Network Configuration Modification", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubectl Network Configuration Modification\n\nKubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and network settings. Adversaries may exploit kubectl to alter network configurations, potentially establishing unauthorized access or data exfiltration channels. The detection rule identifies suspicious kubectl usage patterns, such as port-forwarding or proxy commands, especially when executed from atypical parent processes or directories, indicating possible malicious intent.\n\n### Possible investigation steps\n\n- Review the process command line to confirm the specific kubectl command and arguments used, focusing on \"port-forward\", \"proxy\", or \"expose\" to understand the intended network configuration change.\n- Examine the parent process details, including the name and executable path, to determine if the kubectl command was initiated from an unusual or suspicious location, such as \"/tmp/*\" or \"/var/tmp/*\".\n- Investigate the user account associated with the kubectl process to verify if the activity aligns with their typical behavior or if it indicates potential compromise.\n- Check for any recent changes or anomalies in the Kubernetes cluster's network settings or configurations that could correlate with the detected kubectl activity.\n- Look for additional related alerts or logs that might indicate a broader pattern of suspicious activity, such as other command and control tactics or protocol tunneling attempts.\n\n### False positive analysis\n\n- Legitimate administrative tasks using kubectl port-forward or proxy commands can trigger the rule. To manage this, create exceptions for known administrative scripts or users who frequently perform these tasks.\n- Automated scripts or cron jobs that use kubectl for network configuration changes may cause false positives. Identify these scripts and exclude their specific command patterns or parent processes from the rule.\n- Development environments where developers frequently use kubectl for testing purposes might generate alerts. Consider excluding specific user accounts or directories associated with development activities.\n- Continuous integration/continuous deployment (CI/CD) pipelines that utilize kubectl for deployment processes can be a source of false positives. Exclude the CI/CD tool's process names or execution paths from the rule.\n- Temporary directories like /tmp or /var/tmp used by legitimate applications for kubectl operations can trigger alerts. Review and whitelist these specific applications or their execution contexts.\n\n### Response and remediation\n\n- Immediately isolate the affected host to prevent further unauthorized access or data exfiltration. This can be done by removing the host from the network or applying network segmentation rules.\n- Terminate any suspicious kubectl processes identified by the detection rule to halt any ongoing malicious activity.\n- Review and revoke any unauthorized access credentials or tokens that may have been compromised or used in the attack.\n- Conduct a thorough audit of Kubernetes network configurations and access controls to identify and rectify any unauthorized changes or vulnerabilities.\n- Restore any altered network configurations to their original state using backups or configuration management tools.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.\n- Implement enhanced monitoring and logging for kubectl activities and network configuration changes to detect and respond to similar threats more effectively in the future.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\nprocess.name == \"kubectl\" and (\n process.args == \"port-forward\" and process.command_line like \"*:*\" or\n process.args in (\"proxy\", \"expose\")\n) and (\n process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") or\n (\n process.parent.executable like (\"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/root/*\", \"/home/*\") or\n process.parent.name like (\".*\", \"*.sh\")\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "877cc04a-3320-411d-bbe9-53266fa5e107", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1572", + "name": "Protocol Tunneling", + "reference": "https://attack.mitre.org/techniques/T1572/" + }, + { + "id": "T1090", + "name": "Proxy", + "reference": "https://attack.mitre.org/techniques/T1090/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "877cc04a-3320-411d-bbe9-53266fa5e107_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8d696bd0-5756-11f0-8e3b-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/8d696bd0-5756-11f0-8e3b-f661ea17fbcd_1.json new file mode 100644 index 00000000000..5a9d402ba3c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8d696bd0-5756-11f0-8e3b-f661ea17fbcd_1.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "filebeat-*", + "logs-azure.signinlogs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual ROPC Login Attempt by User Principal", + "new_terms_fields": [ + "azure.signinlogs.properties.user_principal_name" + ], + "note": "## Triage and analysis\n\n### Investigating Unusual ROPC Login Attempt by User Principal\n\nThis rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying.\n\n### Possible investigation steps\n- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the ROPC login attempt. Check if this user is expected to use ROPC or if it is an unusual account for this type of authentication.\n- Analyze the `azure.signinlogs.properties.authentication_protocol` field to confirm that the authentication protocol is indeed ROPC. This protocol is typically used in legacy applications or scripts that do not support modern authentication methods.\n- Check the `user_agent.original` field to identify potentially abused open-source tools or scripts that may be using ROPC for unauthorized access such as TeamFiltration or other enumeration tools.\n- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to determine which application is attempting the ROPC login. FOCI applications are commonly used for enumeration and password spraying.\n- Investigate the `azure.signinlogs.properties.client_ip` to identify the source of the login attempt. Check if the IP address is associated with known malicious activity or if it is a legitimate user location.\n- Review the `azure.signinlogs.properties.authentication_details` field for any additional context on the authentication attempt, such as whether it was successful or if there were any errors.\n- Examine the `azure.signinlogs.properties.applied_conditional_access_policies` to see if any conditional access policies were applied during the login attempt. If no policies were applied, this could indicate a potential bypass of security controls.\n- Identify the resource requested access to by checking the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id`. This can help determine if the login attempt was targeting sensitive resources or applications such as Exchange Online, SharePoint, or Teams.\n\n### False positive analysis\n- Legitimate applications or scripts that use ROPC for automation purposes may trigger this rule.\n- Some legacy applications may still rely on ROPC for authentication, especially in environments where modern authentication methods are not fully implemented.\n- Internal security tools or scripts that perform automated tasks using ROPC may generate false positives if they are not properly whitelisted or excluded from the rule.\n\n### Response and remediation\n- If the ROPC login attempt is confirmed to be malicious, immediately block the user account and reset the password to prevent further unauthorized access.\n- Consider enforcing multi-factor authentication (MFA) for the user account to enhance security and prevent future unauthorized access attempts.\n- Review and update conditional access policies to restrict the use of ROPC for sensitive accounts or applications, ensuring that MFA is required for all login attempts.\n- Investigate the source of the ROPC login attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity.\n- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified.\n- Educate users about the risks associated with ROPC and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible.\n", + "query": "event.dataset: \"azure.signinlogs\" and\n azure.signinlogs.properties.authentication_protocol: \"ropc\" and\n azure.signinlogs.properties.authentication_requirement: \"singleFactorAuthentication\" and\n azure.signinlogs.properties.user_type: \"Member\" and\n event.outcome: \"success\"\n", + "references": [ + "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign", + "https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf", + "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.properties.authentication_protocol", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.authentication_requirement", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "8d696bd0-5756-11f0-8e3b-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Use Case: Identity and Access Audit", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "8d696bd0-5756-11f0-8e3b-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_1.json new file mode 100644 index 00000000000..62580082873 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_1.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration, potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners \u2014 a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures such as the `Microsoft.OData.Client` user agent and specific OS version values. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay.", + "from": "now-9m", + "index": [ + "filebeat-*", + "logs-azure.auditlogs-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Suspicious Cloud Device Registration", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Suspicious Cloud Device Registration\n\nThis rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation. The activity includes three correlated events:\n\n1. Add device operation from the Device Registration Service using a `Microsoft.OData.Client/*` user-agent and a known Windows OS version.\n2. Addition of a registered user with an `enterprise registration` URN.\n3. Assignment of a registered owner to the device.\n\nThis pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.\n\n### Possible investigation steps\n\n- Identify the user principal associated with the device registration.\n- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request.\n- Check for the presence of the `Microsoft.OData.Client/*` user-agent in `azure.auditlogs.properties.additional_details.value`, as this is common in ROADtools usage.\n- Confirm the OS version seen in the modified properties is expected (e.g., `10.0.19041.928`), or investigate unexpected versions.\n- Examine the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) to verify it's not being misused.\n- Use `azure.correlation_id` to pivot across all three steps of the registration flow.\n- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens.\n- Look for signs of persistence or lateral movement enabled by the newly registered device.\n- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization.\n- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration.\n- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`.\n\n### False positive analysis\n\n- Some MDM or autopilot provisioning flows may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.\n- Investigate whether the device name, OS version, and registration details align with normal IT workflows.\n\n### Response and remediation\n\n- If confirmed malicious, remove the registered device from Entra ID.\n- Revoke refresh tokens and primary refresh tokens associated with the user and device.\n- Disable the user account and initiate password reset and identity verification procedures.\n- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.\n- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.\n", + "query": "sequence by azure.correlation_id with maxspan=1m\n[any where event.dataset == \"azure.auditlogs\" and\n azure.auditlogs.identity == \"Device Registration Service\" and\n azure.auditlogs.operation_name == \"Add device\" and\n azure.auditlogs.properties.additional_details.value like \"Microsoft.OData.Client/*\" and (\n `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == \"CloudAccountEnabled\" and\n `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == \"[true]\"\n ) and\n `azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value` like \"*10.0.19041.928*\"]\n[any where event.dataset == \"azure.auditlogs\" and\n azure.auditlogs.operation_name == \"Add registered users to device\" and\n `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like \"*urn:ms-drs:enterpriseregistration.windows.net*\"]\n[any where event.dataset == \"azure.auditlogs\" and\n azure.auditlogs.operation_name == \"Add registered owner to device\"]\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name`", + "type": "unknown" + }, + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`", + "type": "unknown" + }, + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`", + "type": "unknown" + }, + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.auditlogs.identity", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.correlation_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "90efea04-5675-11f0-8f80-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Audit Logs", + "Use Case: Identity and Access Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.005", + "name": "Device Registration", + "reference": "https://attack.mitre.org/techniques/T1098/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "90efea04-5675-11f0-8f80-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_213.json b/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_213.json new file mode 100644 index 00000000000..5a4b50364da --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_213.json @@ -0,0 +1,146 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment.", + "false_positives": [ + "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes. AWS services might assume roles to access AWS resources as part of their standard operations. Automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments." + ], + "from": "now-6m", + "history_window_start": "now-10d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "source.address", + "user_agent.original", + "aws.cloudtrail.user_identity.invoked_by", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.flattened.response_elements.credentials.accessKeyId", + "event.action", + "event.outcome", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "aws.cloudtrail.flattened.request_parameters.roleSessionName", + "cloud.region", + "cloud.account.id", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS STS Role Assumption by Service", + "new_terms_fields": [ + "aws.cloudtrail.user_identity.invoked_by", + "aws.cloudtrail.resources.arn" + ], + "note": "## Triage and analysis\n\n### Investigating AWS STS Role Assumption by Service\n\nThis rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.\n\n#### Possible Investigation Steps\n\n- **Identify the Actor and Assumed Role**:\n - **User Identity**: Review the `aws.cloudtrail.user_identity.invoked_by` field to determine which service initiated the `AssumeRole` action.\n - **Role Assumed**: Check the `aws.cloudtrail.resources.arn` field to confirm the assumed role and ensure it aligns with expected responsibilities.\n - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available.\n - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired.\n\n- **Inspect the User Agent for Tooling Identification**:\n - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include:\n - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts.\n - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction.\n - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools.\n\n- **Contextualize with Related Events**:\n - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources.\n - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise.\n\n- **Evaluate the Privilege Level of the Assumed Role**:\n - **Permissions**: Inspect permissions associated with the assumed role to understand its access level.\n - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities.\n\n### False Positive Analysis\n\n- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows.\n- **Routine AWS Service Actions**: Historical data may reveal if the same service assumes new roles regularly as part of authorized operations.\n\n### Response and Remediation\n\n- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role.\n- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges.\n- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue.\n- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation.\n\n### Additional Information\n\nFor more information on managing and securing AWS STS, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) and AWS security best practices.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"sts.amazonaws.com\"\n and event.action: \"AssumeRole\"\n and event.outcome: \"success\"\n and aws.cloudtrail.user_identity.type: \"AWSService\"\n and aws.cloudtrail.user_identity.invoked_by: (\n \"ec2.amazonaws.com\" or\n \"lambda.amazonaws.com\" or\n \"rds.amazonaws.com\" or\n \"ssm.amazonaws.com\" or\n \"ecs-tasks.amazonaws.com\" or\n \"ecs.amazonaws.com\" or\n \"eks.amazonaws.com\" or\n \"eks-fargate.amazonaws.com\" or\n \"codepipeline.amazonaws.com\" or\n \"codebuild.amazonaws.com\" or\n \"autoscaling.amazonaws.com\")\n", + "references": [ + "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.invoked_by", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "93075852-b0f5-4b8b-89c3-a226efae5726", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS STS", + "Resources: Investigation Guide", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Lateral Movement" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 213 + }, + "id": "93075852-b0f5-4b8b-89c3-a226efae5726_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9395fd2c-9947-4472-86ef-4aceb2f7e872_209.json b/packages/security_detection_engine/kibana/security_rule/9395fd2c-9947-4472-86ef-4aceb2f7e872_209.json deleted file mode 100644 index f4db712e4e7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9395fd2c-9947-4472-86ef-4aceb2f7e872_209.json +++ /dev/null @@ -1,96 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the deletion of one or more flow logs in AWS Elastic Compute Cloud (EC2). An adversary may delete flow logs in an attempt to evade defenses.", - "false_positives": [ - "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Flow log deletions by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS VPC Flow Logs Deletion", - "note": "## Triage and analysis\n\n### Investigating AWS VPC Flow Logs Deletion\n\nVPC Flow Logs is an AWS feature that enables you to capture information about the IP traffic going to and from network interfaces in your virtual private cloud (VPC). Flow log data can be published to Amazon CloudWatch Logs or Amazon S3.\n\nThis rule identifies the deletion of VPC flow logs using the API `DeleteFlowLogs` action. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Contact the account and resource owners and confirm whether they are aware of this activity.\n- Check if this operation was approved and performed according to the organization's change management policy.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- If this rule is noisy in your environment due to expected activity, consider adding exceptions \u2014 preferably with a combination of user and IP address conditions.\n- Administrators may rotate these logs after a certain period as part of their retention policy or after importing them to a SIEM.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DeleteFlowLogs and event.outcome:success\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-flow-logs.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteFlowLogs.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "9395fd2c-9947-4472-86ef-4aceb2f7e872", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "high", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Log Auditing", - "Resources: Investigation Guide", - "Tactic: Defense Evasion" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1562", - "name": "Impair Defenses", - "reference": "https://attack.mitre.org/techniques/T1562/", - "subtechnique": [ - { - "id": "T1562.001", - "name": "Disable or Modify Tools", - "reference": "https://attack.mitre.org/techniques/T1562/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 209 - }, - "id": "9395fd2c-9947-4472-86ef-4aceb2f7e872_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9563dace-5822-11f0-b1d3-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/9563dace-5822-11f0-b1d3-f661ea17fbcd_1.json new file mode 100644 index 00000000000..3b7e46f0a09 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9563dace-5822-11f0-b1d3-f661ea17fbcd_1.json @@ -0,0 +1,113 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "filebeat-*", + "logs-azure.signinlogs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious Entra ID OAuth User Impersonation Scope Detected", + "new_terms_fields": [ + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.app_id" + ], + "note": "## Triage and Analysis\n\n### Investigating Suspicious Entra ID OAuth User Impersonation Scope Detected\n\nIdentifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious\nOAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where\nthe sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or\nunauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity.\n\n### Possible investigation steps\n\n- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow.\n- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user.\n- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access.\n- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies.\n- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.\n- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities.\n- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise.\n\n### False positive analysis\n\n- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.\n- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n\n### Response and remediation\n\n- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor.\n- If the OAuth workflow is confirmed to be malicious:\n - Block the user account and reset the password to prevent further unauthorized access.\n - Revoke active sessions and refresh tokens associated with the user principal.\n - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant.\n - Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity.\n - Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified.\n- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible.\n", + "query": "event.dataset: azure.signinlogs and\n azure.signinlogs.properties.authentication_processing_details: *user_impersonation* and\n azure.signinlogs.properties.authentication_requirement: \"singleFactorAuthentication\" and\n azure.signinlogs.properties.token_issuer_type: \"AzureAD\" and\n azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: \"unbound\" and\n azure.signinlogs.properties.user_type: \"Member\" and\n event.outcome: \"success\"\n", + "references": [ + "https://github.com/Flangvik/TeamFiltration", + "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.properties.authentication_processing_details", + "type": "flattened" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.authentication_requirement", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.token_issuer_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.token_protection_status_details.sign_in_session_status", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "9563dace-5822-11f0-b1d3-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Use Case: Threat Detection", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Tactic: Defense Evasion", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "9563dace-5822-11f0-b1d3-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/96f29282-ffcc-4ce7-834b-b17aee905568_2.json b/packages/security_detection_engine/kibana/security_rule/96f29282-ffcc-4ce7-834b-b17aee905568_2.json new file mode 100644 index 00000000000..cda9cb897cf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/96f29282-ffcc-4ce7-834b-b17aee905568_2.json @@ -0,0 +1,120 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects SSH session ID change followed by a suspicious SSHD child process, this may indicate the successful execution of a potentially malicious process through the Pluggable Authentication Module (PAM) utility. PAM is a framework used by Linux systems to authenticate users. Adversaries may create malicious PAM modules that grant them persistence onto the target every time a user logs in by executing a backdoor script or command.", + "false_positives": [ + "Trusted system module updates or allowed Pluggable Authentication Module (PAM) daemon configuration changes." + ], + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Backdoor Execution Through PAM_EXEC", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Backdoor Execution Through PAM_EXEC\n\nPAM (Pluggable Authentication Module) is a critical framework in Linux systems for user authentication. Adversaries may exploit PAM by inserting malicious modules that execute backdoor scripts during user logins, ensuring persistent access. The detection rule identifies this threat by monitoring SSH session changes followed by unusual child processes, often indicative of backdoor execution, especially when these processes originate from suspicious directories or use scripting languages.\n\n### Possible investigation steps\n\n- Review the process entity ID associated with the alert to identify the specific SSH session and its related activities.\n- Examine the parent process details, specifically focusing on the SSH or SSHD process, to determine the source and legitimacy of the login attempt.\n- Investigate the child process that was started, paying close attention to its name and executable path, especially if it matches patterns like scripting languages (e.g., perl, python) or suspicious directories (e.g., /tmp, /var/tmp).\n- Check the process arguments count and content to understand the command or script being executed, which may provide insights into the potential backdoor's functionality.\n- Correlate the event timestamp with user login records and system logs to identify any unusual login patterns or unauthorized access attempts.\n- Assess the risk and impact by determining if the process has made any unauthorized changes to the system or if it has established any persistent mechanisms.\n- If a backdoor is confirmed, initiate containment measures such as terminating the malicious process, removing the unauthorized PAM module, and conducting a full system audit to prevent further exploitation.\n\n### False positive analysis\n\n- Legitimate administrative scripts executed via SSH may trigger the rule if they use scripting languages like Perl, Python, or PHP. To handle this, identify and whitelist known administrative scripts and their execution paths.\n- Automated backup or maintenance processes that run from directories like /var/backups or /var/log can be mistaken for malicious activity. Exclude these processes by specifying their exact paths and names in the exception list.\n- Development or testing environments where scripts are frequently executed from temporary directories such as /tmp or /dev/shm may cause false positives. Implement exceptions for these environments by defining specific user accounts or process names that are known to be safe.\n- Custom monitoring or logging tools that spawn child processes from SSH sessions might be flagged. Review these tools and add them to the exclusion list if they are verified as non-threatening.\n- Regular user activities involving the use of scripting languages for legitimate purposes can be misinterpreted. Educate users on best practices and adjust the rule to exclude common benign scripts used in daily operations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or using scripting languages.\n- Conduct a thorough review of PAM configuration files and modules to identify and remove any unauthorized or malicious entries.\n- Reset credentials for all users on the affected system, prioritizing those with elevated privileges, to mitigate potential credential compromise.\n- Restore the system from a known good backup if malicious modifications are confirmed, ensuring that the backup is free from tampering.\n- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the threat, focusing on SSH session changes and unusual child processes.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.\n", + "query": "sequence by process.entity_id with maxspan=3s\n [process where host.os.type == \"linux\" and event.type == \"change\" and event.action == \"session_id_change\" and process.name in (\"ssh\", \"sshd\")]\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.parent.name in (\"ssh\", \"sshd\") and\n process.args_count == 2 and (\n process.name like (\"perl*\", \"python*\", \"php*\", \"ruby*\", \"lua*\") or\n process.executable like (\n \"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"./*\", \"/boot/*\", \"/sys/*\", \"/lost+found/*\", \"/media/*\", \"/proc/*\",\n \"/var/backups/*\", \"/var/log/*\", \"/var/mail/*\", \"/var/spool/*\") or\n process.name like \".*\"\n )]\n", + "references": [ + "https://www.elastic.co/security-labs/approaching-the-summit-on-persistence", + "https://www.group-ib.com/blog/pluggable-authentication-module/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "96f29282-ffcc-4ce7-834b-b17aee905568", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/" + } + ] + } + ], + "type": "eql", + "version": 2 + }, + "id": "96f29282-ffcc-4ce7-834b-b17aee905568_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_1.json b/packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_1.json new file mode 100644 index 00000000000..7e5a2003c57 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_1.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule detects the execution of kubectl commands that are commonly used for configuration discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query configuration information, such as configmaps. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Configuration Discovery", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\") and\nprocess.name == \"kubectl\" and process.args in (\"get\", \"describe\") and process.args in (\"configmap\", \"configmaps\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "auditd_manager", + "version": "^1.18.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b", + "severity": "low", + "tags": [ + "Domain: Container", + "Domain: Endpoint", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_209.json b/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_209.json deleted file mode 100644 index f394ddf5d12..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_209.json +++ /dev/null @@ -1,84 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An attempt was made to modify AWS EC2 snapshot attributes. Snapshots are sometimes shared by threat actors in order to exfiltrate bulk data from an EC2 fleet. If the permissions were modified, verify the snapshot was not shared with an unauthorized or unexpected AWS account.", - "false_positives": [ - "IAM users may occasionally share EC2 snapshots with another AWS account belonging to the same organization. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Snapshot Activity", - "note": "## Triage and analysis\n\n### Investigating AWS EC2 Snapshot Activity\n\nAmazon EC2 snapshots are a mechanism to create point-in-time references to data that reside in storage volumes. System administrators commonly use this for backup operations and data recovery.\n\nThis rule looks for the modification of snapshot attributes using the API `ModifySnapshotAttribute` action. This can be used to share snapshots with unauthorized third parties, giving others access to all the data on the snapshot.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Search for dry run attempts against the resource ID of the snapshot from other user accounts within CloudTrail.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- Check if this operation was approved and performed according to the organization's change management policy.\n- Check if the shared permissions of the snapshot were modified to `Public` or include unknown account IDs.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- If this rule is noisy in your environment due to expected activity, consider adding exceptions \u2014 preferably with a combination of user and IP address conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:ModifySnapshotAttribute\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-snapshot-attribute.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "98fd7407-0bd5-5817-cda0-3fcc33113a56", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Asset Visibility", - "Tactic: Exfiltration", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 209 - }, - "id": "98fd7407-0bd5-5817-cda0-3fcc33113a56_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9a6f5d74-c7e7-4a8b-945e-462c102daee4_2.json b/packages/security_detection_engine/kibana/security_rule/9a6f5d74-c7e7-4a8b-945e-462c102daee4_2.json new file mode 100644 index 00000000000..24c993cd35e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9a6f5d74-c7e7-4a8b-945e-462c102daee4_2.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create, or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. This rule detects process discovery executions that involve kubeconfig files, particularly those executed from common shell environments or world-writeable directories.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubeconfig File Discovery", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubeconfig File Discovery\n\nKubeconfig files are essential in Kubernetes, storing credentials and configurations for cluster access. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious processes interacting with kubeconfig files, especially from common shell environments or risky directories, flagging potential misuse by excluding benign commands like 'stat' or 'md5sum'.\n\n### Possible investigation steps\n\n- Review the process details to identify the parent process name and executable path, focusing on those originating from common shell environments or risky directories like /tmp, /var/tmp, or /dev/shm.\n- Examine the process arguments to determine if they include references to sensitive kubeconfig files such as admin.conf, kubelet.conf, or any files within /etc/kubernetes or ~/.kube directories.\n- Check the working directory of the process to see if it aligns with known Kubernetes configuration paths like /etc/kubernetes or ~/.kube, which may indicate an attempt to access or modify kubeconfig files.\n- Investigate the user account associated with the process to assess whether it has legitimate access to Kubernetes configurations or if it might be compromised.\n- Correlate the event with other recent activities from the same user or IP address to identify any patterns of suspicious behavior or potential lateral movement within the cluster.\n- Review any related alerts or logs for the same host or container to gather additional context on the system's state and any other potential indicators of compromise.\n\n### False positive analysis\n\n- Processes like 'stat' and 'md5sum' are excluded from detection as they are commonly used for legitimate file checks. Ensure these exclusions are correctly configured to prevent unnecessary alerts.\n- Scripts located in user directories such as '/home/*/.kube' may trigger alerts if they interact with kubeconfig files. Consider adding exceptions for known scripts or users that regularly access these files for legitimate purposes.\n- Processes originating from world-writeable directories like '/tmp' or '/var/tmp' can be flagged. Review these alerts to identify routine operations and whitelist specific processes or directories that are part of regular maintenance tasks.\n- Alerts triggered by processes with names matching patterns like '*.sh' may include legitimate scripts. Evaluate these scripts and exclude them if they are part of standard operations or administrative tasks.\n- Regular administrative tasks involving kubeconfig files in directories like '/etc/kubernetes' may be flagged. Implement exceptions for known administrative processes to reduce false positives while maintaining security oversight.\n\n### Response and remediation\n\n- Immediately isolate the affected system to prevent further unauthorized access to the Kubernetes cluster.\n- Revoke any compromised credentials associated with the kubeconfig files and issue new credentials to authorized users.\n- Conduct a thorough review of recent access logs and audit trails for the Kubernetes cluster to identify any unauthorized access or lateral movement attempts.\n- Restore any modified or deleted kubeconfig files from a secure backup to ensure the integrity of the cluster configuration.\n- Implement stricter access controls and permissions for directories containing kubeconfig files, ensuring only authorized personnel have access.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.\n- Enhance monitoring and alerting for suspicious activities related to kubeconfig files, leveraging the MITRE ATT&CK framework to identify potential discovery tactics.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") or\n (\n process.parent.executable like (\"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/root/*\", \"/home/*\") or\n process.parent.name like (\".*\", \"*.sh\")\n )\n) and\n(\n (\n process.working_directory like (\"/etc/kubernetes\", \"/root/.kube\", \"/home/*/.kube\") and\n process.args in (\"kubeconfig\", \"admin.conf\", \"super-admin.conf\", \"kubelet.conf\", \"controller-manager.conf\", \"scheduler.conf\")\n ) or\n process.args like (\n \"/etc/kubernetes/admin.conf\",\n \"/etc/kubernetes/super-admin.conf\",\n \"/etc/kubernetes/kubelet.conf\",\n \"/etc/kubernetes/controller-manager.conf\",\n \"/etc/kubernetes/scheduler.conf\",\n \"/home/*/.kube/config\",\n \"/root/.kube/config\",\n \"/var/lib/*/kubeconfig\"\n )\n) and not process.name in (\"stat\", \"md5sum\", \"dirname\")\n", + "references": [ + "https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/", + "https://kubenomicon.com/Initial_access/Kubeconfig_file.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "9a6f5d74-c7e7-4a8b-945e-462c102daee4", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "9a6f5d74-c7e7-4a8b-945e-462c102daee4_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_2.json b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_2.json new file mode 100644 index 00000000000..223604e6e8e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "PowerShell Obfuscation via Negative Index String Reversal", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating PowerShell Obfuscation via Negative Index String Reversal\n\nPowerShell, a powerful scripting language, can be exploited by adversaries using obfuscation techniques like negative index string reversal to evade detection. This method manipulates strings or arrays by iterating in reverse, bypassing static analysis tools. The detection rule identifies scripts with obfuscation patterns by analyzing script length and specific indexing patterns, flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` to understand the script's intent and identify any suspicious or malicious behavior.\n- Check the `host.name` and `user.id` fields to determine the affected system and user, assessing if they are high-value targets or have a history of similar alerts.\n- Analyze the `file.path` to identify the location of the script and assess if it is in a common or suspicious directory.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` to trace the execution flow and determine if this script is part of a larger, potentially malicious sequence.\n- Correlate the `agent.id` with other logs to see if there are additional related activities or alerts from the same endpoint.\n- Examine the `count` of detected patterns to assess the level of obfuscation and potential threat severity.\n\n### False positive analysis\n\n- Scripts containing the keyword \"GENESIS-5654\" are known false positives and are automatically excluded from triggering alerts. Ensure that any legitimate scripts using this keyword are documented to prevent unnecessary investigations.\n- Legitimate administrative scripts that use negative indexing for valid purposes may trigger false positives. Review these scripts and consider adding them to an exception list if they are frequently flagged but verified as non-malicious.\n- Automated scripts generated by trusted software that use similar obfuscation patterns for performance or compatibility reasons can be excluded by identifying unique identifiers or patterns within these scripts and updating the exclusion criteria accordingly.\n- Regularly update the exclusion list to include new patterns or identifiers from trusted sources as they are identified, ensuring that legitimate activities are not hindered by the detection rule.\n- Collaborate with IT and security teams to maintain a list of known safe scripts and their characteristics, which can be referenced when analyzing potential false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the PowerShell script block text and related logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential unauthorized access.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques in the future.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"\\$\\w+\\[\\-\\s?1\\.\\.\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n\n// FP Patterns\n| WHERE NOT powershell.file.script_block_text LIKE \"*GENESIS-5654*\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "9edd1804-83c7-4e48-b97d-c776b4c97564", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "9edd1804-83c7-4e48-b97d-c776b4c97564_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json new file mode 100644 index 00000000000..275fecffe69 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Dynamic IEX Reconstruction via Method String Access", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Dynamic IEX Reconstruction via Method String Access\n\nPowerShell's flexibility allows dynamic command execution, which adversaries exploit by obfuscating commands like Invoke-Expression (IEX). They manipulate method strings to reconstruct IEX, evading static detection. The detection rule identifies scripts using this obfuscation by analyzing patterns in method string access, flagging suspicious activity for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script that triggered the alert. Look for any suspicious patterns or obfuscation techniques.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and user.id fields to identify the machine and user account involved in executing the script, which can help assess whether the activity aligns with expected behavior.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other PowerShell activities on the host, providing a broader view of the script's execution context.\n- Investigate the agent.id field to verify the endpoint's security posture and ensure that it is up-to-date with the latest security patches and configurations.\n\n### False positive analysis\n\n- Scripts with legitimate use of string manipulation methods like IndexOf or SubString may trigger false positives if they are part of complex PowerShell scripts used in administrative tasks. To manage this, review the context of the script and consider adding exceptions for known safe scripts or users.\n- Automated scripts from trusted software that perform extensive string operations for configuration or data processing might be flagged. Identify these scripts and exclude them by their script block ID or file path to prevent unnecessary alerts.\n- Development environments where PowerShell is used for testing or debugging purposes may generate alerts due to frequent use of string manipulation. Implement exclusions based on host names or user IDs associated with these environments to reduce noise.\n- Security tools or monitoring solutions that use PowerShell for log analysis or system checks might inadvertently match the detection pattern. Verify the source of the script and whitelist these tools by agent ID or specific script characteristics.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and script block ID from the alert to understand the scope and intent of the obfuscation technique used.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any additional threats.\n- Restore the affected system from a known good backup if the integrity of the system is compromised and cannot be assured.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|SubString|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "9f432a8b-9588-4550-838e-1f77285580d3_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_115.json b/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_115.json new file mode 100644 index 00000000000..591f61a2731 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_115.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts.", + "false_positives": [ + "Legitimate scheduled tasks may be created during installation of new software." + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual Scheduled Task Update", + "new_terms_fields": [ + "host.id", + "winlog.event_data.TaskName" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Scheduled Task Update\n\nScheduled tasks in Windows environments automate routine tasks, but adversaries can exploit them for persistence by modifying tasks to execute malicious code. The detection rule identifies first-time task modifications by non-system users, flagging potential unauthorized changes. By excluding known system accounts, it focuses on suspicious user activity, aiding in early threat detection.\n\n### Possible investigation steps\n\n- Review the event logs for event code 4702 to identify the specific scheduled task that was modified and the user account responsible for the change.\n- Investigate the user account involved in the modification to determine if it is a legitimate user or potentially compromised. Check for any recent unusual activity associated with this account.\n- Examine the details of the modified scheduled task, including the command or script it is set to execute, to assess if it is potentially malicious or unauthorized.\n- Cross-reference the scheduled task's modification time with other security events or logs to identify any correlated suspicious activities or anomalies.\n- Check the history of the scheduled task to determine if this is the first modification or if there have been previous changes that might indicate a pattern of unauthorized access.\n\n### False positive analysis\n\n- Scheduled task modifications by IT administrators performing routine maintenance can trigger alerts. To manage this, create exceptions for known administrator accounts that regularly update tasks.\n- Software updates or installations by trusted applications may modify scheduled tasks. Identify these applications and exclude their associated user accounts or processes from the rule.\n- Automated scripts or management tools that modify tasks as part of their normal operation can be mistaken for suspicious activity. Document these tools and exclude their activity from detection.\n- Temporary user accounts used for specific projects or tasks might modify scheduled tasks. If these accounts are verified and trusted, consider excluding them from the rule during their active period.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized scheduled task modifications or potential lateral movement by the adversary.\n- Terminate any suspicious processes associated with the modified scheduled task to halt any ongoing malicious activity.\n- Review the modified scheduled task details, including the command or script being executed, and remove or disable any malicious components identified.\n- Reset the credentials of the user account involved in the modification to prevent further unauthorized access, and investigate for any signs of credential compromise.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.\n- Implement additional monitoring and alerting for scheduled task modifications across the environment to enhance detection of similar threats in the future.\n", + "query": "event.category: \"iam\" and event.code: \"4702\" and\n not winlog.event_data.SubjectUserSid: (\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\") and\n not user.name : *$\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserSid", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "a02cb68e-7c93-48d1-93b2-2c39023308eb", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 115 + }, + "id": "a02cb68e-7c93-48d1-93b2-2c39023308eb_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_112.json b/packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_112.json new file mode 100644 index 00000000000..75b39a68757 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_112.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation or modification of a medium-size registry hive file on a Server Message Block (SMB) share, which may indicate an exfiltration attempt of a previously dumped Security Account Manager (SAM) registry hive for credential extraction on an attacker-controlled system.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.file-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Windows Registry File Creation in SMB Share", + "note": "## Triage and analysis\n\n### Investigating Windows Registry File Creation in SMB Share\n\nDumping registry hives is a common way to access credential information. Some hives store credential material, as is the case for the SAM hive, which stores locally cached credentials (SAM secrets), and the SECURITY hive, which stores domain cached credentials (LSA secrets). Dumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets.\n\nAttackers can try to evade detection on the host by transferring this data to a system that is not monitored to be parsed and decrypted. This rule identifies the creation or modification of a medium-size registry hive file on an SMB share, which may indicate this kind of exfiltration attempt.\n\n#### Possible investigation steps\n\n- Investigate other alerts associated with the user/source host during the past 48 hours.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Inspect the source host for suspicious or abnormal behaviors in the alert timeframe.\n- Capture the registry file(s) to determine the extent of the credential compromise in an eventual incident response.\n\n### False positive analysis\n\n- Administrators can export registry hives for backup purposes. Check whether the user should be performing this kind of activity and is aware of it.\n\n### Related rules\n\n- Credential Acquisition via Registry Hive Dumping - a7e7bfa3-088e-4f13-b29e-3986e0e756b8\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "file where host.os.type == \"windows\" and event.type == \"creation\" and\n /* regf file header */\n file.Ext.header_bytes : \"72656766*\" and file.size >= 30000 and\n process.pid == 4 and user.id : (\"S-1-5-21*\", \"S-1-12-1-*\") and\n not file.path : (\n \"?:\\\\*\\\\UPM_Profile\\\\NTUSER.DAT\",\n \"?:\\\\*\\\\UPM_Profile\\\\NTUSER.DAT.LASTGOODLOAD\",\n \"?:\\\\*\\\\UPM_Profile\\\\AppData\\\\Local\\\\Microsoft\\\\Windows\\\\UsrClass.dat*\",\n \"?:\\\\Windows\\\\Netwrix\\\\Temp\\\\????????.???.offreg\",\n \"?:\\\\*\\\\AppData\\\\Local\\\\Packages\\\\Microsoft.*\\\\Settings\\\\settings.dat*\"\n )\n", + "references": [ + "https://www.elastic.co/security-labs/detect-credential-access" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "file.Ext.header_bytes", + "type": "unknown" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.size", + "type": "long" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pid", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "a4c7473a-5cb4-4bc1-9d06-e4a75adbc494", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Credential Access", + "Resources: Investigation Guide", + "Data Source: Elastic Defend" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/", + "subtechnique": [ + { + "id": "T1003.002", + "name": "Security Account Manager", + "reference": "https://attack.mitre.org/techniques/T1003/002/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1021", + "name": "Remote Services", + "reference": "https://attack.mitre.org/techniques/T1021/", + "subtechnique": [ + { + "id": "T1021.002", + "name": "SMB/Windows Admin Shares", + "reference": "https://attack.mitre.org/techniques/T1021/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 112 + }, + "id": "a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_210.json b/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_210.json deleted file mode 100644 index a7ce7401e18..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_210.json +++ /dev/null @@ -1,97 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies AWS CloudTrail events where an IAM role's trust policy has been updated. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker may attempt to modify this policy to gain the privileges of the role. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule, which means it will only trigger once for each unique value of the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.flattened.request_parameters.roleName` fields that has not been seen making this API request within the last 14 days.", - "false_positives": [ - "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Policy updates from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS IAM Assume Role Policy Update", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.flattened.request_parameters.roleName" - ], - "note": "## Triage and analysis\n\n### Investigating AWS IAM Assume Role Policy Update\n\nAn IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.\n\nThe role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role.\n\n#### Possible investigation steps\n\n- Review the `aws.cloudtrail.user_identity.arn` field to determine the user identity that performed the action.\n- Review the `aws.cloudtrail.flattened.request_parameters.roleName` field to confirm the role that was updated.\n- Within the `aws.cloudtrail.request_parameters` field, review the `policyDocument` to understand the changes made to the trust policy.\n- If `aws.cloudtrail.user_identity.access_key_id` is present, investigate the access key used to perform the action as it may be compromised.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Contact the account and resource owners and confirm whether they are aware of this activity.\n- Check if this operation was approved and performed according to the organization's change management policy.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions \u2014 preferably with a combination of the user agent and user ID conditions \u2014 to cover administrator activities and infrastructure as code tooling.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Use AWS [policy versioning](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html) to restore the trust policy to the desired state.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"UpdateAssumeRolePolicy\"\n and event.outcome: \"success\"\n and not source.address: \"cloudformation.amazonaws.com\"\n", - "references": [ - "https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.address", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "a60326d7-dca7-4fb7-93eb-1ca03a1febbd", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Privilege Escalation" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 210 - }, - "id": "a60326d7-dca7-4fb7-93eb-1ca03a1febbd_210", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ac5a2759-5c34-440a-b0c4-51fe674611d6_202.json b/packages/security_detection_engine/kibana/security_rule/ac5a2759-5c34-440a-b0c4-51fe674611d6_202.json deleted file mode 100644 index 33919f22cce..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ac5a2759-5c34-440a-b0c4-51fe674611d6_202.json +++ /dev/null @@ -1,125 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies modifications in registry keys associated with abuse of the Outlook Home Page functionality for command and control or persistence.", - "from": "now-9m", - "index": [ - "winlogbeat-*", - "logs-endpoint.events.registry-*", - "logs-windows.sysmon_operational-*", - "endgame-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Outlook Home Page Registry Modification", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Outlook Home Page Registry Modification\n\nThe Outlook Home Page feature allows users to set a webpage as the default view for folders, leveraging registry keys to store URL configurations. Adversaries exploit this by modifying these keys to redirect to malicious sites, enabling command and control or persistence. The detection rule identifies suspicious registry changes, focusing on URL entries within specific paths, flagging potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the registry path and value to confirm the presence of a suspicious URL entry in the specified registry paths, such as \"HKCU\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL\".\n- Investigate the URL found in the registry data strings to determine if it is known to be malicious or associated with suspicious activity.\n- Check the modification history of the registry key to identify when the change occurred and which user or process made the modification.\n- Correlate the registry modification event with other security events on the host, such as network connections or process executions, to identify potential malicious activity.\n- Assess the affected system for signs of compromise, including unusual network traffic or unauthorized access attempts, to determine the scope of the incident.\n- Consult threat intelligence sources to see if the URL or related indicators are associated with known threat actors or campaigns.\n\n### False positive analysis\n\n- Legitimate software updates or installations may modify the registry keys associated with Outlook's Home Page feature. Users can create exceptions for known software update processes to prevent unnecessary alerts.\n- Custom scripts or administrative tools used by IT departments to configure Outlook settings across multiple machines might trigger this rule. Identifying and excluding these trusted scripts or tools can reduce false positives.\n- Some third-party Outlook add-ins or plugins may alter the registry keys for legitimate purposes. Users should verify the legitimacy of these add-ins and whitelist them if they are deemed safe.\n- Automated backup or recovery solutions that restore Outlook settings might cause registry changes. Users can exclude these processes if they are part of a regular and secure backup routine.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further communication with potentially malicious sites.\n- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the modified registry keys.\n- Restore the modified registry keys to their default values to remove the malicious URL configuration.\n- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.\n- Review and analyze network logs to identify any outbound connections to suspicious domains or IP addresses, and block these at the firewall.\n- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems are affected.\n- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and network activity.", - "query": "registry where host.os.type == \"windows\" and event.action != \"deletion\" and registry.value : \"URL\" and\n registry.path : (\n \"HKCU\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL\",\n \"HKEY_USERS\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL\",\n \"HKU\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL\",\n \"\\\\REGISTRY\\\\USER\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL\",\n \"USER\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL\"\n ) and registry.data.strings : \"*http*\"\n", - "references": [ - "https://cloud.google.com/blog/topics/threat-intelligence/breaking-the-rules-tough-outlook-for-home-page-attacks/", - "https://github.com/trustedsec/specula" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "m365_defender", - "version": "^2.0.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.data.strings", - "type": "wildcard" - }, - { - "ecs": true, - "name": "registry.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.value", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "ac5a2759-5c34-440a-b0c4-51fe674611d6", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Tactic: Persistence", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: SentinelOne", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1137", - "name": "Office Application Startup", - "reference": "https://attack.mitre.org/techniques/T1137/", - "subtechnique": [ - { - "id": "T1137.004", - "name": "Outlook Home Page", - "reference": "https://attack.mitre.org/techniques/T1137/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 202 - }, - "id": "ac5a2759-5c34-440a-b0c4-51fe674611d6_202", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_2.json b/packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_2.json new file mode 100644 index 00000000000..14af956e3dc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_2.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Linux Telegram API Request", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Linux Telegram API Request\n\nTelegram's API allows applications to interact with its messaging platform, often used for legitimate automation and communication tasks. However, adversaries may exploit this by using commands like `curl` or `wget` to communicate with Telegram's API for command and control purposes. The detection rule identifies such suspicious activity by monitoring for these commands accessing the Telegram API, indicating potential misuse.\n\n### Possible investigation steps\n\n- Review the process details to confirm the execution of the curl or wget command with the api.telegram.org domain in the command line, as indicated by the process.command_line field.\n- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if the account may be compromised.\n- Check the network activity logs to identify any additional connections to api.telegram.org or other suspicious domains, which may indicate further command and control communication.\n- Analyze the parent process of the detected curl or wget command to understand how the process was initiated and if it was triggered by another suspicious activity.\n- Examine the system for any other indicators of compromise, such as unusual file modifications or additional unauthorized processes, to assess the scope of potential malicious activity.\n\n### False positive analysis\n\n- Legitimate automation scripts or applications may use curl or wget to interact with Telegram's API for non-malicious purposes. Review the context and purpose of these scripts to determine if they are authorized.\n- System administrators or developers might use curl or wget for testing or maintenance tasks involving Telegram's API. Verify if these activities are part of routine operations and consider excluding them if they are deemed safe.\n- Monitoring tools or integrations that rely on Telegram for notifications could trigger this rule. Identify these tools and add exceptions for their known processes to prevent unnecessary alerts.\n- If a specific user or service account frequently triggers this rule due to legitimate use, consider creating an exception for that account to reduce noise while maintaining security oversight.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further communication with the Telegram API and potential data exfiltration.\n- Terminate any suspicious processes identified as using curl or wget to interact with api.telegram.org to halt ongoing malicious activities.\n- Conduct a thorough review of the affected system's process logs and network connections to identify any additional indicators of compromise or related malicious activity.\n- Remove any unauthorized scripts or binaries that may have been used to automate the interaction with the Telegram API.\n- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access.\n- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that could be exploited in similar attacks.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\nprocess.name in (\"curl\", \"wget\") and process.command_line like \"*api.telegram.org*\"\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "af1e36fe-0abd-4463-b5ec-4e276dec0b26", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\nElastic Defend integration does not collect environment variable logging by default.\nIn order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.\n #### To set up environment variable capture for an Elastic Agent policy:\n- Go to \u201cSecurity \u2192 Manage \u2192 Policies\u201d.\n- Select an \u201cElastic Agent policy\u201d.\n- Click \u201cShow advanced settings\u201d.\n- Scroll down or search for \u201clinux.advanced.capture_env_vars\u201d.\n- Enter the names of environment variables you want to capture, separated by commas.\n- For this rule the linux.advanced.capture_env_vars variable should be set to \"HTTP_PROXY,HTTPS_PROXY,ALL_PROXY\".\n- Click \u201cSave\u201d.\nAfter saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.\nFor more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/", + "subtechnique": [ + { + "id": "T1071.001", + "name": "Web Protocols", + "reference": "https://attack.mitre.org/techniques/T1071/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "af1e36fe-0abd-4463-b5ec-4e276dec0b26_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json new file mode 100644 index 00000000000..57a723fdcc7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Dynamic IEX Reconstruction via Environment Variables", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Dynamic IEX Reconstruction via Environment Variables\n\nPowerShell's Invoke-Expression (IEX) command is a powerful tool for executing strings as code, often exploited by attackers to run obfuscated scripts. Adversaries may dynamically reconstruct IEX using environment variables to evade static detection. The detection rule identifies scripts that manipulate environment variables to form IEX commands, focusing on patterns of character slicing and joining, which are indicative of obfuscation techniques. By analyzing script length and specific patterns, the rule effectively flags potential misuse, aiding in defense against such evasion tactics.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on how environment variables are manipulated to reconstruct the IEX command.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context on whether the activity is expected or suspicious.\n- Analyze the user.id and agent.id fields to identify the user and agent responsible for executing the script, checking for any anomalies or unauthorized access.\n- Investigate the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related PowerShell activities on the host.\n- Assess the count field to understand the extent of obfuscation patterns detected, which can indicate the complexity and potential maliciousness of the script.\n\n### False positive analysis\n\n- Scripts with legitimate use of environment variables for configuration management may trigger the rule. Users can create exceptions for specific scripts or processes known to use environment variables in a non-threatening manner.\n- Automated scripts that dynamically construct commands for legitimate administrative tasks might be flagged. Review the script's purpose and source, and whitelist trusted scripts or processes.\n- Development environments where scripts are frequently tested and modified may produce false positives. Implement monitoring exclusions for development machines or specific user accounts involved in script testing.\n- Scripts using environment variables for localization or language settings can be mistakenly identified. Identify and exclude scripts that are part of standard localization processes.\n- PowerShell scripts from trusted vendors or software packages that use environment variables for legitimate functionality should be reviewed and excluded from detection if verified as safe.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit lateral movement.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and associated file paths to understand the scope and intent of the script, focusing on any obfuscated commands or environment variable manipulations.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation patterns in PowerShell scripts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement additional monitoring for unusual PowerShell activity and environment variable manipulations to enhance detection of similar threats in the future.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "b0c98cfb-0745-4513-b6f9-08dddb033490", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b11116fd-023c-4718-aeb8-fa9d283fc53b_2.json b/packages/security_detection_engine/kibana/security_rule/b11116fd-023c-4718-aeb8-fa9d283fc53b_2.json new file mode 100644 index 00000000000..146a1ffbdd2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b11116fd-023c-4718-aeb8-fa9d283fc53b_2.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.file*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubeconfig File Creation or Modification", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubeconfig File Creation or Modification\nKubeconfig files are essential in Kubernetes environments, storing configurations for cluster access and management. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious creation or modification of kubeconfig files, excluding legitimate processes like kubeadm and minikube, to flag potential threats and mitigate risks associated with unauthorized access.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific file path involved in the creation or modification event, focusing on paths like \"/root/.kube/config\" or \"/etc/kubernetes/admin.conf\".\n- Examine the process responsible for the file creation or modification, ensuring it is not one of the excluded legitimate processes such as \"kubeadm\", \"kubelet\", \"vcluster\", or \"minikube\".\n- Check the user account associated with the process to determine if it has legitimate access to modify kubeconfig files and assess if the activity aligns with typical user behavior.\n- Investigate the timing of the event to see if it coincides with any scheduled maintenance or deployment activities that could explain the modification.\n- Look for any related alerts or logs that might indicate lateral movement or unauthorized access attempts within the Kubernetes cluster.\n- Assess the network activity from the host where the modification occurred to identify any suspicious connections or data transfers that could suggest unauthorized access or exfiltration.\n\n### False positive analysis\n\n- Legitimate administrative tools like kubeadm, kubelet, vcluster, and minikube may create or modify kubeconfig files as part of normal operations. Ensure these processes are excluded from triggering alerts by maintaining the exclusion list in the detection rule.\n- Automated scripts or configuration management tools that use sed to modify kubeconfig files might be flagged. Consider adding specific script names or paths to the exclusion list if they are verified as non-threatening.\n- User-initiated changes to kubeconfig files for legitimate access or configuration updates can trigger alerts. Implement a process to verify and document such changes, allowing for quick exclusion of known user actions.\n- Regular updates or maintenance activities that involve kubeconfig file modifications should be documented and excluded from detection. Coordinate with the operations team to identify and whitelist these activities.\n- Development environments where frequent kubeconfig changes occur, such as in testing or staging, may generate false positives. Establish a separate monitoring policy for these environments to reduce noise while maintaining security oversight.\n\n### Response and remediation\n\n- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the Kubernetes cluster.\n- Revoke any potentially compromised credentials associated with the kubeconfig files and issue new credentials to ensure secure access.\n- Conduct a thorough review of recent access logs and audit trails to identify any unauthorized access or suspicious activity related to the kubeconfig files.\n- Restore the kubeconfig files from a known good backup to ensure the integrity of the configuration and access settings.\n- Implement additional monitoring and alerting for any future modifications to kubeconfig files, focusing on processes not typically involved in legitimate changes.\n- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader Kubernetes environment.\n- Review and update Kubernetes access policies to ensure they align with best practices for security and least privilege, reducing the risk of unauthorized access.\n", + "query": "file where host.os.type == \"linux\" and event.type != \"deletion\" and file.path like (\n \"/root/.kube/config\",\n \"/home/*/.kube/config\",\n \"/etc/kubernetes/admin.conf\",\n \"/etc/kubernetes/super-admin.conf\",\n \"/etc/kubernetes/kubelet.conf\",\n \"/etc/kubernetes/controller-manager.conf\",\n \"/etc/kubernetes/scheduler.conf\",\n \"/var/lib/*/kubeconfig\"\n) and not (\n process.name in (\"kubeadm\", \"kubelet\", \"vcluster\", \"minikube\") or\n (process.name == \"sed\" and file.Ext.original.name like \"sed*\")\n)\n", + "references": [ + "https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/", + "https://kubenomicon.com/Initial_access/Kubeconfig_file.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "file.Ext.original.name", + "type": "unknown" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b11116fd-023c-4718-aeb8-fa9d283fc53b", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\n\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Defense Evasion", + "Tactic: Initial Access", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "b11116fd-023c-4718-aeb8-fa9d283fc53b_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_319.json b/packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_319.json new file mode 100644 index 00000000000..7fe6a3e7a00 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_319.json @@ -0,0 +1,118 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "A suspicious Endpoint Security parent process was detected. This may indicate a process hollowing or other form of code injection.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.process-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Endpoint Security Parent Process", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Endpoint Security Parent Process\n\nEndpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats.\n\n### Possible investigation steps\n\n- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment.\n- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside \"?:\\Program Files\\Elastic\\*\" or \"?:\\Windows\\System32\\*\".\n- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like \"test\", \"version\", or \"status\".\n- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes.\n- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and identify any related suspicious activities.\n- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption.\n\n### False positive analysis\n\n- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list.\n- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list.\n- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list.\n- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.\n- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files.\n- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised.\n- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary.\n- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : (\"esensor.exe\", \"elastic-endpoint.exe\") and\n process.parent.executable != null and\n process.args != null and\n /* add FPs here */\n not process.parent.executable : (\n \"?:\\\\Program Files\\\\Elastic\\\\*\",\n \"?:\\\\Windows\\\\System32\\\\services.exe\",\n \"?:\\\\Windows\\\\System32\\\\WerFault*.exe\",\n \"?:\\\\Windows\\\\System32\\\\wermgr.exe\",\n \"?:\\\\Windows\\\\explorer.exe\"\n ) and\n not (\n process.parent.executable : (\n \"?:\\\\Windows\\\\System32\\\\cmd.exe\",\n \"?:\\\\Windows\\\\System32\\\\SecurityHealthHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\SecurityHealth\\\\*\\\\SecurityHealthHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1.0\\\\powershell.exe\"\n ) and\n process.args : (\n \"test\", \"version\",\n \"top\", \"run\",\n \"*help\", \"status\",\n \"upgrade\", \"/launch\",\n \"/enable\", \"/av\"\n )\n )\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b41a13c6-ba45-4bab-a534-df53d0cfed6a", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1036", + "name": "Masquerading", + "reference": "https://attack.mitre.org/techniques/T1036/", + "subtechnique": [ + { + "id": "T1036.005", + "name": "Match Legitimate Resource Name or Location", + "reference": "https://attack.mitre.org/techniques/T1036/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 319 + }, + "id": "b41a13c6-ba45-4bab-a534-df53d0cfed6a_319", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b53f1d73-150d-484d-8f02-222abeb5d5fa_1.json b/packages/security_detection_engine/kibana/security_rule/b53f1d73-150d-484d-8f02-222abeb5d5fa_1.json new file mode 100644 index 00000000000..65c019f76c2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b53f1d73-150d-484d-8f02-222abeb5d5fa_1.json @@ -0,0 +1,123 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints, which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets, config maps, and other sensitive data, without using the official Kubernetes client tools such as \"kubectl\".", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubernetes Direct API Request via Curl or Wget", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Direct API Request via Curl or Wget\n\nKubernetes API endpoints are crucial for managing cluster resources. Adversaries may exploit tools like curl or wget to directly query these endpoints, bypassing standard clients like kubectl, to extract sensitive data such as secrets or config maps. The detection rule identifies such unauthorized access attempts by monitoring command executions that target specific API paths, flagging potential security threats.\n\n### Possible investigation steps\n\n- Review the process details to confirm the execution of curl or wget, focusing on the process.name and process.args fields to understand the exact command used and the specific Kubernetes API endpoint targeted.\n- Check the user context under which the curl or wget command was executed, including user ID and group ID, to determine if the action was performed by a legitimate user or an unauthorized entity.\n- Investigate the source IP address and host information to identify the origin of the request and assess whether it aligns with expected network activity within the Kubernetes environment.\n- Examine recent authentication and authorization logs for any anomalies or failed attempts that might indicate unauthorized access attempts to the Kubernetes API.\n- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities, such as unusual network traffic or access patterns.\n- Assess the potential impact by reviewing the specific Kubernetes resources targeted, such as secrets or config maps, to determine if sensitive data might have been exposed or compromised.\n\n### False positive analysis\n\n- Routine monitoring scripts or health checks that use curl or wget to verify the availability of Kubernetes API endpoints may trigger this rule. To manage this, identify and whitelist the specific scripts or IP addresses that are known to perform these checks regularly.\n- Automated backup processes that access Kubernetes secrets or config maps using curl or wget could be flagged. Exclude these processes by specifying their unique command patterns or execution contexts in the detection rule.\n- Developers or administrators using curl or wget for legitimate troubleshooting or testing purposes might inadvertently trigger the rule. Implement user-based exceptions for known and trusted personnel who require such access for their roles.\n- Integration tools or CI/CD pipelines that interact with Kubernetes APIs using curl or wget for deployment or configuration tasks may cause false positives. Create exceptions for these tools by identifying their process names or execution environments.\n- Security scanners or vulnerability assessment tools that probe Kubernetes API endpoints as part of their scanning routines can be mistaken for unauthorized access attempts. Whitelist these tools by their known signatures or execution patterns to prevent false alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access to Kubernetes API endpoints.\n- Revoke any potentially compromised credentials or tokens that may have been used in the unauthorized API requests.\n- Conduct a thorough review of Kubernetes audit logs to identify the scope of the unauthorized access and determine if any sensitive data was exfiltrated.\n- Reset and rotate all secrets and config maps that may have been accessed during the incident to ensure they are no longer valid.\n- Implement network segmentation and access controls to restrict direct access to Kubernetes API endpoints, ensuring only authorized clients can communicate with the API.\n- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.\n- Enhance monitoring and alerting for similar unauthorized access attempts by integrating additional threat intelligence and refining detection capabilities.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"executed\", \"process_started\") and\nprocess.name in (\"curl\", \"wget\") and process.args like~ (\n \"*http*//*/apis/authorization.k8s.io/*\",\n \"*http*//*/apis/rbac.authorization.k8s.io/*\",\n \"*http*//*/api/v1/secrets*\",\n \"*http*//*/api/v1/namespaces/*/secrets*\",\n \"*http*//*/api/v1/configmaps*\",\n \"*http*//*/api/v1/pods*\",\n \"*http*//*/apis/apps/v1/deployments*\"\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b53f1d73-150d-484d-8f02-222abeb5d5fa", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "b53f1d73-150d-484d-8f02-222abeb5d5fa_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_6.json b/packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_6.json new file mode 100644 index 00000000000..5e11d67b35f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_6.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.", + "false_positives": [ + "False positives can occur because the rules may be mapped to a few MITRE ATT&CK tactics. Use the attached Timeline to determine which detections were triggered on the host." + ], + "from": "now-24h", + "index": [ + ".alerts-security.*" + ], + "interval": "1h", + "language": "kuery", + "license": "Elastic License v2", + "name": "Multiple Alerts in Different ATT&CK Tactics on a Single Host", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Multiple Alerts in Different ATT&CK Tactics on a Single Host\n\nThe detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.\n- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.\n- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.\n- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.\n- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.\n- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.\n\n### False positive analysis\n\n- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.\n- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.\n- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.\n- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.\n- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.\n\n### Response and remediation\n\n- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.\n- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.\n- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.\n- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.\n- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.\n- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.\n- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.", + "query": "signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*\n", + "required_fields": [ + { + "ecs": false, + "name": "kibana.alert.rule.threat.tactic.id", + "type": "unknown" + }, + { + "ecs": false, + "name": "signal.rule.name", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threshold": { + "cardinality": [ + { + "field": "kibana.alert.rule.threat.tactic.id", + "value": 3 + } + ], + "field": [ + "host.id", + "host.name" + ], + "value": 1 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 6 + }, + "id": "b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bd18f4a3-c4c6-43b9-a1e4-b05e09998110_2.json b/packages/security_detection_engine/kibana/security_rule/bd18f4a3-c4c6-43b9-a1e4-b05e09998110_2.json new file mode 100644 index 00000000000..b53990c3e55 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/bd18f4a3-c4c6-43b9-a1e4-b05e09998110_2.json @@ -0,0 +1,98 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this file to gather information about shared directories and potential targets for further exploitation.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Manual Mount Discovery via /etc/exports or /etc/fstab", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Manual Mount Discovery via /etc/exports or /etc/fstab\n\nIn Linux environments, the `/etc/exports` and `/etc/fstab` files are crucial for managing shared directories and mounting filesystems, respectively. Adversaries may exploit these files to identify shared resources and potential targets for lateral movement. The detection rule identifies suspicious processes accessing these files, using common command-line utilities, to flag potential reconnaissance activities by attackers.\n\n### Possible investigation steps\n\n- Review the process details to identify the user account associated with the suspicious activity, focusing on the process.name and process.command_line fields.\n- Examine the command line arguments in the process.command_line field to determine the specific actions taken and whether they align with legitimate administrative tasks.\n- Check the process start time and correlate it with other system activities to identify any unusual patterns or sequences of events.\n- Investigate the source IP address or hostname if the process was initiated remotely, to assess whether it is a known or trusted entity.\n- Look for any other related alerts or logs around the same timeframe to identify potential lateral movement or further reconnaissance activities.\n- Verify if the accessed directories in /etc/exports or /etc/fstab are critical or sensitive, and assess the potential impact of unauthorized access.\n\n### False positive analysis\n\n- Routine system administration tasks may trigger alerts when administrators use command-line utilities to view or edit /etc/exports or /etc/fstab. To mitigate this, consider excluding processes executed by known administrator accounts or during scheduled maintenance windows.\n- Automated scripts for system monitoring or configuration management might access these files regularly. Identify and whitelist these scripts by their process names or command-line patterns to reduce false positives.\n- Backup operations often involve reading configuration files like /etc/exports or /etc/fstab. Exclude processes associated with backup software or services to prevent unnecessary alerts.\n- Security tools or compliance checks may scan these files as part of their regular operations. Review and whitelist these tools based on their process names or command-line arguments to avoid false positives.\n- Developers or testers might access these files in development environments for testing purposes. Consider excluding processes from development servers or specific user accounts associated with testing activities.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.\n- Conduct a thorough review of the `/etc/exports` and `/etc/fstab` files on the affected system to identify any unauthorized changes or suspicious entries.\n- Revoke any unauthorized access to shared directories identified in the `/etc/exports` file and ensure that only trusted hosts have access.\n- Reset credentials and review access permissions for users and services that have access to the affected system to prevent further unauthorized access.\n- Monitor network traffic for any unusual activity originating from the affected system, focusing on connections to external IPs or unexpected internal hosts.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.\n- Implement enhanced monitoring and logging for access to critical configuration files like `/etc/exports` and `/etc/fstab` to detect similar threats in the future.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\nprocess.name in (\"cat\", \"grep\", \"tail\", \"less\", \"more\", \"egrep\", \"fgrep\") and process.command_line like (\"/etc/exports\", \"/etc/fstab\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "bd18f4a3-c4c6-43b9-a1e4-b05e09998110", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "bd18f4a3-c4c6-43b9-a1e4-b05e09998110_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_2.json b/packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_2.json new file mode 100644 index 00000000000..31943e9fcad --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_2.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Data Exfiltration Through Curl", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Data Exfiltration Through Curl\n\nCurl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line to confirm the presence of suspicious arguments such as \"-F\", \"-T\", \"-d\", or \"--data*\" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server.\n- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose.\n- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity.\n- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration.\n- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt.\n\n### False positive analysis\n\n- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly.\n- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors.\n- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints.\n- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations.\n- Scheduled tasks or cron jobs that use curl for routine data uploads should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat.\n- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers.\n- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data.\n- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access.\n- Notify the security operations team and relevant stakeholders about the incident for awareness and further action.\n- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers.\n- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.name == \"curl\" and\nprocess.parent.executable != null and (process.args in (\"-F\", \"-T\", \"-d\") or process.args like \"--data*\") and \nprocess.command_line like~ (\"*@/*.zip*\", \"*@/*.gz*\", \"*@/*.tgz*\", \"*b64=@*\", \"*=<*\") and\nprocess.command_line like~ \"*http*\"\n", + "references": [ + "https://everything.curl.dev/usingcurl/uploads" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "be70614d-4295-473c-a953-582aef41c865", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\nElastic Defend integration does not collect environment variable logging by default.\nIn order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.\n #### To set up environment variable capture for an Elastic Agent policy:\n- Go to \u201cSecurity \u2192 Manage \u2192 Policies\u201d.\n- Select an \u201cElastic Agent policy\u201d.\n- Click \u201cShow advanced settings\u201d.\n- Scroll down or search for \u201clinux.advanced.capture_env_vars\u201d.\n- Enter the names of environment variables you want to capture, separated by commas.\n- For this rule the linux.advanced.capture_env_vars variable should be set to \"HTTP_PROXY,HTTPS_PROXY,ALL_PROXY\".\n- Click \u201cSave\u201d.\nAfter saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.\nFor more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1048", + "name": "Exfiltration Over Alternative Protocol", + "reference": "https://attack.mitre.org/techniques/T1048/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "be70614d-4295-473c-a953-582aef41c865_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_3.json deleted file mode 100644 index 775b4a2f76e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_3.json +++ /dev/null @@ -1,122 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies discovery request `DescribeInstanceAttribute` with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies when `aws.cloudtrail.user_identity.arn` requests the user data for a specific `aws.cloudtrail.flattened.request_parameters.instanceId` from an EC2 instance in the last 14 days.", - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 User Data Retrieval for EC2 Instance", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.flattened.request_parameters.instanceId" - ], - "note": "## Triage and Analysis\n\n### Investigating AWS EC2 User Data Retrieval for EC2 Instance\n\nThis rule detects requests to retrieve the `userData` attribute of an EC2 instance using the `DescribeInstanceAttribute` API action. The `userData` field can contain sensitive information, such as hardcoded credentials or configuration scripts, that adversaries may exploit for further attacks.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceId` field to identify the EC2 instance targeted by the request. Confirm whether this instance should expose its `userData` and whether it is associated with sensitive workloads.\n - **Analyze userData**: If possible, retrieve and inspect the `userData` field to identify sensitive information like hardcoded credentials or configuration scripts.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to identify the user or role that executed the `DescribeInstanceAttribute` action. Investigate whether this user typically performs such actions.\n - **Access Patterns**: Validate whether the user or role has the necessary permissions and whether the frequency of this action aligns with expected behavior.\n - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to determine the key used to make the request as it may be compromised.\n\n- **Analyze Request Details**:\n - **Parameters**: Verify that the `attribute=userData` parameter was explicitly requested. This indicates intentional access to user data.\n - **Source IP and Geolocation**: Check the `source.address` and `source.geo` fields to validate whether the request originated from a trusted location or network. Unexpected geolocations can indicate adversarial activity.\n\n- **Review Source Tool**:\n - **User Agent**: Inspect the `user_agent.original` field to determine the tool or client used (e.g., Terraform, AWS CLI). Legitimate automation tools may trigger this activity, but custom or unknown user agents may indicate malicious intent.\n\n- **Check for Related Activity**:\n - **IAM Changes**: Correlate this event with any IAM changes or temporary credential creation to identify potential privilege escalation attempts.\n - **API Usage**: Look for other unusual API calls (e.g., `RunInstances`, `GetObject`, `AssumeRole`) by the same user or IP to detect lateral movement or data exfiltration attempts.\n\n- **Validate Intent**:\n - **Permissions and Justification**: Ensure that the user has the least privilege required to perform this action. Investigate whether there is a valid reason for accessing the `userData` field.\n\n### False Positive Analysis\n\n- **Automation**: This event is often triggered by legitimate automation tools, such as Terraform or custom scripts, that require access to `userData` during instance initialization.\n- **Maintenance Activity**: Verify whether this event aligns with expected administrative activities, such as debugging or instance configuration updates.\n\n### Response and Remediation\n\n- **Revoke Excessive Permissions**: If unauthorized, immediately remove `DescribeInstanceAttribute` permissions from the user or role.\n- **Quarantine the Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance to limit further exposure.\n- **Secure User Data**:\n - Avoid storing sensitive information, such as credentials, in `userData`. Use AWS Secrets Manager or Parameter Store instead.\n - Encrypt user data and ensure only authorized users can decrypt it.\n- **Audit IAM Policies**: Regularly review IAM policies to ensure they adhere to the principle of least privilege.\n- **Monitor and Detect**: Set up additional alerts for unexpected `DescribeInstanceAttribute` calls or other suspicious API activity.\n\n### Additional Information\n\nFor more details on managing EC2 user data securely, refer to the [AWS EC2 User Data Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action: \"DescribeInstanceAttribute\"\n and event.outcome: \"success\"\n and aws.cloudtrail.request_parameters: (*attribute=userData* and *instanceId*)\n and not aws.cloudtrail.user_identity.invoked_by: (\n \"AWS Internal\" or\n \"cloudformation.amazonaws.com\"\n )\n", - "references": [ - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html", - "https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.request_parameters", - "type": "keyword" - }, - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.invoked_by", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "c1e79a70-fa6f-11ee-8bc8-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: Amazon EC2", - "Resources: Investigation Guide", - "Use Case: Log Auditing", - "Tactic: Discovery" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1552", - "name": "Unsecured Credentials", - "reference": "https://attack.mitre.org/techniques/T1552/", - "subtechnique": [ - { - "id": "T1552.005", - "name": "Cloud Instance Metadata API", - "reference": "https://attack.mitre.org/techniques/T1552/005/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 3 - }, - "id": "c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_1.json b/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_1.json deleted file mode 100644 index df364dcc3ad..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_1.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-30m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source", - "note": "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.", - "query": "from logs-azure.signinlogs*\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and to_lower(azure.signinlogs.properties.resource_display_name) rlike \"(.*)365(.*)\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome != \"success\"\n\n // For tuning, review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// Count the number of unique targets per source IP\n| stats\n target_count = count_distinct(azure.signinlogs.properties.user_principal_name) by source.ip\n\n// Filter for at least 10 distinct failed login attempts from a single source\n| where target_count >= 10\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" - ], - "risk_score": 47, - "rule_id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_208.json b/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_208.json new file mode 100644 index 00000000000..fcf8ad2ecf3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_208.json @@ -0,0 +1,108 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.", + "false_positives": [ + "By default a container is not allowed to access any devices on the host, but a \"privileged\" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. An administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Privileged Pod Created", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Privileged Pod Created\n\nKubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields.\n- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.\n- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.\n- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.\n- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.\n\n### False positive analysis\n\n- Known safe images like \"docker.elastic.co/beats/elastic-agent:8.4.0\" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.\n- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.\n- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.\n- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.\n- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.\n- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.\n- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.\n- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.\n- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.\n- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:pods\n and kubernetes.audit.verb:create\n and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", + "references": [ + "https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF", + "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.image", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.securityContext.privileged", + "type": "boolean" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "c7908cac-337a-4f38-b50d-5eeb78bdb531", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 208 + }, + "id": "c7908cac-337a-4f38-b50d-5eeb78bdb531_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_2.json new file mode 100644 index 00000000000..9ba042c2904 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Sign-In Brute Force Activity", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Sign-In Brute Force Activity\n\nThis rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response.\n\n### Possible investigation steps\n\n- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`).\n- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted.\n- Review `login_errors`: Repetitive error types like `\"Invalid Grant\"` or `\"User Not Found\"` suggest automated attacks.\n- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.).\n- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks.\n- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation.\n- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools.\n- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms.\n- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts.\n- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly.\n\n### False positive analysis\n\n- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures.\n- Internal red team activity or penetration tests may mimic brute-force behaviors.\n- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured.\n\n### Response and remediation\n\n- Notify your identity security team for further analysis.\n- Investigate and lock or reset impacted accounts if compromise is suspected.\n- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access.\n- Confirm MFA and Conditional Access are enforced for all user types.\n- Audit targeted accounts for credential reuse across services.\n- Implement account lockout or throttling for failed sign-in attempts where possible.\n", + "query": "FROM logs-azure.signinlogs*\n\n// Define a time window for grouping and maintain the original event timestamp\n| EVAL\n time_window = DATE_TRUNC(15 minutes, @timestamp),\n event_time = @timestamp\n\n// Filter relevant failed authentication events with specific error codes\n| WHERE event.dataset == \"azure.signinlogs\"\n AND event.category == \"authentication\"\n AND azure.signinlogs.category IN (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n AND event.outcome == \"failure\"\n AND azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n AND azure.signinlogs.properties.status.error_code IN (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n AND azure.signinlogs.properties.user_principal_name IS NOT NULL AND azure.signinlogs.properties.user_principal_name != \"\"\n AND user_agent.original != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n AND source.`as`.organization.name != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n\n// Aggregate statistics for behavioral pattern analysis\n| STATS\n authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n client_app_id = VALUES(azure.signinlogs.properties.app_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n target_resource_id = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id),\n device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n user_id = VALUES(azure.signinlogs.properties.user_id),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n result_description = VALUES(azure.signinlogs.result_description),\n result_signature = VALUES(azure.signinlogs.result_signature),\n result_type = VALUES(azure.signinlogs.result_type),\n\n unique_users = COUNT_DISTINCT(azure.signinlogs.properties.user_id),\n user_id_list = VALUES(azure.signinlogs.properties.user_id),\n login_errors = VALUES(azure.signinlogs.result_description),\n unique_login_errors = COUNT_DISTINCT(azure.signinlogs.result_description),\n error_codes = VALUES(azure.signinlogs.properties.status.error_code),\n unique_error_codes = COUNT_DISTINCT(azure.signinlogs.properties.status.error_code),\n request_types = VALUES(azure.signinlogs.properties.incoming_token_type),\n app_names = VALUES(azure.signinlogs.properties.app_display_name),\n ip_list = VALUES(source.ip),\n unique_ips = COUNT_DISTINCT(source.ip),\n source_orgs = VALUES(source.`as`.organization.name),\n countries = VALUES(source.geo.country_name),\n unique_country_count = COUNT_DISTINCT(source.geo.country_name),\n unique_asn_orgs = COUNT_DISTINCT(source.`as`.organization.name),\n first_seen = MIN(@timestamp),\n last_seen = MAX(@timestamp),\n total_attempts = COUNT()\nBY time_window\n\n// Determine brute force behavior type based on statistical thresholds\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen),\n bf_type = CASE(\n // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many),\n // and happens quickly. Often bots using leaked credentials.\n unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3\n AND unique_ips >= 5\n AND duration_seconds <= 600\n AND unique_users > unique_ips,\n \"credential_stuffing\",\n\n // One password against many users. Single error (e.g., \"InvalidPassword\"), not necessarily fast.\n unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800,\n \"password_spraying\",\n\n // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs.\n (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300)\n OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100),\n \"password_guessing\",\n\n // everything else\n \"other\"\n )\n\n// Only keep columns necessary for detection output/reporting\n| KEEP\n time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen,\n unique_users, user_id_list, login_errors, unique_login_errors,\n unique_error_codes, error_codes, request_types, app_names,\n ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs,\n authentication_requirement, client_app_id, client_app_display_name,\n target_resource_id, target_resource_display_name, conditional_access_status,\n device_detail_browser, device_detail_device_id, device_detail_operating_system,\n incoming_token_type, risk_state, session_id, user_id,\n user_principal_name, result_description, result_signature, result_type\n\n// Remove anything not classified as credential attack activity\n| WHERE bf_type != \"other\"\n", + "references": [ + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/", + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "cca64114-fb8b-11ef-86e2-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "cca64114-fb8b-11ef-86e2-f661ea17fbce_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cd82e3d6-1346-4afd-8f22-38388bbf34cb_4.json b/packages/security_detection_engine/kibana/security_rule/cd82e3d6-1346-4afd-8f22-38388bbf34cb_4.json deleted file mode 100644 index 9ed9946c056..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cd82e3d6-1346-4afd-8f22-38388bbf34cb_4.json +++ /dev/null @@ -1,110 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies .url shortcut files downloaded from outside the local network. These shortcut files are commonly used in phishing campaigns.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.file-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Downloaded URL Files", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Downloaded URL Files\n\nURL shortcut files, typically used for quick access to web resources, can be exploited by attackers in phishing schemes to execute malicious content. These files, when downloaded from non-local sources, may bypass traditional security measures. The detection rule identifies such files by monitoring their creation events on Windows systems, focusing on those not initiated by standard processes like Explorer, and flags them based on their network origin, aiding in early threat detection.\n\n### Possible investigation steps\n\n- Review the file creation event details to confirm the file extension is \".url\" and verify the zone identifier is greater than 1, indicating a non-local source.\n- Investigate the process that created the .url file, ensuring it was not initiated by \"explorer.exe\" and identify the actual process responsible for the creation.\n- Check the network origin of the downloaded .url file to determine if it is from a known malicious domain or IP address.\n- Analyze the contents of the .url file to identify the target URL and assess its reputation and potential risk.\n- Correlate the event with other security alerts or logs from the same host to identify any additional suspicious activities or patterns.\n- Contact the user associated with the alert to verify if they intentionally downloaded the file and gather any additional context regarding their actions.\n\n### False positive analysis\n\n- Corporate applications that generate .url files for legitimate purposes may trigger alerts. Identify these applications and create exceptions for their processes to prevent unnecessary alerts.\n- Automated scripts or system management tools that download .url files as part of routine operations can be mistaken for threats. Review these tools and whitelist their activities if they are verified as safe.\n- User-initiated downloads from trusted internal web portals might be flagged. Educate users on safe downloading practices and consider excluding specific trusted domains from monitoring.\n- Security software updates or patches that include .url files could be misidentified. Verify the source of these updates and adjust the rule to exclude known safe update processes.\n- Collaboration platforms that share .url files for internal use may cause false positives. Evaluate the platform's behavior and exclude its processes if they are deemed secure.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of any potential malicious activity.\n- Terminate any suspicious processes that are not initiated by standard processes like Explorer, especially those related to the creation of .url files.\n- Delete the identified .url files from the system to remove the immediate threat.\n- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats.\n- Review and analyze the network logs to identify any other systems that may have downloaded similar .url files and apply the same containment measures.\n- Escalate the incident to the security operations team for further investigation and to determine if there is a broader campaign targeting the organization.\n- Update security policies and endpoint protection configurations to block the download and execution of .url files from untrusted sources in the future.", - "query": "file where host.os.type == \"windows\" and event.type == \"creation\" and file.extension == \"url\"\n and file.Ext.windows.zone_identifier > 1 and not process.name : \"explorer.exe\"\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "file.Ext.windows.zone_identifier", - "type": "unknown" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "cd82e3d6-1346-4afd-8f22-38388bbf34cb", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1204", - "name": "User Execution", - "reference": "https://attack.mitre.org/techniques/T1204/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1566", - "name": "Phishing", - "reference": "https://attack.mitre.org/techniques/T1566/", - "subtechnique": [ - { - "id": "T1566.001", - "name": "Spearphishing Attachment", - "reference": "https://attack.mitre.org/techniques/T1566/001/" - }, - { - "id": "T1566.002", - "name": "Spearphishing Link", - "reference": "https://attack.mitre.org/techniques/T1566/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 4 - }, - "id": "cd82e3d6-1346-4afd-8f22-38388bbf34cb_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_214.json b/packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_214.json deleted file mode 100644 index 88f25361c1e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_214.json +++ /dev/null @@ -1,106 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects known PowerShell offensive tooling functions names in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code. This rule aim is to take advantage of that.", - "filters": [ - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" - } - } - } - } - ], - "from": "now-9m", - "index": [ - "winlogbeat-*", - "logs-windows.powershell*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Potential PowerShell HackTool Script by Function Names", - "note": "## Triage and analysis\n\n### Investigating Potential PowerShell HackTool Script by Function Names\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAdversaries often exploit PowerShell's capabilities to execute malicious scripts and perform various attacks. This rule identifies known offensive tooling function names in PowerShell scripts, as attackers commonly use out-of-the-box tools without modifying the code. By monitoring these specific function names, the rule aims to detect and alert potential malicious PowerShell activity.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine the script's execution context, such as the user account, privileges, the role of the system on which it was executed, and any relevant timestamps.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate the origin of the PowerShell script, including its source, download method, and any associated URLs or IP addresses.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the script using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- This rule may generate false positives if legitimate scripts or tools used by administrators contain any of the listed function names. These function names are commonly associated with offensive tooling, but they may also be present in benign scripts or tools.\n- To handle these false positives consider adding exceptions - preferably with a combination of full file path and users.\n\n### Related Rules\n\n- PowerShell Invoke-NinjaCopy script - b8386923-b02c-4b94-986a-d223d9b01f88\n- PowerShell Suspicious Discovery Related Windows API Functions - 61ac3638-40a3-44b2-855a-985636ca985e\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Reimage the host operating system or restore the compromised files to clean versions.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n \"Add-DomainGroupMember\" or \"Add-DomainObjectAcl\" or\n \"Add-RemoteConnection\" or \"Add-ServiceDacl\" or\n \"Add-Win32Type\" or \"Convert-ADName\" or\n \"Convert-LDAPProperty\" or \"ConvertFrom-LDAPLogonHours\" or\n \"ConvertFrom-UACValue\" or \"Copy-ArrayOfMemAddresses\" or\n \"Create-NamedPipe\" or \"Create-ProcessWithToken\" or\n \"Create-RemoteThread\" or \"Create-SuspendedWinLogon\" or\n \"Create-WinLogonProcess\" or \"Emit-CallThreadStub\" or\n \"Enable-SeAssignPrimaryTokenPrivilege\" or \"Enable-SeDebugPrivilege\" or\n \"Enum-AllTokens\" or \"Export-PowerViewCSV\" or\n \"Find-AVSignature\" or \"Find-AppLockerLog\" or\n \"Find-DomainLocalGroupMember\" or \"Find-DomainObjectPropertyOutlier\" or\n \"Find-DomainProcess\" or \"Find-DomainShare\" or\n \"Find-DomainUserEvent\" or \"Find-DomainUserLocation\" or\n \"Find-InterestingDomainAcl\" or \"Find-InterestingDomainShareFile\" or\n \"Find-InterestingFile\" or \"Find-LocalAdminAccess\" or\n \"Find-PSScriptsInPSAppLog\" or \"Find-PathDLLHijack\" or\n \"Find-ProcessDLLHijack\" or \"Find-RDPClientConnection\" or\n \"Get-AllAttributesForClass\" or \"Get-CachedGPPPassword\" or\n \"Get-DecryptedCpassword\" or \"Get-DecryptedSitelistPassword\" or\n \"Get-DelegateType\" or \"New-RelayEnumObject\" or\n \"Get-DomainDFSShare\" or \"Get-DomainDFSShareV1\" or\n \"Get-DomainDFSShareV2\" or \"Get-DomainDNSRecord\" or\n \"Get-DomainDNSZone\" or \"Get-DomainFileServer\" or\n \"Get-DomainForeignGroupMember\" or \"Get-DomainForeignUser\" or\n \"Get-DomainGPO\" or \"Get-DomainGPOComputerLocalGroupMapping\" or\n \"Get-DomainGPOLocalGroup\" or \"Get-DomainGPOUserLocalGroupMapping\" or\n \"Get-DomainGUIDMap\" or \"Get-DomainGroup\" or\n \"Get-DomainGroupMember\" or \"Get-DomainGroupMemberDeleted\" or\n \"Get-DomainManagedSecurityGroup\" or \"Get-DomainOU\" or\n \"Get-DomainObject\" or \"Get-DomainObjectAcl\" or\n \"Get-DomainObjectAttributeHistory\" or \"Get-DomainObjectLinkedAttributeHistory\" or\n \"Get-DomainPolicyData\" or \"Get-DomainSID\" or\n \"Get-DomainSPNTicket\" or \"Get-DomainSearcher\" or\n \"Get-DomainSite\" or \"Get-DomainSubnet\" or\n \"Get-DomainTrust\" or \"Get-DomainTrustMapping\" or\n \"Get-DomainUser\" or \"Get-DomainUserEvent\" or\n \"Get-Forest\" or \"Get-ForestDomain\" or\n \"Get-ForestGlobalCatalog\" or \"Get-ForestSchemaClass\" or\n \"Get-ForestTrust\" or \"Get-GPODelegation\" or\n \"Get-GPPAutologon\" or \"Get-GPPInnerField\" or\n \"Get-GPPInnerFields\" or \"Get-GPPPassword\" or\n \"Get-GptTmpl\" or \"Get-GroupsXML\" or\n \"Get-HttpStatus\" or \"Get-ImageNtHeaders\" or\n \"Get-Keystrokes\" or \"New-SOASerialNumberArray\" or \n \"Get-MemoryProcAddress\" or \"Get-MicrophoneAudio\" or\n \"Get-ModifiablePath\" or \"Get-ModifiableRegistryAutoRun\" or\n \"Get-ModifiableScheduledTaskFile\" or \"Get-ModifiableService\" or\n \"Get-ModifiableServiceFile\" or \"Get-Name\" or\n \"Get-NetComputerSiteName\" or \"Get-NetLocalGroup\" or\n \"Get-NetLocalGroupMember\" or \"Get-NetLoggedon\" or\n \"Get-NetRDPSession\" or \"Get-NetSession\" or\n \"Get-NetShare\" or \"Get-PEArchitecture\" or\n \"Get-PEBasicInfo\" or \"Get-PEDetailedInfo\" or\n \"Get-PathAcl\" or \"Get-PrimaryToken\" or\n \"Get-ProcAddress\" or \"Get-ProcessTokenGroup\" or\n \"Get-ProcessTokenPrivilege\" or \"Get-ProcessTokenType\" or\n \"Get-RegLoggedOn\" or \"Get-RegistryAlwaysInstallElevated\" or\n \"Get-RegistryAutoLogon\" or \"Get-RemoteProcAddress\" or\n \"Get-Screenshot\" or \"Get-ServiceDetail\" or\n \"Get-SiteListPassword\" or \"Get-SitelistField\" or\n \"Get-System\" or \"Get-SystemNamedPipe\" or\n \"Get-SystemToken\" or \"Get-ThreadToken\" or\n \"Get-TimedScreenshot\" or \"Get-TokenInformation\" or\n \"Get-TopPort\" or \"Get-UnattendedInstallFile\" or\n \"Get-UniqueTokens\" or \"Get-UnquotedService\" or\n \"Get-VaultCredential\" or \"Get-VaultElementValue\" or\n \"Get-VirtualProtectValue\" or \"Get-VolumeShadowCopy\" or\n \"Get-WMIProcess\" or \"Get-WMIRegCachedRDPConnection\" or\n \"Get-WMIRegLastLoggedOn\" or \"Get-WMIRegMountedDrive\" or\n \"Get-WMIRegProxy\" or \"Get-WebConfig\" or\n \"Get-Win32Constants\" or \"Get-Win32Functions\" or\n \"Get-Win32Types\" or \"Import-DllImports\" or\n \"Import-DllInRemoteProcess\" or \"Inject-LocalShellcode\" or\n \"Inject-RemoteShellcode\" or \"Install-ServiceBinary\" or\n \"Invoke-CompareAttributesForClass\" or \"Invoke-CreateRemoteThread\" or\n \"Invoke-CredentialInjection\" or \"Invoke-DllInjection\" or\n \"Invoke-EventVwrBypass\" or \"Invoke-ImpersonateUser\" or\n \"Invoke-Kerberoast\" or \"Invoke-MemoryFreeLibrary\" or\n \"Invoke-MemoryLoadLibrary\" or\n \"Invoke-Mimikatz\" or \"Invoke-NinjaCopy\" or\n \"Invoke-PatchDll\" or \"Invoke-Portscan\" or\n \"Invoke-PrivescAudit\" or \"Invoke-ReflectivePEInjection\" or\n \"Invoke-ReverseDnsLookup\" or \"Invoke-RevertToSelf\" or\n \"Invoke-ServiceAbuse\" or \"Invoke-Shellcode\" or\n \"Invoke-TokenManipulation\" or \"Invoke-UserImpersonation\" or\n \"Invoke-WmiCommand\" or \"Mount-VolumeShadowCopy\" or\n \"New-ADObjectAccessControlEntry\" or \"New-DomainGroup\" or\n \"New-DomainUser\" or \"New-DynamicParameter\" or\n \"New-InMemoryModule\" or\n \"New-ThreadedFunction\" or \"New-VolumeShadowCopy\" or\n \"Out-CompressedDll\" or \"Out-EncodedCommand\" or\n \"Out-EncryptedScript\" or \"Out-Minidump\" or\n \"PortScan-Alive\" or \"Portscan-Port\" or\n \"Remove-DomainGroupMember\" or \"Remove-DomainObjectAcl\" or\n \"Remove-RemoteConnection\" or \"Remove-VolumeShadowCopy\" or\n \"Restore-ServiceBinary\" or \"Set-DesktopACLToAllowEveryone\" or\n \"Set-DesktopACLs\" or \"Set-DomainObject\" or\n \"Set-DomainObjectOwner\" or \"Set-DomainUserPassword\" or\n \"Set-ServiceBinaryPath\" or \"Sub-SignedIntAsUnsigned\" or\n \"Test-AdminAccess\" or \"Test-MemoryRangeValid\" or\n \"Test-ServiceDaclPermission\" or \"Update-ExeFunctions\" or\n \"Update-MemoryAddresses\" or \"Update-MemoryProtectionFlags\" or\n \"Write-BytesToMemory\" or \"Write-HijackDll\" or\n \"Write-PortscanOut\" or \"Write-ServiceBinary\" or\n \"Write-UserAddMSI\" or \"Invoke-Privesc\" or\n \"func_get_proc_address\" or \"Invoke-BloodHound\" or\n \"Invoke-HostEnum\" or \"Get-BrowserInformation\" or\n \"Get-DomainAccountPolicy\" or \"Get-DomainAdmins\" or\n \"Get-AVProcesses\" or \"Get-AVInfo\" or\n \"Get-RecycleBin\" or \"Invoke-BruteForce\" or\n \"Get-PassHints\" or \"Invoke-SessionGopher\" or\n \"Get-LSASecret\" or \"Get-PassHashes\" or\n \"Invoke-WdigestDowngrade\" or \"Get-ChromeDump\" or\n \"Invoke-DomainPasswordSpray\" or \"Get-FoxDump\" or\n \"New-HoneyHash\" or \"Invoke-DCSync\" or\n \"Invoke-PowerDump\" or \"Invoke-SSIDExfil\" or\n \"Invoke-PowerShellTCP\" or \"Add-Exfiltration\" or\n \"Do-Exfiltration\" or \"Invoke-DropboxUpload\" or\n \"Invoke-ExfilDataToGitHub\" or \"Invoke-EgressCheck\" or\n \"Invoke-PostExfil\" or \"Create-MultipleSessions\" or\n \"Invoke-NetworkRelay\" or \"New-GPOImmediateTask\" or\n \"Invoke-WMIDebugger\" or \"Invoke-SQLOSCMD\" or\n \"Invoke-SMBExec\" or \"Invoke-PSRemoting\" or\n \"Invoke-ExecuteMSBuild\" or \"Invoke-DCOM\" or\n \"Invoke-InveighRelay\" or \"Invoke-PsExec\" or\n \"Invoke-SSHCommand\" or \"Find-ActiveUsersWMI\" or\n \"Get-SystemDrivesWMI\" or \"Get-ActiveNICSWMI\" or\n \"Remove-Persistence\" or \"DNS_TXT_Pwnage\" or\n \"Execute-OnTime\" or \"HTTP-Backdoor\" or\n \"Add-ConstrainedDelegationBackdoor\" or \"Add-RegBackdoor\" or\n \"Add-ScrnSaveBackdoor\" or \"Gupt-Backdoor\" or\n \"Invoke-ADSBackdoor\" or \"Add-Persistence\" or\n \"Invoke-ResolverBackdoor\" or \"Invoke-EventLogBackdoor\" or\n \"Invoke-DeadUserBackdoor\" or \"Invoke-DisableMachineAcctChange\" or\n \"Invoke-AccessBinary\" or \"Add-NetUser\" or\n \"Invoke-Schtasks\" or \"Invoke-JSRatRegsvr\" or\n \"Invoke-JSRatRundll\" or \"Invoke-PoshRatHttps\" or\n \"Invoke-PsGcatAgent\" or \"Remove-PoshRat\" or\n \"Install-SSP\" or \"Invoke-BackdoorLNK\" or\n \"PowerBreach\" or \"InstallEXE-Persistence\" or\n \"RemoveEXE-Persistence\" or \"Install-ServiceLevel-Persistence\" or\n \"Remove-ServiceLevel-Persistence\" or \"Invoke-Prompt\" or\n \"Invoke-PacketCapture\" or \"Start-WebcamRecorder\" or\n \"Get-USBKeyStrokes\" or \"Invoke-KeeThief\" or\n \"Get-Keystrokes\" or \"Invoke-NetRipper\" or\n \"Get-EmailItems\" or \"Invoke-MailSearch\" or\n \"Invoke-SearchGAL\" or \"Get-WebCredentials\" or\n \"Start-CaptureServer\" or \"Invoke-PowerShellIcmp\" or\n \"Invoke-PowerShellTcpOneLine\" or \"Invoke-PowerShellTcpOneLineBind\" or\n \"Invoke-PowerShellUdp\" or \"Invoke-PowerShellUdpOneLine\" or\n \"Run-EXEonRemote\" or \"Download-Execute-PS\" or\n \"Out-RundllCommand\" or \"Set-RemoteWMI\" or\n \"Set-DCShadowPermissions\" or \"Invoke-PowerShellWMI\" or\n \"Invoke-Vnc\" or \"Invoke-LockWorkStation\" or\n \"Invoke-EternalBlue\" or \"Invoke-ShellcodeMSIL\" or\n \"Invoke-MetasploitPayload\" or \"Invoke-DowngradeAccount\" or\n \"Invoke-RunAs\" or \"ExetoText\" or\n \"Disable-SecuritySettings\" or \"Set-MacAttribute\" or\n \"Invoke-MS16032\" or \"Invoke-BypassUACTokenManipulation\" or\n \"Invoke-SDCLTBypass\" or \"Invoke-FodHelperBypass\" or\n \"Invoke-EventVwrBypass\" or \"Invoke-EnvBypass\" or\n \"Get-ServiceUnquoted\" or \"Get-ServiceFilePermission\" or\n \"Get-ServicePermission\" or\n \"Enable-DuplicateToken\" or \"Invoke-PsUaCme\" or\n \"Invoke-Tater\" or \"Invoke-WScriptBypassUAC\" or\n \"Invoke-AllChecks\" or \"Find-TrustedDocuments\" or\n \"Invoke-Interceptor\" or \"Invoke-PoshRatHttp\" or\n \"Invoke-ExecCommandWMI\" or \"Invoke-KillProcessWMI\" or\n \"Invoke-CreateShareandExecute\" or \"Invoke-RemoteScriptWithOutput\" or\n \"Invoke-SchedJobManipulation\" or \"Invoke-ServiceManipulation\" or\n \"Invoke-PowerOptionsWMI\" or \"Invoke-DirectoryListing\" or\n \"Invoke-FileTransferOverWMI\" or \"Invoke-WMImplant\" or\n \"Invoke-WMIObfuscatedPSCommand\" or \"Invoke-WMIDuplicateClass\" or\n \"Invoke-WMIUpload\" or \"Invoke-WMIRemoteExtract\" or \"Invoke-winPEAS\"\n ) and\n not powershell.file.script_block_text : (\n \"sentinelbreakpoints\" and \"Set-PSBreakpoint\"\n ) and\n not user.id : (\"S-1-5-18\" or \"S-1-5-19\")\n", - "references": [ - "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md", - "https://github.com/BC-SECURITY/Empire" - ], - "related_integrations": [ - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "unknown" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "cde1bafa-9f01-4f43-a872-605b678968b0", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 214 - }, - "id": "cde1bafa-9f01-4f43-a872-605b678968b0_214", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ce73954b-a0a4-4f05-b67b-294c500dac77_2.json b/packages/security_detection_engine/kibana/security_rule/ce73954b-a0a4-4f05-b67b-294c500dac77_2.json new file mode 100644 index 00000000000..7241f398d9a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ce73954b-a0a4-4f05-b67b-294c500dac77_2.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubernetes Service Account Secret Access", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Service Account Secret Access\n\nKubernetes service account secrets are crucial for authenticating applications within clusters, providing access to necessary resources. Adversaries may exploit these secrets to escalate privileges or move laterally within the cluster. The detection rule identifies unauthorized access by monitoring processes that interact with secret file paths or specific secret files, flagging potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line and working directory to confirm if the access to the service account secrets was expected or authorized. Check for any known applications or scripts that should have access to these paths.\n- Investigate the user or service account under which the process was executed to determine if it has legitimate reasons to access the Kubernetes service account secrets.\n- Examine the process arguments, specifically looking for access to files like \"ca.crt\", \"token\", and \"namespace\", to understand the nature of the access and whether it aligns with normal operations.\n- Check the history of the process and any associated processes to identify if there are any patterns of unauthorized access or if this is an isolated incident.\n- Correlate the event with other logs or alerts from the same host or cluster to identify any signs of privilege escalation or lateral movement attempts.\n- Assess the risk score and severity in the context of the environment to prioritize the investigation and response actions accordingly.\n\n### False positive analysis\n\n- Routine access by system processes or monitoring tools can trigger false positives. Identify these processes and create exceptions to prevent unnecessary alerts.\n- Automated scripts or applications that regularly access service account secrets for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening.\n- Development and testing environments often have processes accessing service account secrets as part of normal operations. Exclude these environments from the rule or adjust the rule's scope to focus on production environments.\n- Frequent access by container orchestration tools or agents that manage Kubernetes clusters can be mistaken for unauthorized access. Ensure these tools are recognized and excluded from triggering alerts.\n- Scheduled jobs or cron tasks that interact with service account secrets for maintenance or updates might be flagged. Validate these tasks and add them to an exception list if they are part of regular operations.\n\n### Response and remediation\n\n- Immediately isolate the affected pod or container to prevent further unauthorized access or lateral movement within the cluster.\n- Revoke and rotate the compromised service account credentials to prevent further misuse. Ensure that new credentials are securely distributed and stored.\n- Conduct a thorough review of access logs to identify any unauthorized actions or data access that occurred using the compromised credentials.\n- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the cluster and associated resources.\n- Implement network segmentation and access controls to limit the exposure of sensitive secrets and reduce the risk of unauthorized access in the future.\n- Enhance monitoring and alerting for unusual access patterns to Kubernetes service account secrets to detect similar threats promptly.\n- Review and update Kubernetes security policies to enforce least privilege access and ensure that service accounts have only the necessary permissions for their intended functions.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.command_line like (\n \"*/run/secrets/kubernetes.io/serviceaccount*\",\n \"*/var/run/secrets/kubernetes.io/serviceaccount*\",\n \"*/secrets/kubernetes.io/serviceaccount*\"\n ) or (\n process.working_directory like (\n \"/run/secrets/kubernetes.io/serviceaccount\",\n \"/var/run/secrets/kubernetes.io/serviceaccount\",\n \"/secrets/kubernetes.io/serviceaccount\"\n ) and\n process.args in (\"ca.crt\", \"token\", \"namespace\")\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "ce73954b-a0a4-4f05-b67b-294c500dac77", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1552", + "name": "Unsecured Credentials", + "reference": "https://attack.mitre.org/techniques/T1552/" + }, + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "ce73954b-a0a4-4f05-b67b-294c500dac77_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d121f0a8-4875-11f0-bb2b-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/d121f0a8-4875-11f0-bb2b-f661ea17fbcd_1.json new file mode 100644 index 00000000000..10e8fce302f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d121f0a8-4875-11f0-bb2b-f661ea17fbcd_1.json @@ -0,0 +1,106 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session.", + "from": "now-9m", + "index": [ + "filebeat-*", + "logs-azure.signinlogs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious ADRS Token Request by Microsoft Auth Broker", + "note": "## Triage and analysis\n\n### Investigating Suspicious ADRS Token Request by Microsoft Auth Broker\n\nDetects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session.\n\n### Possible investigation steps\n- Identify the user principal associated with the request by checking `azure.signinlogs.properties.user_principal_name` or `azure.signinlogs.properties.user_id`.\n- Review the `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.resource_id` to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service.\n- Examine the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` for the presence of `adrs_access`, indicating an attempt to access ADRS.\n- Check the `azure.signinlogs.properties.incoming_token_type` to confirm the request is made using a refresh token, which is typical for persistent access scenarios.\n- Review the `azure.signinlogs.properties.user_type` to ensure it is a \"Member\" user, as this behavior is unusual for standard user accounts.\n- Review the `source.address` and `source.geo.country_name` to identify the origin of the request. Look for any anomalies or unexpected locations.\n- Check the `azure.signinlogs.properties.device_detail.operating_system` and `azure.signinlogs.properties.device_detail.browser` to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user.\n- Use the `azure.signinlogs.properties.session_id` to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame.\n- Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status.\n- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts.\n\n### False positive analysis\n- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts.\n- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time.\n\n### Response and remediation\n- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.\n- Disable the user account temporarily to prevent any potential compromise or unauthorized access.\n- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.\n- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.\n- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.\n- Consider deactivating any newly registered devices associated with the user account until further investigation is complete.\n", + "query": "event.dataset: \"azure.signinlogs\" and\n azure.signinlogs.properties.app_id : \"29d9ed98-a469-4536-ade2-f981bc1d605e\" and\n azure.signinlogs.properties.resource_id : \"01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9\" and\n azure.signinlogs.category: \"NonInteractiveUserSignInLogs\" and\n azure.signinlogs.properties.authentication_processing_details: *adrs_access* and\n azure.signinlogs.properties.incoming_token_type: \"refreshToken\" and\n azure.signinlogs.properties.user_type: \"Member\"\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.app_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.authentication_processing_details", + "type": "flattened" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.incoming_token_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.resource_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.user_type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "d121f0a8-4875-11f0-bb2b-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Use Case: Identity and Access Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.005", + "name": "Device Registration", + "reference": "https://attack.mitre.org/techniques/T1098/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "d121f0a8-4875-11f0-bb2b-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d19a2399-f8e2-4b10-80d8-a561ce9d24d1_2.json b/packages/security_detection_engine/kibana/security_rule/d19a2399-f8e2-4b10-80d8-a561ce9d24d1_2.json new file mode 100644 index 00000000000..a7158fc5978 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d19a2399-f8e2-4b10-80d8-a561ce9d24d1_2.json @@ -0,0 +1,108 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation of a symbolic link from a system binary to a suspicious and writable location. This activity may indicate an attacker's attempt to evade detection by behavioral rules that depend on predefined process parent/child relationships. By executing the symlinked variant of a binary instead of the original, the attacker aims to bypass these rules. Through the new_terms rule type, this rule can identify uncommon parent processes that may indicate the presence of a malicious symlink.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "System Binary Symlink to Suspicious Location", + "new_terms_fields": [ + "host.id", + "process.parent.name" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating System Binary Symlink to Suspicious Location\n\nSymbolic links in Linux create shortcuts to files or directories, allowing flexible file management. Adversaries exploit this by linking system binaries to writable, suspicious locations, aiming to bypass security measures that monitor standard execution paths. The detection rule identifies unusual parent processes and symbolic link creation to these locations, flagging potential evasion attempts.\n\n### Possible investigation steps\n\n- Review the parent process executable (process.parent.executable) to determine if it is a known and legitimate process that should be creating symbolic links.\n- Examine the specific system binary involved (process.args) to verify if it is commonly used in the environment and assess if its redirection to a suspicious location is justified.\n- Investigate the destination path of the symbolic link (process.args) to determine if it is a writable and potentially malicious location such as /tmp, /dev/shm, or /var/tmp.\n- Check for any recent or concurrent alerts or logs related to the same parent process or destination path to identify potential patterns or repeated attempts.\n- Assess the user account associated with the process (if available) to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.\n- Correlate with other security tools or logs to identify any additional suspicious activities or anomalies around the time of the alert.\n\n### False positive analysis\n\n- Routine system maintenance tasks may create symbolic links in monitored directories. Exclude known maintenance scripts or processes like mkinitcpio and dracut from triggering alerts by adding them to the exception list.\n- Software installations or updates often involve creating symbolic links in writable directories. Identify and whitelist trusted installation processes or package managers to prevent unnecessary alerts.\n- Development environments may frequently use symbolic links for testing purposes. Consider excluding specific user directories or development tools that are known to create such links regularly.\n- Backup or synchronization tools might create symbolic links as part of their operation. Verify and exclude these tools if they are part of a legitimate and routine process.\n- Custom scripts or automation tools used within the organization might trigger this rule. Review and whitelist these scripts if they are verified to be safe and necessary for business operations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious processes identified as creating symbolic links to writable locations, especially those with uncommon parent processes.\n- Remove any unauthorized symbolic links from system binaries to suspicious locations, ensuring the integrity of the original binaries.\n- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts or unnecessary elevated privileges.\n- Restore affected binaries and system files from a known good backup to ensure no tampered files remain.\n- Monitor the system for any further attempts to create unauthorized symbolic links, using enhanced logging and alerting mechanisms.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.parent.executable:* and\n(process.name:ln or process.name:busybox and process.args:ln or process.name:cp and process.args:--symbolic-link) and\nprocess.args:(\n (\n /bin/* or /lib/* or /lib64/* or /sbin/* or /usr/bin/* or /usr/lib/* or /usr/lib64/* or /usr/local/bin/* or\n /usr/local/lib/* or /usr/local/lib64/* or /usr/local/sbin/* or /usr/sbin/*\n ) and (\n /*/.* or /dev/shm/* or /home/* or /root/* or /tmp/* or /var/tmp/*\n ) and\n not (/usr/bin/coreutils or /tmp/mkinitcpio* or /var/tmp/dracut* or /var/tmp/mkinitramfs*)\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "d19a2399-f8e2-4b10-80d8-a561ce9d24d1", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/" + }, + { + "id": "T1202", + "name": "Indirect Command Execution", + "reference": "https://attack.mitre.org/techniques/T1202/" + }, + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "d19a2399-f8e2-4b10-80d8-a561ce9d24d1_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_2.json b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_2.json new file mode 100644 index 00000000000..653a86124d3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like backtick-escaped variable expansion to evade detection. This method involves disguising malicious scripts to bypass security measures. The detection rule identifies scripts with excessive length and specific obfuscation patterns, flagging potential threats for further analysis.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content of the script and identify any suspicious or malicious commands.\n- Examine the `file.path` and `file.name` fields to determine the origin and context of the script execution, which may provide insights into whether the script is part of a legitimate process or potentially malicious activity.\n- Check the `host.name` and `agent.id` fields to identify the affected system and correlate with other security events or logs from the same host for additional context.\n- Analyze the `user.id` field to determine which user account executed the script, and assess whether this activity aligns with the user's typical behavior or role.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution flow of the script and identify any related script blocks that may have been executed in sequence.\n- Consider the `count` field to evaluate the extent of obfuscation used in the script, which may indicate the level of sophistication or intent behind the script.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use backtick-escaped variable expansion for complex string manipulations. Review the script's context and purpose to determine if it aligns with expected administrative tasks.\n- Automated scripts generated by trusted software might include obfuscation patterns as part of their normal operation. Verify the source and integrity of the software to ensure it is from a reputable vendor.\n- Developers and IT professionals may use obfuscation techniques during testing or development phases. Establish a process to whitelist known development environments or user accounts to reduce unnecessary alerts.\n- PowerShell scripts that are part of legitimate security tools or monitoring solutions may trigger the rule. Identify and exclude these tools by their file path or script block ID to prevent false positives.\n- Regularly update the list of known false positives based on historical data and feedback from users to refine the detection rule and improve its accuracy.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of the potentially malicious script across the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated scripts.\n- Conduct a thorough review of the script block text and associated file paths to identify and remove any malicious scripts or files from the system.\n- Reset credentials for any user accounts involved in the alert to mitigate the risk of compromised credentials being used for further attacks.\n- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or additional compromised systems.\n- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of obfuscation techniques or related suspicious activities.\n- Update endpoint protection and intrusion detection systems with indicators of compromise (IOCs) derived from the analysis to improve detection capabilities for similar threats in the future.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"\\$\\{(\\w++`){2,}\\w++\\}\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, file.name, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "d43f2b43-02a1-4219-8ce9-10929a32a618", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "d43f2b43-02a1-4219-8ce9-10929a32a618_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_208.json b/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_208.json new file mode 100644 index 00000000000..1307446d234 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_208.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root.", + "false_positives": [ + "An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" + ], + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Pod Created With HostPID", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod Created With HostPID\n\nKubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action.\n- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed.\n- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision.\n- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved.\n- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set.\n- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered.\n\n### False positive analysis\n\n- Known safe images like \"docker.elastic.co/beats/elastic-agent:8.4.0\" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list.\n- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts.\n- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames.\n- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria.\n- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods.\n- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry.\n- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities.\n- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker.\n- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future.\n- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required.", + "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostPID:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", + "references": [ + "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", + "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", + "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" + ], + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.objectRef.resource", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.containers.image", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.requestObject.spec.hostPID", + "type": "boolean" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "df7fda76-c92b-4943-bc68-04460a5ea5ba", + "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 208 + }, + "id": "df7fda76-c92b-4943-bc68-04460a5ea5ba_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_320.json b/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_320.json new file mode 100644 index 00000000000..668f982b9dd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_320.json @@ -0,0 +1,156 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerShell scripts. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\Health Service State\\Monitoring Host Temporary\nFiles*\\AvailabilityGroupMonitoring.ps1\n" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious .NET Reflection via PowerShell", + "note": "## Triage and analysis\n\n### Investigating Suspicious .NET Reflection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script, which can circumvent file-based security protections.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the script using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did not identify malware or suspicious activity related to the user or host, this alert can be dismissed.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n \"[System.Reflection.Assembly]::Load\" or\n \"[Reflection.Assembly]::Load\" or\n \"Assembly.Load(\"\n ) and\n not powershell.file.script_block_text : (\n (\"CommonWorkflowParameters\" or \"RelatedLinksHelpInfo\") and\n \"HelpDisplayStrings\"\n ) and\n not (powershell.file.script_block_text :\n (\"Get-SolutionFiles\" or \"Get-VisualStudio\" or \"Select-MSBuildPath\") and\n file.name : \"PathFunctions.ps1\"\n ) and\n not powershell.file.script_block_text : (\n \"Microsoft.PowerShell.Workflow.ServiceCore\" and \"ExtractPluginProperties([string]$pluginDir\"\n ) and \n \n not powershell.file.script_block_text : (\"reflection.assembly]::Load('System.\" or \"LoadWithPartialName('Microsoft.\" or \"::Load(\\\"Microsoft.\" or \"Microsoft.Build.Utilities.Core.dll\") and \n \n not user.id : \"S-1-5-18\"\n", + "references": [ + "https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "e26f042e-c590-4e82-8e05-41e81bd822ad", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1055", + "name": "Process Injection", + "reference": "https://attack.mitre.org/techniques/T1055/", + "subtechnique": [ + { + "id": "T1055.001", + "name": "Dynamic-link Library Injection", + "reference": "https://attack.mitre.org/techniques/T1055/001/" + }, + { + "id": "T1055.002", + "name": "Portable Executable Injection", + "reference": "https://attack.mitre.org/techniques/T1055/002/" + } + ] + }, + { + "id": "T1620", + "name": "Reflective Code Loading", + "reference": "https://attack.mitre.org/techniques/T1620/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 320 + }, + "id": "e26f042e-c590-4e82-8e05-41e81bd822ad_320", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_110.json b/packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_110.json new file mode 100644 index 00000000000..b80c698b24c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_110.json @@ -0,0 +1,108 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "First Time Seen NewCredentials Logon Process", + "new_terms_fields": [ + "process.executable" + ], + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating First Time Seen NewCredentials Logon Process\n\nThe NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks.\n\n### Possible investigation steps\n\n- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files.\n- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account.\n- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous.\n- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections.\n- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments.\n- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors.\n\n### False positive analysis\n\n- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths.\n- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names.\n- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles.\n- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts.\n- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse.\n- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly.\n- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future.", + "query": "event.category:\"authentication\" and host.os.type:\"windows\" and winlog.logon.type:\"NewCredentials\" and\n winlog.event_data.LogonProcessName:Advapi* and\n not winlog.event_data.SubjectUserName:*$ and\n not process.executable: (C\\:\\\\Program*Files*\\(x86\\)\\\\*.exe or C\\:\\\\Program*Files\\\\*.exe)\n", + "references": [ + "https://www.elastic.co/pt/blog/how-attackers-abuse-access-token-manipulation" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.LogonProcessName", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserName", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "e468f3f6-7c4c-45bb-846a-053738b3fe5d", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1134", + "name": "Access Token Manipulation", + "reference": "https://attack.mitre.org/techniques/T1134/", + "subtechnique": [ + { + "id": "T1134.001", + "name": "Token Impersonation/Theft", + "reference": "https://attack.mitre.org/techniques/T1134/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 110 + }, + "id": "e468f3f6-7c4c-45bb-846a-053738b3fe5d_110", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_211.json b/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_211.json new file mode 100644 index 00000000000..d539cda1cee --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_211.json @@ -0,0 +1,144 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Service Creation via Local Kerberos Authentication", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Service Creation via Local Kerberos Authentication\n\nKerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.\n- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.\n- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.\n- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.\n- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.\n- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.\n- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.\n- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.\n- Terminate any suspicious services created during the incident to halt potential malicious activities.\n- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.\n- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.\n- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.\n- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.", + "query": "sequence by winlog.computer_name with maxspan=5m\n [authentication where\n\n /* event 4624 need to be logged */\n event.action == \"logged-in\" and event.outcome == \"success\" and winlog.event_data.ElevatedToken == \"%%1843\" and process.pid == 0 and \n\n /* authenticate locally using relayed kerberos Ticket */\n winlog.event_data.AuthenticationPackageName :\"Kerberos\" and winlog.logon.type == \"Network\" and cidrmatch(source.ip, \"127.0.0.0/8\", \"::1\")] by winlog.event_data.TargetLogonId\n\n [any where\n /* event 4697 need to be logged */\n event.action : \"service-installed\"] by winlog.event_data.SubjectLogonId\n", + "references": [ + "https://github.com/Dec0ne/KrbRelayUp", + "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html", + "https://github.com/cube0x0/KrbRelay", + "https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pid", + "type": "long" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AuthenticationPackageName", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ElevatedToken", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "e4e31051-ee01-4307-a6ee-b21b186958f4", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Tactic: Credential Access", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/", + "subtechnique": [ + { + "id": "T1543.003", + "name": "Windows Service", + "reference": "https://attack.mitre.org/techniques/T1543/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1558", + "name": "Steal or Forge Kerberos Tickets", + "reference": "https://attack.mitre.org/techniques/T1558/" + } + ] + } + ], + "type": "eql", + "version": 211 + }, + "id": "e4e31051-ee01-4307-a6ee-b21b186958f4_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json new file mode 100644 index 00000000000..cd4ad145653 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Reordering", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via String Reordering\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.\n\n### Possible investigation steps\n\n- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.\n- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.\n- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.\n- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.\n\n### False positive analysis\n\n- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name \"framework_cache.psm1\" is excluded from the detection rule.\n- PowerShell scripts that include specific sentinel patterns, such as \"sentinelbreakpoints\" or paths like \":::::\\windows\\sentinel\", combined with variables like \"$local:Bypassed\" or \"origPSExecutionPolicyPreference\", are known to be benign. These should be excluded to reduce noise.\n- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.\n- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.\n- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n| WHERE powershell.file.script_block_text LIKE \"*{0}*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count > 3\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| WHERE (file.name NOT LIKE \"framework_cache.psm1\" or file.name IS NULL)\n| WHERE NOT\n // https://wtfbins.wtf/17\n (\n (powershell.file.script_block_text LIKE \"*sentinelbreakpoints*\" OR\n powershell.file.script_block_text LIKE \"*:::::\\\\\\\\windows\\\\\\\\sentinel*\")\n AND\n (powershell.file.script_block_text LIKE \"*$local:Bypassed*\" OR\n powershell.file.script_block_text LIKE \"*origPSExecutionPolicyPreference*\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ec81962e-4bc8-48e6-bfb0-545fc97d8f6a_1.json b/packages/security_detection_engine/kibana/security_rule/ec81962e-4bc8-48e6-bfb0-545fc97d8f6a_1.json new file mode 100644 index 00000000000..861aed7710d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ec81962e-4bc8-48e6-bfb0-545fc97d8f6a_1.json @@ -0,0 +1,75 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a \"forbid\" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation.", + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubernetes Forbidden Creation Request", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Forbidden Creation Request\n\nKubernetes, a container orchestration platform, manages applications across clusters. It uses authorization policies to control resource creation. Adversaries may exploit misconfigurations or attempt unauthorized resource creation to gain access or escalate privileges. The detection rule identifies denied creation requests, signaling potential unauthorized attempts, by analyzing audit logs for forbidden decisions, aiding in threat detection and response.\n\n### Possible investigation steps\n\n- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `kubernetes.audit.user.username` field.\n- Check the `kubernetes.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting.\n- Investigate the `kubernetes.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt.\n- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations.\n- Cross-reference the user or service account with existing role bindings and cluster role bindings to verify if there are any misconfigurations or missing permissions that could have led to the forbidden request.\n- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request.\n- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy.\n\n### False positive analysis\n\n- Service accounts with limited permissions may trigger false positives when attempting to create resources they are not authorized for. Review service account roles and permissions to ensure they align with intended access levels.\n- Automated processes or scripts that attempt resource creation without proper permissions can result in false positives. Identify and adjust these processes to ensure they operate within their designated permissions.\n- Developers testing new configurations or deployments might inadvertently cause forbidden creation requests. Implement a separate testing environment with appropriate permissions to minimize false positives in production.\n- Changes in authorization policies can lead to temporary false positives as users adjust to new permissions. Communicate policy changes effectively and provide guidance on necessary adjustments to avoid unnecessary alerts.\n- Regularly scheduled tasks or cron jobs that attempt resource creation without updated permissions can trigger false positives. Review and update these tasks to ensure they have the necessary access rights.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or resource manipulation. This can be done by restricting network access or applying stricter firewall rules temporarily.\n- Identify and revoke any unauthorized or suspicious service accounts or user credentials that attempted the forbidden creation request. Ensure that these accounts are disabled or have their permissions reduced to prevent further misuse.\n- Review and update the Kubernetes Role-Based Access Control (RBAC) policies to ensure that only authorized users and service accounts have the necessary permissions to create resources. This includes verifying that least privilege principles are applied.\n- Conduct a thorough audit of recent Kubernetes audit logs to identify any other unauthorized access attempts or suspicious activities that may have occurred around the same time as the detected alert.\n- Escalate the incident to the security operations team for further investigation and to determine if there is a broader security incident or breach. Provide them with all relevant logs and findings.\n- Implement additional monitoring and alerting for similar unauthorized creation attempts in the future. This can include setting up alerts for any \"forbid\" decisions in the audit logs to ensure rapid detection and response.\n- Consider deploying additional security tools or services, such as intrusion detection systems or anomaly detection solutions, to enhance the security posture of the Kubernetes environment and prevent similar threats.\n", + "query": "any where host.os.type == \"linux\" and event.dataset == \"kubernetes.audit_logs\" and kubernetes.audit.verb == \"create\" and\nkubernetes.audit.stage == \"ResponseComplete\" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == \"forbid\"\n", + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "`kubernetes.audit.annotations.authorization_k8s_io/decision`", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.stage", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.verb", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "ec81962e-4bc8-48e6-bfb0-545fc97d8f6a", + "severity": "medium", + "tags": [ + "Data Source: Kubernetes", + "Domain: Kubernetes", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "ec81962e-4bc8-48e6-bfb0-545fc97d8f6a_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c_1.json b/packages/security_detection_engine/kibana/security_rule/eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c_1.json new file mode 100644 index 00000000000..141b99b9b04 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c_1.json @@ -0,0 +1,104 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the execution of the \"kubectl apply\" command with a URL argument. This command is often used to apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious pods or modify existing ones, potentially leading to unauthorized access or data exfiltration.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Apply Pod from URL", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubectl Apply Pod from URL\n\nKubectl is a command-line tool for managing Kubernetes clusters, allowing users to deploy and manage applications. Adversaries may exploit the 'kubectl apply' command with a URL to deploy malicious configurations or pods, potentially compromising the cluster. The detection rule identifies such activities by monitoring for the execution of 'kubectl apply' with URL arguments, flagging potential unauthorized deployments.\n\n### Possible investigation steps\n\n- Review the process execution details to confirm the presence of 'kubectl apply' with a URL argument, ensuring the command matches the query criteria.\n- Identify the source IP address or hostname from which the 'kubectl apply' command was executed to determine if it originates from a known or trusted source.\n- Check the URL used in the 'kubectl apply' command to assess its legitimacy and whether it points to a trusted or suspicious source.\n- Investigate the user account associated with the execution of the command to verify if it has the necessary permissions and if the activity aligns with expected behavior.\n- Examine the Kubernetes cluster logs for any recent changes or deployments that correspond with the time of the alert to identify any unauthorized modifications or deployments.\n- Cross-reference the alert with other security tools or logs, such as network traffic analysis, to detect any related suspicious activities or data exfiltration attempts.\n\n### False positive analysis\n\n- Routine administrative tasks: Regular use of 'kubectl apply' with URLs for legitimate configuration updates or deployments can trigger alerts. To manage this, create exceptions for known and trusted URLs used by administrators.\n- Automated deployment scripts: Continuous integration/continuous deployment (CI/CD) pipelines often use 'kubectl apply' with URLs to automate deployments. Identify and exclude these scripts by their specific process arguments or originating IP addresses.\n- Monitoring and logging tools: Some monitoring solutions may use 'kubectl apply' with URLs as part of their normal operations. Review and whitelist these tools by verifying their source and purpose.\n- Internal development environments: Developers may frequently use 'kubectl apply' with URLs in test environments. Establish a separate rule set or exceptions for these environments to reduce noise while maintaining security in production clusters.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized deployments or access. This can be done by restricting network access or disabling external API access temporarily.\n- Review the specific pod or configuration deployed using the 'kubectl apply' command with a URL. Identify any malicious or unauthorized changes and remove them from the cluster.\n- Conduct a thorough audit of the cluster's current state to identify any other unauthorized deployments or configurations that may have been applied.\n- Revoke any compromised credentials or access tokens that may have been used to execute the unauthorized 'kubectl apply' command. Ensure that all access keys and tokens are rotated.\n- Escalate the incident to the security operations team for further investigation and to determine the root cause of the breach. This may involve analyzing logs and network traffic to trace the source of the attack.\n- Implement network policies and role-based access controls (RBAC) to limit the ability to apply configurations from external URLs, ensuring only trusted sources are allowed.\n- Enhance monitoring and alerting for similar activities by integrating with security information and event management (SIEM) systems to detect and respond to future threats promptly.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\nprocess.name == \"kubectl\" and process.args == \"apply\" and process.args like \"http*\"\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1610", + "name": "Deploy Container", + "reference": "https://attack.mitre.org/techniques/T1610/" + }, + { + "id": "T1609", + "name": "Container Administration Command", + "reference": "https://attack.mitre.org/techniques/T1609/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_2.json b/packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_2.json new file mode 100644 index 00000000000..9b6a5fdb932 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_2.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Linux Tunneling and/or Port Forwarding via SSH Option", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Linux Tunneling and/or Port Forwarding via SSH Option\n\nSSH is a secure protocol used for encrypted communication over networks, often employed for remote administration. Adversaries exploit SSH options like port forwarding to create tunnels, facilitating covert data exfiltration or unauthorized access. The detection rule identifies suspicious SSH commands indicative of tunneling by monitoring specific SSH options, helping to flag potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line details to identify the specific SSH options used, such as ProxyCommand, LocalForward, RemoteForward, DynamicForward, Tunnel, GatewayPorts, ExitOnForwardFailure, or ProxyJump, to understand the nature of the potential tunneling or port forwarding.\n- Examine the user account associated with the SSH process to determine if the activity aligns with their typical behavior or if it appears suspicious.\n- Check the source and destination IP addresses involved in the SSH connection to identify any unusual or unauthorized endpoints that may indicate malicious activity.\n- Investigate the timing and frequency of the SSH connections to assess whether they coincide with known business operations or if they suggest unauthorized access patterns.\n- Correlate the event with other security logs or alerts from the same host or network segment to identify any additional indicators of compromise or related suspicious activities.\n\n### False positive analysis\n\n- Legitimate administrative tasks using SSH options like ProxyCommand or LocalForward can trigger the rule. To manage this, create exceptions for known administrative scripts or users frequently using these options for valid purposes.\n- Automated backup or synchronization processes that use SSH tunneling for secure data transfer may be flagged. Identify these processes and exclude them by specifying the associated process names or user accounts.\n- Development or testing environments where developers use SSH tunneling for accessing remote services might cause alerts. Implement exceptions for specific IP addresses or user groups associated with these environments.\n- Monitoring or logging tools that utilize SSH for secure data collection can be mistaken for malicious activity. Whitelist these tools by their process names or command-line patterns to prevent false positives.\n- Internal network services that rely on SSH port forwarding for legitimate communication should be reviewed and excluded based on their known behavior and usage patterns.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any suspicious SSH sessions identified by the detection rule to halt potential tunneling or port forwarding activities.\n- Conduct a thorough review of SSH configuration files and logs on the affected system to identify unauthorized changes or access patterns.\n- Reset credentials for any accounts that were used in the suspicious SSH activity to prevent further unauthorized access.\n- Implement network segmentation to limit SSH access to only necessary systems and services, reducing the risk of lateral movement.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.\n- Enhance monitoring and logging of SSH activities across the network to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\nprocess.name in (\"ssh\", \"sshd\") and process.args == \"-o\" and\nprocess.command_line like~ (\n \"*ProxyCommand*\", \"*LocalForward*\", \"*RemoteForward*\", \"*DynamicForward*\", \"*Tunnel*\", \"*GatewayPorts*\",\n \"*ExitOnForwardFailure*\", \"*ProxyCommand*\", \"*ProxyJump*\"\n)\n", + "references": [ + "https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform", + "https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "ef395dff-be12-4a6e-8919-d87d627c2174", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1572", + "name": "Protocol Tunneling", + "reference": "https://attack.mitre.org/techniques/T1572/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "ef395dff-be12-4a6e-8919-d87d627c2174_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json new file mode 100644 index 00000000000..b31408e838f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Reverse Keywords", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Reverse Keywords\n\nPowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic.\n- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious.\n- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution.\n- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine.\n- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.\n- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.\n- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.\n- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.\n- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.\n- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.\n- Restore affected systems from a known good backup if malicious activity has altered system integrity.\n- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Filter for scripts that contains these keywords using MATCH, boosts the query performance, match will ignore the | and look for the individual words\n| WHERE powershell.file.script_block_text : \"rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, agent.id\n| WHERE count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f38633f4-3b31-4c80-b13d-e77c70ce8254", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_3.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_3.json new file mode 100644 index 00000000000..1ebb414df10 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Concatenation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via String Concatenation\n\nPowerShell is a powerful scripting language used for task automation and configuration management. Adversaries exploit its flexibility to obfuscate malicious scripts, often using string concatenation to evade detection. The detection rule identifies scripts with excessive concatenation patterns, flagging potential obfuscation by analyzing script length and pattern frequency, thus aiding in uncovering hidden threats.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and purpose of the script, focusing on the sections identified by the string concatenation patterns.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and agent.id fields to identify the affected system and correlate with other security events or alerts from the same host for broader context.\n- Investigate the user.id field to determine which user executed the script, assessing their role and whether they have a legitimate reason to run such scripts.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution flow and sequence of the script blocks, which may reveal additional obfuscation or malicious behavior.\n- Cross-reference the _id and _index fields with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.\n\n### False positive analysis\n\n- Scripts with legitimate string concatenation for logging or configuration purposes may trigger the rule. Review the script context to determine if the concatenation is part of a benign operation.\n- Automated scripts generated by development tools might use string concatenation extensively. Identify these tools and consider excluding their output directories or specific script patterns from the rule.\n- PowerShell scripts used in complex data processing tasks may naturally contain high levels of string concatenation. Analyze the script's purpose and, if deemed safe, add exceptions for specific script block IDs or paths.\n- Frequent administrative scripts that concatenate strings for dynamic command execution could be flagged. Verify the script's source and function, then whitelist known safe scripts by user ID or host name.\n- Consider adjusting the threshold for pattern detection if legitimate scripts frequently exceed the current limit, ensuring that the rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts across the network. Disconnect it from the network and any shared resources.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of potentially obfuscated scripts.\n- Conduct a thorough examination of the script block text and associated files to identify and remove any malicious code or artifacts. Use a secure, isolated environment for analysis.\n- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be easily remediated.\n- Update and run a full antivirus and antimalware scan on the affected system to ensure no additional threats are present.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.\n- Implement enhanced monitoring and logging for PowerShell activities across the network to detect similar obfuscation attempts in the future, ensuring that alerts are configured to notify the appropriate personnel promptly.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 47, + "rule_id": "f6d8c743-0916-4483-8333-3c6f107e0caa", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "f6d8c743-0916-4483-8333-3c6f107e0caa_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json new file mode 100644 index 00000000000..0a41949d4e8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Numeric Character Proportion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via High Numeric Character Proportion\n\nPowerShell is a powerful scripting language used for system administration, but adversaries exploit its capabilities to obfuscate malicious scripts. Obfuscation often involves encoding payloads using numeric characters, making detection challenging. The detection rule identifies scripts with a high proportion of numeric characters, signaling potential obfuscation. By analyzing script length and numeric density, it flags suspicious activity, aiding in defense evasion detection.\n\n### Possible investigation steps\n\n- Review the script block text from the alert to understand the context and identify any obvious signs of obfuscation or malicious intent.\n- Examine the file path and host name fields to determine the origin and location of the script execution, which can help assess the potential impact and scope.\n- Check the user ID and agent ID fields to identify the user and system involved, which may provide insights into whether the activity is expected or suspicious.\n- Analyze the powershell.sequence and powershell.total fields to understand the sequence of script execution and the total number of scripts executed, which can indicate whether this is part of a larger pattern of behavior.\n- Investigate any related logs or alerts from the same host or user to identify patterns or correlations that might suggest broader malicious activity.\n\n### False positive analysis\n\n- Scripts with legitimate numeric-heavy content such as data processing or mathematical calculations may trigger the rule. To handle this, identify and whitelist specific scripts or script patterns that are known to be safe.\n- Automated scripts that generate or manipulate large datasets often contain high numeric content. Consider creating exceptions for scripts executed by trusted users or from known safe directories.\n- PowerShell scripts used for legitimate software installations or updates might include encoded data blocks. Review and exclude these scripts by verifying their source and purpose.\n- Scripts containing large hexadecimal strings for legitimate purposes, such as cryptographic operations, may be flagged. Use the exclusion pattern to filter out these known safe operations.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate scripts that may be introduced.\n\n### Response and remediation\n\n- Immediately isolate the affected host to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Review the PowerShell script block text and script block ID to identify any malicious payloads or encoded strings. If confirmed malicious, remove or quarantine the script.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to detect and remove any additional threats or remnants of the obfuscated script.\n- Analyze the file path and user ID associated with the script execution to determine if unauthorized access or privilege escalation occurred. Revoke any suspicious user access and reset credentials if necessary.\n- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other alerts to assess the scope and impact of the threat across the network.\n- Implement enhanced monitoring and logging for PowerShell activities on all endpoints to detect similar obfuscation attempts in the future, focusing on scripts with high numeric character proportions.\n- Review and update endpoint protection policies to restrict the execution of scripts with high numeric density, ensuring compliance with security best practices and reducing the risk of obfuscation-based attacks.\n", + "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of numbers and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 30%+ proportion of numbers\n| WHERE proportion > 0.30\n\n// Exclude noisy patterns\n| WHERE\n NOT powershell.file.script_block_text RLIKE \"\"\".*\\\"[a-fA-F0-9]{64}\\\"\\,.*\"\"\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_423.json b/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_423.json new file mode 100644 index 00000000000..7afc32f5a9f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_423.json @@ -0,0 +1,220 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.command_line": { + "case_insensitive": true, + "value": "*SysVol*WindowsDefenderATPOnboardingScript.cmd*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.command_line": { + "case_insensitive": true, + "value": "\"cmd.exe\" /d /c C:\\\\???????\\\\system32\\\\hpatchmonTask.cmd" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.command_line": { + "case_insensitive": true, + "value": "\"C:\\\\???????\\\\system32\\\\cmd.exe\" /d /c C:\\\\???????\\\\system32\\\\hpatchmonTask.cmd" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.args": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\silcollector.cmd" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.command_line": { + "case_insensitive": true, + "value": "*?:\\\\Program Files\\\\Npcap\\\\CheckStatus.bat*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.command_line": { + "case_insensitive": true, + "value": "*?:\\\\Program Files*\\\\Pulseway\\\\watchdog.bat*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "process.command_line": { + "case_insensitive": true, + "value": "cmd /C \".\\inetsrv\\iissetup.exe /keygen \"\n" + } + } + } + } + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-endpoint.events.process-*", + "winlogbeat-*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-system.security*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Svchost spawning Cmd", + "new_terms_fields": [ + "host.id", + "process.command_line", + "user.id" + ], + "note": "## Triage and analysis\n\n### Investigating Svchost spawning Cmd\n\nThe Service Host process (SvcHost) is a system process that can host one, or multiple, Windows services in the Windows NT family of operating systems. Note that `Svchost.exe` is reserved for use by the operating system and should not be used by non-Windows services.\n\nThis rule looks for the creation of the `cmd.exe` process with `svchost.exe` as its parent process. This is an unusual behavior that can indicate the masquerading of a malicious process as `svchost.exe` or exploitation for privilege escalation.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "host.os.type:windows and event.category:process and event.type:start and process.parent.name:\"svchost.exe\" and\nprocess.name:(\"cmd.exe\" or \"Cmd.exe\" or \"CMD.EXE\") and\n\n not process.command_line : \"\\\"cmd.exe\\\" /C sc control hptpsmarthealthservice 211\"\n", + "references": [ + "https://nasbench.medium.com/demystifying-the-svchost-exe-process-and-its-command-line-options-508e9114e747" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "fd7a6052-58fa-4397-93c3-4795249ccfa2", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Sysmon", + "Data Source: SentinelOne" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/" + } + ] + } + ], + "timeline_id": "e70679c2-6cde-4510-9764-4823df18f7db", + "timeline_title": "Comprehensive Process Timeline", + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 423 + }, + "id": "fd7a6052-58fa-4397-93c3-4795249ccfa2_423", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 2839910e01c..614c96994bf 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.7 +version: 9.0.8-beta.1 From 76810e3079ea3420515e076eb236a98632bbd385 Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 8 Jul 2025 07:19:14 -0400 Subject: [PATCH 03/13] [Security Rules] Update security rules package to v9.0.8 (#14451) --- packages/security_detection_engine/changelog.yml | 5 +++++ packages/security_detection_engine/manifest.yml | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 83a87ce31ff..ff914989d7a 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.8 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14451 - version: 9.0.8-beta.1 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 614c96994bf..59e8e60cff1 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.8-beta.1 +version: 9.0.8 From 81682c6923ab56ecacd137e271f5e680a9e470f5 Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 22 Jul 2025 04:49:09 -0400 Subject: [PATCH 04/13] [Security Rules] Update security rules package to v9.0.9-beta.1 (#14633) --- .../security_detection_engine/changelog.yml | 5 + ...1ef73-1fde-4a49-a34a-5dd40011b076_313.json | 137 --------- ...d3d2254-2b4a-11f0-a019-f661ea17fbcc_2.json | 90 ++++++ ...e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json | 65 ++++ ...2f15d-597e-4334-88ff-38a02cb1330b_204.json | 93 ------ ...bf709-69e8-4055-94f9-24314385c27e_205.json | 109 ------- ...e811c-d60f-11ec-9fd7-f661ea17fbce_205.json | 87 ------ ...a3f7c-21e7-4bb1-98c7-2036612fb1be_210.json | 289 ------------------ ...fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json | 55 ++++ ...18264-2d6d-11ef-9413-f661ea17fbce_205.json | 78 +++++ ...5e7fee6-fc25-11ee-ba0f-f661ea17fbce_5.json | 123 ++++++++ ...64c641e-c202-11ef-993e-f661ea17fbce_6.json | 111 +++++++ ...88a198e-9b9b-11ef-a0a8-f661ea17fbcd_2.json | 139 --------- ...52c19-ff3e-42fd-8363-7be14d7c5469_211.json | 126 ++++++++ ...da169-416b-4bb3-9a6b-f8d239fd78ba_205.json | 108 ------- ...9e96a-b67c-455a-afe4-de6183431d0d_213.json | 129 -------- ...6e1bc-867a-11ee-b13e-f661ea17fbcd_203.json | 62 ---- ...6e1bc-867a-11ee-b13e-f661ea17fbcd_306.json | 63 ++++ ...5ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_3.json | 58 ---- ...211e8-4e2f-440f-86d8-06cc8f158cfa_211.json | 102 ------- ...211e8-4e2f-440f-86d8-06cc8f158cfa_215.json | 117 +++++++ ...c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d_1.json | 144 +++++++++ ...2c97e6e-60c3-11f0-832a-f661ea17fbcd_1.json | 96 ++++++ ...0d948-40d4-4cef-ac69-4002e29bc3db_316.json | 158 ---------- ...19484-9826-4083-9eba-1da74cd0eaf2_108.json | 99 ------ ...98e4094-60e7-11f0-8847-f661ea17fbcd_1.json | 59 ++++ ...0a2bdea-9876-11ef-89db-f661ea17fbcd_2.json | 107 ------- ...2bf58-2a39-4c58-a384-c8b1978153c2_213.json | 103 ------- ...f6e7a-7acf-4bcd-ad42-c4969124d3c0_103.json | 75 ----- ...f6e7a-7acf-4bcd-ad42-c4969124d3c0_104.json | 75 ----- ...f6e7a-7acf-4bcd-ad42-c4969124d3c0_105.json | 75 ----- ...3c05204-339a-11ed-a261-0242ac120002_7.json | 99 ------ ...3c056a0-339a-11ed-a261-0242ac120002_6.json | 77 ----- ...3c057cc-339a-11ed-a261-0242ac120002_7.json | 90 ------ ...9bccd-510b-40df-8263-334f03174fed_204.json | 89 ------ ...96015ef-718e-40ff-ac4a-cc2ba88dbeeb_7.json | 104 +++++++ ...a309864-fc3f-11ee-b8cc-f661ea17fbce_6.json | 100 ++++++ ...b341d03-1d63-41ac-841a-2009c86959ca_4.json | 55 ++++ ...a2cc4-d260-11ed-8829-f661ea17fbcc_110.json | 118 ------- ...947e9-de7e-4281-a55d-09289bdf947e_109.json | 112 ------- ...164081a-3930-11ed-a261-0242ac120002_6.json | 110 ------- ...ccb61-e19b-452f-b104-79a60e546a95_317.json | 111 ------- ...5c53838-5dcd-11f0-829c-f661ea17fbcd_1.json | 76 +++++ ...c8437-a581-4537-8060-1fdb0e92c92d_205.json | 109 ------- ...7122db4-5876-4127-b91b-6c179eb21f88_4.json | 94 ++++++ ...dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_107.json | 82 +++++ ...60f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json | 55 ++++ ...a1db198-da6f-4500-b985-7fe2457300af_1.json | 77 +++++ ...a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json | 101 ++++++ ...eeeda11-dca6-4c3e-910f-7089db412d1c_4.json | 59 ++++ ...09bf7c8-d371-11ef-bcc3-f661ea17fbcd_4.json | 117 +++++++ ...75852-b0f5-4b8b-89c3-a226efae5726_210.json | 144 --------- ...e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_209.json | 95 ++++++ ...734c0-2cda-11ef-84e1-f661ea17fbce_205.json | 78 +++++ ...99adc-2cda-11ef-84e1-f661ea17fbce_205.json | 78 +++++ ...76b2391-413f-4a94-acb4-7911f3803346_4.json | 101 ++++++ ...d7407-0bd5-5817-cda0-3fcc33113a56_210.json | 84 ----- ...d7407-0bd5-5817-cda0-3fcc33113a56_211.json | 84 ----- ...d7407-0bd5-5817-cda0-3fcc33113a56_212.json | 84 ----- ...aa4be8d-5828-417d-9f54-7cd304571b24_6.json | 102 +++++++ ...cb68e-7c93-48d1-93b2-2c39023308eb_112.json | 97 ------ ...7473a-5cb4-4bc1-9d06-e4a75adbc494_109.json | 126 -------- ...326d7-dca7-4fb7-93eb-1ca03a1febbd_214.json | 123 ++++++++ ...b8f074c-5565-4bc4-991c-d49770e19fc9_5.json | 59 ++++ ...a13c6-ba45-4bab-a534-df53d0cfed6a_316.json | 118 ------- ...946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_3.json | 57 ---- ...07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json | 68 +++++ ...1a9ed70-d349-11ef-841c-f661ea17fbcd_4.json | 117 +++++++ ...1e79a70-fa6f-11ee-8bc8-f661ea17fbce_7.json | 141 +++++++++ ...5637438-e32d-4bb3-bc13-bd7932b3289f_4.json | 94 ++++++ ...70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_3.json | 114 +++++++ ...08cac-337a-4f38-b50d-5eeb78bdb531_205.json | 108 ------- ...82a2e-7e52-11ee-9aac-f661ea17fbcd_306.json | 56 ++++ ...ca64114-fb8b-11ef-86e2-f661ea17fbce_3.json | 82 +++++ ...f307a5a-d503-44a4-8158-db196d99c9df_1.json | 84 +++++ ...de13d58-bc39-4aa0-87fd-b4bdbf4591da_5.json | 86 ++++++ ...e67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json | 56 ++++ ...fda76-c92b-4943-bc68-04460a5ea5ba_205.json | 109 ------- ...f919b5e-a0f6-4fd8-8598-e3ce79299e3b_5.json | 86 ++++++ ...f042e-c590-4e82-8e05-41e81bd822ad_317.json | 143 --------- ...8f3f6-7c4c-45bb-846a-053738b3fe5d_107.json | 108 ------- ...31051-ee01-4307-a6ee-b21b186958f4_208.json | 139 --------- ...8ea6f58-0040-11f0-a243-f661ea17fbcd_4.json | 117 +++++++ ...903ce9a-5ce6-4246-bb14-75ed3ec2edf5_1.json | 79 ----- ...541ca3a-5752-11f0-b44b-f661ea17fbcd_1.json | 167 ++++++++++ ...6d07a70-9ad0-11ef-954f-f661ea17fbcd_5.json | 121 ++++++++ ...d332492-0bc6-11ef-b5be-f661ea17fbcc_6.json | 127 ++++++++ ...a6052-58fa-4397-93c3-4795249ccfa2_420.json | 181 ----------- .../security_detection_engine/manifest.yml | 2 +- 89 files changed, 4205 insertions(+), 4582 deletions(-) delete mode 100644 packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_313.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_204.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_205.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_205.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_210.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json create mode 100644 packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_6.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_211.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_205.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_213.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_203.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_211.json create mode 100644 packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_215.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/42c97e6e-60c3-11f0-832a-f661ea17fbcd_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_316.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_108.json create mode 100644 packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_213.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_103.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_104.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_105.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_7.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_6.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_7.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_204.json create mode 100644 packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_110.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_109.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_6.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_317.json create mode 100644 packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_205.json create mode 100644 packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_107.json create mode 100644 packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8a1db198-da6f-4500-b985-7fe2457300af_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_210.json create mode 100644 packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json create mode 100644 packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json create mode 100644 packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_210.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_211.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_212.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_6.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_112.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_109.json create mode 100644 packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_214.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_5.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_316.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_205.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cf307a5a-d503-44a4-8158-db196d99c9df_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_205.json create mode 100644 packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_5.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_317.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_107.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_208.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e8ea6f58-0040-11f0-a243-f661ea17fbcd_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f541ca3a-5752-11f0-b44b-f661ea17fbcd_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_6.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_420.json diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index ff914989d7a..5b0d029b6a9 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.9-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14633 - version: 9.0.8 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_313.json b/packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_313.json deleted file mode 100644 index 84b2a22f27e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/07b1ef73-1fde-4a49-a34a-5dd40011b076_313.json +++ /dev/null @@ -1,137 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies registry modification to the LocalAccountTokenFilterPolicy policy. If this value exists (which doesn't by default) and is set to 1, then remote connections from all local members of Administrators are granted full high-integrity tokens during negotiation.", - "from": "now-9m", - "index": [ - "winlogbeat-*", - "logs-endpoint.events.registry-*", - "logs-windows.sysmon_operational-*", - "endgame-*", - "logs-sentinel_one_cloud_funnel.*", - "logs-m365_defender.event-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Local Account TokenFilter Policy Disabled", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Local Account TokenFilter Policy Disabled\n\nThe LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses.\n\n### Possible investigation steps\n\n- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is \"LocalAccountTokenFilterPolicy\" and registry.data.strings is \"1\" or \"0x00000001\".\n- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information.\n- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement.\n- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity.\n- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and assess the scope of the potential threat.\n- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change.\n\n### False positive analysis\n\n- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes.\n- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign.\n- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts.\n- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.\n- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization.\n- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes.\n- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials.\n- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings.\n- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign.\n- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats.", - "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.value : \"LocalAccountTokenFilterPolicy\" and\n registry.path : (\n \"HKLM\\\\*\\\\LocalAccountTokenFilterPolicy\",\n \"\\\\REGISTRY\\\\MACHINE\\\\*\\\\LocalAccountTokenFilterPolicy\",\n \"MACHINE\\\\*\\\\LocalAccountTokenFilterPolicy\"\n ) and registry.data.strings : (\"1\", \"0x00000001\")\n", - "references": [ - "https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2014-04-02/finding/V-36439", - "https://posts.specterops.io/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy-506c25a7c167", - "https://www.welivesecurity.com/wp-content/uploads/2018/01/ESET_Turla_Mosquito.pdf" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - }, - { - "package": "m365_defender", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.data.strings", - "type": "wildcard" - }, - { - "ecs": true, - "name": "registry.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.value", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "07b1ef73-1fde-4a49-a34a-5dd40011b076", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Tactic: Lateral Movement", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Data Source: SentinelOne", - "Data Source: Microsoft Defender for Endpoint", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1112", - "name": "Modify Registry", - "reference": "https://attack.mitre.org/techniques/T1112/" - }, - { - "id": "T1562", - "name": "Impair Defenses", - "reference": "https://attack.mitre.org/techniques/T1562/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0008", - "name": "Lateral Movement", - "reference": "https://attack.mitre.org/tactics/TA0008/" - }, - "technique": [ - { - "id": "T1550", - "name": "Use Alternate Authentication Material", - "reference": "https://attack.mitre.org/techniques/T1550/", - "subtechnique": [ - { - "id": "T1550.002", - "name": "Pass the Hash", - "reference": "https://attack.mitre.org/techniques/T1550/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 313 - }, - "id": "07b1ef73-1fde-4a49-a34a-5dd40011b076_313", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_2.json b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_2.json new file mode 100644 index 00000000000..cfd164e90a6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_2.json @@ -0,0 +1,90 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services.", + "false_positives": [ + "This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved." + ], + "from": "now-1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Session Reuse with Suspicious Graph Access", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Session Reuse with Suspicious Graph Access\n\nThis rule identifies when Microsoft Graph is accessed from a different IP than the one used for the original sign-in,\nbut using the same session ID within 5 minutes. This may suggest an adversary has stolen a session cookie or refresh/access\ntoken and is impersonating the user from an alternate host or location.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be\nperformed to the original sign-in and Graph events for further context.\n\n### Investigation Steps\n\n- Review the `user_id`, `session_id`, and `source_ip_list`. Confirm whether both IPs belong to the same user and geography.\n- Check for inconsistencies in `client_id_list` (e.g., unknown apps) or user agents across correlated events.\n- Investigate recent phishing reports or device infections for the `user_id`.\n- Pivot to Entra ID `auditlogs` to see if a device was registered or privileges were modified.\n- Review `graph_time` to determine what action was taken after the sign-in.\n- Use the `session_id` to correlate with other logs in the same time window to identify any additional suspicious activity.\n\n### False Positive Analysis\n- This pattern may occur if the user is switching between networks (e.g., corporate to mobile) or using a VPN.\n- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges.\n- However, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.\n- If the user is a developer or automation engineer, validate if this behavior was for testing purposes.\n- If the user is a system administrator, validate if this behavior was for administrative purposes.\n\n### Response Recommendations\n\n- If confirmed malicious, revoke all refresh/access tokens for the `user_id`.\n- Block the source IP(s) involved in the Graph access.\n- Notify the user and reset credentials.\n- Review session control policies and conditional access enforcement.\n- Monitor for follow-on activity, such as lateral movement or privilege escalation.\n- Review conditional access policies to ensure they are enforced correctly.\n", + "query": "FROM logs-azure.*\n| WHERE\n (event.dataset == \"azure.signinlogs\" AND source.`as`.organization.name != \"MICROSOFT-CORP-MSN-AS-BLOCK\" AND azure.signinlogs.properties.session_id IS NOT NULL)\n OR\n (event.dataset == \"azure.graphactivitylogs\" AND source.`as`.organization.name != \"MICROSOFT-CORP-MSN-AS-BLOCK\" AND azure.graphactivitylogs.properties.c_sid IS NOT NULL)\n| EVAL\n session_id = COALESCE(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid),\n user_id = COALESCE(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id),\n client_id = COALESCE(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id),\n source_ip = source.ip,\n event_time = @timestamp,\n event_type = CASE(\n event.dataset == \"azure.signinlogs\", \"signin\",\n event.dataset == \"azure.graphactivitylogs\", \"graph\",\n \"other\"\n ),\n time_window = DATE_TRUNC(5 minutes, @timestamp)\n| KEEP session_id, source_ip, event_time, event_type, time_window, user_id, client_id\n| STATS\n user_id = VALUES(user_id),\n session_id = VALUES(session_id),\n source_ip_list = VALUES(source_ip),\n source_ip_count = COUNT_DISTINCT(source_ip),\n client_id_list = VALUES(client_id),\n application_count = COUNT_DISTINCT(client_id),\n event_type_list = VALUES(event_type),\n event_type_count = COUNT_DISTINCT(event_type),\n event_start = MIN(event_time),\n event_end = MAX(event_time),\n signin_time = MIN(CASE(event_type == \"signin\", event_time, NULL)),\n graph_time = MIN(CASE(event_type == \"graph\", event_time, NULL)),\n document_count = COUNT()\n BY session_id, time_window\n| EVAL\n duration_minutes = DATE_DIFF(\"minutes\", event_start, event_end),\n signin_to_graph_delay_minutes = DATE_DIFF(\"minutes\", signin_time, graph_time)\n| WHERE\n event_type_count > 1 AND\n source_ip_count > 1 AND\n duration_minutes <= 5 AND\n signin_time IS NOT NULL AND\n graph_time IS NOT NULL AND\n signin_to_graph_delay_minutes >= 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://attack.mitre.org/techniques/T1078/004/" + ], + "risk_score": 73, + "rule_id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc", + "setup": "#### Required Microsoft Entra ID Sign-In and Graph Activity Logs\nThis rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Data Source: Microsoft Graph", + "Data Source: Microsoft Graph Activity Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion", + "Tactic: Initial Access" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json new file mode 100644 index 00000000000..b976e6f1717 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json @@ -0,0 +1,65 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive.", + "false_positives": [ + "Legitimate users may download files from OneDrive using OAuth authentication. Ensure that the downloads are authorized and the user is known before taking action." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "M365 OneDrive Excessive File Downloads with OAuth Token", + "note": "## Triage and Analysis\n\n### Investigating M365 OneDrive Excessive File Downloads with OAuth Token\n\nThis rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique.\n\nThis rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested.\n\n#### Possible Investigation Steps\n\n- Review the `o365.audit.UserId` field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive.\n- Correlate `o365.audit.UserId` with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user.\n- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user.\n- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application.\n- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration.\n- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved.\n- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed.\n- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise.\n- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication.\n- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access.\n- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity.\n- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded.\n\n### False Positive Analysis\n\n- Verify if the user regularly downloads large batches of files as part of their job function.\n- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool.\n- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns.\n\n### Response and Remediation\n\n- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions.\n- Reset the affected user's password and require reauthentication to prevent continued unauthorized access.\n- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications.\n- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts.\n- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks.\n- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools.\n", + "query": "FROM logs-o365.audit-*\n| WHERE @timestamp > now() - 14 day\n| WHERE\n event.dataset == \"o365.audit\" and\n\n // filter on files downloaded from OneDrive\n event.provider == \"OneDrive\" and\n event.action == \"FileDownloaded\" and\n\n // filter on OAuth authentication which encompasses device code workflow\n o365.audit.AuthenticationType == \"OAuth\"\n and event.outcome == \"success\"\n// bucket authentication attempts by 1 minute\n| EVAL target_time_window = DATE_TRUNC(1 minutes, @timestamp)\n| KEEP target_time_window, o365.audit.UserId, file.name, source.ip\n\n// aggregate on unique file names and download attempts\n| STATS unique_file_count = count_distinct(file.name), download_attempt_count = count(*) BY target_time_window, o365.audit.UserId, source.ip\n\n// adjustable range for \"excessive\" unique files that were downloaded\n| WHERE unique_file_count >= 25\n", + "references": [ + "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/" + ], + "risk_score": 47, + "rule_id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: SharePoint", + "Data Source: OneDrive", + "Use Case: Threat Detection", + "Tactic: Collection", + "Tactic: Exfiltration", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_204.json b/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_204.json deleted file mode 100644 index 6b0f4c30ff2..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_204.json +++ /dev/null @@ -1,93 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster.", - "false_positives": [ - "An administrator may submit this request as an \"impersonatedUser\" to determine what privileges a particular service account has been granted. However, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Suspicious Self-Subject Review", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Suspicious Self-Subject Review\n\nKubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields.\n- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews.\n- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source.\n- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior.\n- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered.\n- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise.\n\n### False positive analysis\n\n- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls.\n- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule.\n- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts.\n- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors.\n\n### Response and remediation\n\n- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster.\n- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts.\n- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely.\n- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.\n- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts.\n- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb:\"create\"\n and kubernetes.audit.objectRef.resource:(\"selfsubjectaccessreviews\" or \"selfsubjectrulesreviews\")\n and (kubernetes.audit.user.username:(system\\:serviceaccount\\:* or system\\:node\\:*)\n or kubernetes.audit.impersonatedUser.username:(system\\:serviceaccount\\:* or system\\:node\\:*))\n", - "references": [ - "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms", - "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access", - "https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.impersonatedUser.username", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.user.username", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "12a2f15d-597e-4334-88ff-38a02cb1330b", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Discovery", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1613", - "name": "Container and Resource Discovery", - "reference": "https://attack.mitre.org/techniques/T1613/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 204 - }, - "id": "12a2f15d-597e-4334-88ff-38a02cb1330b_204", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_205.json b/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_205.json deleted file mode 100644 index 8cc8c106360..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_205.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.", - "false_positives": [ - "An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod Created With HostNetwork", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod Created With HostNetwork\n\nKubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.\n- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like \"docker.elastic.co/beats/elastic-agent:8.4.0\".\n- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.\n- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.\n- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.\n\n### False positive analysis\n\n- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.\n- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.\n- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.\n- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.\n- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.\n- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.\n- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.\n- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.\n- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.\n- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostNetwork:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", - "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.hostNetwork", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "12cbf709-69e8-4055-94f9-24314385c27e", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "12cbf709-69e8-4055-94f9-24314385c27e_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_205.json deleted file mode 100644 index a06e71ab6b7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_205.json +++ /dev/null @@ -1,87 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets.", - "false_positives": [ - "An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra -- sh" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes User Exec into Pod", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes User Exec into Pod\n\nKubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for \"kubernetes.audit_logs\".\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access.\n- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource.\n- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access.\n- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address.\n- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment.\n\n### False positive analysis\n\n- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly.\n- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses.\n- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows.\n- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod.\n- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized.\n- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege.\n- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod.\n- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised.\n- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb:\"create\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.objectRef.subresource:\"exec\"\n", - "references": [ - "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/", - "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.subresource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "14de811c-d60f-11ec-9fd7-f661ea17fbce", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1609", - "name": "Container Administration Command", - "reference": "https://attack.mitre.org/techniques/T1609/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "14de811c-d60f-11ec-9fd7-f661ea17fbce_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_210.json b/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_210.json deleted file mode 100644 index 13169a65409..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_210.json +++ /dev/null @@ -1,289 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "building_block_type": "default", - "description": "Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc.", - "filters": [ - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\*.ps?1" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Program Files\\\\Microsoft Azure AD Sync\\\\Extensions\\\\AADConnector.psm1" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "*ServiceNow MID Server*\\\\agent\\\\scripts\\\\PowerShell\\\\*.psm1" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Windows\\\\IMECache\\\\HealthScripts\\\\*\\\\detect.ps1" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Windows\\\\TEMP\\\\SDIAG*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Temp\\\\SDIAG*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\SDIAG*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "?:\\\\Program Files\\\\Microsoft Monitoring Agent\\\\Agent\\\\Health Service State\\\\Monitoring Host Temporary Files*" - } - } - } - } - ], - "from": "now-119m", - "index": [ - "winlogbeat-*", - "logs-windows.powershell*" - ], - "interval": "60m", - "language": "kuery", - "license": "Elastic License v2", - "name": "PowerShell Script with Discovery Capabilities", - "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (\n \"Get-ADDefaultDomainPasswordPolicy\" or\n \"Get-ADDomain\" or \"Get-ComputerInfo\" or\n \"Get-Disk\" or \"Get-DnsClientCache\" or\n \"Get-GPOReport\" or \"Get-HotFix\" or\n \"Get-LocalUser\" or \"Get-NetFirewallProfile\" or\n \"get-nettcpconnection\" or \"Get-NetAdapter\" or\n \"Get-PhysicalDisk\" or \"Get-Process\" or\n \"Get-PSDrive\" or \"Get-Service\" or\n \"Get-SmbShare\" or \"Get-WinEvent\"\n ) or\n (\n (\"Get-WmiObject\" or \"gwmi\" or \"Get-CimInstance\" or\n \"gcim\" or \"Management.ManagementObjectSearcher\" or\n \"System.Management.ManagementClass\" or\n \"[WmiClass]\") and\n (\n \"AntiVirusProduct\" or \"CIM_BIOSElement\" or \"CIM_ComputerSystem\" or \"CIM_Product\" or \"CIM_DiskDrive\" or\n \"CIM_LogicalDisk\" or \"CIM_NetworkAdapter\" or \"CIM_StorageVolume\" or \"CIM_OperatingSystem\" or\n \"CIM_Process\" or \"CIM_Service\" or \"MSFT_DNSClientCache\" or \"Win32_BIOS\" or \"Win32_ComputerSystem\" or\n \"Win32_ComputerSystemProduct\" or \"Win32_DiskDrive\" or \"win32_environment\" or \"Win32_Group\" or\n \"Win32_groupuser\" or \"Win32_IP4RouteTable\" or \"Win32_logicaldisk\" or \"Win32_MappedLogicalDisk\" or\n \"Win32_NetworkAdapterConfiguration\" or \"win32_ntdomain\" or \"Win32_OperatingSystem\" or\n \"Win32_PnPEntity\" or \"Win32_Process\" or \"Win32_Product\" or \"Win32_quickfixengineering\" or\n \"win32_service\" or \"Win32_Share\" or \"Win32_UserAccount\"\n )\n ) or\n (\n (\"ADSI\" and \"WinNT\") or\n (\"Get-ChildItem\" and \"sysmondrv.sys\") or\n (\"::GetIPGlobalProperties()\" and \"GetActiveTcpConnections()\") or\n (\"ServiceProcess.ServiceController\" and \"::GetServices\") or\n (\"Diagnostics.Process\" and \"::GetProcesses\") or\n (\"DirectoryServices.Protocols.GroupPolicy\" and \".GetGPOReport()\") or\n (\"DirectoryServices.AccountManagement\" and \"PrincipalSearcher\") or\n (\"NetFwTypeLib.NetFwMgr\" and \"CurrentProfile\") or\n (\"NetworkInformation.NetworkInterface\" and \"GetAllNetworkInterfaces\") or\n (\"Automation.PSDriveInfo\") or\n (\"Microsoft.Win32.RegistryHive\")\n ) or\n (\n \"Get-ItemProperty\" and\n (\n \"\\Control\\SecurityProviders\\WDigest\" or\n \"\\microsoft\\windows\\currentversion\\explorer\\runmru\" or\n \"\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Kerberos\\Parameters\" or\n \"\\Microsoft\\Windows\\CurrentVersion\\Uninstall\" or\n \"\\Microsoft\\Windows\\WindowsUpdate\" or\n \"Policies\\Microsoft\\Windows\\Installer\" or\n \"Software\\Microsoft\\Windows\\CurrentVersion\\Policies\" or\n (\"\\Services\\SharedAccess\\Parameters\\FirewallPolicy\" and \"EnableFirewall\") or\n (\"Microsoft\\Windows\\CurrentVersion\\Internet Settings\" and \"proxyEnable\")\n )\n ) or\n (\n (\"Directoryservices.Activedirectory\" or\n \"DirectoryServices.AccountManagement\") and \n (\n \"Domain Admins\" or \"DomainControllers\" or\n \"FindAllGlobalCatalogs\" or \"GetAllTrustRelationships\" or\n \"GetCurrentDomain\" or \"GetCurrentForest\"\n ) or\n \"DirectoryServices.DirectorySearcher\" and\n (\n \"samAccountType=805306368\" or\n \"samAccountType=805306369\" or\n \"objectCategory=group\" or\n \"objectCategory=groupPolicyContainer\" or\n \"objectCategory=site\" or\n \"objectCategory=subnet\" or\n \"objectClass=trustedDomain\"\n )\n ) or\n (\n \"Get-Process\" and\n (\n \"mcshield\" or \"windefend\" or \"savservice\" or\n \"TMCCSF\" or \"symantec antivirus\" or\n \"CSFalcon\" or \"TmPfw\" or \"kvoop\"\n )\n )\n ) and\n not powershell.file.script_block_text : (\n (\n \"__cmdletization_BindCommonParameters\" and\n \"Microsoft.PowerShell.Core\\Export-ModuleMember\" and\n \"Microsoft.PowerShell.Cmdletization.Cim.CimCmdletAdapter\"\n ) or\n \"CmdletsToExport=@(\\\"Add-Content\\\",\" or\n (\"cmdletization\" and \"cdxml-Help.xml\")\n ) and\n not user.id : (\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\")\n", - "related_integrations": [ - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "unknown" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Collection", - "Tactic: Discovery", - "Data Source: PowerShell Logs", - "Rule Type: BBR" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1087", - "name": "Account Discovery", - "reference": "https://attack.mitre.org/techniques/T1087/", - "subtechnique": [ - { - "id": "T1087.001", - "name": "Local Account", - "reference": "https://attack.mitre.org/techniques/T1087/001/" - }, - { - "id": "T1087.002", - "name": "Domain Account", - "reference": "https://attack.mitre.org/techniques/T1087/002/" - } - ] - }, - { - "id": "T1482", - "name": "Domain Trust Discovery", - "reference": "https://attack.mitre.org/techniques/T1482/" - }, - { - "id": "T1082", - "name": "System Information Discovery", - "reference": "https://attack.mitre.org/techniques/T1082/" - }, - { - "id": "T1083", - "name": "File and Directory Discovery", - "reference": "https://attack.mitre.org/techniques/T1083/" - }, - { - "id": "T1615", - "name": "Group Policy Discovery", - "reference": "https://attack.mitre.org/techniques/T1615/" - }, - { - "id": "T1135", - "name": "Network Share Discovery", - "reference": "https://attack.mitre.org/techniques/T1135/" - }, - { - "id": "T1201", - "name": "Password Policy Discovery", - "reference": "https://attack.mitre.org/techniques/T1201/" - }, - { - "id": "T1057", - "name": "Process Discovery", - "reference": "https://attack.mitre.org/techniques/T1057/" - }, - { - "id": "T1518", - "name": "Software Discovery", - "reference": "https://attack.mitre.org/techniques/T1518/", - "subtechnique": [ - { - "id": "T1518.001", - "name": "Security Software Discovery", - "reference": "https://attack.mitre.org/techniques/T1518/001/" - } - ] - }, - { - "id": "T1012", - "name": "Query Registry", - "reference": "https://attack.mitre.org/techniques/T1012/" - }, - { - "id": "T1082", - "name": "System Information Discovery", - "reference": "https://attack.mitre.org/techniques/T1082/" - }, - { - "id": "T1049", - "name": "System Network Connections Discovery", - "reference": "https://attack.mitre.org/techniques/T1049/" - }, - { - "id": "T1007", - "name": "System Service Discovery", - "reference": "https://attack.mitre.org/techniques/T1007/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 210 - }, - "id": "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_210", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json new file mode 100644 index 00000000000..be41054c37f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "High Number of Egress Network Connections from Unusual Executable", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating High Number of Egress Network Connections from Unusual Executable\n\nIn Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment.\n- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious.\n- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity.\n- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host.\n- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns.\n- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement.\n\n### False positive analysis\n\n- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts.\n- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious.\n- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list.\n- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe.\n- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement.\n- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection.\n- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat.\n- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited.\n- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and (\n (\n process.executable like \"/tmp/*\" or\n process.executable like \"/var/tmp/*\" or\n process.executable like \"/dev/shm/*\"\n ) or\n (process.name like \".*\")\n) and not (\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable like \"/nix/store/*\" or\n process.executable like \"/tmp/newroot/*\" or\n process.executable like \"/tmp/.mount*\" or\n process.executable like \"/tmp/go-build*\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json new file mode 100644 index 00000000000..880bd59f156 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "High Number of Okta Device Token Cookies Generated for Authentication", + "note": "## Triage and analysis\n\n### Investigating High Number of Okta Device Token Cookies Generated for Authentication\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.request_uri == \"/api/v1/authn\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count >= 30\n| SORT\n source_auth_count DESC\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 21, + "rule_id": "23f18264-2d6d-11ef-9413-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 205 + }, + "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_205", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_5.json b/packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_5.json new file mode 100644 index 00000000000..6cf30a1a002 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_5.json @@ -0,0 +1,123 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access.", + "false_positives": [ + "Administrators may legitimately add security group rules to allow traffic from any IP address or from specific IP addresses to common remote access ports." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Insecure AWS EC2 VPC Security Group Ingress Rule Added", + "note": "## Triage and analysis\n\n### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added\n\nThis rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Investigate whether this actor has the necessary permissions and typically performs these actions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent.\n- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management.\n- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing security group rules and securing AWS environments, refer to the [Amazon VPC Security Groups documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) and AWS best practices for security.\n\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: ec2.amazonaws.com\n and event.action: AuthorizeSecurityGroupIngress\n and event.outcome: success\n and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.ipRanges.items.cidrIp: (\"0.0.0.0/0\" or \"::/0\")\n and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.fromPort: (\n 21 or 22 or 23 or 445 or 3389 or 5985 or 5986)\n", + "references": [ + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html", + "https://www.linkedin.com/pulse/my-backdoors-your-aws-infrastructure-part-3-network-micha%C5%82-brygidyn/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.ipPermissions.items.fromPort", + "type": "unknown" + }, + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.ipPermissions.items.ipRanges.items.cidrIp", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "25e7fee6-fc25-11ee-ba0f-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.007", + "name": "Disable or Modify Cloud Firewall", + "reference": "https://attack.mitre.org/techniques/T1562/007/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 5 + }, + "id": "25e7fee6-fc25-11ee-ba0f-f661ea17fbce_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_6.json new file mode 100644 index 00000000000..eece9f2732d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_6.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks.", + "false_positives": [ + "Legitimate use of deprecated AMIs for testing or development purposes.", + "Automated tools or scripts that query for deprecated AMIs as part of a security assessment.", + "Misconfigured applications or services that rely on deprecated AMIs for compatibility reasons.", + "Administrators or developers who are unaware of the deprecation status of AMIs they are using." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 Deprecated AMI Discovery", + "note": "## Triage and analysis\n\n## Investigating AWS EC2 Deprecated AMI Discovery\n\nThis rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations.\n\n### Possible Investigation Steps\n\n1. **Identify the User Performing the Query**:\n - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request.\n - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity).\n\n2. **Analyze the Source of the Request**:\n - Review the `source.ip` field to determine the IP address of the source making the request.\n - Check `source.geo` for the geographic location of the IP address.\n - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK).\n\n3. **Validate the Query Context**:\n - Inspect the `aws.cloudtrail.request_parameters` field \n - Determine if the request is part of legitimate activity, such as:\n - Security assessments or vulnerability scans.\n - Maintenance or testing of legacy systems.\n - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services.\n\n4. **Correlate with Other Events**:\n - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation.\n - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call).\n\n5. **Assess Security Risks**:\n - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities.\n - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats.\n\n### False Positive Analysis\n\n- **Legitimate Use**: Users may query for deprecated AMIs for testing or compatibility purposes.\n- **Automated Tools**: Security or compliance tools might query deprecated AMIs as part of regular assessments.\n- **Misconfigured Services**: Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Verify the intent of the user querying for deprecated AMIs.\n - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs.\n\n2. **Mitigation Steps**:\n - Identify and replace deprecated AMIs in use with supported and updated AMIs.\n - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future queries involving deprecated AMIs or other unusual API activity.\n - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior.\n\n4. **Security Audits**:\n - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images.\n - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing.\n\n5. **Add Rule Exceptions**:\n - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs.\n - Document and communicate the exceptions to relevant teams to avoid future alerts.\n\n### Additional Resources\n\n- [AWS Documentation: AMI Lifecycle Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)\n- [AWS Documentation: Deprecated AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html)\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action: \"DescribeImages\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.includeDeprecated: \"true\"\n", + "references": [ + "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.includeDeprecated", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "264c641e-c202-11ef-993e-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: AWS EC2", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 6 + }, + "id": "264c641e-c202-11ef-993e-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_2.json deleted file mode 100644 index 664a8131501..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/288a198e-9b9b-11ef-a0a8-f661ea17fbcd_2.json +++ /dev/null @@ -1,139 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment.", - "false_positives": [ - "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes.", - "Applications integrated with AWS might assume roles to access AWS resources.", - "Automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments." - ], - "history_window_start": "now-10d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "user_agent.original", - "source.address", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.resources.arn", - "aws.cloudtrail.resources.type", - "aws.cloudtrail.flattened.request_parameters.roleArn", - "aws.cloudtrail.flattened.request_parameters.roleSessionName", - "event.action", - "event.outcome", - "cloud.region", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS STS Role Assumption by User", - "new_terms_fields": [ - "user.name", - "aws.cloudtrail.flattened.request_parameters.roleArn" - ], - "note": "## Triage and analysis\n\n### Investigating AWS STS Role Assumption by User\n\nThis rule detects when a user assumes a role in AWS Security Token Service (STS), receiving temporary credentials to access AWS resources. While often used for legitimate purposes, this action can be leveraged by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.\n\n#### Possible Investigation Steps\n\n- **Identify the User and Assumed Role**:\n - **User Identity**: Check `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` for details about the initiator of the `AssumeRole` action.\n - **Role Assumed**: Review `aws.cloudtrail.flattened.request_parameters.roleArn` to confirm the role assumed and ensure it aligns with the user\u2019s standard permissions.\n - **Session Name**: Note `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the purpose of the session.\n\n- **Evaluate Session Context and Credential Duration**:\n - **Session Details**: Look into `aws.cloudtrail.user_identity.session_context.creation_date` for the start of the session and `aws.cloudtrail.user_identity.session_context.mfa_authenticated` to check for MFA usage.\n - **Credential Validity**: Examine `aws.cloudtrail.flattened.request_parameters.durationSeconds` for how long the credentials are valid.\n - **Expiration Time**: Use `aws.cloudtrail.flattened.response_elements.credentials.expiration` to confirm the credential expiration.\n\n- **Inspect User Agent and Source Information**:\n - **User Agent**: Analyze the `user_agent.original` field to identify if specific tooling or SDKs like AWS CLI, Boto3, or custom agents were used.\n - **Source IP and Geolocation**: Examine `source.address` and `source.geo` fields to determine the origin of the request, confirming if it aligns with expected locations.\n\n- **Correlate with Related Events**:\n - **Identify Patterns**: Review related CloudTrail events for unusual access patterns, such as resource access or sensitive actions following this `AssumeRole` action.\n - **Filter High-Volume Roles**: If this role or user has a high volume of access, evaluate `roleArn` or `user_agent` values for common patterns and add trusted entities as exceptions.\n\n- **Review the Privileges of the Assumed Role**:\n - **Permissions**: Examine permissions associated with the `roleArn` to assess its access scope.\n - **Authorized Usage**: Confirm if the role is used frequently for administrative purposes and if this aligns with the user\u2019s regular responsibilities.\n\n### False Positive Analysis\n\n- **Automated Processes and Applications**: Applications or scheduled tasks may assume roles regularly for operational purposes. Validate the consistency of the `user_agent` or `roleArn` with known automated workflows.\n- **Standard IAM Policy Usage**: Confirm if the user or application routinely assumes this specific role for normal operations by reviewing historical activity.\n\n### Response and Remediation\n\n- **Terminate Unauthorized Sessions**: If the role assumption is deemed unauthorized, revoke the session by modifying IAM policies or the permissions associated with the assumed role.\n- **Strengthen Monitoring and Alerts**: Implement additional monitoring for specific high-risk roles, especially those with elevated permissions.\n- **Regularly Manage Exceptions**: Regularly review high-volume roles and user agent patterns to refine alerts, minimizing noise by adding trusted patterns as exceptions.\n- **Incident Response**: If confirmed as malicious, follow incident response protocols for containment, investigation, and remediation.\n\n### Additional Information\n\nFor more details on managing and securing AWS STS in your environment, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html).\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"sts.amazonaws.com\"\n and event.action: \"AssumeRole\"\n and event.outcome: \"success\"\n and aws.cloudtrail.user_identity.type: (\"AssumedRole\" or \"IAMUser\")\n", - "references": [ - "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "288a198e-9b9b-11ef-a0a8-f661ea17fbcd", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS STS", - "Resources: Investigation Guide", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0008", - "name": "Lateral Movement", - "reference": "https://attack.mitre.org/tactics/TA0008/" - }, - "technique": [ - { - "id": "T1550", - "name": "Use Alternate Authentication Material", - "reference": "https://attack.mitre.org/techniques/T1550/", - "subtechnique": [ - { - "id": "T1550.001", - "name": "Application Access Token", - "reference": "https://attack.mitre.org/techniques/T1550/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 2 - }, - "id": "288a198e-9b9b-11ef-a0a8-f661ea17fbcd_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_211.json b/packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_211.json new file mode 100644 index 00000000000..94c5d0672ff --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_211.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment.", + "false_positives": [ + "A security group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 Security Group Configuration Change", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS EC2 Security Group Configuration Change\n\nThis rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.\n\n#### Possible Investigation Steps\n\n1. **Identify the Modified Security Group**:\n - **Security Group ID**: Check the `aws.cloudtrail.request_parameters` field to identify the specific security group affected.\n - **Rule Changes**: Review `aws.cloudtrail.response_elements` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.\n\n2. **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.\n - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.\n\n3. **Analyze the Configuration Change**:\n - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.\n - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.\n\n4. **Check User Agent and Source IP**:\n - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual.\n - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.\n\n5. **Evaluate for Persistence Indicators**:\n - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.\n - **Permissions Review**: Confirm that the user\u2019s IAM policies are configured to limit changes to security groups only as necessary.\n\n6. **Correlate with Other CloudTrail Events**:\n - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access.\n - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.\n\n### False Positive Analysis\n\n- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.\n- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments.\n\n### Response and Remediation\n\n- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment.\n- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.\n- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.\n- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.\n\n### Additional Information\n\nFor more details on managing AWS Security Groups and best practices, refer to the [AWS EC2 Security Groups Documentation](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html) and AWS security best practices.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\" and event.outcome: \"success\"\n and (event.action:(\n \"AuthorizeSecurityGroupIngress\" or\n \"AuthorizeSecurityGroupEgress\" or\n \"CreateSecurityGroup\" or\n \"ModifySecurityGroupRules\" or\n \"RevokeSecurityGroupEgress\" or\n \"RevokeSecurityGroupIngress\") or \n (event.action: \"ModifyInstanceAttribute\" and aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId:*))\n", + "references": [ + "https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "29052c19-ff3e-42fd-8363-7be14d7c5469", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Network Security Monitoring", + "Resources: Investigation Guide", + "Tactic: Persistence", + "Tactic: Defense Evasion" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.007", + "name": "Disable or Modify Cloud Firewall", + "reference": "https://attack.mitre.org/techniques/T1562/007/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 211 + }, + "id": "29052c19-ff3e-42fd-8363-7be14d7c5469_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_205.json b/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_205.json deleted file mode 100644 index a5eb06a6d46..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_205.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.", - "false_positives": [ - "An administrator may need to attach a hostPath volume for a legitimate reason. This alert should be investigated for legitimacy by determining if the kuberenetes.audit.requestObject.spec.volumes.hostPath.path triggered is one needed by its target container/pod. For example, when the fleet managed elastic agent is deployed as a daemonset it creates several hostPath volume mounts, some of which are sensitive host directories like /proc, /etc/kubernetes, and /var/log. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod created with a Sensitive hostPath Volume", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod created with a Sensitive hostPath Volume\n\nKubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value \"kubernetes.audit_logs\".\n- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path.\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision.\n- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories.\n- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment.\n- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data.\n\n### False positive analysis\n\n- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads.\n- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image.\n- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening.\n- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods.\n- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources.\n- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise.\n- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image.\n- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod.\n- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities.\n- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.volumes.hostPath.path:\n (\"/\" or\n \"/proc\" or\n \"/root\" or\n \"/var\" or\n \"/var/run\" or\n \"/var/run/docker.sock\" or\n \"/var/run/crio/crio.sock\" or\n \"/var/run/cri-dockerd.sock\" or\n \"/var/lib/kubelet\" or\n \"/var/lib/kubelet/pki\" or\n \"/var/lib/docker/overlay2\" or\n \"/etc\" or\n \"/etc/kubernetes\" or\n \"/etc/kubernetes/manifests\" or\n \"/etc/kubernetes/pki\" or\n \"/home/admin\")\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216", - "https://kubernetes.io/docs/concepts/storage/volumes/#hostpath" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.volumes.hostPath.path", - "type": "unknown" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "2abda169-416b-4bb3-9a6b-f8d239fd78ba", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "2abda169-416b-4bb3-9a6b-f8d239fd78ba_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_213.json b/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_213.json deleted file mode 100644 index bbdef460e53..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_213.json +++ /dev/null @@ -1,129 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the use of Windows API functions that are commonly abused by malware and security tools to load malicious code or inject it into remote processes.", - "false_positives": [ - "Legitimate PowerShell scripts that make use of these functions." - ], - "from": "now-9m", - "index": [ - "winlogbeat-*", - "logs-windows.powershell*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Potential Process Injection via PowerShell", - "note": "## Triage and analysis\n\n### Investigating Potential Process Injection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nPowerShell also has solid capabilities to make the interaction with the Win32 API in an uncomplicated and reliable way, like the execution of inline C# code, PSReflect, Get-ProcAddress, etc.\n\nRed Team tooling and malware developers take advantage of these capabilities to develop stagers and loaders that inject payloads directly into the memory without touching the disk to circumvent file-based security protections.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Check if the imported function was executed and which process it targeted.\n- Check if the injected code can be retrieved (hardcoded in the script or on command line logs).\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or\n LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and\n (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or\n SuspendThread or ResumeThread or GetDelegateForFunctionPointer)\n ) and not \n file.directory: (\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\SenseCM\" or\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\"\n )\n", - "references": [ - "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1", - "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-ReflectivePEInjection.ps1", - "https://github.com/BC-SECURITY/Empire/blob/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1", - "https://www.elastic.co/security-labs/detect-credential-access" - ], - "related_integrations": [ - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.directory", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "unknown" - } - ], - "risk_score": 73, - "rule_id": "2e29e96a-b67c-455a-afe4-de6183431d0d", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Tactic: Execution", - "Resources: Investigation Guide", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1055", - "name": "Process Injection", - "reference": "https://attack.mitre.org/techniques/T1055/", - "subtechnique": [ - { - "id": "T1055.001", - "name": "Dynamic-link Library Injection", - "reference": "https://attack.mitre.org/techniques/T1055/001/" - }, - { - "id": "T1055.002", - "name": "Portable Executable Injection", - "reference": "https://attack.mitre.org/techniques/T1055/002/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - }, - { - "id": "T1106", - "name": "Native API", - "reference": "https://attack.mitre.org/techniques/T1106/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 213 - }, - "id": "2e29e96a-b67c-455a-afe4-de6183431d0d_213", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_203.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_203.json deleted file mode 100644 index cd387f0335a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_203.json +++ /dev/null @@ -1,62 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", - "from": "now-30m", - "interval": "15m", - "language": "esql", - "license": "Elastic License v2", - "name": "Okta User Sessions Started from Different Geolocations", - "note": "\n## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.security_context.is_proxy != true and okta.actor.id != \"unknown\"\n AND event.outcome == \"success\"\n| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id\n| STATS\n geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)\n BY okta.actor.id, okta.actor.alternate_id\n| WHERE\n geo_auth_counts >= 2\n", - "references": [ - "https://developer.okta.com/docs/reference/api/system-log/", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 47, - "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", - "severity": "medium", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Initial Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.004", - "name": "Cloud Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 203 - }, - "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_203", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json new file mode 100644 index 00000000000..6f05201073e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", + "from": "now-30m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Okta User Sessions Started from Different Geolocations", + "note": "## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.security_context.is_proxy != true and okta.actor.id != \"unknown\"\n AND event.outcome == \"success\"\n| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id\n| STATS\n geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)\n BY okta.actor.id, okta.actor.alternate_id\n| WHERE\n geo_auth_counts >= 2\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 47, + "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 306 + }, + "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_3.json b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_3.json deleted file mode 100644 index 5a4292e5a4b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_3.json +++ /dev/null @@ -1,58 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Azure Entra Sign-in Brute Force against Microsoft 365 Accounts\n\nAzure Entra ID, integral to Microsoft 365, manages user identities and access. Adversaries exploit this by attempting numerous login attempts to breach accounts, targeting services like Exchange and Teams. The detection rule identifies such threats by analyzing failed login patterns within a 30-minute window, flagging unusual activity from multiple sources or excessive failed attempts, thus highlighting potential brute-force attacks.\n\n### Possible investigation steps\n\n- Review the `azure.signinlogs.properties.user_principal_name` to identify the specific user account targeted by the brute-force attempts.\n- Examine the `source.ip` field to determine the origin of the failed login attempts and assess if multiple IP addresses are involved, indicating a distributed attack.\n- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted during the login attempts.\n- Analyze the `target_time_window` to confirm the timeframe of the attack and correlate it with other security events or alerts that may have occurred simultaneously.\n- Investigate the `azure.signinlogs.properties.status.error_code` for specific error codes that might provide additional context on the nature of the failed login attempts.\n- Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat.\n\n### False positive analysis\n\n- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery processes. To mitigate this, consider excluding known IP addresses associated with IT support or helpdesk operations.\n- Automated scripts or applications that frequently access Microsoft 365 services using non-interactive logins may be misidentified as brute force attempts. Identify and whitelist these applications by their user principal names or IP addresses.\n- Users traveling or working remotely may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exclusions for known travel patterns or use conditional access policies to manage these scenarios.\n- Bulk operations performed by administrators, such as batch account updates or migrations, can result in numerous failed logins. Exclude these activities by recognizing the specific user principal names or IP addresses involved in such operations.\n- Frequent logins from shared IP addresses, such as those from corporate VPNs or proxy servers, might be flagged. Consider excluding these IP ranges if they are known and trusted within the organization.\n\n### Response and remediation\n\n- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.\n- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique.\n- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources.\n- Enable multi-factor authentication (MFA) for the affected accounts and any other accounts that do not have it enabled to add an additional layer of security.\n- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation.\n- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats.\n- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats.\n\nThis rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.", - "query": "from logs-azure.signinlogs*\n// truncate the timestamp to a 30-minute window\n| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and to_lower(azure.signinlogs.properties.resource_display_name) rlike \"(.*)365(.*)\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome != \"success\"\n // for tuning review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// keep only relevant fields\n| keep target_time_window, event.dataset, event.category, azure.signinlogs.properties.resource_display_name, azure.signinlogs.category, event.outcome, azure.signinlogs.properties.user_principal_name, source.ip\n\n// count the number of login sources and failed login attempts\n| stats\n login_source_count = count(source.ip),\n failed_login_count = count(*) by target_time_window, azure.signinlogs.properties.user_principal_name\n\n// filter for users with more than 20 login sources or failed login attempts\n| where (login_source_count >= 20 or failed_login_count >= 20)\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" - ], - "risk_score": 47, - "rule_id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_211.json b/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_211.json deleted file mode 100644 index a86b72bd3df..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_211.json +++ /dev/null @@ -1,102 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as `RunShellScript`, `RunPowerShellScript` or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that looks for the first instance of this behavior by the `aws.cloudtrail.user_identity.arn` field in the last 7 days.", - "false_positives": [ - "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-9m", - "history_window_start": "now-7d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS SSM `SendCommand` Execution by Rare User", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn" - ], - "note": "## Triage and analysis\n\n### Investigating AWS SSM `SendCommand` Execution by Rare User\n\nThis rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.targets` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM.\n - **Document Used**: Check the `aws.cloudtrail.flattened.request_parameters.documentName` field, which specifies the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access.\n - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior.\n\n- **Analyze Command Parameters**:\n - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities.\n - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack.\n\n- **Check User Agent and Source IP**:\n - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually.\n - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries.\n\n- **Evaluate for Persistence Indicators**:\n - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access.\n - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions.\n\n- **Correlate with Other CloudTrail Events**:\n - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.\n - **Monitor Data Access or Modification**: Correlate with `S3` access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.\n\n### False Positive Analysis\n\n- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.\n- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances.\n\n### Response and Remediation\n\n- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.\n- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.\n- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.\n- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.\n\n### Additional Information\n\nFor further details on managing AWS SSM and security best practices for EC2 instances, refer to the [AWS Systems Manager Documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) and AWS best practices.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: \"SendCommand\"\n and event.outcome: \"success\"\n and not aws.cloudtrail.user_identity.arn: *AWSServiceRoleForAmazonSSM/StateManagerService*\n and not source.address: (\n \"ssm-guiconnect.amazonaws.com\" or\n \"ssm.amazonaws.com\" or\n \"inspector2.amazonaws.com\"\n )\n", - "references": [ - "https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.arn", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.address", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS SSM", - "Use Case: Log Auditing", - "Use Case: Threat Detection", - "Tactic: Execution", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1651", - "name": "Cloud Administration Command", - "reference": "https://attack.mitre.org/techniques/T1651/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 211 - }, - "id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa_211", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_215.json b/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_215.json new file mode 100644 index 00000000000..2fae027f982 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_215.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role.", + "false_positives": [ + "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "history_window_start": "now-7d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS SSM `SendCommand` Execution by Rare User", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": "## Triage and analysis\n\n### Investigating AWS SSM `SendCommand` Execution by Rare User\n\nThis rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.request_parameters` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM.\n - **Document Used**: Check the `aws.cloudtrail.request_parameters` field, which specifies the name of the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access.\n - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior.\n\n- **Analyze Command Parameters**:\n - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities.\n - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack.\n\n- **Check User Agent and Source IP**:\n - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually.\n - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries.\n\n- **Evaluate for Persistence Indicators**:\n - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access.\n - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions.\n\n- **Correlate with Other CloudTrail Events**:\n - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.\n - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.\n\n### False Positive Analysis\n\n- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.\n- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances.\n\n### Response and Remediation\n\n- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.\n- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.\n- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.\n- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.\n\n### Additional Information\n\nFor further details on managing AWS SSM and security best practices for EC2 instances, refer to the [AWS Systems Manager Documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) and AWS best practices.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: \"SendCommand\"\n and event.outcome: \"success\"\n and not source.address: (\n \"ssm-guiconnect.amazonaws.com\" or\n \"ssm.amazonaws.com\" or\n \"inspector2.amazonaws.com\"\n )\n", + "references": [ + "https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS SSM", + "Data Source: AWS Systems Manager", + "Use Case: Log Auditing", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1651", + "name": "Cloud Administration Command", + "reference": "https://attack.mitre.org/techniques/T1651/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 215 + }, + "id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa_215", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d_1.json b/packages/security_detection_engine/kibana/security_rule/3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d_1.json new file mode 100644 index 00000000000..0b1454404aa --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d_1.json @@ -0,0 +1,144 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential impersonation attempts via the \"kubectl\" command in Linux environments. It identifies process events where \"kubectl\" is executed with arguments that suggest an attempt to impersonate another user or group, such as using \"--kubeconfig\", \"--token\", \"--as\", or \"--as-group\". This could indicate an adversary trying to gain unauthorized access or escalate privileges within a Kubernetes cluster. If this rule is triggered, in conjunction with rules related to secret access or kubeconfig file discovery, it may indicate a potential impersonation attempt.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Impersonation Attempt via Kubectl", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Impersonation Attempt via Kubectl\n\nKubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit kubectl by using specific arguments to impersonate users, gaining unauthorized access or escalating privileges. The detection rule identifies suspicious kubectl executions, focusing on arguments that suggest impersonation, such as those related to user identity and authentication, to flag potential misuse.\n\n### Possible investigation steps\n\n- Review the process arguments to confirm the presence of impersonation-related flags such as \"--kubeconfig\", \"--token\", \"--as\", \"--as-group\", or \"--as-uid\" to understand the scope of the impersonation attempt.\n- Examine the parent process name and executable path to determine if the kubectl command was initiated from a suspicious location or script, such as \"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/root/*\", or \"/home/*\".\n- Check the user account associated with the kubectl execution to assess whether it aligns with expected usage patterns or if it indicates potential unauthorized access.\n- Investigate related alerts or logs for secret access or kubeconfig file discovery to identify if there is a broader pattern of suspicious activity that could indicate a coordinated impersonation attempt.\n- Analyze the network activity associated with the kubectl execution to identify any unusual connections or data transfers that may suggest unauthorized access or data exfiltration.\n\n### False positive analysis\n\n- Legitimate administrative tasks: System administrators may use kubectl with impersonation arguments for legitimate purposes such as testing permissions or managing resources on behalf of other users. To handle this, create exceptions for known administrative accounts or specific IP addresses.\n- Automation scripts: Automated scripts or CI/CD pipelines might use impersonation arguments to perform tasks across different environments. Review and whitelist these scripts by identifying their unique execution patterns or specific user accounts.\n- Development and testing environments: Developers might use impersonation features in non-production environments for testing purposes. Exclude these environments by filtering based on environment-specific identifiers or network segments.\n- Security tools: Some security tools or monitoring solutions may use impersonation arguments to audit or verify access controls. Identify these tools and exclude their processes by recognizing their signatures or execution paths.\n- Frequent legitimate use cases: If certain teams or departments regularly use impersonation for valid reasons, consider creating role-based exceptions to reduce noise while maintaining security oversight.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or privilege escalation.\n- Revoke any potentially compromised credentials, such as tokens or kubeconfig files, and issue new ones with updated security policies.\n- Review and audit the Kubernetes RBAC (Role-Based Access Control) settings to ensure that only authorized users have the necessary permissions, and adjust roles and permissions as needed to minimize privilege escalation risks.\n- Conduct a thorough investigation of the affected systems to identify any unauthorized changes or deployments made by the adversary, and roll back any malicious or suspicious configurations.\n- Monitor for any further suspicious kubectl activity, especially those involving impersonation arguments, and set up alerts for any similar future attempts.\n- Escalate the incident to the security operations team for a comprehensive review and to determine if additional security measures or incident response actions are required.\n- Implement additional logging and monitoring for kubectl commands and Kubernetes API interactions to enhance detection capabilities for similar threats in the future.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"executed\", \"process_started\") and\nprocess.name == \"kubectl\" and (\n process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") or\n (\n process.parent.executable like (\"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/root/*\", \"/home/*\") or\n process.parent.name like (\".*\", \"*.sh\")\n )\n) and process.args like~ (\"--kubeconfig*\", \"--token*\", \"--as*\", \"--as-group*\", \"--as-uid*\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "auditd_manager", + "version": "^1.18.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Discovery", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + }, + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1552", + "name": "Unsecured Credentials", + "reference": "https://attack.mitre.org/techniques/T1552/" + }, + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/42c97e6e-60c3-11f0-832a-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/42c97e6e-60c3-11f0-832a-f661ea17fbcd_1.json new file mode 100644 index 00000000000..a883dab8d16 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/42c97e6e-60c3-11f0-832a-f661ea17fbcd_1.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "filebeat-*", + "logs-azure.graphactivitylogs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "External Authentication Method Addition or Modification in Entra ID", + "new_terms_fields": [ + "azure.graphactivitylogs.properties.user_principal_object_id" + ], + "note": "## Triage and analysis\n\n### Investigating External Authentication Method Addition or Modification in Entra ID\n\nThis rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods.\n\n### Possible investigation steps\n- Validate that `event.action` is `\"Microsoft Graph Activity\"` and that `http.request.method` is `\"PATCH\"`, indicating a configuration change was made.\n- Confirm that `url.path` contains the string `authenticationMethodsPolicy`, which is associated with external authentication settings in Entra ID.\n- Review `user.id` to identify the Azure AD object ID of the user or service principal that initiated the change.\n- Examine `azure.graphactivitylogs.properties.app_id` to determine the application ID that performed the action.\n- Analyze `azure.graphactivitylogs.properties.scopes[]` to assess whether the request used privileged scopes such as `AuthenticationMethod.ReadWrite.All`.\n- Review the geographic origin of the request using `source.geo.*` and the `source.ip` field to identify anomalous locations.\n- Examine `user_agent.original` to determine whether the request was made through a browser or automation (e.g., scripted activity).\n- Correlate `azure.graphactivitylogs.properties.token_issued_at` and `azure.graphactivitylogs.properties.time_generated` to assess whether the change occurred shortly after token issuance.\n- Investigate additional activity by the same `user.id` or `app_id` within a short timeframe (e.g., 30 minutes) to detect related suspicious behavior.\n- Use the `operation_id` or `correlation_id` to pivot across related Graph API or Entra ID activity logs, if available.\n\n### False positive analysis\n- Legitimate administrative activity may trigger this rule, such as configuring FIDO2 or enabling passwordless sign-in methods during onboarding or security upgrades.\n- Some enterprise integrations or federated identity providers may programmatically update EAM settings as part of legitimate operations.\n- Routine security assessments or red team exercises may include changes to authentication policies. Validate with internal teams when in doubt.\n- If appropriate, filter or suppress alerts originating from known trusted service principals or administrative accounts.\n\n### Response and remediation\n- Confirm whether the user or application that made the change was authorized to do so. If not, immediately revoke access and reset credentials as needed.\n- Review the application or automation that triggered the change to ensure it is legitimate. If unauthorized, disable or remove it and rotate secrets or tokens it may have accessed.\n- Audit current external authentication configurations and conditional access policies to ensure no persistent backdoors were introduced.\n- Revoke session tokens associated with the change using Entra ID's portal or Microsoft Graph API, and enforce reauthentication where appropriate.\n- Implement stricter RBAC or conditional access policies to prevent unauthorized EAM changes in the future.\n- Monitor for repeat or similar activity from the same source or identity as part of an ongoing compromise assessment.\n", + "query": "event.dataset: azure.graphactivitylogs and\n url.path: *authenticationMethodsPolicy* and\n http.request.method: \"PATCH\" and\n http.response.status_code: 200\n", + "references": [ + "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/" + ], + "related_integrations": [ + { + "integration": "graphactivitylogs", + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "http.request.method", + "type": "keyword" + }, + { + "ecs": true, + "name": "http.response.status_code", + "type": "long" + }, + { + "ecs": true, + "name": "url.path", + "type": "wildcard" + } + ], + "risk_score": 47, + "rule_id": "42c97e6e-60c3-11f0-832a-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Graph", + "Data Source: Microsoft Graph Activity Logs", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Tactic: Persistence" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/", + "subtechnique": [ + { + "id": "T1556.009", + "name": "Conditional Access Policies", + "reference": "https://attack.mitre.org/techniques/T1556/009/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "42c97e6e-60c3-11f0-832a-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_316.json b/packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_316.json deleted file mode 100644 index 46c4af5c9f3..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4630d948-40d4-4cef-ac69-4002e29bc3db_316.json +++ /dev/null @@ -1,158 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-crowdstrike.fdr*", - "logs-endpoint.events.process-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*", - "logs-system.security*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Adding Hidden File Attribute via Attrib", - "note": "## Triage and analysis\n\n### Investigating Adding Hidden File Attribute via Attrib\n\nThe `Hidden` attribute is a file or folder attribute that makes the file or folder invisible to regular directory listings when the attribute is set. \n\nAttackers can use this attribute to conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it.\n\nThis rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Examine the command line to identify the target file or folder.\n - Examine the file, which process created it, header, etc.\n - If suspicious, retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Observe and collect information about the following activities in the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n (process.name : \"attrib.exe\" or ?process.pe.original_file_name == \"ATTRIB.EXE\") and process.args : \"+h\" and\n not (process.parent.name: \"cmd.exe\" and process.command_line: \"attrib +R +H +S +A *.cui\")\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "m365_defender", - "version": "^2.0.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - }, - { - "package": "crowdstrike", - "version": "^1.1.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.pe.original_file_name", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "4630d948-40d4-4cef-ac69-4002e29bc3db", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Tactic: Persistence", - "Data Source: Elastic Endgame", - "Resources: Investigation Guide", - "Data Source: Elastic Defend", - "Data Source: Windows Security Event Logs", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Sysmon", - "Data Source: SentinelOne", - "Data Source: Crowdstrike" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1222", - "name": "File and Directory Permissions Modification", - "reference": "https://attack.mitre.org/techniques/T1222/", - "subtechnique": [ - { - "id": "T1222.001", - "name": "Windows File and Directory Permissions Modification", - "reference": "https://attack.mitre.org/techniques/T1222/001/" - } - ] - }, - { - "id": "T1564", - "name": "Hide Artifacts", - "reference": "https://attack.mitre.org/techniques/T1564/", - "subtechnique": [ - { - "id": "T1564.001", - "name": "Hidden Files and Directories", - "reference": "https://attack.mitre.org/techniques/T1564/001/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [] - } - ], - "timeline_id": "e70679c2-6cde-4510-9764-4823df18f7db", - "timeline_title": "Comprehensive Process Timeline", - "timestamp_override": "event.ingested", - "type": "eql", - "version": 316 - }, - "id": "4630d948-40d4-4cef-ac69-4002e29bc3db_316", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_108.json b/packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_108.json deleted file mode 100644 index a58e86e6f4c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/48819484-9826-4083-9eba-1da74cd0eaf2_108.json +++ /dev/null @@ -1,99 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a Microsoft 365 Mailbox is accessed by a ClientAppId that was observed for the fist time during the last 10 days.", - "false_positives": [ - "User using a new mail client." - ], - "from": "now-30m", - "history_window_start": "now-25d", - "index": [ - "filebeat-*", - "logs-o365*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Suspicious Microsoft 365 Mail Access by ClientAppId", - "new_terms_fields": [ - "o365.audit.ClientAppId" - ], - "note": "## Triage and analysis\n\n### Investigating Suspicious Microsoft 365 Mail Access by ClientAppId\n\n- Verify the ClientAppId, source.ip and geolocation associated with Mail Access.\n- Verify the total number of used ClientAppId by that specific user.id.\n- Verify if the mailbox owner was on leave and just resumed working or not.\n- Verify if there are other alerts associated with the same user.id.\n- Verify the total number of connections from that ClientAppId, if it's accessing other mailboxes and with a high frequency there is a high chance it's a false positive.\n\n### False positive analysis\n\n- Legit Microsoft or third party ClientAppId.\n- User changing of ClientAppId or new connection post an extended period of leave.\n- If the total number of accessed Mailboxes by ClientAppId is too high there is a high chance it's a false positive.\n", - "query": "event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:MailItemsAccessed and event.outcome:success and \nnot o365.audit.ClientAppId : (\"13937bba-652e-4c46-b222-3003f4d1ff97\" or \"6326e366-9d6d-4c70-b22a-34c7ea72d73d\" or \n \"a3883eba-fbe9-48bd-9ed3-dca3e0e84250\" or \"d3590ed6-52b3-4102-aeff-aad2292ab01c\" or \"27922004-5251-4030-b22d-91ecd9a37ea4\" or \n \"1fec8e78-bce4-4aaf-ab1b-5451cc387264\" or \"26a7ee05-5602-4d76-a7ba-eae8b7b67941\" or \"00000002-0000-0000-c000-000000000000\" or \n \"00000002-0000-0ff1-ce00-000000000000\" or \"ffcb16e8-f789-467c-8ce9-f826a080d987\" or \"00000003-0000-0ff1-ce00-000000000000\" or \n \"00000004-0000-0ff1-ce00-000000000000\" or \"00000005-0000-0ff1-ce00-000000000000\" or \"00000006-0000-0ff1-ce00-000000000000\" or \n \"00000007-0000-0000-c000-000000000000\" or \"00000007-0000-0ff1-ce00-000000000000\" or \n \"00000009-0000-0000-c000-000000000000\" or \"0000000c-0000-0000-c000-000000000000\" or \"00000015-0000-0000-c000-000000000000\" or \n \"0000001a-0000-0000-c000-000000000000\" or \"00b41c95-dab0-4487-9791-b9d2c32c80f2\" or \"022907d3-0f1b-48f7-badc-1ba6abab6d66\" or \n \"04b07795-8ddb-461a-bbee-02f9e1bf7b46\" or \"08e18876-6177-487e-b8b5-cf950c1e598c\" or \"0cb7b9ec-5336-483b-bc31-b15b5788de71\" or \n \"0cd196ee-71bf-4fd6-a57c-b491ffd4fb1e\" or \"0f698dd4-f011-4d23-a33e-b36416dcb1e6\" or \"13937bba-652e-4c46-b222-3003f4d1ff97\" or \n \"14d82eec-204b-4c2f-b7e8-296a70dab67e\" or \"16aeb910-ce68-41d1-9ac3-9e1673ac9575\" or \"1786c5ed-9644-47b2-8aa0-7201292175b6\" or \n \"17d5e35f-655b-4fb0-8ae6-86356e9a49f5\" or \"18fbca16-2224-45f6-85b0-f7bf2b39b3f3\" or \"1950a258-227b-4e31-a9cf-717495945fc2\" or \n \"1b3c667f-cde3-4090-b60b-3d2abd0117f0\" or \"1fec8e78-bce4-4aaf-ab1b-5451cc387264\" or \"20a11fe0-faa8-4df5-baf2-f965f8f9972e\" or \n \"23523755-3a2b-41ca-9315-f81f3f566a95\" or \"243c63a3-247d-41c5-9d83-7788c43f1c43\" or \"268761a2-03f3-40df-8a8b-c3db24145b6b\" or \n \"26a7ee05-5602-4d76-a7ba-eae8b7b67941\" or \"26abc9a8-24f0-4b11-8234-e86ede698878\" or \"27922004-5251-4030-b22d-91ecd9a37ea4\" or \n \"28b567f6-162c-4f54-99a0-6887f387bbcc\" or \"29d9ed98-a469-4536-ade2-f981bc1d605e\" or \"2abdc806-e091-4495-9b10-b04d93c3f040\" or \n \"2d4d3d8e-2be3-4bef-9f87-7875a61c29de\" or \"2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8\" or \"3090ab82-f1c1-4cdf-af2c-5d7a6f3e2cc7\" or \n \"35d54a08-36c9-4847-9018-93934c62740c\" or \"37182072-3c9c-4f6a-a4b3-b3f91cacffce\" or \"38049638-cc2c-4cde-abe4-4479d721ed44\" or \n \"3c896ded-22c5-450f-91f6-3d1ef0848f6e\" or \"4345a7b9-9a63-4910-a426-35363201d503\" or \"45a330b1-b1ec-4cc1-9161-9f03992aa49f\" or \n \"4765445b-32c6-49b0-83e6-1d93765276ca\" or \"497effe9-df71-4043-a8bb-14cf78c4b63b\" or \"4b233688-031c-404b-9a80-a4f3f2351f90\" or \n \"4d5c2d63-cf83-4365-853c-925fd1a64357\" or \"51be292c-a17e-4f17-9a7e-4b661fb16dd2\" or \n \"5572c4c0-d078-44ce-b81c-6cbf8d3ed39e\" or \"5e3ce6c0-2b1f-4285-8d4b-75ee78787346\" or \"60c8bde5-3167-4f92-8fdb-059f6176dc0f\" or \n \"61109738-7d2b-4a0b-9fe3-660b1ff83505\" or \"62256cef-54c0-4cb4-bcac-4c67989bdc40\" or \"6253bca8-faf2-4587-8f2f-b056d80998a7\" or \n \"65d91a3d-ab74-42e6-8a2f-0add61688c74\" or \"66a88757-258c-4c72-893c-3e8bed4d6899\" or \"67e3df25-268a-4324-a550-0de1c7f97287\" or \n \"69893ee3-dd10-4b1c-832d-4870354be3d8\" or \"74658136-14ec-4630-ad9b-26e160ff0fc6\" or \"74bcdadc-2fdc-4bb3-8459-76d06952a0e9\" or \n \"797f4846-ba00-4fd7-ba43-dac1f8f63013\" or \"7ab7862c-4c57-491e-8a45-d52a7e023983\" or \"7ae974c5-1af7-4923-af3a-fb1fd14dcb7e\" or \n \"7b7531ad-5926-4f2d-8a1d-38495ad33e17\" or \"80ccca67-54bd-44ab-8625-4b79c4dc7775\" or \"835b2a73-6e10-4aa5-a979-21dfda45231c\" or \n \"871c010f-5e61-4fb1-83ac-98610a7e9110\" or \"89bee1f7-5e6e-4d8a-9f3d-ecd601259da7\" or \"8edd93e1-2103-40b4-bd70-6e34e586362d\" or \n \"905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba\" or \"91ca2ca5-3b3e-41dd-ab65-809fa3dffffa\" or \"93625bc8-bfe2-437a-97e0-3d0060024faa\" or \n \"93d53678-613d-4013-afc1-62e9e444a0a5\" or \"944f0bd1-117b-4b1c-af26-804ed95e767e\" or \"94c63fef-13a3-47bc-8074-75af8c65887a\" or \n \"95de633a-083e-42f5-b444-a4295d8e9314\" or \"97cb1f73-50df-47d1-8fb0-0271f2728514\" or \"98db8bd6-0cc0-4e67-9de5-f187f1cd1b41\" or \n \"99b904fd-a1fe-455c-b86c-2f9fb1da7687\" or \"9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7\" or \"a3475900-ccec-4a69-98f5-a65cd5dc5306\" or \n \"a3b79187-70b2-4139-83f9-6016c58cd27b\" or \"a57aca87-cbc0-4f3c-8b9e-dc095fdc8978\" or \"a970bac6-63fe-4ec5-8884-8536862c42d4\" or \n \"a9b49b65-0a12-430b-9540-c80b3332c127\" or \"ab9b8c07-8f02-4f72-87fa-80105867a763\" or \"ae8e128e-080f-4086-b0e3-4c19301ada69\" or \n \"b23dd4db-9142-4734-867f-3577f640ad0c\" or \"b4bddae8-ab25-483e-8670-df09b9f1d0ea\" or \"b669c6ea-1adf-453f-b8bc-6d526592b419\" or \n \"b6e69c34-5f1f-4c34-8cdf-7fea120b8670\" or \"bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4\" or \"bdd48c81-3a58-4ea9-849c-ebea7f6b6360\" or \n \"c1c74fed-04c9-4704-80dc-9f79a2e515cb\" or \"c35cb2ba-f88b-4d15-aa9d-37bd443522e1\" or \"c44b4083-3bb0-49c1-b47d-974e53cbdf3c\" or \n \"c9a559d2-7aab-4f13-a6ed-e7e9c52aec87\" or \"cc15fd57-2c6c-4117-a88c-83b1d56b4bbe\" or \"cf36b471-5b44-428c-9ce7-313bf84528de\" or \n \"cf53fce8-def6-4aeb-8d30-b158e7b1cf83\" or \"d176f6e7-38e5-40c9-8a78-3998aab820e7\" or \"d3590ed6-52b3-4102-aeff-aad2292ab01c\" or \n \"d73f4b35-55c9-48c7-8b10-651f6f2acb2e\" or \"d9b8ec3a-1e4e-4e08-b3c2-5baf00c0fcb0\" or \"de8bc8b5-d9f9-48b1-a8ad-b748da725064\" or \n \"dfe74da8-9279-44ec-8fb2-2aed9e1c73d0\" or \"e1ef36fd-b883-4dbf-97f0-9ece4b576fc6\" or \"e64aa8bc-8eb4-40e2-898b-cf261a25954f\" or \n \"e9f49c6b-5ce5-44c8-925d-015017e9f7ad\" or \"ee272b19-4411-433f-8f28-5c13cb6fd407\" or \"f5eaa862-7f08-448c-9c4e-f4047d4d4521\" or \n \"fb78d390-0c51-40cd-8e17-fdbfab77341b\" or \"fc0f3af4-6835-4174-b806-f7db311fd2f3\" or \"fdf9885b-dd37-42bf-82e5-c3129ef5a302\"\n)\n", - "references": [ - "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a" - ], - "related_integrations": [ - { - "package": "o365", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - }, - { - "ecs": false, - "name": "o365.audit.ClientAppId", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "48819484-9826-4083-9eba-1da74cd0eaf2", - "setup": "## Setup\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Microsoft 365", - "Use Case: Configuration Audit", - "Tactic: Initial Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 108 - }, - "id": "48819484-9826-4083-9eba-1da74cd0eaf2_108", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json new file mode 100644 index 00000000000..fac2036bc3d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "OIDC Discovery URL Changed in Entra ID", + "note": "## Triage and analysis\n\n### Investigating OIDC Discovery URL Changed in Entra ID\n\nThis rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity.\n\n### Possible investigation steps\n- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.\n- Examine the `old_oidc_discovery` and `new_oidc_discovery` to confirm if the new `discoveryUrl` points to an unexpected or untrusted IdP.\n- Check that the discovery URLs have `.well-known/openid-configuration` endpoints, which are standard for OIDC providers.\n- Use `azure.auditlogs.properties.correlation_id` to pivot to related changes and activity from the same session.\n- Review any subsequent sign-in activity that may have originated from the new IdP.\n- Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity.\n\n### False positive analysis\n- Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements.\n- Validate any changes with the identity or security operations team before taking action.\n\n### Response and remediation\n- If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal.\n- Revoke tokens or sessions issued after the configuration change.\n- Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app).\n- Apply conditional access policies and change control procedures to protect IdP configuration changes.\n", + "query": "FROM logs-azure.auditlogs-*\n| WHERE event.action == \"Authentication Methods Policy Update\"\n| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, \"\\\\\\\\\", \"\")\n| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, \"\\\\\\\\\", \"\")\n| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new}\\\"}%{}\"\n| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old}\\\"}%{}\"\n| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new IS NOT NULL and Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old IS NOT NULL\n| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new != Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old\n| KEEP\n @timestamp,\n event.action,\n event.outcome,\n azure.tenant_id,\n azure.correlation_id,\n azure.auditlogs.properties.activity_datetime,\n azure.auditlogs.properties.operation_type,\n azure.auditlogs.properties.initiated_by.user.userPrincipalName,\n azure.auditlogs.properties.initiated_by.user.displayName,\n azure.auditlogs.properties.initiated_by.user.ipAddress,\n source.geo.city_name,\n source.geo.region_name,\n source.geo.country_name,\n Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new,\n Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old\n", + "references": [ + "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/" + ], + "risk_score": 73, + "rule_id": "498e4094-60e7-11f0-8847-f661ea17fbcd", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Audit Logs", + "Use Case: Identity and Access Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/", + "subtechnique": [ + { + "id": "T1556.009", + "name": "Conditional Access Policies", + "reference": "https://attack.mitre.org/techniques/T1556/009/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_2.json deleted file mode 100644 index 3082b646b17..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/50a2bdea-9876-11ef-89db-f661ea17fbcd_2.json +++ /dev/null @@ -1,107 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more.", - "false_positives": [ - "Legitimate users may create SSM command documents for legitimate purposes. Ensure that the document is authorized and the user is known before taking action." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "user_agent.original", - "event.action", - "event.outcome", - "cloud.region", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS SSM Command Document Created by Rare User", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn" - ], - "note": "## Triage and analysis\n\n### Investigating AWS SSM Command Document Created by Rare User\n\nThis rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration.\n\n#### Possible Investigation Steps\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action.\n- **Analyze the Document Details**:\n - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose.\n - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console.\n- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.address`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances.\n- **Check Document Status and Metadata**:\n - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress.\n - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist.\n\n### False Positive Analysis\n\n- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel.\n- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage.\n\n### Response and Remediation\n\n- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently.\n- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users.\n- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation.\n- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation.\n\n### Additional Information\n\nFor further guidance on managing and securing AWS Systems Manager in your environment, refer to the [AWS SSM documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) and AWS security best practices.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: \"CreateDocument\"\n and event.outcome: \"success\"\n and aws.cloudtrail.response_elements: *documentType=Command*\n", - "references": [ - "https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html", - "https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.response_elements", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "50a2bdea-9876-11ef-89db-f661ea17fbcd", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS SNS", - "Data Source: AWS Systems Manager", - "Resources: Investigation Guide", - "Use Case: Threat Detection", - "Tactic: Execution" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 2 - }, - "id": "50a2bdea-9876-11ef-89db-f661ea17fbcd_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_213.json b/packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_213.json deleted file mode 100644 index 55a3258b03a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/55c2bf58-2a39-4c58-a384-c8b1978153c2_213.json +++ /dev/null @@ -1,103 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM.", - "from": "now-9m", - "index": [ - "logs-system.security*", - "logs-windows.forwarded*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Windows Service Installed via an Unusual Client", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Windows Service Installed via an Unusual Client\n\nWindows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations initiated by atypical processes, excluding known legitimate services. This helps in spotting potential privilege escalation attempts by monitoring unusual client activity.\n\n### Possible investigation steps\n\n- Review the event logs to identify the specific client process that initiated the service installation by examining the winlog.event_data.ClientProcessId and winlog.event_data.ParentProcessId fields.\n- Investigate the parent process associated with the unusual client process to determine if it is a known legitimate application or potentially malicious.\n- Check the winlog.event_data.ServiceFileName to verify the path and name of the service file, ensuring it is not a known legitimate service excluded in the query.\n- Analyze the timeline of events around the service installation to identify any preceding suspicious activities or related alerts that might indicate a broader attack.\n- Conduct a reputation check on the client process and service file using threat intelligence sources to assess if they are associated with known malicious activities.\n- Examine the system for any additional indicators of compromise, such as unexpected network connections or changes to critical system files, that may suggest privilege escalation or lateral movement attempts.\n\n### False positive analysis\n\n- Legitimate software installations or updates may trigger the rule if they create services using unusual client processes. To manage this, identify and whitelist these processes in the detection rule to prevent unnecessary alerts.\n- System management tools like Veeam and PDQ Inventory are already excluded, but other similar tools might not be. Regularly review and update the exclusion list to include any additional legitimate tools used in your environment.\n- Custom scripts or administrative tools that create services for maintenance or monitoring purposes can also cause false positives. Document these scripts and consider adding them to the exclusion list if they are verified as safe.\n- Temporary or one-time service installations for troubleshooting or testing can be mistaken for threats. Ensure that such activities are logged and communicated to the security team to avoid confusion and unnecessary alerts.\n- Changes in system configurations or updates to existing software might alter the behavior of legitimate processes, causing them to be flagged. Regularly review and adjust the detection rule to accommodate these changes while maintaining security integrity.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate the suspicious service and any associated processes identified by the alert to stop potential privilege escalation or malicious activity.\n- Conduct a thorough review of the service's configuration and associated files to identify any unauthorized changes or malicious code.\n- Restore any altered or compromised system files from a known good backup to ensure system integrity.\n- Change all administrator and SYSTEM account passwords on the affected system and any connected systems to prevent further unauthorized access.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.\n- Implement additional monitoring and logging on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities.", - "query": "configuration where host.os.type == \"windows\" and\n event.action == \"service-installed\" and\n (winlog.event_data.ClientProcessId == \"0\" or winlog.event_data.ParentProcessId == \"0\") and\n not winlog.event_data.ServiceFileName : (\n \"?:\\\\Windows\\\\VeeamVssSupport\\\\VeeamGuestHelper.exe\",\n \"?:\\\\Windows\\\\VeeamLogShipper\\\\VeeamLogShipper.exe\",\n \"%SystemRoot%\\\\system32\\\\Drivers\\\\Crowdstrike\\\\*-CsInstallerService.exe\",\n \"\\\"%windir%\\\\AdminArsenal\\\\PDQInventory-Scanner\\\\service-1\\\\PDQInventory-Scanner-1.exe\\\" \"\n )\n", - "references": [ - "https://www.x86matthew.com/view_post?id=create_svc_rpc", - "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697", - "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md", - "https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry" - ], - "related_integrations": [ - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.ClientProcessId", - "type": "unknown" - }, - { - "ecs": false, - "name": "winlog.event_data.ParentProcessId", - "type": "unknown" - }, - { - "ecs": false, - "name": "winlog.event_data.ServiceFileName", - "type": "unknown" - } - ], - "risk_score": 73, - "rule_id": "55c2bf58-2a39-4c58-a384-c8b1978153c2", - "setup": "## Setup\n\nThe 'Audit Security System Extension' logging policy must be configured for (Success)\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nSystem >\nAudit Security System Extension (Success)\n```\n", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "Data Source: Windows Security Event Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.003", - "name": "Windows Service", - "reference": "https://attack.mitre.org/techniques/T1543/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 213 - }, - "id": "55c2bf58-2a39-4c58-a384-c8b1978153c2_213", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_103.json b/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_103.json deleted file mode 100644 index 9662ea1ef01..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_103.json +++ /dev/null @@ -1,75 +0,0 @@ -{ - "attributes": { - "author": [ - "Austin Songer" - ], - "description": "Identifies when a virtual network device is modified or deleted. This can be a network virtual appliance, virtual hub, or virtual router.", - "false_positives": [ - "Virtual Network Device modification or deletion may be performed by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Virtual Network Device modification or deletion by unfamiliar users should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-25m", - "index": [ - "filebeat-*", - "logs-azure*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Azure Virtual Network Device Modified or Deleted", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Azure Virtual Network Device Modified or Deleted\n\nAzure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for malicious purposes. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions of these devices, helping identify potential unauthorized changes that could signify an attack.\n\n### Possible investigation steps\n\n- Review the Azure activity logs to identify the specific operation that triggered the alert, focusing on the operation_name field to determine whether it was a WRITE or DELETE action.\n- Check the event.outcome field to confirm the success of the operation, ensuring that the modification or deletion was completed.\n- Investigate the user or service principal responsible for the action by examining the identity information in the activity logs to determine if the change was authorized.\n- Assess the impact of the modification or deletion by identifying the affected virtual network device, such as a network interface, virtual hub, or virtual router, and evaluate its role in the network architecture.\n- Cross-reference the time of the alert with any other suspicious activities or alerts in the environment to identify potential patterns or coordinated actions.\n- Consult with relevant stakeholders or system owners to verify if the change was planned or expected, and gather additional context if necessary.\n\n### False positive analysis\n\n- Routine maintenance activities by network administrators can trigger alerts when they modify or delete virtual network devices. To manage this, create exceptions for known maintenance windows or specific administrator accounts.\n- Automated scripts or tools used for network management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.\n- Changes made by authorized third-party services or integrations that manage network configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.\n- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.\n- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.\n\n### Response and remediation\n\n- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes. This can be done by disabling the network interface or applying restrictive network security group rules.\n- Review the Azure activity logs to identify the source of the modification or deletion. Correlate this with user activity logs to determine if the action was performed by an authorized user or a compromised account.\n- If a compromised account is suspected, reset the credentials for the affected account and any other accounts that may have been exposed. Implement multi-factor authentication if not already in place.\n- Restore the modified or deleted virtual network device from a known good backup or configuration snapshot to ensure continuity of services.\n- Conduct a thorough security assessment of the affected Azure environment to identify any additional unauthorized changes or indicators of compromise.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.\n- Implement enhanced monitoring and alerting for similar activities in the future, ensuring that any modifications or deletions of virtual network devices are promptly detected and reviewed.", - "query": "event.dataset:azure.activitylogs and azure.activitylogs.operation_name:(\"MICROSOFT.NETWORK/NETWORKINTERFACES/TAPCONFIGURATIONS/WRITE\" or\n\"MICROSOFT.NETWORK/NETWORKINTERFACES/TAPCONFIGURATIONS/DELETE\" or \"MICROSOFT.NETWORK/NETWORKINTERFACES/WRITE\" or\n\"MICROSOFT.NETWORK/NETWORKINTERFACES/JOIN/ACTION\" or \"MICROSOFT.NETWORK/NETWORKINTERFACES/DELETE\" or\n\"MICROSOFT.NETWORK/NETWORKVIRTUALAPPLIANCES/DELETE\" or \"MICROSOFT.NETWORK/NETWORKVIRTUALAPPLIANCES/WRITE\" or\n\"MICROSOFT.NETWORK/VIRTUALHUBS/DELETE\" or \"MICROSOFT.NETWORK/VIRTUALHUBS/WRITE\" or\n\"MICROSOFT.NETWORK/VIRTUALROUTERS/WRITE\" or \"MICROSOFT.NETWORK/VIRTUALROUTERS/DELETE\") and\nevent.outcome:(Success or success)\n", - "references": [ - "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations" - ], - "related_integrations": [ - { - "integration": "activitylogs", - "package": "azure", - "version": "^1.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "azure.activitylogs.operation_name", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "573f6e7a-7acf-4bcd-ad42-c4969124d3c0", - "setup": "The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: Azure", - "Use Case: Network Security Monitoring", - "Tactic: Impact", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 103 - }, - "id": "573f6e7a-7acf-4bcd-ad42-c4969124d3c0_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_104.json b/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_104.json deleted file mode 100644 index f587336b9f5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_104.json +++ /dev/null @@ -1,75 +0,0 @@ -{ - "attributes": { - "author": [ - "Austin Songer" - ], - "description": "Identifies when a virtual network device is modified or deleted. This can be a network virtual appliance, virtual hub, or virtual router. **Deprecated Notice** - This rule has been deprecated in favor of other rules that provide more contextual threat behavior for Azure Virtual Network.", - "false_positives": [ - "Virtual Network Device modification or deletion may be performed by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Virtual Network Device modification or deletion by unfamiliar users should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-25m", - "index": [ - "filebeat-*", - "logs-azure*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Deprecated - Azure Virtual Network Device Modified or Deleted", - "note": "## Triage and analysis\n\n**Deprecated Notice** - This rule has been deprecated in favor of other rules that provide more contextual threat behavior for Azure Virtual Network.\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Deprecated - Azure Virtual Network Device Modified or Deleted\n\nAzure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for malicious purposes. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions of these devices, helping identify potential unauthorized changes that could signify an attack.\n\n### Possible investigation steps\n\n- Review the Azure activity logs to identify the specific operation that triggered the alert, focusing on the operation_name field to determine whether it was a WRITE or DELETE action.\n- Check the event.outcome field to confirm the success of the operation, ensuring that the modification or deletion was completed.\n- Investigate the user or service principal responsible for the action by examining the identity information in the activity logs to determine if the change was authorized.\n- Assess the impact of the modification or deletion by identifying the affected virtual network device, such as a network interface, virtual hub, or virtual router, and evaluate its role in the network architecture.\n- Cross-reference the time of the alert with any other suspicious activities or alerts in the environment to identify potential patterns or coordinated actions.\n- Consult with relevant stakeholders or system owners to verify if the change was planned or expected, and gather additional context if necessary.\n\n### False positive analysis\n\n- Routine maintenance activities by network administrators can trigger alerts when they modify or delete virtual network devices. To manage this, create exceptions for known maintenance windows or specific administrator accounts.\n- Automated scripts or tools used for network management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.\n- Changes made by authorized third-party services or integrations that manage network configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.\n- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.\n- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.\n\n### Response and remediation\n\n- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes. This can be done by disabling the network interface or applying restrictive network security group rules.\n- Review the Azure activity logs to identify the source of the modification or deletion. Correlate this with user activity logs to determine if the action was performed by an authorized user or a compromised account.\n- If a compromised account is suspected, reset the credentials for the affected account and any other accounts that may have been exposed. Implement multi-factor authentication if not already in place.\n- Restore the modified or deleted virtual network device from a known good backup or configuration snapshot to ensure continuity of services.\n- Conduct a thorough security assessment of the affected Azure environment to identify any additional unauthorized changes or indicators of compromise.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.\n- Implement enhanced monitoring and alerting for similar activities in the future, ensuring that any modifications or deletions of virtual network devices are promptly detected and reviewed.", - "query": "event.dataset:azure.activitylogs and azure.activitylogs.operation_name:(\"MICROSOFT.NETWORK/NETWORKINTERFACES/TAPCONFIGURATIONS/WRITE\" or\n\"MICROSOFT.NETWORK/NETWORKINTERFACES/TAPCONFIGURATIONS/DELETE\" or \"MICROSOFT.NETWORK/NETWORKINTERFACES/WRITE\" or\n\"MICROSOFT.NETWORK/NETWORKINTERFACES/JOIN/ACTION\" or \"MICROSOFT.NETWORK/NETWORKINTERFACES/DELETE\" or\n\"MICROSOFT.NETWORK/NETWORKVIRTUALAPPLIANCES/DELETE\" or \"MICROSOFT.NETWORK/NETWORKVIRTUALAPPLIANCES/WRITE\" or\n\"MICROSOFT.NETWORK/VIRTUALHUBS/DELETE\" or \"MICROSOFT.NETWORK/VIRTUALHUBS/WRITE\" or\n\"MICROSOFT.NETWORK/VIRTUALROUTERS/WRITE\" or \"MICROSOFT.NETWORK/VIRTUALROUTERS/DELETE\") and\nevent.outcome:(Success or success)\n", - "references": [ - "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations" - ], - "related_integrations": [ - { - "integration": "activitylogs", - "package": "azure", - "version": "^1.22.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "azure.activitylogs.operation_name", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "573f6e7a-7acf-4bcd-ad42-c4969124d3c0", - "setup": "The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: Azure", - "Use Case: Network Security Monitoring", - "Tactic: Impact", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 104 - }, - "id": "573f6e7a-7acf-4bcd-ad42-c4969124d3c0_104", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_105.json b/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_105.json deleted file mode 100644 index dc685d4001a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/573f6e7a-7acf-4bcd-ad42-c4969124d3c0_105.json +++ /dev/null @@ -1,75 +0,0 @@ -{ - "attributes": { - "author": [ - "Austin Songer" - ], - "description": "Identifies when a virtual network device is modified or deleted. This can be a network virtual appliance, virtual hub, or virtual router. **Deprecated Notice** - This rule has been deprecated in favor of other rules that provide more contextual threat behavior for Azure Virtual Network.", - "false_positives": [ - "Virtual Network Device modification or deletion may be performed by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Virtual Network Device modification or deletion by unfamiliar users should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-25m", - "index": [ - "filebeat-*", - "logs-azure*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Deprecated - Azure Virtual Network Device Modified or Deleted", - "note": "## Triage and analysis\n\n**Deprecated Notice** - This rule has been deprecated in favor of other rules that provide more contextual threat behavior for Azure Virtual Network.\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Deprecated - Azure Virtual Network Device Modified or Deleted\n\nAzure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for malicious purposes. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions of these devices, helping identify potential unauthorized changes that could signify an attack.\n\n### Possible investigation steps\n\n- Review the Azure activity logs to identify the specific operation that triggered the alert, focusing on the operation_name field to determine whether it was a WRITE or DELETE action.\n- Check the event.outcome field to confirm the success of the operation, ensuring that the modification or deletion was completed.\n- Investigate the user or service principal responsible for the action by examining the identity information in the activity logs to determine if the change was authorized.\n- Assess the impact of the modification or deletion by identifying the affected virtual network device, such as a network interface, virtual hub, or virtual router, and evaluate its role in the network architecture.\n- Cross-reference the time of the alert with any other suspicious activities or alerts in the environment to identify potential patterns or coordinated actions.\n- Consult with relevant stakeholders or system owners to verify if the change was planned or expected, and gather additional context if necessary.\n\n### False positive analysis\n\n- Routine maintenance activities by network administrators can trigger alerts when they modify or delete virtual network devices. To manage this, create exceptions for known maintenance windows or specific administrator accounts.\n- Automated scripts or tools used for network management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.\n- Changes made by authorized third-party services or integrations that manage network configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.\n- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.\n- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.\n\n### Response and remediation\n\n- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes. This can be done by disabling the network interface or applying restrictive network security group rules.\n- Review the Azure activity logs to identify the source of the modification or deletion. Correlate this with user activity logs to determine if the action was performed by an authorized user or a compromised account.\n- If a compromised account is suspected, reset the credentials for the affected account and any other accounts that may have been exposed. Implement multi-factor authentication if not already in place.\n- Restore the modified or deleted virtual network device from a known good backup or configuration snapshot to ensure continuity of services.\n- Conduct a thorough security assessment of the affected Azure environment to identify any additional unauthorized changes or indicators of compromise.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.\n- Implement enhanced monitoring and alerting for similar activities in the future, ensuring that any modifications or deletions of virtual network devices are promptly detected and reviewed.", - "query": "event.dataset:azure.activitylogs and azure.activitylogs.operation_name:(\"MICROSOFT.NETWORK/NETWORKINTERFACES/TAPCONFIGURATIONS/WRITE\" or\n\"MICROSOFT.NETWORK/NETWORKINTERFACES/TAPCONFIGURATIONS/DELETE\" or \"MICROSOFT.NETWORK/NETWORKINTERFACES/WRITE\" or\n\"MICROSOFT.NETWORK/NETWORKINTERFACES/JOIN/ACTION\" or \"MICROSOFT.NETWORK/NETWORKINTERFACES/DELETE\" or\n\"MICROSOFT.NETWORK/NETWORKVIRTUALAPPLIANCES/DELETE\" or \"MICROSOFT.NETWORK/NETWORKVIRTUALAPPLIANCES/WRITE\" or\n\"MICROSOFT.NETWORK/VIRTUALHUBS/DELETE\" or \"MICROSOFT.NETWORK/VIRTUALHUBS/WRITE\" or\n\"MICROSOFT.NETWORK/VIRTUALROUTERS/WRITE\" or \"MICROSOFT.NETWORK/VIRTUALROUTERS/DELETE\") and\nevent.outcome:(Success or success)\n", - "references": [ - "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations" - ], - "related_integrations": [ - { - "integration": "activitylogs", - "package": "azure", - "version": "^1.22.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "azure.activitylogs.operation_name", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "573f6e7a-7acf-4bcd-ad42-c4969124d3c0", - "setup": "The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: Azure", - "Use Case: Network Security Monitoring", - "Tactic: Impact", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 105 - }, - "id": "573f6e7a-7acf-4bcd-ad42-c4969124d3c0_105", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_7.json b/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_7.json deleted file mode 100644 index 52faf0b026f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_7.json +++ /dev/null @@ -1,99 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control.", - "false_positives": [ - "Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few legitimate use-cases and should result in very few false positives." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Suspicious Assignment of Controller Service Account", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Suspicious Assignment of Controller Service Account\n\nKubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the audit logs to confirm the presence of a \"create\" event for a pod in the \"kube-system\" namespace with a service account name containing \"controller\".\n- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.\n- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.\n- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.\n- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.\n- Review recent changes or deployments in the \"kube-system\" namespace to identify any unauthorized modifications or anomalies.\n\n### False positive analysis\n\n- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.\n- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.\n- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.\n- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.\n- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.\n\n### Response and remediation\n\n- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.\n- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.\n- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.\n- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.\n- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.\n- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb : \"create\"\n and kubernetes.audit.objectRef.resource : \"pods\"\n and kubernetes.audit.objectRef.namespace : \"kube-system\"\n and kubernetes.audit.requestObject.spec.serviceAccountName:*controller\n", - "references": [ - "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.namespace", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.serviceAccountName", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "63c05204-339a-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.001", - "name": "Default Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 7 - }, - "id": "63c05204-339a-11ed-a261-0242ac120002_7", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_6.json b/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_6.json deleted file mode 100644 index ce7c2a3a184..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_6.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster.", - "false_positives": [ - "Unauthorized requests from service accounts are highly abnormal and more indicative of human behavior or a serious problem within the cluster. This behavior should be investigated further." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Denied Service Account Request", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Denied Service Account Request\n\nKubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations.\n\n### Possible investigation steps\n\n- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used.\n- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request.\n- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated.\n- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior.\n- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations.\n- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request.\n\n### False positive analysis\n\n- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use.\n- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities.\n- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions.\n- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities.\n- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior.\n\n### Response and remediation\n\n- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests.\n- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account.\n- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation.\n- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required.\n- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents.\n- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future.", - "query": "event.dataset: \"kubernetes.audit_logs\"\n and kubernetes.audit.user.username: system\\:serviceaccount\\:*\n and kubernetes.audit.annotations.authorization_k8s_io/decision: \"forbid\"\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.user.username", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "63c056a0-339a-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Discovery", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1613", - "name": "Container and Resource Discovery", - "reference": "https://attack.mitre.org/techniques/T1613/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 6 - }, - "id": "63c056a0-339a-11ed-a261-0242ac120002_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_7.json b/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_7.json deleted file mode 100644 index 940449bb304..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_7.json +++ /dev/null @@ -1,90 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.", - "false_positives": [ - "Anonymous access to the API server is a dangerous setting enabled by default. Common anonymous connections (e.g., health checks) have been excluded from this rule. All other instances of authorized anonymous requests should be investigated." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Anonymous Request Authorized", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Anonymous Request Authorized\n\nKubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.\n- Examine the kubernetes.audit.user.username field to confirm if the request was made by \"system:anonymous\" or \"system:unauthenticated\" and assess the potential risk associated with these accounts.\n- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.\n- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.\n- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.\n\n### False positive analysis\n\n- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.\n- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.\n- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.\n- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.\n- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.\n- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.\n- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.\n- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.\n- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.\n- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.", - "query": "event.dataset:kubernetes.audit_logs\n and kubernetes.audit.annotations.authorization_k8s_io/decision:allow\n and kubernetes.audit.user.username:(\"system:anonymous\" or \"system:unauthenticated\" or not *)\n and not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz*)\n", - "references": [ - "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestURI", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.user.username", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "63c057cc-339a-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Initial Access", - "Tactic: Defense Evasion", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.001", - "name": "Default Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 7 - }, - "id": "63c057cc-339a-11ed-a261-0242ac120002_7", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_204.json b/packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_204.json deleted file mode 100644 index 5ffff33b950..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/65f9bccd-510b-40df-8263-334f03174fed_204.json +++ /dev/null @@ -1,89 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster.", - "false_positives": [ - "Developers may have a legitimate use for NodePorts. For frontend parts of an application you may want to expose a Service onto an external IP address without using cloud specific Loadbalancers. NodePort can be used to expose the Service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort Service from outside the cluster, by requesting :. NodePort unlike Loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by Kubernetes, or even to expose one or more node's IPs directly." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Exposed Service Created With Type NodePort", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Exposed Service Created With Type NodePort\n\nKubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is \"services\" and kubernetes.audit.verb is \"create\", \"update\", or \"patch\".\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized.\n- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name.\n- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally.\n- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception.\n- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent.\n\n### False positive analysis\n\n- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly.\n- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters.\n- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts.\n- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms.\n- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period.\n\n### Response and remediation\n\n- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception.\n- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service.\n- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service.\n- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed.\n- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture.\n- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited.\n- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"services\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.type:\"NodePort\"\n", - "references": [ - "https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types", - "https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport", - "https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "65f9bccd-510b-40df-8263-334f03174fed", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1133", - "name": "External Remote Services", - "reference": "https://attack.mitre.org/techniques/T1133/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 204 - }, - "id": "65f9bccd-510b-40df-8263-334f03174fed_204", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_7.json b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_7.json new file mode 100644 index 00000000000..b9d598f4b15 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_7.json @@ -0,0 +1,104 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `CreateAccessKey` for the targeted user." + ], + "from": "now-6m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "source.address", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "user_agent.original", + "user.target.name", + "event.action", + "event.outcome", + "cloud.region", + "event.provider", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM User Created Access Keys For Another User", + "note": "## Triage and analysis\n\n### Investigating AWS IAM User Created Access Keys For Another User\n\nAWS access keys created for IAM users or root user are long-term credentials that provide programmatic access to AWS.\nWith access to the `iam:CreateAccessKey` permission, a set of compromised credentials could be used to create a new\nset of credentials for another user for privilege escalation or as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `CreateAccessKey` operation where the user.name is different from the user.target.name.\n\n\n#### Possible investigation steps\n\n- Identify both related accounts and their role in the environment.\n- Review IAM permission policies for the user identities.\n- Identify the applications or users that should use these accounts.\n- Investigate other alerts associated with the accounts during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owners and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `CreateAccessKey` operation. Verify the `aws.cloudtrail.user_identity.arn` should use this operation against the `user.target.name` account.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the newly created credentials from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\"\n and event.action == \"CreateAccessKey\"\n and event.outcome == \"success\"\n and user.name != user.target.name\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n user.name,\n source.address,\n user.target.name,\n user_agent.original,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.response_elements,\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.type\n", + "references": [ + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey", + "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence", + "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud", + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html" + ], + "risk_score": 47, + "rule_id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.001", + "name": "Additional Cloud Credentials", + "reference": "https://attack.mitre.org/techniques/T1098/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.001", + "name": "Additional Cloud Credentials", + "reference": "https://attack.mitre.org/techniques/T1098/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_6.json new file mode 100644 index 00000000000..d2ac497b103 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_6.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well.", + "false_positives": [ + "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action. AWS Marketplace subscriptions automatically result in assets.marketplace.amazonaws.com invoking ModifyImageAttribute to share the AMI with your account. This rule excludes Marketplace-invoked sharing by design. Other AWS services like workspaces.amazonaws.com and backup.amazonaws.com may invoke this action when users configure sharing through WorkSpaces or Backup plans. Review such service-invoked events to confirm they match legitimate and intended sharing configurations." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 AMI Shared with Another Account", + "note": "## Triage and analysis\n\n### Investigating AWS EC2 AMI Shared with Another Account\n\nThis rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control.\n\n#### Possible Investigation Steps\n\n- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts.\n - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared.\n- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it.\n- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.\n- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources.\n- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments.\n- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing.\n\n### False Positive Analysis\n\n- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating.\n- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior.\n- **AWS Services**: Some AWS services, such as WorkSpaces and Backup, automate AMI sharing when users configure cross-account sharing or disaster recovery plans. These will appear in CloudTrail with `userIdentity.invokedBy` and `source.address` fields like `workspaces.amazonaws.com` or `backup.amazonaws.com`. Confirm that such activity aligns with your organization's approved configurations.\n\n### Response and Remediation\n\n- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI.\n- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns.\n- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.\n- **Policy Update**: Review and possibly update your organization\u2019s policies on AMI sharing to tighten control and prevent unauthorized access.\n- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing.\n\n### Additional Information\n\nFor more information on managing and sharing AMIs, refer to the [Amazon EC2 User Guide on AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) and [Sharing AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html). Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team [here](https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/).\n\n", + "query": "event.dataset: \"aws.cloudtrail\" and event.provider: \"ec2.amazonaws.com\"\n and event.action: ModifyImageAttribute and event.outcome: success\n and aws.cloudtrail.request_parameters: *add=*\n and not aws.cloudtrail.user_identity.invoked_by: \"assets.marketplace.amazonaws.com\"\n", + "references": [ + "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html", + "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html", + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.invoked_by", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6a309864-fc3f-11ee-b8cc-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 6 + }, + "id": "6a309864-fc3f-11ee-b8cc-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_4.json b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_4.json new file mode 100644 index 00000000000..04fc4f68f85 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_4.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Port Scanning Activity from Compromised Host", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Port Scanning Activity from Compromised Host\n\nPort scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent.\n\n### Possible investigation steps\n\n- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields.\n- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host.\n- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious.\n- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in.\n- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations.\n- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation.\n\n### False positive analysis\n\n- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools.\n- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names.\n- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables.\n- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers.\n- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures.\n\n### Response and remediation\n\n- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement.\n- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities.\n- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts.\n- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited.\n- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access.\n- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), port_count = count_distinct(destination.port), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.ip\n| where agent_count == 1 and port_count > 100\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "6b341d03-1d63-41ac-841a-2009c86959ca", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1046", + "name": "Network Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1046/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "6b341d03-1d63-41ac-841a-2009c86959ca_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_110.json b/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_110.json deleted file mode 100644 index b08d50828ce..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_110.json +++ /dev/null @@ -1,118 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Adversaries may install legitimate remote access tools (RAT) to compromised endpoints for further command-and-control (C2). Adversaries can rely on installed RATs for persistence, execution of native commands and more. This rule detects when a process is started whose name or code signature resembles commonly abused RATs. This is a New Terms rule type indicating the host has not seen this RAT process started before within the last 30 days.", - "from": "now-9m", - "history_window_start": "now-15d", - "index": [ - "logs-endpoint.events.process-*", - "endgame-*", - "winlogbeat-*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "logs-system.security*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "First Time Seen Commonly Abused Remote Access Tool Execution", - "new_terms_fields": [ - "host.id" - ], - "note": "## Triage and analysis\n\n### Investigating First Time Seen Commonly Abused Remote Access Tool Execution\n\nRemote access software is a class of tools commonly used by IT departments to provide support by connecting securely to users' computers. Remote access is an ever-growing market where new companies constantly offer new ways of quickly accessing remote systems.\n\nAt the same pace as IT departments adopt these tools, the attackers also adopt them as part of their workflow to connect into an interactive session, maintain access with legitimate software as a persistence mechanism, drop malicious software, etc.\n\nThis rule detects when a remote access tool is seen in the environment for the first time in the last 15 days, enabling analysts to investigate and enforce the correct usage of such tools.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Check if the execution of the remote access tool is approved by the organization's IT department.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n - If the tool is not approved for use in the organization, the employee could have been tricked into installing it and providing access to a malicious third party. Investigate whether this third party could be attempting to scam the end-user or gain access to the environment through social engineering.\n- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.\n\n### False positive analysis\n\n- If an authorized support person or administrator used the tool to conduct legitimate support or remote access, consider reinforcing that only tooling approved by the IT policy should be used. The analyst can dismiss the alert if no other suspicious behavior is observed involving the host or users.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Run a full scan using the antimalware tool in place. This scan can reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- If an unauthorized third party did the access via social engineering, consider improvements to the security awareness program.\n- Enforce that only tooling approved by the IT policy should be used for remote access purposes and only by authorized staff.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "host.os.type: \"windows\" and\n\n event.category: \"process\" and event.type : \"start\" and\n\n (\n process.code_signature.subject_name : (\n \"Action1 Corporation\" or\n \"AeroAdmin LLC\" or\n \"Ammyy LLC\" or\n \"Atera Networks Ltd\" or\n \"AWERAY PTE. LTD.\" or\n \"BeamYourScreen GmbH\" or\n \"Bomgar Corporation\" or\n \"DUC FABULOUS CO.,LTD\" or\n \"DOMOTZ INC.\" or\n \"DWSNET O\u00dc\" or\n \"FleetDeck Inc\" or\n \"GlavSoft LLC\" or\n \"GlavSoft LLC.\" or\n \"Hefei Pingbo Network Technology Co. Ltd\" or\n \"IDrive, Inc.\" or\n \"IMPERO SOLUTIONS LIMITED\" or\n \"Instant Housecall\" or\n \"ISL Online Ltd.\" or\n \"LogMeIn, Inc.\" or\n \"Monitoring Client\" or\n \"MMSOFT Design Ltd.\" or\n \"Nanosystems S.r.l.\" or\n \"NetSupport Ltd\" or\n \"NinjaRMM, LLC\" or\n \"Parallels International GmbH\" or\n \"philandro Software GmbH\" or\n \"Pro Softnet Corporation\" or\n \"RealVNC\" or\n \"RealVNC Limited\" or\n \"BreakingSecurity.net\" or\n \"Remote Utilities LLC\" or\n \"Rocket Software, Inc.\" or\n \"SAFIB\" or\n \"Servably, Inc.\" or\n \"ShowMyPC INC\" or\n \"Splashtop Inc.\" or\n \"Superops Inc.\" or\n \"TeamViewer\" or\n \"TeamViewer GmbH\" or\n \"TeamViewer Germany GmbH\" or\n \"Techinline Limited\" or\n \"uvnc bvba\" or\n \"Yakhnovets Denis Aleksandrovich IP\" or\n \"Zhou Huabing\"\n ) or\n\n process.name.caseless : (\n AA_v*.exe or\n \"AeroAdmin.exe\" or\n \"AnyDesk.exe\" or\n \"apc_Admin.exe\" or\n \"apc_host.exe\" or\n \"AteraAgent.exe\" or\n aweray_remote*.exe or\n \"AweSun.exe\" or\n \"B4-Service.exe\" or\n \"BASupSrvc.exe\" or\n \"bomgar-scc.exe\" or\n \"domotzagent.exe\" or\n \"domotz-windows-x64-10.exe\" or\n \"dwagsvc.exe\" or\n \"DWRCC.exe\" or\n \"ImperoClientSVC.exe\" or\n \"ImperoServerSVC.exe\" or\n \"ISLLight.exe\" or\n \"ISLLightClient.exe\" or\n fleetdeck_commander*.exe or\n \"getscreen.exe\" or\n \"LMIIgnition.exe\" or\n \"LogMeIn.exe\" or\n \"ManageEngine_Remote_Access_Plus.exe\" or\n \"Mikogo-Service.exe\" or\n \"NinjaRMMAgent.exe\" or\n \"NinjaRMMAgenPatcher.exe\" or\n \"ninjarmm-cli.exe\" or\n \"r_server.exe\" or\n \"radmin.exe\" or\n \"radmin3.exe\" or\n \"RCClient.exe\" or\n \"RCService.exe\" or\n \"RemoteDesktopManager.exe\" or\n \"RemotePC.exe\" or\n \"RemotePCDesktop.exe\" or\n \"RemotePCService.exe\" or\n \"rfusclient.exe\" or\n \"ROMServer.exe\" or\n \"ROMViewer.exe\" or\n \"RPCSuite.exe\" or\n \"rserver3.exe\" or\n \"rustdesk.exe\" or\n \"rutserv.exe\" or\n \"rutview.exe\" or\n \"saazapsc.exe\" or\n ScreenConnect*.exe or\n \"smpcview.exe\" or\n \"spclink.exe\" or\n \"Splashtop-streamer.exe\" or\n \"SRService.exe\" or\n \"strwinclt.exe\" or\n \"Supremo.exe\" or\n \"SupremoService.exe\" or\n \"teamviewer.exe\" or\n \"TiClientCore.exe\" or\n \"TSClient.exe\" or\n \"tvn.exe\" or\n \"tvnserver.exe\" or\n \"tvnviewer.exe\" or\n UltraVNC*.exe or\n UltraViewer*.exe or\n \"vncserver.exe\" or\n \"vncviewer.exe\" or\n \"winvnc.exe\" or\n \"winwvc.exe\" or\n \"Zaservice.exe\" or\n \"ZohoURS.exe\"\n ) or\n process.name : (\n AA_v*.exe or\n \"AeroAdmin.exe\" or\n \"AnyDesk.exe\" or\n \"apc_Admin.exe\" or\n \"apc_host.exe\" or\n \"AteraAgent.exe\" or\n aweray_remote*.exe or\n \"AweSun.exe\" or\n \"B4-Service.exe\" or\n \"BASupSrvc.exe\" or\n \"bomgar-scc.exe\" or\n \"domotzagent.exe\" or\n \"domotz-windows-x64-10.exe\" or\n \"dwagsvc.exe\" or\n \"DWRCC.exe\" or\n \"ImperoClientSVC.exe\" or\n \"ImperoServerSVC.exe\" or\n \"ISLLight.exe\" or\n \"ISLLightClient.exe\" or\n fleetdeck_commander*.exe or\n \"getscreen.exe\" or\n \"LMIIgnition.exe\" or\n \"LogMeIn.exe\" or\n \"ManageEngine_Remote_Access_Plus.exe\" or\n \"Mikogo-Service.exe\" or\n \"NinjaRMMAgent.exe\" or\n \"NinjaRMMAgenPatcher.exe\" or\n \"ninjarmm-cli.exe\" or\n \"r_server.exe\" or\n \"radmin.exe\" or\n \"radmin3.exe\" or\n \"RCClient.exe\" or\n \"RCService.exe\" or\n \"RemoteDesktopManager.exe\" or\n \"RemotePC.exe\" or\n \"RemotePCDesktop.exe\" or\n \"RemotePCService.exe\" or\n \"rfusclient.exe\" or\n \"ROMServer.exe\" or\n \"ROMViewer.exe\" or\n \"RPCSuite.exe\" or\n \"rserver3.exe\" or\n \"rustdesk.exe\" or\n \"rutserv.exe\" or\n \"rutview.exe\" or\n \"saazapsc.exe\" or\n ScreenConnect*.exe or\n \"smpcview.exe\" or\n \"spclink.exe\" or\n \"Splashtop-streamer.exe\" or\n \"SRService.exe\" or\n \"strwinclt.exe\" or\n \"Supremo.exe\" or\n \"SupremoService.exe\" or\n \"teamviewer.exe\" or\n \"TiClientCore.exe\" or\n \"TSClient.exe\" or\n \"tvn.exe\" or\n \"tvnserver.exe\" or\n \"tvnviewer.exe\" or\n UltraVNC*.exe or\n UltraViewer*.exe or\n \"vncserver.exe\" or\n \"vncviewer.exe\" or\n \"winvnc.exe\" or\n \"winwvc.exe\" or\n \"Zaservice.exe\" or\n \"ZohoURS.exe\"\n )\n\t) and\n\n\tnot (process.pe.original_file_name : (\"G2M.exe\" or \"Updater.exe\" or \"powershell.exe\") and process.code_signature.subject_name : \"LogMeIn, Inc.\")\n", - "references": [ - "https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/", - "https://attack.mitre.org/techniques/T1219/", - "https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - }, - { - "package": "system", - "version": "^1.64.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.code_signature.subject_name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "process.name.caseless", - "type": "unknown" - }, - { - "ecs": true, - "name": "process.pe.original_file_name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "6e1a2cc4-d260-11ed-8829-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Resources: Investigation Guide", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Windows Security Event Logs", - "Data Source: Sysmon" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1219", - "name": "Remote Access Software", - "reference": "https://attack.mitre.org/techniques/T1219/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 110 - }, - "id": "6e1a2cc4-d260-11ed-8829-f661ea17fbcc_110", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_109.json b/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_109.json deleted file mode 100644 index fa8d4b82e76..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_109.json +++ /dev/null @@ -1,112 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-crowdstrike.fdr*", - "logs-endpoint.events.process*", - "logs-sentinel_one_cloud_funnel.*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Potential Linux Tunneling and/or Port Forwarding", - "note": "## Triage and analysis\n\n### Investigating Potential Linux Tunneling and/or Port Forwarding\n\nAttackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems.\n\nThis rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. \n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n#### Possible investigation steps\n\n- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior.\n - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Process Info\",\"query\":\"SELECT name, cmdline, parent, path, uid FROM processes\"}}\n- Investigate other alerts associated with the user/host during the past 48 hours.\n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n\n### Related rules\n\n- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd\n- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f\n- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769\n- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4\n- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37\n\n### False positive analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and (\n (\n // gost & pivotnacci - spawned without process.parent.name\n (process.name == \"gost\" and process.args : (\"-L*\", \"-C*\", \"-R*\")) or (process.name == \"pivotnacci\")) or (\n // ssh\n (process.name in (\"ssh\", \"sshd\") and (process.args in (\"-R\", \"-L\", \"-D\", \"-w\") and process.args_count >= 4 and \n not process.args : \"chmod\")) or\n // sshuttle\n (process.name == \"sshuttle\" and process.args in (\"-r\", \"--remote\", \"-l\", \"--listen\") and process.args_count >= 4) or\n // socat\n (process.name == \"socat\" and process.args : (\"TCP4-LISTEN:*\", \"SOCKS*\") and process.args_count >= 3) or\n // chisel\n (process.name : \"chisel*\" and process.args in (\"client\", \"server\")) or\n // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok \n (process.name in (\"iodine\", \"iodined\", \"dnscat\", \"hans\", \"hans-ubuntu\", \"ptunnel-ng\", \"ssf\", \"3proxy\", \"ngrok\"))\n ) and process.parent.name in (\"bash\", \"dash\", \"ash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")\n)\n", - "references": [ - "https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform", - "https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "crowdstrike", - "version": "^1.1.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args_count", - "type": "long" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "6ee947e9-de7e-4281-a55d-09289bdf947e", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1572", - "name": "Protocol Tunneling", - "reference": "https://attack.mitre.org/techniques/T1572/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 109 - }, - "id": "6ee947e9-de7e-4281-a55d-09289bdf947e_109", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_6.json b/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_6.json deleted file mode 100644 index 318660f0e7a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_6.json +++ /dev/null @@ -1,110 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine.", - "false_positives": [ - "Some container images require the addition of privileged capabilities. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Container Created with Excessive Linux Capabilities", - "note": "## Triage and analysis\n\n### Investigating Kubernetes Container Created with Excessive Linux Capabilities\n\nLinux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change\ncore processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques:\n\nBPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.\nDAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks.\nNET_ADMIN - Perform various network-related operations.\nSYS_ADMIN - Perform a range of system administration operations.\nSYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.\nSYS_MODULE - Load and unload kernel modules.\nSYS_PTRACE - Trace arbitrary processes using ptrace(2).\nSYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)).\nSYSLOG - Perform privileged syslog(2) operations.\n\n### False positive analysis\n\n- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image.", - "query": "event.dataset: kubernetes.audit_logs\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb: create\n and kubernetes.audit.objectRef.resource: pods\n and kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: (\"BPF\" or \"DAC_READ_SEARCH\" or \"NET_ADMIN\" or \"SYS_ADMIN\" or \"SYS_BOOT\" or \"SYS_MODULE\" or \"SYS_PTRACE\" or \"SYS_RAWIO\" or \"SYSLOG\")\n and not kubernetes.audit.requestObject.spec.containers.image : (\"docker.elastic.co/beats/elastic-agent:8.4.0\" or \"rancher/klipper-lb:v0.3.5\" or \"\")\n", - "references": [ - "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container", - "https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities", - "https://man7.org/linux/man-pages/man7/capabilities.7.html", - "https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "7164081a-3930-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 6 - }, - "id": "7164081a-3930-11ed-a261-0242ac120002_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_317.json b/packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_317.json deleted file mode 100644 index 94c40127065..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/71bccb61-e19b-452f-b104-79a60e546a95_317.json +++ /dev/null @@ -1,111 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies suspicious creation of Alternate Data Streams on highly targeted files. This is uncommon for legitimate files and sometimes done by adversaries to hide malware.", - "from": "now-9m", - "index": [ - "winlogbeat-*", - "logs-endpoint.events.file-*", - "logs-windows.sysmon_operational-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*", - "endgame-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Unusual File Creation - Alternate Data Stream", - "note": "## Triage and analysis\n\n### Investigating Unusual File Creation - Alternate Data Stream\n\nAlternate Data Streams (ADS) are file attributes only found on the NTFS file system. In this file system, files are built up from a couple of attributes; one of them is $Data, also known as the data attribute.\n\nThe regular data stream, also referred to as the unnamed data stream since the name string of this attribute is empty, contains the data inside the file. So any data stream that has a name is considered an alternate data stream.\n\nAttackers can abuse these alternate data streams to hide malicious files, string payloads, etc. This rule detects the creation of alternate data streams on highly targeted file types.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Retrieve the contents of the alternate data stream, and analyze it for potential maliciousness. Analysts can use the following PowerShell cmdlet to accomplish this:\n - `Get-Content C:\\Path\\To\\file.exe -stream SampleAlternateDataStreamName`\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- If this activity is expected and noisy in your environment, consider adding exceptions \u2014 preferably with a combination of process executable and file conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "file where host.os.type == \"windows\" and event.type == \"creation\" and\n\n file.path : \"C:\\\\*:*\" and\n not file.path : \n (\"C:\\\\*:zone.identifier*\",\n \"C:\\\\users\\\\*\\\\appdata\\\\roaming\\\\microsoft\\\\teams\\\\old_weblogs_*:$DATA\",\n \"C:\\\\Windows\\\\CSC\\\\*:CscBitmapStream\") and\n\n not process.executable : (\n \"?:\\\\Program Files (x86)\\\\Dropbox\\\\Client\\\\Dropbox.exe\",\n \"?:\\\\Program Files (x86)\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\EXCEL.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\OUTLOOK.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\POWERPNT.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\root\\\\*\\\\WINWORD.EXE\",\n \"?:\\\\Program Files (x86)\\\\Microsoft\\\\Edge\\\\Application\\\\msedge.exe\",\n \"?:\\\\Program Files\\\\ExpressConnect\\\\ExpressConnectNetworkService.exe\",\n \"?:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\EXCEL.EXE\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\OUTLOOK.EXE\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\POWERPNT.EXE\",\n \"?:\\\\Program Files\\\\Microsoft Office\\\\root\\\\*\\\\WINWORD.EXE\",\n \"?:\\\\Program Files\\\\Mozilla Firefox\\\\firefox.exe\",\n \"?:\\\\Program Files\\\\Rivet Networks\\\\SmartByte\\\\SmartByteNetworkService.exe\",\n \"?:\\\\Windows\\\\explorer.exe\",\n \"?:\\\\Windows\\\\System32\\\\DataExchangeHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\drivers\\\\Intel\\\\ICPS\\\\IntelConnectivityNetworkService.exe\",\n \"?:\\\\Windows\\\\System32\\\\drivers\\\\RivetNetworks\\\\Killer\\\\KillerNetworkService.exe\",\n \"?:\\\\Windows\\\\System32\\\\inetsrv\\\\w3wp.exe\",\n \"?:\\\\Windows\\\\System32\\\\PickerHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\RuntimeBroker.exe\",\n \"?:\\\\Windows\\\\System32\\\\SearchProtocolHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\sihost.exe\",\n \"?:\\\\windows\\\\System32\\\\svchost.exe\"\n ) and\n\n file.extension :\n (\n \"pdf\", \"dll\", \"exe\", \"dat\", \"com\", \"bat\", \"cmd\", \"sys\", \"vbs\", \"ps1\", \"hta\", \"txt\", \"vbe\", \"js\",\n \"wsh\", \"docx\", \"doc\", \"xlsx\", \"xls\", \"pptx\", \"ppt\", \"rtf\", \"gif\", \"jpg\", \"png\", \"bmp\", \"img\", \"iso\"\n )\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - }, - { - "package": "m365_defender", - "version": "^2.22.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.9.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.extension", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "71bccb61-e19b-452f-b104-79a60e546a95", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Resources: Investigation Guide", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: SentinelOne", - "Data Source: Elastic Endgame" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1564", - "name": "Hide Artifacts", - "reference": "https://attack.mitre.org/techniques/T1564/", - "subtechnique": [ - { - "id": "T1564.004", - "name": "NTFS File Attributes", - "reference": "https://attack.mitre.org/techniques/T1564/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 317 - }, - "id": "71bccb61-e19b-452f-b104-79a60e546a95_317", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json new file mode 100644 index 00000000000..5750cb08d45 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json @@ -0,0 +1,76 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts.", + "false_positives": [ + "Service accounts or applications that frequently access Azure Key Vault for configuration or operational purposes may trigger this rule.", + "Automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or application configuration, may also lead to false positives.", + "Security teams performing routine audits or assessments that involve retrieving keys or secrets from Key Vaults may trigger this rule if they perform multiple retrievals in a short time frame." + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-azure.platformlogs-*" + ], + "language": "esql", + "license": "Elastic License v2", + "name": "Azure Key Vault Secret Key Usage by Unusual Identity", + "new_terms_fields": [ + "azure.platformlogs.identity.claim.upn", + "azure.platformlogs.properties.id" + ], + "note": "## Triage and analysis\n\n### Investigating Azure Key Vault Secret Key Usage by Unusual Identity\n\nAzure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts.\n\n### Possible investigation steps\n- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious.\n- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies.\n- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources.\n- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault.\n- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.\n- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity.\n- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents.\n- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies.\n\n### False positive analysis\n- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.\n- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n\n### Response and remediation\n- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals.\n- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault.\n- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals.\n- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts.\n- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets.\n- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments.\n", + "query": "event.dataset : \"azure.platformlogs\" and\nevent.outcome: \"success\" and\nevent.action : (\n \"VaultGet\" or\n \"KeyGet\" or\n \"KeyList\" or\n \"KeyListVersions\" or\n \"KeyGetDeleted\" or\n \"KeyListDeleted\" or\n \"SecretGet\" or\n \"SecretList\" or\n \"SecretListVersions\" or\n \"SecretGetDeleted\" or\n \"SecretListDeleted\" or\n \"CertificateGet\" or\n \"CertificateList\" or\n \"CertificateListVersions\" or\n \"CertificateGetDeleted\" or\n \"CertificateListDeleted\" or\n \"CertificatePolicyGet\" or\n \"CertificateContactsGet\" or\n \"CertificateIssuerGet\" or\n \"CertificateIssuersList\"\n) and azure.platformlogs.identity.claim.upn: * and azure.platformlogs.properties.id: *\n", + "references": [ + "https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html" + ], + "risk_score": 43, + "rule_id": "75c53838-5dcd-11f0-829c-f661ea17fbcd", + "setup": "#### Required Azure Key Vault Diagnostic Logs\n\nTo ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:\n- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Storage", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Azure Platform Logs", + "Data Source: Azure Key Vault", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1555", + "name": "Credentials from Password Stores", + "reference": "https://attack.mitre.org/techniques/T1555/", + "subtechnique": [ + { + "id": "T1555.006", + "name": "Cloud Secrets Management Stores", + "reference": "https://attack.mitre.org/techniques/T1555/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "75c53838-5dcd-11f0-829c-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_205.json b/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_205.json deleted file mode 100644 index 8f5464a3cf6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_205.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.", - "false_positives": [ - "An administrator or developer may want to use a pod that runs as root and shares the host's IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod Created With HostIPC", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod Created With HostIPC\n\nKubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value \"kubernetes.audit_logs\".\n- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request.\n- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation.\n- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list.\n- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk.\n- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited.\n\n### False positive analysis\n\n- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function.\n- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening.\n- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts.\n- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process.\n- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications.\n- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification.\n- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms.\n- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred.\n- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved.\n- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostIPC:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", - "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.hostIPC", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "764c8437-a581-4537-8060-1fdb0e92c92d", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "764c8437-a581-4537-8060-1fdb0e92c92d_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json new file mode 100644 index 00000000000..b4ff712d480 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Malware-Driven SSH Brute Force Attempt", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Malware-Driven SSH Brute Force Attempt\n\nSSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths.\n- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information.\n- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations.\n- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise.\n- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware.\n- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts.\n\n### False positive analysis\n\n- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list.\n- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule.\n- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers.\n- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions.\n\n### Response and remediation\n\n- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems.\n- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise.\n- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software.\n- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security.\n- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats.\n- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly.\n- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and\n destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and not\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.port\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "77122db4-5876-4127-b91b-6c179eb21f88", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Impact", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1496", + "name": "Resource Hijacking", + "reference": "https://attack.mitre.org/techniques/T1496/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "77122db4-5876-4127-b91b-6c179eb21f88_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_107.json b/packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_107.json new file mode 100644 index 00000000000..e0399fbe155 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_107.json @@ -0,0 +1,82 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame.", + "false_positives": [ + "Key vault modifications may be done by a system or network administrator. Verify whether the username, hostname, and/or resource name should be making changes in your environment. Key vault modifications from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-azure.activitylogs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Azure Key Vault Modified", + "new_terms_fields": [ + "azure.activitylogs.identity.claims_initiated_by_user.name" + ], + "note": "## Triage and analysis\n\n### Investigating Azure Key Vault Modified\n\nAzure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects modifications to Key Vaults, which may indicate potential security incidents or misconfigurations.\n\n### Possible investigation steps\n- Review the `azure.activitylogs.operation_name` field to identify the specific operation performed on the Key Vault. Common operations include `Microsoft.KeyVault/vaults/write` for modifications and `Microsoft.KeyVault/vaults/delete` for deletions.\n- Check the `event.outcome` field to confirm the success of the operation. A successful outcome indicates that the modification or deletion was completed.\n- Investigate the `azure.activitylogs.identity.principal_id` or `azure.activitylogs.identity.principal_name` fields to determine the user or service principal that performed the operation. This can help identify whether the action was authorized or potentially malicious.\n- Analyze the `azure.activitylogs.resource_id` field to identify the specific Key Vault that was modified. This can help assess the impact of the change and whether it affects critical resources or applications.\n- Cross-reference the time of the modification with other security events or alerts in the environment to identify any patterns or related activities that may indicate a coordinated attack or misconfiguration.\n- Consult with relevant stakeholders or system owners to verify if the modification was planned or expected, and gather additional context if necessary.\n\n### False positive analysis\n- Routine maintenance activities by administrators can trigger alerts when they modify or delete Key Vaults. To manage this, create exceptions for known maintenance windows or specific administrator accounts.\n- Automated scripts or tools used for Key Vault management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.\n- Changes made by authorized third-party services or integrations that manage Key Vault configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.\n- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.\n- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.\n\n### Response and remediation\n- Immediately isolate the affected Key Vault to prevent further unauthorized access or changes.\n- Review the Azure activity logs to identify the specific operations performed on the Key Vault and their outcomes.\n- Collaborate with security teams to assess the impact of the modifications and determine if any sensitive data was compromised.\n- If unauthorized changes are confirmed, initiate incident response procedures, including notifying affected parties and conducting a thorough investigation.\n- Implement additional monitoring and alerting for the affected Key Vault to detect any further suspicious activity.\n", + "query": "event.dataset: \"azure.activitylogs\"\n and azure.activitylogs.operation_name: MICROSOFT.KEYVAULT/VAULTS/*\n and event.outcome:(Success or success)\n", + "references": [ + "https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts", + "https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault", + "https://learn.microsoft.com/en-us/azure/key-vault/general/security-features" + ], + "related_integrations": [ + { + "integration": "activitylogs", + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.activitylogs.operation_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Azure Activity Logs", + "Tactic: Impact", + "Use Case: Configuration Audit", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 107 + }, + "id": "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_107", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json new file mode 100644 index 00000000000..a9d44d65336 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Subnet Scanning Activity from Compromised Host", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Subnet Scanning Activity from Compromised Host\n\nSubnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections.\n- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external.\n- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access.\n- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host.\n- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes.\n\n### False positive analysis\n\n- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list.\n- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID.\n- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved.\n- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID.\n- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID.\n\n### Response and remediation\n\n- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker.\n- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities.\n- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed.\n- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists.\n- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps.\n- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise.\n- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), dest_count = count_distinct(destination.ip), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable\n| where agent_count == 1 and dest_count > 250\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1046", + "name": "Network Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1046/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a1db198-da6f-4500-b985-7fe2457300af_1.json b/packages/security_detection_engine/kibana/security_rule/8a1db198-da6f-4500-b985-7fe2457300af_1.json new file mode 100644 index 00000000000..3d452fdb54b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8a1db198-da6f-4500-b985-7fe2457300af_1.json @@ -0,0 +1,77 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual request responses in Kubernetes audit logs through the use of the \"new_terms\" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment.", + "history_window_start": "now-10d", + "index": [ + "logs-kubernetes.audit_logs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Kubernetes Unusual Decision by User Agent", + "new_terms_fields": [ + "kubernetes.audit.annotations.authorization_k8s_io/decision", + "kubernetes.audit.user.username", + "user_agent.original" + ], + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Unusual Decision by User Agent\n\nKubernetes orchestrates containerized applications, relying on API requests for operations. Typically, these requests originate from system components or trusted users with consistent user agents. Adversaries might exploit this by using atypical user agents to mask unauthorized access or misconfigurations. The detection rule identifies anomalies in user agents and response annotations, signaling potential threats in the Kubernetes environment.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs for entries where the user_agent.original field is present to identify any unusual or unexpected user agents.\n- Cross-reference the identified user agents with known system components and trusted users to determine if the user agent is legitimate or potentially malicious.\n- Examine the kubernetes.audit.stage field for \"ResponseComplete\" entries to understand the context and outcome of the requests associated with the unusual user agent.\n- Investigate the source IP addresses and associated usernames in the audit logs to identify any patterns or anomalies that could indicate unauthorized access.\n- Check for any recent changes or deployments in the Kubernetes environment that might explain the presence of unusual user agents or unexpected behavior.\n- Assess the risk and impact of the detected anomaly by considering the sensitivity of the accessed resources and the permissions associated with the user account involved.\n\n### False positive analysis\n\n- System components or trusted users with legitimate but infrequent user agents may trigger the rule. To manage this, identify these user agents and add them to an exception list to prevent unnecessary alerts.\n- Automated scripts or tools used for maintenance or monitoring might use unique user agents. Regularly review these tools and update the exception list to include their user agents if they are verified as non-threatening.\n- New deployments or updates to Kubernetes components can introduce new user agents temporarily. Monitor these changes and adjust the rule exceptions accordingly to accommodate expected behavior during these periods.\n- Third-party integrations or plugins may use distinct user agents. Validate these integrations and, if deemed safe, include their user agents in the exception list to reduce false positives.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary.\n- Review and terminate any suspicious or unauthorized sessions identified in the audit logs to cut off any active malicious activity.\n- Revoke and rotate credentials associated with the compromised user agent to prevent further unauthorized access using the same credentials.\n- Conduct a thorough review of the affected system's configurations and permissions to identify and rectify any misconfigurations or overly permissive access controls.\n- Implement additional monitoring and logging for the affected systems to detect any further anomalies or unauthorized activities promptly.\n- Escalate the incident to the security operations team for a comprehensive investigation and to determine if any data exfiltration or further compromise has occurred.\n- Update and enhance detection rules and alerts to better identify similar anomalies in user agents and response annotations in the future, ensuring quicker response times.\n", + "query": "host.os.type:\"linux\" and event.dataset:\"kubernetes.audit_logs\" and kubernetes.audit.stage:\"ResponseComplete\" and user_agent.original:*\n", + "related_integrations": [ + { + "package": "kubernetes", + "version": "^1.80.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "kubernetes.audit.stage", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "8a1db198-da6f-4500-b985-7fe2457300af", + "severity": "low", + "tags": [ + "Domain: Kubernetes", + "Domain: Container", + "Use Case: Threat Detection", + "Data Source: Kubernetes", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "8a1db198-da6f-4500-b985-7fe2457300af_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json new file mode 100644 index 00000000000..0532f39183b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Command Execution from Web Server Parent", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Command Execution from Web Server Parent\n\nWeb servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent.\n- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise.\n- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited.\n- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user.\n- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack.\n- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue.\n\n### False positive analysis\n\n- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule.\n- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs.\n- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables.\n- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule.\n- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation.\n\n- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes.\n\n- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies.\n\n- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches.\n\n- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration.\n\n- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections.\n\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps.\n", + "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.command_line, process.parent.executable, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n) and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.command_line like \"* -c *\" and\n not (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.working_directory like \"/vscode/vscode-server/*\" or\n process.parent.executable like \"/vscode/vscode-server/*\" or\n process.parent.executable == \"/usr/bin/xfce4-terminal\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.command_line, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json new file mode 100644 index 00000000000..e6f00c2e63c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual File Transfer Utility Launched", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual File Transfer Utility Launched\n\nFile transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious.\n- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity.\n- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context.\n- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution.\n- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule.\n\n### False positive analysis\n\n- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs.\n- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives.\n- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts.\n- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration.\n- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access.\n- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers.\n- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer.\n- Change credentials and access keys associated with the compromised system to prevent further unauthorized access.\n- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems.\n- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system.\n- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.\n", + "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\n process.name in (\"scp\", \"ftp\", \"sftp\", \"vsftpd\", \"sftp-server\", \"rsync\")\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.parent.executable, process.command_line\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "8eeeda11-dca6-4c3e-910f-7089db412d1c", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "8eeeda11-dca6-4c3e-910f-7089db412d1c_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_4.json b/packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_4.json new file mode 100644 index 00000000000..daed0ffff42 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_4.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window.", + "false_positives": [ + "Legitimate use of Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt objects in an S3 bucket." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "tls.client.server_name", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Excessive AWS S3 Object Encryption with SSE-C", + "note": "### Triage and Analysis\n\n#### Investigating Excessive AWS S3 Object Encryption with SSE-C\nThis rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys.\n\n##### Possible Investigation Steps\n\n1. **Identify the User and Source**:\n - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation.\n - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access.\n - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key.\n\n2. **Examine the Targeted Resources**:\n - Check `aws.cloudtrail.request_parameters` to identify the bucket involved.\n - Analyze the object key from `aws.cloudtrail.request_parameters`.\n\n3. **Evaluate Encryption Behavior**:\n - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`.\n - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key.\n\n4. **Correlate with Recent Events**:\n - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP.\n - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects.\n - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note.\n\n5. **Validate Access Permissions**:\n - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects.\n\n6. **Assess Impact**:\n - Identify the number of encrypted objects in the bucket by examining other similar events.\n - Determine if this encryption aligns with standard business practices or constitutes a deviation.\n\n### False Positive Analysis\n\n- **Legitimate Use Cases**:\n - Confirm if SSE-C encryption is part of regular operations for compliance or data protection.\n - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Disable access keys or permissions for the user if unauthorized behavior is confirmed.\n - Rotate the bucket's encryption configuration to mitigate further misuse.\n\n2. **Data Recovery**:\n - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future SSE-C encryption attempts in critical buckets.\n - Review and tighten IAM policies for roles and users accessing S3.\n\n4. **Post-Incident Review**:\n - Audit logs for additional activities by the same user or IP.\n - Document findings and apply lessons learned to improve preventive measures.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"s3.amazonaws.com\"\n and event.action: \"PutObject\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: \"AES256\"\n", + "references": [ + "https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c", + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "909bf7c8-d371-11ef-bcc3-f661ea17fbcd", + "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Impact" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "threshold": { + "field": [ + "tls.client.server_name" + ], + "value": 20 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 4 + }, + "id": "909bf7c8-d371-11ef-bcc3-f661ea17fbcd_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_210.json b/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_210.json deleted file mode 100644 index 0b3ebea4f1d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_210.json +++ /dev/null @@ -1,144 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic", - "Austin Songer" - ], - "description": "Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment.", - "false_positives": [ - "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes.", - "AWS services might assume roles to access AWS resources as part of their standard operations.", - "Automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "@timestamp", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.resources.arn", - "aws.cloudtrail.resources.type", - "source.address", - "aws.cloudtrail.user_identity.invoked_by", - "aws.cloudtrail.flattened.request_parameters.roleArn", - "aws.cloudtrail.flattened.request_parameters.roleSessionName", - "event.action", - "event.outcome", - "cloud.region", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS STS Role Assumption by Service", - "new_terms_fields": [ - "aws.cloudtrail.resources.arn", - "aws.cloudtrail.user_identity.invoked_by" - ], - "note": "## Triage and analysis\n\n### Investigating AWS STS Role Assumption by Service\n\nThis rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.\n\n#### Possible Investigation Steps\n\n- **Identify the Actor and Assumed Role**:\n - **User Identity**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` fields to determine who initiated the `AssumeRole` action.\n - **Role Assumed**: Check the `aws.cloudtrail.flattened.request_parameters.roleArn` field to confirm the assumed role and ensure it aligns with expected responsibilities.\n - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available.\n\n- **Analyze the Role Session and Duration**:\n - **Session Context**: Look at the `aws.cloudtrail.user_identity.session_context.creation_date` to understand when the session began and check if multi-factor authentication (MFA) was used, indicated by the `aws.cloudtrail.user_identity.session_context.mfa_authenticated` field.\n - **Credential Validity**: Examine the `aws.cloudtrail.flattened.request_parameters.durationSeconds` for the credential's validity period.\n - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired.\n\n- **Inspect the User Agent for Tooling Identification**:\n - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include:\n - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts.\n - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction.\n - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools.\n - **Source IP and Location**: Evaluate the `source.address` and `source.geo` fields to confirm if the access source aligns with typical access locations for your environment.\n\n- **Contextualize with Related Events**:\n - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources.\n - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise.\n\n- **Evaluate the Privilege Level of the Assumed Role**:\n - **Permissions**: Inspect permissions associated with the assumed role to understand its access level.\n - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities.\n\n### False Positive Analysis\n\n- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows.\n- **Routine IAM Policy Actions**: Historical data may reveal if the same user or application assumes this specific role regularly as part of authorized operations.\n\n### Response and Remediation\n\n- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role.\n- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges.\n- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue.\n- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation.\n\n### Additional Information\n\nFor more information on managing and securing AWS STS, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) and AWS security best practices.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"sts.amazonaws.com\"\n and event.action: \"AssumeRole\"\n and event.outcome: \"success\"\n and aws.cloudtrail.user_identity.type: \"AWSService\"\n and aws.cloudtrail.user_identity.invoked_by: (\n \"ec2.amazonaws.com\" or\n \"lambda.amazonaws.com\" or\n \"rds.amazonaws.com\" or\n \"ssm.amazonaws.com\" or\n \"ecs-tasks.amazonaws.com\" or\n \"ecs.amazonaws.com\" or\n \"eks.amazonaws.com\" or\n \"eks-fargate.amazonaws.com\" or\n \"codepipeline.amazonaws.com\" or\n \"codebuild.amazonaws.com\" or\n \"autoscaling.amazonaws.com\")\n", - "references": [ - "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.invoked_by", - "type": "keyword" - }, - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "93075852-b0f5-4b8b-89c3-a226efae5726", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS STS", - "Resources: Investigation Guide", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0008", - "name": "Lateral Movement", - "reference": "https://attack.mitre.org/tactics/TA0008/" - }, - "technique": [ - { - "id": "T1550", - "name": "Use Alternate Authentication Material", - "reference": "https://attack.mitre.org/techniques/T1550/", - "subtechnique": [ - { - "id": "T1550.001", - "name": "Application Access Token", - "reference": "https://attack.mitre.org/techniques/T1550/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 210 - }, - "id": "93075852-b0f5-4b8b-89c3-a226efae5726_210", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_209.json b/packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_209.json new file mode 100644 index 00000000000..0a207f23ce0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_209.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "A sudoers file specifies the commands that users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "logs-endpoint.events.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Sudoers File Modification", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Sudoers File Modification\n\nThe sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific file path that triggered the alert, focusing on /etc/sudoers* or /private/etc/sudoers*.\n- Examine the process information associated with the change event, particularly the process.name and process.executable fields, to determine if the modification was made by a suspicious or unauthorized process.\n- Check the user account associated with the process that made the change to the sudoers file to assess if the account has a legitimate reason to modify the file.\n- Investigate recent login activity and user behavior for the account involved in the modification to identify any anomalies or signs of compromise.\n- Review system logs around the time of the alert to gather additional context on what other activities occurred on the system, which might indicate a broader attack or compromise.\n- Assess the current state of the sudoers file to identify any unauthorized or suspicious entries that could indicate privilege escalation attempts.\n\n### False positive analysis\n\n- System updates and package installations can trigger changes to the sudoers file. Exclude processes like dpkg, yum, dnf, and platform-python from triggering alerts as they are commonly involved in legitimate updates.\n- Configuration management tools such as Puppet and Chef may modify the sudoers file as part of their normal operations. Exclude process executables like /opt/chef/embedded/bin/ruby and /opt/puppetlabs/puppet/bin/ruby to prevent false positives.\n- Docker daemon processes might interact with the sudoers file during container operations. Exclude /usr/bin/dockerd to avoid unnecessary alerts related to Docker activities.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and operational tools, minimizing false positives while maintaining security vigilance.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.\n- Review the recent changes to the sudoers file to identify unauthorized modifications and revert them to the last known good configuration.\n- Conduct a thorough examination of system logs to identify any unauthorized access or actions performed using elevated privileges, focusing on the time frame of the detected change.\n- Reset passwords and review access permissions for all users with sudo privileges to ensure no unauthorized accounts have been added or existing accounts have been compromised.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected.\n- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify the sudoers file or other privilege escalation activities.\n- Review and update security policies and configurations to prevent similar incidents, ensuring that only authorized processes can modify the sudoers file.", + "query": "file where host.os.type in (\"linux\", \"macos\") and event.type in (\"creation\", \"change\") and\nfile.path like (\"/etc/sudoers*\", \"/private/etc/sudoers*\") and not (\n process.name in (\"dpkg\", \"platform-python\", \"puppet\", \"yum\", \"dnf\") or\n process.executable in (\"/opt/chef/embedded/bin/ruby\", \"/opt/puppetlabs/puppet/bin/ruby\", \"/usr/bin/dockerd\")\n)\n", + "references": [ + "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "OS: macOS", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/", + "subtechnique": [ + { + "id": "T1548.003", + "name": "Sudo and Sudo Caching", + "reference": "https://attack.mitre.org/techniques/T1548/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 209 + }, + "id": "931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json new file mode 100644 index 00000000000..9f5d3e05dc9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Okta User Authentication Events with Client Address", + "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Client Address\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\nSince this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action == \"user.session.start\" OR event.action RLIKE \"user\\\\.authentication(.*)\")\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP okta.client.ip, okta.actor.alternate_id, okta.actor.id, event.action, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count > 5\n| SORT\n source_auth_count DESC\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 21, + "rule_id": "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 205 + }, + "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_205", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json new file mode 100644 index 00000000000..b3adc5db0c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Okta User Authentication Events with Same Device Token Hash", + "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Same Device Token Hash\n\nThis rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n", + "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.dt_hash != \"-\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.actor.id, okta.actor.alternate_id, okta.outcome.reason\n| STATS\n target_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id\n| WHERE\n target_auth_count > 20\n| SORT\n target_auth_count DESC\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 21, + "rule_id": "95b99adc-2cda-11ef-84e1-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 205 + }, + "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_205", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json new file mode 100644 index 00000000000..57a6dd8a1ac --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Process Spawned from Web Server Parent", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Process Spawned from Web Server Parent\n\nWeb servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment.\n- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories.\n- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account.\n- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced.\n- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise.\n- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited.\n\n### False positive analysis\n\n- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening.\n- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts.\n- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories.\n- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows.\n- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.\n- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations.\n- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary.\n- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup.\n- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access.\n- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.\n", + "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.executable, process.command_line, process.parent.executable, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n) and\nnot (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.parent.executable like \"/vscode/vscode-server/*\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "976b2391-413f-4a94-acb4-7911f3803346", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "976b2391-413f-4a94-acb4-7911f3803346_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_210.json b/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_210.json deleted file mode 100644 index a06d4cc84e9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_210.json +++ /dev/null @@ -1,84 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An attempt was made to modify AWS EC2 snapshot attributes. Snapshots are sometimes shared by threat actors in order to exfiltrate bulk data from an EC2 fleet. If the permissions were modified, verify the snapshot was not shared with an unauthorized or unexpected AWS account.", - "false_positives": [ - "IAM users may occasionally share EC2 snapshots with another AWS account belonging to the same organization. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Snapshot Activity", - "note": "## Triage and analysis\n\n### Investigating AWS EC2 Snapshot Activity\n\nAmazon EC2 snapshots are a mechanism to create point-in-time references to data that reside in storage volumes. System administrators commonly use this for backup operations and data recovery.\n\nThis rule looks for the modification of snapshot attributes using the API `ModifySnapshotAttribute` action. This can be used to share snapshots with unauthorized third parties, giving others access to all the data on the snapshot.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Search for dry run attempts against the resource ID of the snapshot from other user accounts within CloudTrail.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- Check if this operation was approved and performed according to the organization's change management policy.\n- Check if the shared permissions of the snapshot were modified to `Public` or include unknown account IDs.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- If this rule is noisy in your environment due to expected activity, consider adding exceptions \u2014 preferably with a combination of user and IP address conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:ModifySnapshotAttribute\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-snapshot-attribute.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.40.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "98fd7407-0bd5-5817-cda0-3fcc33113a56", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Asset Visibility", - "Tactic: Exfiltration", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 210 - }, - "id": "98fd7407-0bd5-5817-cda0-3fcc33113a56_210", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_211.json b/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_211.json deleted file mode 100644 index f2181376c4c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_211.json +++ /dev/null @@ -1,84 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An attempt was made to modify AWS EC2 snapshot attributes. Snapshots are sometimes shared by threat actors in order to exfiltrate bulk data from an EC2 fleet. If the permissions were modified, verify the snapshot was not shared with an unauthorized or unexpected AWS account.", - "false_positives": [ - "IAM users may occasionally share EC2 snapshots with another AWS account belonging to the same organization. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Snapshot Activity", - "note": "## Triage and analysis\n\n### Investigating AWS EC2 Snapshot Activity\n\nAmazon EC2 snapshots are a mechanism to create point-in-time references to data that reside in storage volumes. System administrators commonly use this for backup operations and data recovery.\n\nThis rule looks for the modification of snapshot attributes using the API `ModifySnapshotAttribute` action. This can be used to share snapshots with unauthorized third parties, giving others access to all the data on the snapshot.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Search for dry run attempts against the resource ID of the snapshot from other user accounts within CloudTrail.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- Check if this operation was approved and performed according to the organization's change management policy.\n- Check if the shared permissions of the snapshot were modified to `Public` or include unknown account IDs.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- If this rule is noisy in your environment due to expected activity, consider adding exceptions \u2014 preferably with a combination of user and IP address conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:ModifySnapshotAttribute\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-snapshot-attribute.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "98fd7407-0bd5-5817-cda0-3fcc33113a56", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Asset Visibility", - "Tactic: Exfiltration", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 211 - }, - "id": "98fd7407-0bd5-5817-cda0-3fcc33113a56_211", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_212.json b/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_212.json deleted file mode 100644 index b32576bb9ec..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/98fd7407-0bd5-5817-cda0-3fcc33113a56_212.json +++ /dev/null @@ -1,84 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An attempt was made to modify AWS EC2 snapshot attributes. Snapshots are sometimes shared by threat actors in order to exfiltrate bulk data from an EC2 fleet. If the permissions were modified, verify the snapshot was not shared with an unauthorized or unexpected AWS account.", - "false_positives": [ - "IAM users may occasionally share EC2 snapshots with another AWS account belonging to the same organization. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "Deprecated - AWS EC2 Snapshot Activity", - "note": "## Triage and analysis\n\n### Investigating Deprecated - AWS EC2 Snapshot Activity\n\nAmazon EC2 snapshots are a mechanism to create point-in-time references to data that reside in storage volumes. System administrators commonly use this for backup operations and data recovery.\n\nThis rule looks for the modification of snapshot attributes using the API `ModifySnapshotAttribute` action. This can be used to share snapshots with unauthorized third parties, giving others access to all the data on the snapshot.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Search for dry run attempts against the resource ID of the snapshot from other user accounts within CloudTrail.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- Check if this operation was approved and performed according to the organization's change management policy.\n- Check if the shared permissions of the snapshot were modified to `Public` or include unknown account IDs.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- If this rule is noisy in your environment due to expected activity, consider adding exceptions \u2014 preferably with a combination of user and IP address conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:ModifySnapshotAttribute\n", - "references": [ - "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-snapshot-attribute.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "98fd7407-0bd5-5817-cda0-3fcc33113a56", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Asset Visibility", - "Tactic: Exfiltration", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 212 - }, - "id": "98fd7407-0bd5-5817-cda0-3fcc33113a56_212", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_6.json b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_6.json new file mode 100644 index 00000000000..0e7c3cd2f22 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_6.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target user." + ], + "from": "now-6m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "source.address", + "aws.cloudtrail.user_identity.arn", + "user_agent.original", + "target.userName", + "event.action", + "policyName", + "event.outcome", + "cloud.region", + "event.provider", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM AdministratorAccess Policy Attached to User", + "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to User\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachUserPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user for privilege escalation or another user as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachUserPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachUserPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?userName}=%{target.userName}}\"\n| where policyName == \"AdministratorAccess\"\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n policyName,\n target.userName,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.user_identity.arn,\n related.user,\n user_agent.original,\n user.name,\n source.address\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" + ], + "risk_score": 47, + "rule_id": "9aa4be8d-5828-417d-9f54-7cd304571b24", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "9aa4be8d-5828-417d-9f54-7cd304571b24_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_112.json b/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_112.json deleted file mode 100644 index cabdca35c8d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_112.json +++ /dev/null @@ -1,97 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Indicates the update of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, by changing the configuration of a legit scheduled task. Some changes such as disabling or enabling a scheduled task are common and may may generate noise.", - "false_positives": [ - "Legitimate scheduled tasks may be created during installation of new software." - ], - "from": "now-9m", - "index": [ - "logs-system.security*", - "logs-windows.forwarded*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "A scheduled task was updated", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating A scheduled task was updated\n\nScheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this by modifying tasks to maintain persistence, often altering legitimate tasks to evade detection. The detection rule identifies suspicious updates by filtering out benign changes, such as those by system accounts or known safe tasks, focusing on anomalies that suggest malicious intent.\n\n### Possible investigation steps\n\n- Review the event logs to identify the specific scheduled task that was updated, focusing on the winlog.event_data.TaskName field to determine if it matches any known malicious patterns.\n- Investigate the user account associated with the update by examining the user.name field to ensure it is not a compromised account or an unauthorized user.\n- Check the winlog.event_data.SubjectUserSid field to verify if the update was made by a system account or a potentially malicious user, as system accounts like S-1-5-18, S-1-5-19, and S-1-5-20 are typically benign.\n- Analyze the history of changes to the scheduled task to identify any unusual or unauthorized modifications that could indicate persistence mechanisms.\n- Correlate the scheduled task update with other security events or alerts to determine if it is part of a broader attack pattern or campaign.\n\n### False positive analysis\n\n- Scheduled tasks updated by system accounts can be false positives. Exclude updates made by system accounts by filtering out user names ending with a dollar sign.\n- Legitimate Microsoft tasks often update automatically. Exclude tasks with names containing \"Microsoft\" to reduce noise from these updates.\n- Commonly updated tasks like User Feed Synchronization and OneDrive Reporting are typically benign. Exclude these specific task names to avoid unnecessary alerts.\n- Tasks updated by well-known service SIDs such as S-1-5-18, S-1-5-19, and S-1-5-20 are generally safe. Exclude these SIDs to prevent false positives from routine system operations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Review the specific scheduled task that was updated to determine if it was altered by an unauthorized user or process. Revert any unauthorized changes to their original state.\n- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced.\n- Analyze the user account that made the changes to the scheduled task. If the account is compromised, reset the password and review recent activities for further signs of compromise.\n- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized scheduled task updates or related suspicious activities.\n- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.\n- Review and update access controls and permissions related to scheduled tasks to ensure only authorized personnel can make changes, reducing the risk of future unauthorized modifications.", - "query": "iam where event.action == \"scheduled-task-updated\" and\n\n /* excluding tasks created by the computer account */\n not user.name : \"*$\" and\n not winlog.event_data.TaskName : \"*Microsoft*\" and\n not winlog.event_data.TaskName :\n (\"\\\\User_Feed_Synchronization-*\",\n \"\\\\OneDrive Reporting Task-S-1-5-21*\",\n \"\\\\OneDrive Reporting Task-S-1-12-1-*\",\n \"\\\\Hewlett-Packard\\\\HP Web Products Detection\",\n \"\\\\Hewlett-Packard\\\\HPDeviceCheck\",\n \"\\\\Microsoft\\\\Windows\\\\UpdateOrchestrator\\\\UpdateAssistant\",\n \"\\\\IpamDnsProvisioning\",\n \"\\\\Microsoft\\\\Windows\\\\UpdateOrchestrator\\\\UpdateAssistantAllUsersRun\",\n \"\\\\Microsoft\\\\Windows\\\\UpdateOrchestrator\\\\UpdateAssistantCalendarRun\",\n \"\\\\Microsoft\\\\Windows\\\\UpdateOrchestrator\\\\UpdateAssistantWakeupRun\",\n \"\\\\Microsoft\\\\Windows\\\\.NET Framework\\\\.NET Framework NGEN v*\",\n \"\\\\Microsoft\\\\VisualStudio\\\\Updates\\\\BackgroundDownload\") and\n not winlog.event_data.SubjectUserSid : (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\")\n", - "references": [ - "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698" - ], - "related_integrations": [ - { - "package": "system", - "version": "^1.64.0" - }, - { - "package": "windows", - "version": "^2.5.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "user.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.SubjectUserSid", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.TaskName", - "type": "unknown" - } - ], - "risk_score": 47, - "rule_id": "a02cb68e-7c93-48d1-93b2-2c39023308eb", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Data Source: Windows Security Event Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1053", - "name": "Scheduled Task/Job", - "reference": "https://attack.mitre.org/techniques/T1053/", - "subtechnique": [ - { - "id": "T1053.005", - "name": "Scheduled Task", - "reference": "https://attack.mitre.org/techniques/T1053/005/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 112 - }, - "id": "a02cb68e-7c93-48d1-93b2-2c39023308eb_112", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_109.json b/packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_109.json deleted file mode 100644 index e4941440984..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_109.json +++ /dev/null @@ -1,126 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the creation or modification of a medium-size registry hive file on a Server Message Block (SMB) share, which may indicate an exfiltration attempt of a previously dumped Security Account Manager (SAM) registry hive for credential extraction on an attacker-controlled system.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.file-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Windows Registry File Creation in SMB Share", - "note": "## Triage and analysis\n\n### Investigating Windows Registry File Creation in SMB Share\n\nDumping registry hives is a common way to access credential information. Some hives store credential material, as is the case for the SAM hive, which stores locally cached credentials (SAM secrets), and the SECURITY hive, which stores domain cached credentials (LSA secrets). Dumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets.\n\nAttackers can try to evade detection on the host by transferring this data to a system that is not monitored to be parsed and decrypted. This rule identifies the creation or modification of a medium-size registry hive file on an SMB share, which may indicate this kind of exfiltration attempt.\n\n#### Possible investigation steps\n\n- Investigate other alerts associated with the user/source host during the past 48 hours.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Inspect the source host for suspicious or abnormal behaviors in the alert timeframe.\n- Capture the registry file(s) to determine the extent of the credential compromise in an eventual incident response.\n\n### False positive analysis\n\n- Administrators can export registry hives for backup purposes. Check whether the user should be performing this kind of activity and is aware of it.\n\n### Related rules\n\n- Credential Acquisition via Registry Hive Dumping - a7e7bfa3-088e-4f13-b29e-3986e0e756b8\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "file where host.os.type == \"windows\" and event.type == \"creation\" and\n /* regf file header */\n file.Ext.header_bytes : \"72656766*\" and file.size >= 30000 and\n process.pid == 4 and user.id : (\"S-1-5-21*\", \"S-1-12-1-*\") and\n not file.path : (\n \"?:\\\\*\\\\UPM_Profile\\\\NTUSER.DAT\",\n \"?:\\\\*\\\\UPM_Profile\\\\NTUSER.DAT.LASTGOOD.LOAD\",\n \"?:\\\\*\\\\UPM_Profile\\\\AppData\\\\Local\\\\Microsoft\\\\Windows\\\\UsrClass.dat*\",\n \"?:\\\\Windows\\\\Netwrix\\\\Temp\\\\????????.???.offreg\",\n \"?:\\\\*\\\\AppData\\\\Local\\\\Packages\\\\Microsoft.*\\\\Settings\\\\settings.dat*\"\n )\n", - "references": [ - "https://www.elastic.co/security-labs/detect-credential-access" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "file.Ext.header_bytes", - "type": "unknown" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.size", - "type": "long" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.pid", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "a4c7473a-5cb4-4bc1-9d06-e4a75adbc494", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Lateral Movement", - "Tactic: Credential Access", - "Resources: Investigation Guide", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1003", - "name": "OS Credential Dumping", - "reference": "https://attack.mitre.org/techniques/T1003/", - "subtechnique": [ - { - "id": "T1003.002", - "name": "Security Account Manager", - "reference": "https://attack.mitre.org/techniques/T1003/002/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0008", - "name": "Lateral Movement", - "reference": "https://attack.mitre.org/tactics/TA0008/" - }, - "technique": [ - { - "id": "T1021", - "name": "Remote Services", - "reference": "https://attack.mitre.org/techniques/T1021/", - "subtechnique": [ - { - "id": "T1021.002", - "name": "SMB/Windows Admin Shares", - "reference": "https://attack.mitre.org/techniques/T1021/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 109 - }, - "id": "a4c7473a-5cb4-4bc1-9d06-e4a75adbc494_109", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_214.json b/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_214.json new file mode 100644 index 00000000000..38bf749b940 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_214.json @@ -0,0 +1,123 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies AWS CloudTrail events where an IAM role's trust policy has been updated by an IAM user or Assumed Role identity. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker may attempt to modify this policy to gain the privileges of the role. This is a New Terms rule, which means it will only trigger once for each unique combination of the \"cloud.account.id\", \"user.name\" and \"target.entity.id\" fields, that have not been seen making this API request.", + "false_positives": [ + "Verify whether the user identity should be making changes in your environment. Policy updates from unfamiliar users should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM Assume Role Policy Update", + "new_terms_fields": [ + "cloud.account.id", + "user.name", + "target.entity.id" + ], + "note": "## Triage and analysis\n\n### Investigating AWS IAM Assume Role Policy Update\n\nAn IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.\n\nThe role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role.\n\n#### Possible investigation steps\n\n- Review the `aws.cloudtrail.user_identity.arn` to determine the IAM User that performed the action. \n- If an AssumedRole identity type performed the action review the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field to determine which role was used.\n- Review the `target.entity.id` field to confirm the role that was updated.\n- Within the `aws.cloudtrail.request_parameters` field, review the `policyDocument` to understand the changes made to the trust policy.\n- If `aws.cloudtrail.user_identity.access_key_id` is present, investigate the access key used to perform the action as it may be compromised.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Contact the account and resource owners and confirm whether they are aware of this activity.\n- Check if this operation was approved and performed according to the organization's change management policy.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions \u2014 preferably with a combination of the user agent and user ID conditions \u2014 to cover administrator activities and infrastructure as code tooling.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Use AWS [policy versioning](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html) to restore the trust policy to the desired state.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"UpdateAssumeRolePolicy\"\n and event.outcome: \"success\"\n and not source.address: \"cloudformation.amazonaws.com\"\n", + "references": [ + "https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "a60326d7-dca7-4fb7-93eb-1ca03a1febbd", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Tactic: Privilege Escalation" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 214 + }, + "id": "a60326d7-dca7-4fb7-93eb-1ca03a1febbd_214", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_5.json b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_5.json new file mode 100644 index 00000000000..ed0adae22c9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_5.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data.", + "false_positives": [ + "Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before taking action." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS S3 Object Encryption Using External KMS Key", + "note": "## Triage and analysis\n\n### Investigating AWS S3 Object Encryption Using External KMS Key\n\nThis rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data.\nThis rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule) to look for use of the `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the object was copied. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions.\n- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n\n### Response and Remediation:\n\n- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n// any successful copy event\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"CopyObject\"\n and event.outcome == \"success\"\n\n// abstract key account id, key id, encrypted object bucket name and object name\n| dissect aws.cloudtrail.request_parameters \"{%{?bucketName}=%{target.bucketName},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{key.account.id}:%{?key}/%{keyId},%{?Host}=%{?tls.client.server_name},%{?x-amz-server-side-encryption}=%{?server-side-encryption},%{?x-amz-copy-source}=%{?bucket.objectName},%{?key}=%{target.objectName}}\"\n\n// filter for s3 objects whose account id is different from the encryption key's account id\n// add exceptions based on key.account.id or keyId for known external accounts or encryption keys\n| where cloud.account.id != key.account.id\n\n// keep relevant fields\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, target.bucketName, key.account.id, keyId, target.objectName\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/", + "https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/", + "https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/", + "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" + ], + "risk_score": 47, + "rule_id": "ab8f074c-5565-4bc4-991c-d49770e19fc9", + "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Data Source: AWS KMS", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "ab8f074c-5565-4bc4-991c-d49770e19fc9_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_316.json b/packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_316.json deleted file mode 100644 index 00c53753d2f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b41a13c6-ba45-4bab-a534-df53d0cfed6a_316.json +++ /dev/null @@ -1,118 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "A suspicious Endpoint Security parent process was detected. This may indicate a process hollowing or other form of code injection.", - "from": "now-9m", - "index": [ - "endgame-*", - "logs-endpoint.events.process-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*", - "logs-system.security*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Suspicious Endpoint Security Parent Process", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Endpoint Security Parent Process\n\nEndpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats.\n\n### Possible investigation steps\n\n- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment.\n- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside \"?:\\Program Files\\Elastic\\*\" or \"?:\\Windows\\System32\\*\".\n- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like \"test\", \"version\", or \"status\".\n- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes.\n- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and identify any related suspicious activities.\n- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption.\n\n### False positive analysis\n\n- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list.\n- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list.\n- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list.\n- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.\n- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files.\n- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised.\n- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary.\n- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.", - "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : (\"esensor.exe\", \"elastic-endpoint.exe\") and\n process.parent.executable != null and\n /* add FPs here */\n not process.parent.executable : (\n \"?:\\\\Program Files\\\\Elastic\\\\*\",\n \"?:\\\\Windows\\\\System32\\\\services.exe\",\n \"?:\\\\Windows\\\\System32\\\\WerFault*.exe\",\n \"?:\\\\Windows\\\\System32\\\\wermgr.exe\",\n \"?:\\\\Windows\\\\explorer.exe\"\n ) and\n not (\n process.parent.executable : (\n \"?:\\\\Windows\\\\System32\\\\cmd.exe\",\n \"?:\\\\Windows\\\\System32\\\\SecurityHealthHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1.0\\\\powershell.exe\"\n ) and\n process.args : (\n \"test\", \"version\",\n \"top\", \"run\",\n \"*help\", \"status\",\n \"upgrade\", \"/launch\",\n \"/enable\"\n )\n )\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - }, - { - "package": "system", - "version": "^1.64.0" - }, - { - "package": "m365_defender", - "version": "^2.22.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.9.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.executable", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "b41a13c6-ba45-4bab-a534-df53d0cfed6a", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Windows Security Event Logs", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Sysmon", - "Data Source: SentinelOne", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1036", - "name": "Masquerading", - "reference": "https://attack.mitre.org/techniques/T1036/", - "subtechnique": [ - { - "id": "T1036.005", - "name": "Match Legitimate Name or Location", - "reference": "https://attack.mitre.org/techniques/T1036/005/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 316 - }, - "id": "b41a13c6-ba45-4bab-a534-df53d0cfed6a_316", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_3.json b/packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_3.json deleted file mode 100644 index 10dc7db398a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_3.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.", - "false_positives": [ - "False positives can occur because the rules may be mapped to a few MITRE ATT&CK tactics. Use the attached Timeline to determine which detections were triggered on the host." - ], - "from": "now-24h", - "index": [ - ".alerts-security.*" - ], - "interval": "1h", - "language": "kuery", - "license": "Elastic License v2", - "name": "Multiple Alerts in Different ATT&CK Tactics on a Single Host", - "query": "signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*\n", - "required_fields": [ - { - "ecs": false, - "name": "kibana.alert.rule.threat.tactic.id", - "type": "unknown" - }, - { - "ecs": false, - "name": "signal.rule.name", - "type": "unknown" - } - ], - "risk_score": 73, - "rule_id": "b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c", - "severity": "high", - "tags": [ - "Elastic", - "Threat Detection", - "Higher-Order Rules" - ], - "threshold": { - "cardinality": [ - { - "field": "kibana.alert.rule.threat.tactic.id", - "value": 3 - } - ], - "field": [ - "host.id" - ], - "value": 1 - }, - "timestamp_override": "event.ingested", - "type": "threshold", - "version": 3 - }, - "id": "b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json new file mode 100644 index 00000000000..0ca8dac5750 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information.", + "false_positives": [ + "Service accounts or applications that frequently access Azure Key Vault for configuration or operational purposes may trigger this rule.", + "Automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or application configuration, may also lead to false positives.", + "Security teams performing routine audits or assessments that involve retrieving keys or secrets from Key Vaults may trigger this rule if they perform multiple retrievals in a short time frame." + ], + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "Excessive Secret or Key Retrieval from Azure Key Vault", + "note": "## Triage and analysis\n\n### Investigating Excessive Secret or Key Retrieval from Azure Key Vault\n\nAzure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts.\n\n### Possible investigation steps\n- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious.\n- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies.\n- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources.\n- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault.\n- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.\n- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity.\n- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents.\n- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies.\n\n### False positive analysis\n- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.\n- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n\n### Response and remediation\n- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals.\n- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault.\n- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals.\n- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts.\n- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets.\n- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments.\n", + "query": "FROM logs-azure.platformlogs-* METADATA _id, _index\n\n// Filter for Azure Key Vault read operations\n| WHERE event.dataset == \"azure.platformlogs\"\n AND event.action IN (\n \"VaultGet\",\n \"KeyGet\",\n \"KeyList\",\n \"KeyListVersions\",\n \"KeyGetDeleted\",\n \"KeyListDeleted\",\n \"SecretGet\",\n \"SecretList\",\n \"SecretListVersions\",\n \"SecretGetDeleted\",\n \"SecretListDeleted\",\n \"CertificateGet\",\n \"CertificateList\",\n \"CertificateListVersions\",\n \"CertificateGetDeleted\",\n \"CertificateListDeleted\",\n \"CertificatePolicyGet\",\n \"CertificateContactsGet\",\n \"CertificateIssuerGet\",\n \"CertificateIssuersList\"\n )\n\n// Truncate timestamps into 1-minute windows\n| EVAL Esql.time_window.date_trunc = DATE_TRUNC(1 minute, @timestamp)\n\n// Aggregate identity, geo, resource, and activity info\n| STATS\n Esql.azure.platformlogs.identity.claim.upn.values = VALUES(azure.platformlogs.identity.claim.upn),\n Esql.azure.platformlogs.identity.claim.upn.count_unique = COUNT_DISTINCT(azure.platformlogs.identity.claim.upn),\n Esql.azure.platformlogs.identity.claim.appid.values = VALUES(azure.platformlogs.identity.claim.appid),\n Esql.azure.platformlogs.identity.claim.objectid.values = VALUES(azure.platformlogs.identity.claim.objectid),\n\n Esql.source.ip.values = VALUES(source.ip),\n Esql.geo.city.values = VALUES(geo.city_name),\n Esql.geo.region.values = VALUES(geo.region_name),\n Esql.geo.country.values = VALUES(geo.country_name),\n Esql.network.as_org.values = VALUES(source.as.organization.name),\n\n Esql.event.actions.values = VALUES(event.action),\n Esql.event.count = COUNT(*),\n Esql.event.action.count_distinct = COUNT_DISTINCT(event.action),\n Esql.azure.resource.name.count_distinct = COUNT_DISTINCT(azure.resource.name),\n Esql.azure.resource.name.values = VALUES(azure.resource.name),\n Esql.azure.platformlogs.result_type.values = VALUES(azure.platformlogs.result_type),\n Esql.cloud.region.values = VALUES(cloud.region),\n\n Esql.agent.name.values = VALUES(agent.name),\n Esql.azure.subscription_id.values = VALUES(azure.subscription_id),\n Esql.azure.resource_group.values = VALUES(azure.resource.group),\n Esql.azure.resource_id.values = VALUES(azure.resource.id)\n\nBY Esql.time_window.date_trunc, azure.platformlogs.identity.claim.upn\n\n// Keep relevant fields\n| KEEP\n Esql.time_window.date_trunc,\n Esql.azure.platformlogs.identity.claim.upn.values,\n Esql.azure.platformlogs.identity.claim.upn.count_unique,\n Esql.azure.platformlogs.identity.claim.appid.values,\n Esql.azure.platformlogs.identity.claim.objectid.values,\n Esql.source.ip.values,\n Esql.geo.city.values,\n Esql.geo.region.values,\n Esql.geo.country.values,\n Esql.network.as_org.values,\n Esql.event.actions.values,\n Esql.event.count,\n Esql.event.action.count_distinct,\n Esql.azure.resource.name.count_distinct,\n Esql.azure.resource.name.values,\n Esql.azure.platformlogs.result_type.values,\n Esql.cloud.region.values,\n Esql.agent.name.values,\n Esql.azure.subscription_id.values,\n Esql.azure.resource_group.values,\n Esql.azure.resource_id.values\n\n// Filter for suspiciously high volume of distinct Key Vault reads by a single actor\n| WHERE Esql.azure.platformlogs.identity.claim.upn.count_unique == 1 AND Esql.event.count >= 10 AND Esql.event.action.count_distinct >= 2\n\n| SORT Esql.time_window.date_trunc DESC\n", + "references": [ + "https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html" + ], + "risk_score": 43, + "rule_id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd", + "setup": "#### Required Azure Key Vault Diagnostic Logs\n\nTo ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:\n- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Storage", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Azure Platform Logs", + "Data Source: Azure Key Vault", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1555", + "name": "Credentials from Password Stores", + "reference": "https://attack.mitre.org/techniques/T1555/", + "subtechnique": [ + { + "id": "T1555.006", + "name": "Cloud Secrets Management Stores", + "reference": "https://attack.mitre.org/techniques/T1555/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_4.json b/packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_4.json new file mode 100644 index 00000000000..fbe944ff249 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_4.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name.", + "false_positives": [ + "Legitimate use of Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt objects in an S3 bucket." + ], + "from": "now-6m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "source.ip", + "user_agent.original", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.additional_eventdata", + "aws.cloudtrail.response_elements", + "cloud.region", + "cloud.account.id" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual AWS S3 Object Encryption with SSE-C", + "new_terms_fields": [ + "cloud.account.id", + "user.name", + "tls.client.server_name" + ], + "note": "### Triage and Analysis\n\n#### Investigating Unusual AWS S3 Object Encryption with SSE-C\nThis rule identifies the use of Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys.\n\n##### Possible Investigation Steps\n\n1. **Identify the User and Source**:\n - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation.\n - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access.\n - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key.\n\n2. **Examine the Targeted Resources**:\n - Check `aws.cloudtrail.request_parameters` to identify the bucket involved.\n - Analyze the object key from `aws.cloudtrail.request_parameters`.\n\n3. **Evaluate Encryption Behavior**:\n - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`.\n - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key.\n\n4. **Correlate with Recent Events**:\n - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP.\n - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects.\n - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note.\n\n5. **Validate Access Permissions**:\n - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects.\n\n6. **Assess Impact**:\n - Identify the number of encrypted objects in the bucket by examining other similar events.\n - Determine if this encryption aligns with standard business practices or constitutes a deviation.\n\n### False Positive Analysis\n\n- **Legitimate Use Cases**:\n - Confirm if SSE-C encryption is part of regular operations for compliance or data protection.\n - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Disable access keys or permissions for the user if unauthorized behavior is confirmed.\n - Rotate the bucket's encryption configuration to mitigate further misuse.\n\n2. **Data Recovery**:\n - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future SSE-C encryption attempts in critical buckets.\n - Review and tighten IAM policies for roles and users accessing S3.\n\n4. **Post-Incident Review**:\n - Audit logs for additional activities by the same user or IP.\n - Document findings and apply lessons learned to improve preventive measures.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"s3.amazonaws.com\"\n and event.action: \"PutObject\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: \"AES256\"\n", + "references": [ + "https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c", + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "c1a9ed70-d349-11ef-841c-f661ea17fbcd", + "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Impact" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 4 + }, + "id": "c1a9ed70-d349-11ef-841c-f661ea17fbcd_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_7.json b/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_7.json new file mode 100644 index 00000000000..080c24d60ec --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_7.json @@ -0,0 +1,141 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance.", + "from": "now-6m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "5m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 User Data Retrieval for EC2 Instance", + "new_terms_fields": [ + "cloud.account.id", + "user.name", + "aws.cloudtrail.flattened.request_parameters.instanceId" + ], + "note": "## Triage and Analysis\n\n### Investigating AWS EC2 User Data Retrieval for EC2 Instance\n\nThis rule detects requests to retrieve the `userData` attribute of an EC2 instance using the `DescribeInstanceAttribute` API action. The `userData` field can contain sensitive information, such as hardcoded credentials or configuration scripts, that adversaries may exploit for further attacks.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceId` field to identify the EC2 instance targeted by the request. Confirm whether this instance should expose its `userData` and whether it is associated with sensitive workloads.\n - **Analyze userData**: If possible, retrieve and inspect the `userData` field to identify sensitive information like hardcoded credentials or configuration scripts.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to identify the user or role that executed the `DescribeInstanceAttribute` action. Investigate whether this user typically performs such actions.\n - **Access Patterns**: Validate whether the user or role has the necessary permissions and whether the frequency of this action aligns with expected behavior.\n - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to determine the key used to make the request as it may be compromised.\n - **Source IP and Geolocation**: Check the `source.address` and `source.geo` fields to validate whether the request originated from a trusted location or network. Unexpected geolocations can indicate adversarial activity.\n - **User Agent**: Inspect the `user_agent.original` field to determine the tool or client used (e.g., Terraform, AWS CLI). Legitimate automation tools may trigger this activity, but custom or unknown user agents may indicate malicious intent.\n\n- **Check for Related Activity**:\n - **IAM Changes**: Correlate this event with any IAM changes or temporary credential creation to identify potential privilege escalation attempts.\n - **API Usage**: Look for other unusual API calls (e.g., `RunInstances`, `GetObject`, `AssumeRole`) by the same user or IP to detect lateral movement or data exfiltration attempts.\n\n- **Validate Intent**:\n - **Permissions and Justification**: Ensure that the user has the least privilege required to perform this action. Investigate whether there is a valid reason for accessing the `userData` field.\n\n### False Positive Analysis\n\n- **Automation**: This event is often triggered by legitimate automation tools, such as Terraform or custom scripts, that require access to `userData` during instance initialization.\n- **Maintenance Activity**: Verify whether this event aligns with expected administrative activities, such as debugging or instance configuration updates.\n\n### Response and Remediation\n\n- **Revoke Excessive Permissions**: If unauthorized, immediately remove `DescribeInstanceAttribute` permissions from the user or role.\n- **Quarantine the Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance to limit further exposure.\n- **Secure User Data**:\n - Avoid storing sensitive information, such as credentials, in `userData`. Use AWS Secrets Manager or Parameter Store instead.\n - Encrypt user data and ensure only authorized users can decrypt it.\n- **Audit IAM Policies**: Regularly review IAM policies to ensure they adhere to the principle of least privilege.\n- **Monitor and Detect**: Set up additional alerts for unexpected `DescribeInstanceAttribute` calls or other suspicious API activity.\n\n### Additional Information\n\nFor more details on managing EC2 user data securely, refer to the [AWS EC2 User Data Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action: \"DescribeInstanceAttribute\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.attribute: \"userData\"\n and not aws.cloudtrail.user_identity.invoked_by: (\n \"AWS Internal\" or\n \"cloudformation.amazonaws.com\"\n )\n", + "references": [ + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html", + "https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.attribute", + "type": "unknown" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.invoked_by", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "c1e79a70-fa6f-11ee-8bc8-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon EC2", + "Resources: Investigation Guide", + "Use Case: Log Auditing", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1552", + "name": "Unsecured Credentials", + "reference": "https://attack.mitre.org/techniques/T1552/", + "subtechnique": [ + { + "id": "T1552.005", + "name": "Cloud Instance Metadata API", + "reference": "https://attack.mitre.org/techniques/T1552/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 7 + }, + "id": "c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_4.json b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_4.json new file mode 100644 index 00000000000..edc4b25a0ce --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_4.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Base64 Encoding/Decoding Activity", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Base64 Encoding/Decoding Activity\nBase64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.\n\n### Possible investigation steps\n\n- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.\n- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.\n- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.\n- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.\n- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.\n- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.\n- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.\n\n### False positive analysis\n\n- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.\n- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.\n- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.\n- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.\n- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.\n\n### Response and remediation\n\n- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.\n- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.\n- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.\n- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.\n- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.\n- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.\n", + "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n (process.name in (\"base64\", \"base64plain\", \"base64url\", \"base64mime\", \"base64pem\", \"base32\", \"base16\") and process.command_line like \"*-*d*\") or\n (process.name == \"openssl\" and process.args == \"enc\" and process.args in (\"-d\", \"-base64\", \"-a\")) or\n (process.name like \"python*\" and\n (process.args == \"base64\" and process.args in (\"-d\", \"-u\", \"-t\")) or\n (process.args == \"-c\" and process.command_line like \"*base64*\" and process.command_line like \"*b64decode*\")\n ) or\n (process.name like \"perl*\" and process.command_line like \"*decode_base64*\") or\n (process.name like \"ruby*\" and process.args == \"-e\" and process.command_line like \"*Base64.decode64*\")\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.name, process.command_line\n| where agent_count == 1 and cc < 15\n| sort cc asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "c5637438-e32d-4bb3-bc13-bd7932b3289f", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + }, + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "c5637438-e32d-4bb3-bc13-bd7932b3289f_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_3.json b/packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_3.json new file mode 100644 index 00000000000..1c999157aff --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_3.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects use of sensitive AWS IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with temporary session tokens.", + "false_positives": [ + "Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to validate." + ], + "from": "now-6m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM API Calls via Temporary Session Tokens", + "new_terms_fields": [ + "aws.cloudtrail.user_identity.arn" + ], + "note": "## Triage and analysis\n\n### Investigating AWS IAM API Calls via Temporary Session Tokens\n\nThis rule detects sensitive IAM API operations performed using temporary AWS credentials (session tokens starting with 'ASIA'). These are short-lived credentials commonly obtained via sts:GetSessionToken, sts:AssumeRole, or AWS SSO login. While temporary credentials are often used for development and automation, they are rarely associated with direct IAM manipulation and may indicate credential theft, privilege escalation, or abuse of developer access.\n\n#### Possible investigation steps:\n\n- Review `aws.cloudtrail.user_identity.arn` to determine which IAM user or assumed role initiated the request.\n- Check `aws.cloudtrail.user_identity.access_key_id` to confirm if the credential starts with 'ASIA', indicating a temporary session token.\n- Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` to verify whether MFA was present during session creation.\n- Investigate `source.ip` to assess whether the request originated from a known network, office IP, or corporate VPN.\n- Look at `user_agent.original` to determine if the API call came from a known CLI version or unexpected tool (e.g., unknown SDK, custom script).\n- Confirm whether a recent sts:GetSessionToken, sts:AssumeRole, or AWS SSO login event issued the temporary credential.\n- Correlate other events using the same access key ID to identify additional privileged actions, such as iam:CreateAccessKey, iam:PutUserPolicy, or iam:EnableMFADevice.\n- Analyze timing via @timestamp to determine if the action occurred during off-hours or deviates from normal user behavior.\n- Review the `event.outcome` to check if the API call was successful or failed, which may indicate unauthorized access attempts.\n- Check for related events in the same session, such as iam:CreateUser, iam:AttachUserPolicy, or sts:GetCallerIdentity, to identify potential lateral movement or privilege escalation.\n\n### False positive analysis:\n\n- Determine if the IAM user or automation pipeline routinely performs privileged actions using temporary session tokens.\n- Validate whether the MFA context and source IP match expected developer or CI/CD behavior.\n- Review recent IAM policy changes or deployments that may explain the behavior.\n- Confirm if the user has a legitimate reason to perform sensitive IAM operations with temporary credentials, such as during a deployment or maintenance window.\n\n### Response and remediation:\n\n- Revoke the temporary session token and rotate long-term access keys for the associated user if the behavior is unauthorized.\n- Audit related CloudTrail events within the same session to identify policy changes, resource creation, or lateral movement.\n- Add explicit deny statements in IAM policies to prevent sensitive IAM actions when aws:authType is not \"console\".\n- Implement IP restrictions for IAM and STS API actions using aws:SourceIp conditions.\n- Strengthen monitoring for IAM activity initiated by session tokens with MFA to improve detection coverage.\n", + "query": "event.dataset: aws.cloudtrail\n and event.provider: (\"iam.amazonaws.com\")\n and event.outcome: \"success\"\n and aws.cloudtrail.user_identity.type: \"IAMUser\"\n and aws.cloudtrail.user_identity.access_key_id: ASIA*\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.access_key_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS CloudTrail", + "Data Source: AWS IAM", + "Data Source: AWS STS", + "Tactic: Persistence", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 3 + }, + "id": "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_205.json b/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_205.json deleted file mode 100644 index 1768e7eb77e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_205.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.", - "false_positives": [ - "By default a container is not allowed to access any devices on the host, but a \"privileged\" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. An administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Privileged Pod Created", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Privileged Pod Created\n\nKubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields.\n- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.\n- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.\n- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.\n- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.\n\n### False positive analysis\n\n- Known safe images like \"docker.elastic.co/beats/elastic-agent:8.4.0\" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.\n- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.\n- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.\n- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.\n- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.\n- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.\n- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.\n- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.\n- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.\n- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:pods\n and kubernetes.audit.verb:create\n and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF", - "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.securityContext.privileged", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "c7908cac-337a-4f38-b50d-5eeb78bdb531", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "c7908cac-337a-4f38-b50d-5eeb78bdb531_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json new file mode 100644 index 00000000000..da407c59027 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json @@ -0,0 +1,56 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Device Token Hashes for Single Okta Session", + "note": "## Triage and analysis\n\n### Investigating Multiple Device Token Hashes for Single Okta Session\n\nThis rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - Authentication events have been filtered out to focus on Okta activity via established sessions.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.\n - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.\n\n### Response and remediation:\n- Consider stopping all sessions for the user(s) involved in this action.\n- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n // ignore authentication events where session and device token hash change often\n AND NOT event.action IN (\n \"policy.evaluate_sign_on\",\n \"user.session.start\",\n \"user.authentication.sso\"\n )\n // ignore Okta system events and only allow registered users\n AND (\n okta.actor.alternate_id != \"system@okta.com\"\n AND okta.actor.alternate_id RLIKE \"[^@\\\\s]+\\\\@[^@\\\\s]+\"\n )\n AND okta.authentication_context.external_session_id != \"unknown\"\n| KEEP event.action, okta.actor.alternate_id, okta.authentication_context.external_session_id, okta.debug_context.debug_data.dt_hash\n| STATS\n dt_hash_counts = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id\n| WHERE\n dt_hash_counts >= 2\n| SORT\n dt_hash_counts DESC\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 47, + "rule_id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd", + "setup": "## Setup\n\nThe Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Domain: SaaS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1539", + "name": "Steal Web Session Cookie", + "reference": "https://attack.mitre.org/techniques/T1539/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 306 + }, + "id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json new file mode 100644 index 00000000000..12759b4d30b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json @@ -0,0 +1,82 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Sign-In Brute Force Activity", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Sign-In Brute Force Activity\n\nThis rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response.\n\n### Possible investigation steps\n\n- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`).\n- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted.\n- Review `login_errors`: Repetitive error types like `\"Invalid Grant\"` or `\"User Not Found\"` suggest automated attacks.\n- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.).\n- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks.\n- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation.\n- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools.\n- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms.\n- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts.\n- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly.\n\n### False positive analysis\n\n- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures.\n- Internal red team activity or penetration tests may mimic brute-force behaviors.\n- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured.\n\n### Response and remediation\n\n- Notify your identity security team for further analysis.\n- Investigate and lock or reset impacted accounts if compromise is suspected.\n- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access.\n- Confirm MFA and Conditional Access are enforced for all user types.\n- Audit targeted accounts for credential reuse across services.\n- Implement account lockout or throttling for failed sign-in attempts where possible.\n", + "query": "FROM logs-azure.signinlogs*\n\n// Define a time window for grouping and maintain the original event timestamp\n| EVAL\n time_window = DATE_TRUNC(15 minutes, @timestamp),\n event_time = @timestamp\n\n// Filter relevant failed authentication events with specific error codes\n| WHERE event.dataset == \"azure.signinlogs\"\n AND event.category == \"authentication\"\n AND azure.signinlogs.category IN (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n AND event.outcome == \"failure\"\n AND azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n AND azure.signinlogs.properties.status.error_code IN (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n AND azure.signinlogs.properties.user_principal_name IS NOT NULL AND azure.signinlogs.properties.user_principal_name != \"\"\n AND user_agent.original != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n AND source.`as`.organization.name != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n\n// Aggregate statistics for behavioral pattern analysis\n| STATS\n authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n client_app_id = VALUES(azure.signinlogs.properties.app_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n target_resource_id = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id),\n device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n user_id = VALUES(azure.signinlogs.properties.user_id),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n result_description = VALUES(azure.signinlogs.result_description),\n result_signature = VALUES(azure.signinlogs.result_signature),\n result_type = VALUES(azure.signinlogs.result_type),\n\n unique_users = COUNT_DISTINCT(azure.signinlogs.properties.user_id),\n user_id_list = VALUES(azure.signinlogs.properties.user_id),\n login_errors = VALUES(azure.signinlogs.result_description),\n unique_login_errors = COUNT_DISTINCT(azure.signinlogs.result_description),\n error_codes = VALUES(azure.signinlogs.properties.status.error_code),\n unique_error_codes = COUNT_DISTINCT(azure.signinlogs.properties.status.error_code),\n request_types = VALUES(azure.signinlogs.properties.incoming_token_type),\n app_names = VALUES(azure.signinlogs.properties.app_display_name),\n ip_list = VALUES(source.ip),\n unique_ips = COUNT_DISTINCT(source.ip),\n source_orgs = VALUES(source.`as`.organization.name),\n countries = VALUES(source.geo.country_name),\n unique_country_count = COUNT_DISTINCT(source.geo.country_name),\n unique_asn_orgs = COUNT_DISTINCT(source.`as`.organization.name),\n first_seen = MIN(@timestamp),\n last_seen = MAX(@timestamp),\n total_attempts = COUNT()\nBY time_window\n\n// Determine brute force behavior type based on statistical thresholds\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen),\n bf_type = CASE(\n // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many),\n // and happens quickly. Often bots using leaked credentials.\n unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3\n AND unique_ips >= 5\n AND duration_seconds <= 600\n AND unique_users > unique_ips,\n \"credential_stuffing\",\n\n // One password against many users. Single error (e.g., \"InvalidPassword\"), not necessarily fast.\n unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800,\n \"password_spraying\",\n\n // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs.\n (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300)\n OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100),\n \"password_guessing\",\n\n // everything else\n \"other\"\n )\n\n// Only keep columns necessary for detection output/reporting\n| KEEP\n time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen,\n unique_users, user_id_list, login_errors, unique_login_errors,\n unique_error_codes, error_codes, request_types, app_names,\n ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs,\n authentication_requirement, client_app_id, client_app_display_name,\n target_resource_id, target_resource_display_name, conditional_access_status,\n device_detail_browser, device_detail_device_id, device_detail_operating_system,\n incoming_token_type, risk_state, session_id, user_id,\n user_principal_name, result_description, result_signature, result_type\n\n// Remove anything not classified as credential attack activity\n| WHERE bf_type != \"other\"\n", + "references": [ + "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign", + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/", + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "cca64114-fb8b-11ef-86e2-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "cca64114-fb8b-11ef-86e2-f661ea17fbce_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cf307a5a-d503-44a4-8158-db196d99c9df_1.json b/packages/security_detection_engine/kibana/security_rule/cf307a5a-d503-44a4-8158-db196d99c9df_1.json new file mode 100644 index 00000000000..58b0b16b4c3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cf307a5a-d503-44a4-8158-db196d99c9df_1.json @@ -0,0 +1,84 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of unusual kill signals, specifically kill signals in the range of 32-64, which are not commonly used in standard operations. Rootkits may leverage these signals to conduct certain actions, such as manipulating processes in unexpected ways, potentially escalating privileges or evading detection.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "logs-auditd_manager.auditd-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Unusual Kill Signal", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Kill Signal\n\nIn Linux environments, kill signals are used to manage process lifecycles. Signals in the range of 32-64 are less common and can be exploited by adversaries, such as rootkits, to manipulate processes stealthily, potentially leading to privilege escalation or evasion of security measures. The 'Unusual Kill Signal' detection rule identifies these rare signals, flagging potential misuse by monitoring specific syscall activities, thus aiding in early threat detection.\n\n### Possible investigation steps\n\n- Review the process details associated with the alert, focusing on the process name, PID, and parent process to understand the context of the kill signal usage.\n- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential unauthorized access.\n- Investigate the command line arguments and environment variables of the process to identify any suspicious or unusual commands that may suggest malicious activity.\n- Check the system logs around the time of the alert for any related events or anomalies that could provide additional context or indicate a broader attack pattern.\n- Correlate the alert with other security events or alerts from the same host to identify if this is part of a larger attack or if there are other indicators of compromise.\n- Assess the network activity of the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.\n\n### False positive analysis\n\n- Legitimate applications or services may use signals in the 32-64 range for custom inter-process communication, leading to false positives. Identify these applications and create exceptions for their specific processes.\n- Some system monitoring or management tools might utilize these signals for legitimate process management tasks. Review the tools in use and whitelist their activities if they are verified as non-threatening.\n- Development environments or testing frameworks might employ unusual signals for debugging or testing purposes. Ensure these environments are properly isolated and exclude their activities from triggering alerts.\n- Custom scripts or automation tasks could be configured to use these signals for specific operations. Audit these scripts and, if deemed safe, add them to an exception list to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.\n- Terminate any suspicious processes identified with unusual kill signals in the range of 32-64 to halt any ongoing malicious activity.\n- Conduct a thorough forensic analysis of the affected system to identify any rootkits or malicious software that may have been installed, focusing on the processes and files associated with the unusual kill signals.\n- Restore the system from a known good backup if rootkit presence is confirmed, ensuring that the backup is free from any compromise.\n- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.\n- Implement enhanced monitoring and logging for unusual kill signals and related activities to detect any future attempts at similar attacks.\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the need for broader organizational response measures.\n", + "query": "process where host.os.type == \"linux\" and event.action == \"killed-pid\" and auditd.data.syscall == \"kill\" and\nauditd.data.a1 in (\n \"21\", \"22\", \"23\", \"24\", \"25\", \"26\", \"27\", \"28\", \"29\", \"2a\", \"2b\", \"2c\", \"2d\", \"2e\", \"2f\", \"30\",\n \"31\", \"32\", \"33\", \"34\", \"35\", \"36\", \"37\", \"38\", \"39\", \"3a\", \"3b\", \"3c\", \"3d\", \"3e\", \"3f\", \"40\",\n \"41\", \"42\", \"43\", \"44\", \"45\", \"46\", \"47\"\n)\n", + "references": [ + "https://github.com/m0nad/Diamorphine/blob/master/diamorphine.c#L302", + "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.18.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "auditd.data.a1", + "type": "unknown" + }, + { + "ecs": false, + "name": "auditd.data.syscall", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "cf307a5a-d503-44a4-8158-db196d99c9df", + "setup": "## Setup\n\nThis rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.\n```\nKibana -->\nManagement -->\nIntegrations -->\nAuditd Manager -->\nAdd Auditd Manager\n```\n`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the \"audit rules\" configuration box or the \"auditd rule files\" box by specifying a file to read the audit rules from.\nFor this detection rule to trigger, the following additional audit rules are required to be added to the integration:\n```\n-a always,exit -F arch=b64 -S kill\n```\nAdd the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Auditd Manager", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1014", + "name": "Rootkit", + "reference": "https://attack.mitre.org/techniques/T1014/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "cf307a5a-d503-44a4-8158-db196d99c9df_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_5.json b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_5.json new file mode 100644 index 00000000000..b52e8124143 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_5.json @@ -0,0 +1,86 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target role." + ], + "from": "now-6m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM AdministratorAccess Policy Attached to Role", + "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Role\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachRolePolicy` permission, a set of compromised credentials could be used to attach\nthis policy to a compromised role for privilege escalation or as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachRolePolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachRolePolicy` permission and that the `role.name` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected role(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachRolePolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?roleName}=%{role.name}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, role.name\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" + ], + "risk_score": 47, + "rule_id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json new file mode 100644 index 00000000000..cae482a028f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json @@ -0,0 +1,56 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Microsoft 365 User Account Lockouts in Short Time Window", + "note": "## Triage and Analysis\n\n### Investigating Multiple Microsoft 365 User Account Lockouts in Short Time Window\n\nDetects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context.\n\n### Investigation Steps\n\n- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)?\n- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers.\n- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation.\n- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly?\n- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs.\n- Correlate with any recent detection of password spraying or credential stuffing activity.\n- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.).\n- Check for any successful logins from the same IP or ASN after the lockouts.\n\n### False Positive Analysis\n\n- Automated systems with stale credentials may cause repeated failed logins.\n- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts.\n- Red team exercises or penetration tests may resemble the same lockout pattern.\n- Some organizations may have a high volume of lockouts due to user behavior or legacy systems.\n\n### Response Recommendations\n\n- Notify affected users and confirm whether activity was expected or suspicious.\n- Lock or reset credentials for impacted accounts.\n- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.\n- Strengthen lockout and retry delay policies if necessary.\n- Review the originating application(s) involved via `request_types`.\n", + "query": "FROM logs-o365.audit-*\n\n| MV_EXPAND event.category\n| EVAL\n time_window = DATE_TRUNC(5 minutes, @timestamp),\n user_id = TO_LOWER(o365.audit.UserId),\n ip = source.ip,\n login_error = o365.audit.LogonError,\n request_type = TO_LOWER(o365.audit.ExtendedProperties.RequestType),\n asn_org = source.`as`.organization.name,\n country = source.geo.country_name,\n event_time = @timestamp\n\n| WHERE event.dataset == \"o365.audit\"\n AND event.category == \"authentication\"\n AND event.provider IN (\"AzureActiveDirectory\", \"Exchange\")\n AND event.action IN (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\")\n AND request_type RLIKE \"(oauth.*||.*login.*)\"\n AND login_error == \"IdsLocked\"\n AND user_id != \"not available\"\n AND o365.audit.Target.Type IN (\"0\", \"2\", \"6\", \"10\")\n AND asn_org != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n\n| STATS\n unique_users = COUNT_DISTINCT(user_id),\n user_id_list = VALUES(user_id),\n ip_list = VALUES(ip),\n unique_ips = COUNT_DISTINCT(ip),\n source_orgs = VALUES(asn_org),\n countries = VALUES(country),\n unique_country_count = COUNT_DISTINCT(country),\n unique_asn_orgs = COUNT_DISTINCT(asn_org),\n request_types = VALUES(request_type),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_lockout_responses = COUNT()\n BY time_window\n\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen)\n\n| KEEP\n time_window, unique_users, user_id_list, ip_list,\n unique_ips, source_orgs, countries, unique_country_count,\n unique_asn_orgs, request_types, first_seen, last_seen,\n total_lockout_responses, duration_seconds\n\n| WHERE\n unique_users >= 10 AND\n total_lockout_responses >= 10 AND\n duration_seconds <= 300\n", + "references": [ + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_205.json b/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_205.json deleted file mode 100644 index dc693c34185..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_205.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root.", - "false_positives": [ - "An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod Created With HostPID", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Pod Created With HostPID\n\nKubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action.\n- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed.\n- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision.\n- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved.\n- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set.\n- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered.\n\n### False positive analysis\n\n- Known safe images like \"docker.elastic.co/beats/elastic-agent:8.4.0\" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list.\n- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts.\n- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames.\n- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria.\n- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods.\n- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry.\n- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities.\n- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker.\n- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future.\n- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostPID:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", - "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.hostPID", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "df7fda76-c92b-4943-bc68-04460a5ea5ba", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "df7fda76-c92b-4943-bc68-04460a5ea5ba_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_5.json b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_5.json new file mode 100644 index 00000000000..36ead6180a9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_5.json @@ -0,0 +1,86 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user group." + ], + "from": "now-6m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM AdministratorAccess Policy Attached to Group", + "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Group\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected group(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachGroupPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?groupName}=%{group.name}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, group.name\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" + ], + "risk_score": 47, + "rule_id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_317.json b/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_317.json deleted file mode 100644 index 2b013929315..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_317.json +++ /dev/null @@ -1,143 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerShell scripts. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions.", - "filters": [ - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "file.path": { - "case_insensitive": true, - "value": "C:\\\\Program Files\\\\Microsoft Monitoring Agent\\\\Agent\\\\Health Service State\\\\Monitoring Host Temporary Files*\\\\AvailabilityGroupMonitoring.ps1" - } - } - } - } - ], - "from": "now-9m", - "index": [ - "winlogbeat-*", - "logs-windows.powershell*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Suspicious .NET Reflection via PowerShell", - "note": "## Triage and analysis\n\n### Investigating Suspicious .NET Reflection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script, which can circumvent file-based security protections.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the script using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did not identify malware or suspicious activity related to the user or host, this alert can be dismissed.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n \"[System.Reflection.Assembly]::Load\" or\n \"[Reflection.Assembly]::Load\" or\n \"Assembly.Load(\" or\n \"System.Reflection\"\n ) and\n not powershell.file.script_block_text : (\n (\"CommonWorkflowParameters\" or \"RelatedLinksHelpInfo\") and\n \"HelpDisplayStrings\"\n ) and\n not (powershell.file.script_block_text :\n (\"Get-SolutionFiles\" or \"Get-VisualStudio\" or \"Select-MSBuildPath\") and\n file.name : \"PathFunctions.ps1\"\n ) and\n not powershell.file.script_block_text : (\n \"Microsoft.PowerShell.Workflow.ServiceCore\" and \"ExtractPluginProperties([string]$pluginDir\"\n ) and \n \n not powershell.file.script_block_text : (\"reflection.assembly]::Load('System.\" or \"LoadWithPartialName('Microsoft.\" or \"::Load(\\\"Microsoft.\" or \"Microsoft.Build.Utilities.Core.dll\") and \n \n not user.id : \"S-1-5-18\"\n", - "references": [ - "https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load" - ], - "related_integrations": [ - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "unknown" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "e26f042e-c590-4e82-8e05-41e81bd822ad", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Tactic: Execution", - "Resources: Investigation Guide", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1620", - "name": "Reflective Code Loading", - "reference": "https://attack.mitre.org/techniques/T1620/" - }, - { - "id": "T1055", - "name": "Process Injection", - "reference": "https://attack.mitre.org/techniques/T1055/", - "subtechnique": [ - { - "id": "T1055.001", - "name": "Dynamic-link Library Injection", - "reference": "https://attack.mitre.org/techniques/T1055/001/" - }, - { - "id": "T1055.002", - "name": "Portable Executable Injection", - "reference": "https://attack.mitre.org/techniques/T1055/002/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 317 - }, - "id": "e26f042e-c590-4e82-8e05-41e81bd822ad_317", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_107.json b/packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_107.json deleted file mode 100644 index 772b2712317..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e468f3f6-7c4c-45bb-846a-053738b3fe5d_107.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions.", - "from": "now-9m", - "history_window_start": "now-7d", - "index": [ - "winlogbeat-*", - "logs-system.security*", - "logs-windows.forwarded*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "First Time Seen NewCredentials Logon Process", - "new_terms_fields": [ - "process.executable" - ], - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating First Time Seen NewCredentials Logon Process\n\nThe NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks.\n\n### Possible investigation steps\n\n- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files.\n- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account.\n- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous.\n- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections.\n- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments.\n- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors.\n\n### False positive analysis\n\n- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths.\n- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names.\n- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles.\n- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts.\n- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse.\n- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly.\n- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future.", - "query": "event.category:\"authentication\" and host.os.type:\"windows\" and winlog.logon.type:\"NewCredentials\" and winlog.event_data.LogonProcessName:(Advapi* or \"Advapi \") and not winlog.event_data.SubjectUserName:*$ and not process.executable :???\\\\Program?Files*\n", - "references": [ - "https://www.elastic.co/pt/blog/how-attackers-abuse-access-token-manipulation" - ], - "related_integrations": [ - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.LogonProcessName", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.SubjectUserName", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.logon.type", - "type": "unknown" - } - ], - "risk_score": 47, - "rule_id": "e468f3f6-7c4c-45bb-846a-053738b3fe5d", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "Data Source: Windows Security Event Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1134", - "name": "Access Token Manipulation", - "reference": "https://attack.mitre.org/techniques/T1134/", - "subtechnique": [ - { - "id": "T1134.001", - "name": "Token Impersonation/Theft", - "reference": "https://attack.mitre.org/techniques/T1134/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 107 - }, - "id": "e468f3f6-7c4c-45bb-846a-053738b3fe5d_107", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_208.json b/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_208.json deleted file mode 100644 index fa6fd473520..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_208.json +++ /dev/null @@ -1,139 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.", - "from": "now-9m", - "index": [ - "logs-system.security*", - "logs-windows.forwarded*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Service Creation via Local Kerberos Authentication", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Service Creation via Local Kerberos Authentication\n\nKerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.\n- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.\n- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.\n- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.\n- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.\n- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.\n- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.\n- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.\n- Terminate any suspicious services created during the incident to halt potential malicious activities.\n- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.\n- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.\n- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.\n- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.", - "query": "sequence by winlog.computer_name with maxspan=5m\n [authentication where\n\n /* event 4624 need to be logged */\n event.action == \"logged-in\" and event.outcome == \"success\" and\n\n /* authenticate locally using relayed kerberos Ticket */\n winlog.event_data.AuthenticationPackageName :\"Kerberos\" and winlog.logon.type == \"Network\" and\n cidrmatch(source.ip, \"127.0.0.0/8\", \"::1\") and source.port > 0] by winlog.event_data.TargetLogonId\n\n [any where\n /* event 4697 need to be logged */\n event.action : \"service-installed\"] by winlog.event_data.SubjectLogonId\n", - "references": [ - "https://github.com/Dec0ne/KrbRelayUp", - "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html", - "https://github.com/cube0x0/KrbRelay", - "https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82" - ], - "related_integrations": [ - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "windows", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.ip", - "type": "ip" - }, - { - "ecs": true, - "name": "source.port", - "type": "long" - }, - { - "ecs": false, - "name": "winlog.computer_name", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.AuthenticationPackageName", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.SubjectLogonId", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.event_data.TargetLogonId", - "type": "keyword" - }, - { - "ecs": false, - "name": "winlog.logon.type", - "type": "unknown" - } - ], - "risk_score": 73, - "rule_id": "e4e31051-ee01-4307-a6ee-b21b186958f4", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "Tactic: Credential Access", - "Use Case: Active Directory Monitoring", - "Data Source: Active Directory", - "Data Source: Windows Security Event Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.003", - "name": "Windows Service", - "reference": "https://attack.mitre.org/techniques/T1543/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1558", - "name": "Steal or Forge Kerberos Tickets", - "reference": "https://attack.mitre.org/techniques/T1558/" - } - ] - } - ], - "type": "eql", - "version": 208 - }, - "id": "e4e31051-ee01-4307-a6ee-b21b186958f4_208", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e8ea6f58-0040-11f0-a243-f661ea17fbcd_4.json b/packages/security_detection_engine/kibana/security_rule/e8ea6f58-0040-11f0-a243-f661ea17fbcd_4.json new file mode 100644 index 00000000000..a8049a14c57 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e8ea6f58-0040-11f0-a243-f661ea17fbcd_4.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by the \"user.name\" for the first time.", + "false_positives": [ + "Legitimate users may export DynamoDB tables for various reasons, such as data analysis or backup purposes. Ensure that the user has the necessary permissions and that the ExportTableToPointInTime operation is authorized before taking action." + ], + "from": "now-6m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS DynamoDB Table Exported to S3", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": " ## Triage and analysis\n\n### Investigating AWS DynamoDB Table Exported to S3\n\nThis rule identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs.\n\nThis is a New Terms rule that only flags when this behavior is observed for the first time.\n\n#### Possible Investigation Steps\n- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the export. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user.\n- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access.\n- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key has been compromised.\n- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the ExportTableToPointInTime request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being exported.\n\n### False Positive Analysis\n- Historical User Actions: If the user has a history of exporting DynamoDB tables for legitimate purposes, this may be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions.\n- Automated Processes: Some automated processes or applications may perform exports on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may be a false positive.\n\n### Response and Remediation\n- Immediate Review and Reversal: If the ExportTableToPointInTime action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's access keys or removing their permissions.\n- Investigate Compromise: If the ExportTableToPointInTime action is determined to be malicious, investigate the source and destination of the request and any potential compromise of the user's account. If the destination S3 bucket is not known, it may be a sign of data exfiltration and may require incident response.\n- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources.\n- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts.\n\n### Additional Information\n\nFor further guidance on managing and securing DynamoDB in AWS environments, refer to the [AWS DynamoDB documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html) and AWS best practices for security.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"dynamodb.amazonaws.com\"\n and event.action: \"ExportTableToPointInTime\"\n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "e8ea6f58-0040-11f0-a243-f661ea17fbcd", + "setup": "DynamoDB data events must be enabled in CloudTrail to capture the ExportTableToPointInTime actions. Ensure that the AWS CloudTrail service is configured to log data events for DynamoDB tables.", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS DynamoDB", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Exfiltration" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1567", + "name": "Exfiltration Over Web Service", + "reference": "https://attack.mitre.org/techniques/T1567/", + "subtechnique": [ + { + "id": "T1567.002", + "name": "Exfiltration to Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1567/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 4 + }, + "id": "e8ea6f58-0040-11f0-a243-f661ea17fbcd_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_1.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_1.json deleted file mode 100644 index 4e30993c253..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential PowerShell Obfuscation via String Reordering", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n| WHERE powershell.file.script_block_text LIKE \"*{0}*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count > 3\n", - "related_integrations": [ - { - "package": "windows", - "version": "^2.5.0" - } - ], - "risk_score": 21, - "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f541ca3a-5752-11f0-b44b-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/f541ca3a-5752-11f0-b44b-f661ea17fbcd_1.json new file mode 100644 index 00000000000..33015365812 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f541ca3a-5752-11f0-b44b-f661ea17fbcd_1.json @@ -0,0 +1,167 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs.", + "false_positives": [ + "Legitimate administrative or security assessment activities may use these user-agents, especially in environments where TeamFiltration is employed for authorized audits. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user-agents or IP addresses.", + "Expected red team assessments or penetration tests may utilize TeamFiltration to evaluate the security posture of Azure or Microsoft 365 environments. If this is expected behavior, consider adjusting the rule or adding exceptions for specific IP addresses, registered applications, JWT tokens, PRTs or user" + ], + "from": "now-9m", + "index": [ + "filebeat-*", + "logs-azure.signinlogs-*", + "logs-o365.audit-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "TeamFiltration User-Agents Detected", + "note": "## Triage and analysis\n\nIdentifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs.\n\nThe detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including:\n\n- Azure Graph API Activity Logs\n- Microsoft 365 Audit Logs\n- Entra ID Sign-in Logs\n- Entra ID Audit Logs\n- Azure Activity Logs\n\n### Possible investigation steps\n\n- Confirm the tool used via `user_agent.original`.\n- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts.\n- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration.\n- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs.\n- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious?\n- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway.\n- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit.\n\n### False positive analysis\n\n- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization.\n\n### Response and remediation\n\n- If confirmed malicious:\n - Identify successful sign-in attempts or API calls made by the user or app.\n - Revoke active sessions or tokens associated with the identified user/app.\n - Disable the account or rotate credentials immediately.\n - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges.\n - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried.\n - Enable Conditional Access policies to require MFA for API and CLI-based access.\n - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads.\n\n- If legitimate:\n - Document the source or user (e.g., red team operation, security tool).\n - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows.\n\n", + "query": "event.dataset:(\"azure.signinlogs\" or \"o365.audit\")\n and ((user_agent.name:\"Electron\" and user_agent.os.name:\"Windows\" and user_agent.version:\"8.5.1\") or\n user_agent.original:\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36\")\n", + "references": [ + "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign", + "https://github.com/Flangvik/TeamFiltration" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.22.0" + }, + { + "package": "o365", + "version": "^2.11.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.os.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.version", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "f541ca3a-5752-11f0-b44b-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1069", + "name": "Permission Groups Discovery", + "reference": "https://attack.mitre.org/techniques/T1069/", + "subtechnique": [ + { + "id": "T1069.003", + "name": "Cloud Groups", + "reference": "https://attack.mitre.org/techniques/T1069/003/" + } + ] + }, + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + }, + { + "id": "T1087", + "name": "Account Discovery", + "reference": "https://attack.mitre.org/techniques/T1087/", + "subtechnique": [ + { + "id": "T1087.004", + "name": "Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1087/004/" + } + ] + }, + { + "id": "T1201", + "name": "Password Policy Discovery", + "reference": "https://attack.mitre.org/techniques/T1201/" + }, + { + "id": "T1526", + "name": "Cloud Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1526/" + }, + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + }, + { + "id": "T1673", + "name": "Virtual Machine Discovery", + "reference": "https://attack.mitre.org/techniques/T1673/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "f541ca3a-5752-11f0-b44b-f661ea17fbcd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_5.json b/packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_5.json new file mode 100644 index 00000000000..e343ef26bad --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_5.json @@ -0,0 +1,121 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a New Terms rule that uses the \"cloud.account.id\", \"user.name\" and \"target.entity.id\" fields to check if the combination of the actor identity and target role name has not been seen before.", + "false_positives": [ + "Legitimate IAM administrators may attach customer-managed policies to roles for various reasons, such as granting temporary permissions or updating existing policies. Ensure that the user attaching the policy is authorized to do so and that the action is expected." + ], + "from": "now-6m", + "history_window_start": "now-14d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM Customer-Managed Policy Attached to Role by Rare User", + "new_terms_fields": [ + "cloud.account.id", + "user.name", + "target.entity.id" + ], + "note": "## Triage and analysis\n\n### Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User\n\nThis rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access.\n\n#### Possible Investigation Steps\n\n- **Identify the Initiating User and Target Role**:\n - **User Identity**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the user who initiated the policy attachment. Confirm if this user typically has permissions to modify IAM roles and if their activity is consistent with their usual responsibilities.\n - **Target Role**: Review `target.entity.id` to identify the role to which the policy was attached. Assess whether modifying this role is expected for this user or if this action is unusual in your environment.\n\n- **Analyze the Attached Policy**:\n - **Policy ARN**: Inspect the `aws.cloudtrail.request_parameters` field to identify the specific customer-managed policy attached to the role. Evaluate if this policy grants sensitive permissions, especially permissions that could enable privileged actions or data access.\n - **Policy Permissions**: Examine the policy content to determine the scope of permissions granted. Policies enabling actions like `s3:*`, `ec2:*`, or `iam:*` could be leveraged for broader access, persistence, or lateral movement.\n\n- **Review Source and User Agent Details**:\n - **Source IP and Location**: Analyze the `source.ip` and `source.geo` fields to confirm the IP address and geographic location where the policy attachment originated. Verify if this matches expected locations for the initiating user.\n - **User Agent Analysis**: Examine `user_agent.original` to determine if AWS CLI, SDK, or other tooling was used to perform this action. Tool identifiers like `aws-cli` or `boto3` may indicate automation, while others may suggest interactive sessions.\n\n- **Evaluate Anomalous Behavior Patterns**:\n - **User\u2019s Historical Activity**: Check if the initiating user has a history of attaching policies to roles. An unusual pattern in policy attachments could indicate suspicious behavior, especially if the user lacks authorization.\n - **Role Modification History**: Investigate if the targeted role is frequently modified by this or other users. Repeated, unauthorized modifications to a role could signal an attempt to maintain elevated access.\n\n- **Correlate with Related CloudTrail Events**:\n - **Other IAM or CloudTrail Activities**: Look for recent actions associated with the same user or role by reviewing `event.action` and `event.provider` to identify which AWS services were accessed. This may provide context on the user\u2019s intent or additional actions taken.\n - **Broader Suspicious Patterns**: Identify if similar anomalous events have recently occurred, potentially suggesting a coordinated or escalating attack pattern within the AWS account.\n\n### False Positive Analysis\n\n- **Authorized Administrative Actions**: IAM administrators may legitimately attach policies to roles as part of routine role management. Verify if the user is authorized and if the activity aligns with expected administrative tasks.\n- **Role-Specific Modifications**: Roles that frequently undergo policy updates may trigger this rule during standard operations. Consider monitoring for patterns or establishing known exceptions for specific users or roles where appropriate.\n\n### Response and Remediation\n\n- **Immediate Access Review**: If the policy attachment is unauthorized, consider detaching the policy and reviewing the permissions granted to the initiating user.\n- **Restrict Role Modification Permissions**: Limit which users or roles can attach policies to critical IAM roles. Apply least privilege principles to reduce the risk of unauthorized policy changes.\n- **Enhance Monitoring and Alerts**: Enable real-time alerts and monitoring on IAM policy modifications to detect similar actions promptly.\n- **Regular Policy Audits**: Conduct periodic audits of IAM policies and role permissions to ensure that unauthorized changes are quickly identified and addressed.\n\n### Additional Information\n\nFor more information on managing IAM policies and roles in AWS environments, refer to the [AWS IAM Documentation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) and AWS security best practices.\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"AttachRolePolicy\"\n and event.outcome: \"success\"\n and not related.entity: arn\\:aws\\:iam\\:\\:aws\\:policy*\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "related.entity", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f6d07a70-9ad0-11ef-954f-f661ea17fbcd", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Resources: Investigation Guide", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/", + "subtechnique": [ + { + "id": "T1548.005", + "name": "Temporary Elevated Cloud Access", + "reference": "https://attack.mitre.org/techniques/T1548/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 5 + }, + "id": "f6d07a70-9ad0-11ef-954f-f661ea17fbcd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_6.json b/packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_6.json new file mode 100644 index 00000000000..7503ba4447f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_6.json @@ -0,0 +1,127 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption.", + "false_positives": [ + "Users may legitimately access AWS Systems Manager (SSM) parameters using the GetParameter, GetParameters, or DescribeParameters API actions with credentials in the request parameters. Ensure that the user has a legitimate reason to access the parameters and that the credentials are secured." + ], + "from": "now-6m", + "history_window_start": "now-10d", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS Systems Manager SecureString Parameter Request with Decryption Flag", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": "## Triage and analysis\n\n### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag\n\nThis rule detects when an AWS resource accesses SecureString parameters within AWS Systems Manager (SSM) with the decryption flag set to true. SecureStrings are encrypted using a KMS key, and accessing these with decryption can indicate attempts to access sensitive data.\n\nAdversaries may target SecureStrings to retrieve sensitive information such as encryption keys, passwords, and other credentials that are stored securely. Accessing these parameters with decryption enabled is particularly concerning because it implies the adversary is attempting to bypass the encryption to obtain plain text values that can be immediately used or exfiltrated. This behavior might be part of a larger attack strategy aimed at escalating privileges or moving laterally within an environment to access protected data or critical infrastructure.\n\n#### Possible Investigation Steps\n\n- **Review the Access Event**: Identify the specific API call (`GetParameter` or `GetParameters`) that triggered the rule. Examine the `request_parameters` for `withDecryption` set to true and the name of the accessed parameter.\n- **Verify User Identity and Access Context**: Check the `aws.cloudtrail.user_identity` details to understand who accessed the parameter and their role within the organization. This includes checking the ARN and access key ID to determine if the access was authorized.\n - **User ID**: Review the `user.name` field to identify the specific user or role that initiated the API call. Note that the ARN associated may be an assumed role and may not directly correspond to a human user.\n- **Contextualize with User Behavior**: Assess whether the access pattern fits the user\u2019s normal behavior or job responsibilities. Investigate any out-of-pattern activities around the time of the event.\n- **Analyze Geographic and IP Context**: Using the `source.ip` and `source.geo` information, verify if the request came from a trusted location or if there are any anomalies that suggest a compromised account.\n- **Inspect Related CloudTrail Events**: Look for other related events in CloudTrail to see if there was unusual activity before or after this event, such as unusual login attempts, changes to permissions, or other API calls that could indicate broader unauthorized actions.\n\n### False Positive Analysis\n\n- **Legitimate Administrative Use**: Verify if the decryption of SecureString parameters is a common practice for the user\u2019s role, particularly if used in automation scripts or deployment processes like those involving Terraform or similar tools.\n- **Authorized Access**: Ensure that the user or role has a legitimate reason to access the SecureString parameters and that the access is part of their expected job responsibilities.\n\n### Response and Remediation\n\n- **Immediate Verification**: Contact the user or team responsible for the API call to verify their intent and authorization.\n- **Review and Revise Permissions**: If the access was unauthorized, review the permissions assigned to the user or role to ensure they align with the principle of least privilege.\n- **Audit Parameter Access Policies**: Ensure that policies governing access to SecureString parameters are strict and audit logs are enabled to track access with decryption.\n- **Incident Response**: If suspicious activity is confirmed, follow through with your organization's incident response plan to mitigate any potential security issues.\n- **Enhanced Monitoring and Alerting**: Strengthen monitoring rules to detect unusual accesses to SecureString parameters, especially those that involve decryption.\n\n### Additional Information\n\nThis rule focuses solely on SecureStrings in AWS Systems Manager (SSM) parameters. SecureStrings are encrypted using an AWS Key Management Service (KMS) key. When a user accesses a SecureString parameter, they can specify whether the parameter should be decrypted. If the user specifies that the parameter should be decrypted, the decrypted value is returned in the response.\n", + "query": "event.dataset: aws.cloudtrail\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: (GetParameters or GetParameter)\n and event.outcome: success\n and aws.cloudtrail.flattened.request_parameters.withDecryption: true\n and not source.address: (\n \"cloudformation.amazonaws.com\" or\n \"servicecatalog.amazonaws.com\"\n )\n", + "references": [ + "https://docs.aws.amazon.com/vsts/latest/userguide/systemsmanager-getparameter.html", + "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.flattened.request_parameters.withDecryption", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "fd332492-0bc6-11ef-b5be-f661ea17fbcc", + "setup": "This rule requires that AWS CloudTrail logs are ingested into the Elastic Stack. Ensure that the AWS integration is properly configured to collect AWS CloudTrail logs. This rule also requires event logging for AWS Systems Manager (SSM) API actions which can be enabled in CloudTrail's data events settings.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Systems Manager", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1555", + "name": "Credentials from Password Stores", + "reference": "https://attack.mitre.org/techniques/T1555/", + "subtechnique": [ + { + "id": "T1555.006", + "name": "Cloud Secrets Management Stores", + "reference": "https://attack.mitre.org/techniques/T1555/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 6 + }, + "id": "fd332492-0bc6-11ef-b5be-f661ea17fbcc_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_420.json b/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_420.json deleted file mode 100644 index b84d51b4ed9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_420.json +++ /dev/null @@ -1,181 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe", - "filters": [ - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.args": { - "case_insensitive": true, - "value": "?:\\\\Windows\\\\system32\\\\silcollector.cmd" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.command_line": { - "case_insensitive": true, - "value": "*?:\\\\Program Files\\\\Npcap\\\\CheckStatus.bat*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.command_line": { - "case_insensitive": true, - "value": "*?:\\\\Program Files*\\\\Pulseway\\\\watchdog.bat*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.command_line": { - "case_insensitive": true, - "value": "cmd /C \".\\\\inetsrv\\\\iissetup.exe /keygen \"" - } - } - } - } - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "logs-endpoint.events.process-*", - "winlogbeat-*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "endgame-*", - "logs-system.security*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Svchost spawning Cmd", - "new_terms_fields": [ - "host.id", - "process.command_line", - "user.id" - ], - "note": "## Triage and analysis\n\n### Investigating Svchost spawning Cmd\n\nThe Service Host process (SvcHost) is a system process that can host one, or multiple, Windows services in the Windows NT family of operating systems. Note that `Svchost.exe` is reserved for use by the operating system and should not be used by non-Windows services.\n\nThis rule looks for the creation of the `cmd.exe` process with `svchost.exe` as its parent process. This is an unusual behavior that can indicate the masquerading of a malicious process as `svchost.exe` or exploitation for privilege escalation.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "host.os.type:windows and event.category:process and event.type:start and process.parent.name:\"svchost.exe\" and\nprocess.name:(\"cmd.exe\" or \"Cmd.exe\" or \"CMD.EXE\") and\nnot process.command_line : \"\\\"cmd.exe\\\" /C sc control hptpsmarthealthservice 211\"\n", - "references": [ - "https://nasbench.medium.com/demystifying-the-svchost-exe-process-and-its-command-line-options-508e9114e747" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "m365_defender", - "version": "^2.0.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "fd7a6052-58fa-4397-93c3-4795249ccfa2", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Execution", - "Resources: Investigation Guide", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Windows Security Event Logs", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Sysmon", - "Data Source: SentinelOne" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/" - } - ] - } - ], - "timeline_id": "e70679c2-6cde-4510-9764-4823df18f7db", - "timeline_title": "Comprehensive Process Timeline", - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 420 - }, - "id": "fd7a6052-58fa-4397-93c3-4795249ccfa2_420", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 59e8e60cff1..869419307ed 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.8 +version: 9.0.9-beta.1 From d357ec6e23adee7d16280c4ab187e0d46b19440d Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 22 Jul 2025 09:37:51 -0400 Subject: [PATCH 05/13] [Security Rules] Update security rules package to v9.0.9-beta.2 (#14642) --- packages/security_detection_engine/changelog.yml | 5 +++++ ...1.json => 498e4094-60e7-11f0-8847-f661ea17fbcd_2.json} | 8 ++++---- packages/security_detection_engine/manifest.yml | 2 +- 3 files changed, 10 insertions(+), 5 deletions(-) rename packages/security_detection_engine/kibana/security_rule/{498e4094-60e7-11f0-8847-f661ea17fbcd_1.json => 498e4094-60e7-11f0-8847-f661ea17fbcd_2.json} (68%) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 5b0d029b6a9..a2479055d35 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.9-beta.2 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14642 - version: 9.0.9-beta.1 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_2.json similarity index 68% rename from packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json rename to packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_2.json index fac2036bc3d..014fe1c0243 100644 --- a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_1.json +++ b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_2.json @@ -9,7 +9,7 @@ "license": "Elastic License v2", "name": "OIDC Discovery URL Changed in Entra ID", "note": "## Triage and analysis\n\n### Investigating OIDC Discovery URL Changed in Entra ID\n\nThis rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity.\n\n### Possible investigation steps\n- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.\n- Examine the `old_oidc_discovery` and `new_oidc_discovery` to confirm if the new `discoveryUrl` points to an unexpected or untrusted IdP.\n- Check that the discovery URLs have `.well-known/openid-configuration` endpoints, which are standard for OIDC providers.\n- Use `azure.auditlogs.properties.correlation_id` to pivot to related changes and activity from the same session.\n- Review any subsequent sign-in activity that may have originated from the new IdP.\n- Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity.\n\n### False positive analysis\n- Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements.\n- Validate any changes with the identity or security operations team before taking action.\n\n### Response and remediation\n- If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal.\n- Revoke tokens or sessions issued after the configuration change.\n- Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app).\n- Apply conditional access policies and change control procedures to protect IdP configuration changes.\n", - "query": "FROM logs-azure.auditlogs-*\n| WHERE event.action == \"Authentication Methods Policy Update\"\n| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, \"\\\\\\\\\", \"\")\n| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, \"\\\\\\\\\", \"\")\n| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new}\\\"}%{}\"\n| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old}\\\"}%{}\"\n| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new IS NOT NULL and Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old IS NOT NULL\n| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new != Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old\n| KEEP\n @timestamp,\n event.action,\n event.outcome,\n azure.tenant_id,\n azure.correlation_id,\n azure.auditlogs.properties.activity_datetime,\n azure.auditlogs.properties.operation_type,\n azure.auditlogs.properties.initiated_by.user.userPrincipalName,\n azure.auditlogs.properties.initiated_by.user.displayName,\n azure.auditlogs.properties.initiated_by.user.ipAddress,\n source.geo.city_name,\n source.geo.region_name,\n source.geo.country_name,\n Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new,\n Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old\n", + "query": "FROM logs-azure.auditlogs-* metadata _id, _version, _index\n| WHERE event.action == \"Authentication Methods Policy Update\"\n| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, \"\\\\\\\\\", \"\")\n| EVAL Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace = REPLACE(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, \"\\\\\\\\\", \"\")\n| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.new_value.replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new}\\\"}%{}\"\n| DISSECT Esql.azure.auditlogs.properties.target_resources.modified_properties.old_value.replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old}\\\"}%{}\"\n| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new IS NOT NULL and Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old IS NOT NULL\n| WHERE Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new != Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old\n| KEEP\n @timestamp,\n event.action,\n event.outcome,\n azure.tenant_id,\n azure.correlation_id,\n azure.auditlogs.properties.activity_datetime,\n azure.auditlogs.properties.operation_type,\n azure.auditlogs.properties.initiated_by.user.userPrincipalName,\n azure.auditlogs.properties.initiated_by.user.displayName,\n azure.auditlogs.properties.initiated_by.user.ipAddress,\n source.geo.city_name,\n source.geo.region_name,\n source.geo.country_name,\n Esql.azure.auditlogs.properties.auth.oidc.discovery.url.new,\n Esql.azure.auditlogs.properties.auth.oidc.discovery.url.old\n", "references": [ "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/" ], @@ -51,9 +51,9 @@ } ], "timestamp_override": "event.ingested", - "type": "query", - "version": 1 + "type": "esql", + "version": 2 }, - "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_1", + "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_2", "type": "security-rule" } \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 869419307ed..a67711ba4f9 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.9-beta.1 +version: 9.0.9-beta.2 From 49abc0a7adf744b92efd73210ef88dbae9aed3ba Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 22 Jul 2025 13:40:38 -0400 Subject: [PATCH 06/13] [Security Rules] Update security rules package to v9.0.9-beta.3 (#14651) --- .../security_detection_engine/changelog.yml | 5 +++ ...c53838-5dcd-11f0-829c-f661ea17fbcd_2.json} | 40 +++++++++++++++++-- .../security_detection_engine/manifest.yml | 2 +- 3 files changed, 43 insertions(+), 4 deletions(-) rename packages/security_detection_engine/kibana/security_rule/{75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json => 75c53838-5dcd-11f0-829c-f661ea17fbcd_2.json} (89%) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index a2479055d35..b83beb5fd7b 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.9-beta.3 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14651 - version: 9.0.9-beta.2 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_2.json similarity index 89% rename from packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json rename to packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_2.json index 5750cb08d45..c07689f17f9 100644 --- a/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_1.json +++ b/packages/security_detection_engine/kibana/security_rule/75c53838-5dcd-11f0-829c-f661ea17fbcd_2.json @@ -15,7 +15,7 @@ "filebeat-*", "logs-azure.platformlogs-*" ], - "language": "esql", + "language": "kuery", "license": "Elastic License v2", "name": "Azure Key Vault Secret Key Usage by Unusual Identity", "new_terms_fields": [ @@ -27,6 +27,40 @@ "references": [ "https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html" ], + "related_integrations": [ + { + "integration": "platformlogs", + "package": "azure", + "version": "^1.22.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.platformlogs.identity.claim.upn", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.platformlogs.properties.id", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], "risk_score": 43, "rule_id": "75c53838-5dcd-11f0-829c-f661ea17fbcd", "setup": "#### Required Azure Key Vault Diagnostic Logs\n\nTo ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:\n- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.\n", @@ -69,8 +103,8 @@ ], "timestamp_override": "event.ingested", "type": "new_terms", - "version": 1 + "version": 2 }, - "id": "75c53838-5dcd-11f0-829c-f661ea17fbcd_1", + "id": "75c53838-5dcd-11f0-829c-f661ea17fbcd_2", "type": "security-rule" } \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index a67711ba4f9..d5f071e933d 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.9-beta.2 +version: 9.0.9-beta.3 From c50714d2bf02bddac9b82827d268d664b73788e9 Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 22 Jul 2025 14:57:31 -0400 Subject: [PATCH 07/13] [Security Rules] Update security rules package to v9.0.9 (#14656) --- packages/security_detection_engine/changelog.yml | 5 +++++ packages/security_detection_engine/manifest.yml | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index b83beb5fd7b..b75caf6f5b7 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.9 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14656 - version: 9.0.9-beta.3 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index d5f071e933d..1c4f4dac9ec 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.9-beta.3 +version: 9.0.9 From f17f11dec125cff8a421bd188ad78d62d2d038df Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 5 Aug 2025 01:45:40 -0400 Subject: [PATCH 08/13] [Security Rules] Update security rules package to v9.0.10-beta.1 (#14802) --- .../security_detection_engine/changelog.yml | 5 + ...f6b23-3799-445e-9589-0018328a9e46_206.json | 125 ++++++++++++++++++ ...fa350e0-0aa2-4055-bf8f-ab8b59233e59_1.json | 53 -------- ...18264-2d6d-11ef-9413-f661ea17fbce_103.json | 77 ----------- ...5e7fee6-fc25-11ee-ba0f-f661ea17fbce_2.json | 107 --------------- ...64c641e-c202-11ef-993e-f661ea17fbce_3.json | 111 ---------------- ...52c19-ff3e-42fd-8363-7be14d7c5469_208.json | 121 ----------------- ...6e1bc-867a-11ee-b13e-f661ea17fbcd_303.json | 62 --------- ...211e8-4e2f-440f-86d8-06cc8f158cfa_212.json | 102 -------------- ...fac01b2-b811-11ef-b25b-f661ea17fbce_3.json | 66 +++++++++ ...841b80f-a1f8-4c00-a966-d2cc4a7a82e4_1.json | 91 +++++++++++++ ...96015ef-718e-40ff-ac4a-cc2ba88dbeeb_4.json | 104 --------------- ...a309864-fc3f-11ee-b8cc-f661ea17fbce_3.json | 95 ------------- ...b341d03-1d63-41ac-841a-2009c86959ca_1.json | 53 -------- ...0558fd5-6448-4c65-804a-8567ce02c3a2_1.json | 89 +++++++++++++ ...20fc1aa-e195-4a1d-81d8-04edfe5313ed_1.json | 89 +++++++++++++ ...4147312-ba03-4bea-91d1-040d54c1e8c3_1.json | 89 +++++++++++++ ...7122db4-5876-4127-b91b-6c179eb21f88_1.json | 92 ------------- ...dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_104.json | 89 ------------- ...60f2a03-a1cf-48d6-a674-c6d62ae608a1_1.json | 53 -------- ...a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_1.json | 99 -------------- ...eeeda11-dca6-4c3e-910f-7089db412d1c_1.json | 57 -------- ...09bf7c8-d371-11ef-bcc3-f661ea17fbcd_1.json | 105 --------------- ...e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_206.json | 101 -------------- ...734c0-2cda-11ef-84e1-f661ea17fbce_103.json | 77 ----------- ...99adc-2cda-11ef-84e1-f661ea17fbce_103.json | 77 ----------- ...76b2391-413f-4a94-acb4-7911f3803346_1.json | 99 -------------- ...aa4be8d-5828-417d-9f54-7cd304571b24_3.json | 86 ------------ ...b35422b-9102-45a9-8610-2e0c22281c55_1.json | 89 +++++++++++++ ...326d7-dca7-4fb7-93eb-1ca03a1febbd_211.json | 97 -------------- ...b8f074c-5565-4bc4-991c-d49770e19fc9_2.json | 58 -------- ...eebe561-c338-4118-9924-8cb4e478aa58_1.json | 89 +++++++++++++ ...1a9ed70-d349-11ef-841c-f661ea17fbcd_1.json | 123 ----------------- ...1e79a70-fa6f-11ee-8bc8-f661ea17fbce_4.json | 122 ----------------- ...5637438-e32d-4bb3-bc13-bd7932b3289f_1.json | 92 ------------- ...82a2e-7e52-11ee-9aac-f661ea17fbcd_204.json | 55 -------- ...3b6222f-537e-4b84-956a-3ebae2dcf811_1.json | 89 +++++++++++++ ...de13d58-bc39-4aa0-87fd-b4bdbf4591da_2.json | 86 ------------ ...f919b5e-a0f6-4fd8-8598-e3ce79299e3b_2.json | 86 ------------ ...43b7578-f3cc-4682-a8cf-f9d8a5fb07f1_1.json | 77 +++++++++++ ...0cc239b-67fa-46fc-89d4-f861753a40f5_3.json | 57 ++++++++ ...3e68a4-bd19-11ed-b02f-f661ea17fbcc_11.json | 108 +++++++++++++++ ...6d07a70-9ad0-11ef-954f-f661ea17fbcd_2.json | 121 ----------------- ...d332492-0bc6-11ef-b5be-f661ea17fbcc_3.json | 109 --------------- .../security_detection_engine/manifest.yml | 2 +- 45 files changed, 1064 insertions(+), 2770 deletions(-) create mode 100644 packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_206.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_103.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_208.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_303.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_212.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/5841b80f-a1f8-4c00-a966-d2cc4a7a82e4_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/70558fd5-6448-4c65-804a-8567ce02c3a2_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/74147312-ba03-4bea-91d1-040d54c1e8c3_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_104.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_206.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_103.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_103.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9b35422b-9102-45a9-8610-2e0c22281c55_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_211.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/aeebe561-c338-4118-9924-8cb4e478aa58_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_204.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d3b6222f-537e-4b84-956a-3ebae2dcf811_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e43b7578-f3cc-4682-a8cf-f9d8a5fb07f1_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_11.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_3.json diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index b75caf6f5b7..a293a9a632f 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.10-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14802 - version: 9.0.9 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_206.json b/packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_206.json new file mode 100644 index 00000000000..9dd695aabf3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_206.json @@ -0,0 +1,125 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the execution of scripts via HTML applications using Windows utilities rundll32.exe or mshta.exe. Adversaries may bypass process and/or signature-based defenses by proxying execution of malicious content with signed binaries.", + "from": "now-9m", + "index": [ + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Script Execution via Microsoft HTML Application", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Script Execution via Microsoft HTML Application\n\nMicrosoft HTML Applications (HTA) allow scripts to run in a trusted environment, often using utilities like `rundll32.exe` or `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns, such as unusual command lines or execution from common download locations, to flag potential abuse.\n\n### Possible investigation steps\n\n- Review the process command line details to identify any suspicious patterns or indicators of malicious activity, such as the presence of script execution commands like \"eval\", \"GetObject\", or \"WScript.Shell\".\n- Check the parent process executable path to determine if the process was spawned by a known legitimate application or if it deviates from expected behavior, especially if it is not from the specified exceptions like Citrix, Microsoft Office, or Quokka.Works GTInstaller.\n- Investigate the origin of the HTA file, particularly if it was executed from common download locations like the Downloads folder or temporary archive extraction paths, to assess if it was downloaded from the internet or extracted from an archive.\n- Analyze the process arguments and count to identify any unusual or unexpected parameters that could indicate malicious intent, especially if the process name is \"mshta.exe\" and the command line does not include typical HTA or HTM file references.\n- Correlate the event with other security logs and alerts from data sources like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and determine if this activity is part of a broader attack pattern.\n\n### False positive analysis\n\n- Execution of legitimate scripts by enterprise applications like Citrix, Microsoft Office, or Quokka.Works GTInstaller can trigger false positives. Users can mitigate this by adding these applications to the exclusion list in the detection rule.\n- Scripts executed by mshta.exe that do not involve malicious intent, such as internal web applications or administrative scripts, may be flagged. Users should review these scripts and, if deemed safe, exclude them based on specific command line patterns or parent processes.\n- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users can create exceptions for these sources by specifying trusted download paths or file hashes.\n- Temporary files created by legitimate software installations or updates in user temp directories can be misinterpreted as malicious. Users should monitor these activities and exclude known safe processes or directories from the detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further spread of the malicious script or unauthorized access.\n- Terminate any suspicious processes identified by the detection rule, specifically those involving `rundll32.exe` or `mshta.exe` with unusual command lines.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts.\n- Review and analyze the command lines and scripts executed to understand the scope and intent of the attack, and identify any additional compromised systems.\n- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated.\n- Implement network segmentation to limit the ability of similar threats to propagate across the network in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : (\"rundll32.exe\", \"mshta.exe\") and\n (\n (process.command_line :\n (\n \"*script*eval(*\",\n \"*script*GetObject*\",\n \"*.regread(*\",\n \"*WScript.Shell*\",\n \"*.run(*\",\n \"*).Exec()*\",\n \"*mshta*http*\",\n \"*mshtml*RunHTMLApplication*\",\n \"*mshtml*,#135*\",\n \"*StrReverse*\",\n \"*.RegWrite*\",\n /* Issue #379 */\n \"*window.close(*\",\n \"* Chr(*\"\n )\n and not process.parent.executable :\n (\"?:\\\\Program Files (x86)\\\\Citrix\\\\System32\\\\wfshell.exe\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\Office*\\\\MSACCESS.EXE\",\n \"?:\\\\Program Files\\\\Quokka.Works GTInstaller\\\\GTInstaller.exe\")\n ) or\n\n (process.name : \"mshta.exe\" and\n not process.command_line : (\"*.hta*\", \"*.htm*\", \"-Embedding\") and ?process.args_count >=2) or\n\n /* Execution of HTA file downloaded from the internet */\n (process.name : \"mshta.exe\" and process.command_line : \"*\\\\Users\\\\*\\\\Downloads\\\\*.hta*\") or\n\n /* Execution of HTA file from archive */\n (process.name : \"mshta.exe\" and\n process.args : (\"?:\\\\Users\\\\*\\\\Temp\\\\7z*\", \"?:\\\\Users\\\\*\\\\Temp\\\\Rar$*\", \"?:\\\\Users\\\\*\\\\Temp\\\\Temp?_*\", \"?:\\\\Users\\\\*\\\\Temp\\\\BNZ.*\"))\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "181f6b23-3799-445e-9589-0018328a9e46", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Windows Security Event Logs", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1218", + "name": "System Binary Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1218/", + "subtechnique": [ + { + "id": "T1218.005", + "name": "Mshta", + "reference": "https://attack.mitre.org/techniques/T1218/005/" + }, + { + "id": "T1218.011", + "name": "Rundll32", + "reference": "https://attack.mitre.org/techniques/T1218/011/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 206 + }, + "id": "181f6b23-3799-445e-9589-0018328a9e46_206", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_1.json b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_1.json deleted file mode 100644 index b0014900f91..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_1.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "High Number of Egress Network Connections from Unusual Executable", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and (\n (\n process.executable like \"/tmp/*\" or\n process.executable like \"/var/tmp/*\" or\n process.executable like \"/dev/shm/*\"\n ) or\n (process.name like \".*\")\n) and not (\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable like \"/nix/store/*\" or\n process.executable like \"/tmp/newroot/*\" or\n process.executable like \"/tmp/.mount*\" or\n process.executable like \"/tmp/go-build*\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.executable\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 47, - "rule_id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_103.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_103.json deleted file mode 100644 index 3ca0885f21f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_103.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", - "false_positives": [ - "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", - "Shared systems such as Kiosks and conference room computers may be used by multiple users." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "High Number of Okta Device Token Cookies Generated for Authentication", - "note": "## Triage and analysis\n\n### Investigating High Number of Okta Device Token Cookies Generated for Authentication\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.request_uri == \"/api/v1/authn\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count >= 30\n| SORT\n source_auth_count DESC\n", - "references": [ - "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 21, - "rule_id": "23f18264-2d6d-11ef-9413-f661ea17fbce", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - }, - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.004", - "name": "Credential Stuffing", - "reference": "https://attack.mitre.org/techniques/T1110/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 103 - }, - "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_2.json deleted file mode 100644 index 5353fd58896..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/25e7fee6-fc25-11ee-ba0f-f661ea17fbce_2.json +++ /dev/null @@ -1,107 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access.", - "false_positives": [ - "Administrators may legitimately add security group rules to allow traffic from any IP address or from specific IP addresses to common remote access ports." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "Insecure AWS EC2 VPC Security Group Ingress Rule Added", - "note": "## Triage and analysis\n\n### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added\n\nThis rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Investigate whether this actor has the necessary permissions and typically performs these actions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent.\n- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management.\n- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing security group rules and securing AWS environments, refer to the [Amazon VPC Security Groups documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) and AWS best practices for security.\n\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: ec2.amazonaws.com\n and event.action: AuthorizeSecurityGroupIngress\n and event.outcome: success\n and aws.cloudtrail.flattened.request_parameters.cidrIp: (\"0.0.0.0/0\" or \"::/0\")\n and aws.cloudtrail.flattened.request_parameters.fromPort: (\n 21 or 22 or 23 or 445 or 3389 or 5985 or 5986)\n", - "references": [ - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html", - "https://www.linkedin.com/pulse/my-backdoors-your-aws-infrastructure-part-3-network-micha%C5%82-brygidyn/" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.cidrIp", - "type": "unknown" - }, - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.fromPort", - "type": "unknown" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "25e7fee6-fc25-11ee-ba0f-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS EC2", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1562", - "name": "Impair Defenses", - "reference": "https://attack.mitre.org/techniques/T1562/", - "subtechnique": [ - { - "id": "T1562.007", - "name": "Disable or Modify Cloud Firewall", - "reference": "https://attack.mitre.org/techniques/T1562/007/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 2 - }, - "id": "25e7fee6-fc25-11ee-ba0f-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_3.json deleted file mode 100644 index 24ab7219a82..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/264c641e-c202-11ef-993e-f661ea17fbce_3.json +++ /dev/null @@ -1,111 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary whom is looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicate breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks.", - "false_positives": [ - "Legitimate use of deprecated AMIs for testing or development purposes.", - "Automated tools or scripts that query for deprecated AMIs as part of a security assessment.", - "Misconfigured applications or services that rely on deprecated AMIs for compatibility reasons.", - "Administrators or developers who are unaware of the deprecation status of AMIs they are using." - ], - "from": "now-9m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.user_identity.access_key_id", - "source.ip", - "cloud.account.id", - "cloud.region", - "user_agent.original", - "event.action" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Deprecated AMI Discovery", - "note": "## Triage and analysis\n\n## Investigating AWS EC2 Deprecated AMI Discovery\n\nThis rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations.\n\n### Possible Investigation Steps\n\n1. **Identify the User Performing the Query**:\n - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request.\n - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity).\n - Investigate the `related.user` field for additional user context.\n\n2. **Analyze the Source of the Request**:\n - Review the `source.ip` field to determine the IP address of the source making the request.\n - Check `source.geo` for the geographic location of the IP address.\n - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK).\n\n3. **Review the Request Details**:\n - Inspect the `aws.cloudtrail.flattened.request_parameters` field for query parameters, such as `includeDeprecated=true`.\n - Confirm that the request explicitly includes deprecated AMIs (`includeDeprecated=true`) and is tied to specific owners via the `ownersSet` field.\n - Verify the `event.action` is `DescribeImages` and the `event.outcome` is `success`.\n\n4. **Validate the Query Context**:\n - Determine if the request is part of legitimate activity, such as:\n - Security assessments or vulnerability scans.\n - Maintenance or testing of legacy systems.\n - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services.\n\n5. **Correlate with Other Events**:\n - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation.\n - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call).\n\n6. **Assess Security Risks**:\n - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities.\n - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats.\n\n### False Positive Analysis\n\n- **Legitimate Use**: Users may query for deprecated AMIs for testing or compatibility purposes.\n- **Automated Tools**: Security or compliance tools might query deprecated AMIs as part of regular assessments.\n- **Misconfigured Services**: Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Verify the intent of the user querying for deprecated AMIs.\n - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs.\n\n2. **Mitigation Steps**:\n - Identify and replace deprecated AMIs in use with supported and updated AMIs.\n - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future queries involving deprecated AMIs or other unusual API activity.\n - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior.\n\n4. **Security Audits**:\n - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images.\n - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing.\n\n5. **Add Rule Exceptions**:\n - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs.\n - Document and communicate the exceptions to relevant teams to avoid future alerts.\n\n### Additional Resources\n\n- [AWS Documentation: AMI Lifecycle Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)\n- [AWS Documentation: Deprecated AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html)\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action: \"DescribeImages\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.includeDeprecated: \"true\"\n and aws.cloudtrail.request_parameters: *owner=*\n", - "references": [ - "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.40.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.includeDeprecated", - "type": "unknown" - }, - { - "ecs": false, - "name": "aws.cloudtrail.request_parameters", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "264c641e-c202-11ef-993e-f661ea17fbce", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: AWS EC2", - "Resources: Investigation Guide", - "Use Case: Threat Detection", - "Tactic: Discovery" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 3 - }, - "id": "264c641e-c202-11ef-993e-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_208.json b/packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_208.json deleted file mode 100644 index 734e2ac39a4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/29052c19-ff3e-42fd-8363-7be14d7c5469_208.json +++ /dev/null @@ -1,121 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic", - "Austin Songer" - ], - "description": "Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment.", - "false_positives": [ - "A security group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-9m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "user_agent.original", - "aws.cloudtrail.flattened.request_parameters.instanceId", - "event.action", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 Security Group Configuration Change", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS EC2 Security Group Configuration Change\n\nAWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or exfiltrate data. The detection rule monitors successful modifications to security group settings, such as rule changes or new group creation, to identify potential security breaches and unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event.dataset \"aws.cloudtrail\" to identify the exact changes made to the security group configuration.\n- Examine the event.provider \"ec2.amazonaws.com\" and event.action fields to determine the type of action performed, such as \"AuthorizeSecurityGroupEgress\" or \"ModifySecurityGroupRules\", to understand the nature of the change.\n- Check the event.outcome field to confirm the success of the action and correlate it with any suspicious activity or unauthorized access attempts.\n- Investigate the IAM user or role associated with the change to verify if the action aligns with their typical behavior and permissions.\n- Analyze the timing and context of the change to see if it coincides with any other unusual activities or alerts in the AWS environment.\n- Assess the impact of the security group change on the overall security posture, including potential exposure of sensitive resources or data.\n- If necessary, consult with the responsible team or individual to validate the legitimacy of the change and ensure it was authorized.\n\n### False positive analysis\n\n- Routine administrative changes to security groups by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who regularly perform these tasks and create exceptions for their activities.\n- Automated scripts or tools used for infrastructure management may frequently modify security group settings. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers or tags.\n- Scheduled updates or deployments that involve security group modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these expected changes during specific time windows.\n- Changes made by cloud service providers as part of their maintenance or updates might be flagged. Verify these changes through official communication from the provider and consider excluding them if they are part of standard operations.\n\n### Response and remediation\n\n- Immediately isolate the affected EC2 instances by removing them from the compromised security group to prevent further unauthorized access.\n- Revert any unauthorized changes to the security group configurations by restoring them to their last known good state using AWS CloudTrail logs for reference.\n- Conduct a thorough review of IAM roles and permissions associated with the affected security groups to ensure that only authorized personnel have the ability to modify security group settings.\n- Implement additional monitoring and alerting for any future changes to security group configurations, focusing on the specific actions identified in the detection rule.\n- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related threats within the AWS environment.\n- Review and update the AWS security group policies to enforce stricter rules and minimize the attack surface, ensuring that only necessary ports and protocols are allowed.\n- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing logging and monitoring capabilities or applying stricter access controls.\n\n### Investigating AWS EC2 Security Group Configuration Change\n\nThis rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.\n\n#### Possible Investigation Steps\n\n1. **Identify the Modified Security Group**:\n - **Security Group ID**: Check the `aws.cloudtrail.flattened.request_parameters.groupId` field to identify the specific security group affected.\n - **Rule Changes**: Review `aws.cloudtrail.flattened.response_elements.securityGroupRuleSet` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.\n\n2. **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.\n - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.\n\n3. **Analyze the Configuration Change**:\n - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.\n - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.\n\n4. **Check User Agent and Source IP**:\n - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual.\n - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.\n\n5. **Evaluate for Persistence Indicators**:\n - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.\n - **Permissions Review**: Confirm that the user\u2019s IAM policies are configured to limit changes to security groups only as necessary.\n\n6. **Correlate with Other CloudTrail Events**:\n - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access.\n - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.\n\n### False Positive Analysis\n\n- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.\n- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments.\n\n### Response and Remediation\n\n- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment.\n- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.\n- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.\n- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.\n\n### Additional Information\n\nFor more details on managing AWS Security Groups and best practices, refer to the [AWS EC2 Security Groups Documentation](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html) and AWS security best practices.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action:(\n \"AuthorizeSecurityGroupEgress\" or\n \"CreateSecurityGroup\" or\n \"ModifyInstanceAttribute\" or\n \"ModifySecurityGroupRules\" or\n \"RevokeSecurityGroupEgress\" or\n \"RevokeSecurityGroupIngress\")\n and event.outcome: \"success\"\n", - "references": [ - "https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "29052c19-ff3e-42fd-8363-7be14d7c5469", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS EC2", - "Use Case: Network Security Monitoring", - "Resources: Investigation Guide", - "Tactic: Persistence", - "Tactic: Defense Evasion" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1562", - "name": "Impair Defenses", - "reference": "https://attack.mitre.org/techniques/T1562/", - "subtechnique": [ - { - "id": "T1562.007", - "name": "Disable or Modify Cloud Firewall", - "reference": "https://attack.mitre.org/techniques/T1562/007/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 208 - }, - "id": "29052c19-ff3e-42fd-8363-7be14d7c5469_208", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_303.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_303.json deleted file mode 100644 index 9834aacb26d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_303.json +++ /dev/null @@ -1,62 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", - "from": "now-30m", - "interval": "15m", - "language": "esql", - "license": "Elastic License v2", - "name": "Okta User Sessions Started from Different Geolocations", - "note": "\n## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.security_context.is_proxy != true and okta.actor.id != \"unknown\"\n AND event.outcome == \"success\"\n| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id\n| STATS\n geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)\n BY okta.actor.id, okta.actor.alternate_id\n| WHERE\n geo_auth_counts >= 2\n", - "references": [ - "https://developer.okta.com/docs/reference/api/system-log/", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 47, - "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", - "severity": "medium", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Initial Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.004", - "name": "Cloud Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 303 - }, - "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_303", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_212.json b/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_212.json deleted file mode 100644 index fc5b8fb3751..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/37b211e8-4e2f-440f-86d8-06cc8f158cfa_212.json +++ /dev/null @@ -1,102 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as `RunShellScript`, `RunPowerShellScript` or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that looks for the first instance of this behavior by the `aws.cloudtrail.user_identity.arn` field in the last 7 days.", - "false_positives": [ - "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-9m", - "history_window_start": "now-7d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS SSM `SendCommand` Execution by Rare User", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn" - ], - "note": "## Triage and analysis\n\n### Investigating AWS SSM `SendCommand` Execution by Rare User\n\nThis rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.targets` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM.\n - **Document Used**: Check the `aws.cloudtrail.flattened.request_parameters.documentName` field, which specifies the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access.\n - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior.\n\n- **Analyze Command Parameters**:\n - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities.\n - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack.\n\n- **Check User Agent and Source IP**:\n - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually.\n - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries.\n\n- **Evaluate for Persistence Indicators**:\n - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access.\n - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions.\n\n- **Correlate with Other CloudTrail Events**:\n - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.\n - **Monitor Data Access or Modification**: Correlate with `S3` access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.\n\n### False Positive Analysis\n\n- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.\n- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances.\n\n### Response and Remediation\n\n- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.\n- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.\n- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.\n- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.\n\n### Additional Information\n\nFor further details on managing AWS SSM and security best practices for EC2 instances, refer to the [AWS Systems Manager Documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) and AWS best practices.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: \"SendCommand\"\n and event.outcome: \"success\"\n and not aws.cloudtrail.user_identity.arn: *AWSServiceRoleForAmazonSSM/StateManagerService*\n and not source.address: (\n \"ssm-guiconnect.amazonaws.com\" or\n \"ssm.amazonaws.com\" or\n \"inspector2.amazonaws.com\"\n )\n", - "references": [ - "https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.40.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.arn", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.address", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS SSM", - "Use Case: Log Auditing", - "Use Case: Threat Detection", - "Tactic: Execution", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1651", - "name": "Cloud Administration Command", - "reference": "https://attack.mitre.org/techniques/T1651/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 212 - }, - "id": "37b211e8-4e2f-440f-86d8-06cc8f158cfa_212", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json new file mode 100644 index 00000000000..e12579f9cae --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code.", + "false_positives": [ + "Based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed TOTP code attempts in a short time-span over multiple sessions." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID MFA TOTP Brute Force Attempts", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID MFA TOTP Brute Force Attempts\n\nThis rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code.\n\n#### Possible Investigation Steps:\n\n - Check the source addresses associated with the failed TOTP attempts.\n - Determine if the source IP address is consistent with the user\u2019s typical login locations.\n - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user\u2019s normal activity).\n - Review the error code associated with the failed attempts. This can help identify if the failures are due to incorrect TOTP codes or other issues.\n - Verify that that auth metho reported is `OAth` as it indicates the use of TOTP codes.\n - Pivot into signin logs for the target user and check if auth via TOTP was successful which would indicate a successful brute force attempt.\n - Review conditional access policies applied to the user or group as reported by the sign-in logs.\n - Analyze the client application ID and display name to determine if the attempts are coming from a legitimate application or a potentially malicious script.\n - Adversaries may use legitimate FOCI applications to bypass security controls or make login attempts appear legitimate.\n - Review the resource ID access is being attempted against such as MyApps, Microsoft Graph, or other resources. This can help identify if the attempts are targeting specific applications or services.\n - The correlation IDs or session IDs can be used to trace the authentication attempts across different logs or systems. Note that for this specific behavior, unique session ID count is high and could be challenging to correlate.\n\n#### False Positive Analysis:\n\n - Verify if the failed attempts could result from the user\u2019s unfamiliarity with TOTP codes or issues with device synchronization.\n - Check if the user recently switched MFA methods or devices, which could explain multiple failures.\n - Determine if this is whitebox testing or a developer testing MFA integration.\n\n#### Response and Remediation:\n\n - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts.\n - Notify the user of suspicious activity and validate their access to the account.\n - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user.\n - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior.\n - Consider a different MFA method or additional security controls to prevent future bypass attempts.\n - Implement additional monitoring to track high-frequency authentication failures across the environment.\n - Audit historical logs for similar patterns involving other accounts to identify broader threats.\n - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity.\n", + "query": "from logs-azure.signinlogs* metadata _id, _version, _index\n\n| where\n // filter for Entra Sign-In Logs\n event.dataset == \"azure.signinlogs\"\n and azure.signinlogs.operation_name == \"Sign-in activity\"\n and azure.signinlogs.properties.user_type == \"Member\"\n\n // filter for MFA attempts with OATH conditional access attempts or TOTP\n and azure.signinlogs.properties.mfa_detail.auth_method == \"OATH verification code\"\n\n // filter on failures only from brute-force attempts\n and (\n (\n azure.signinlogs.result_signature == \"FAILURE\" and\n azure.signinlogs.result_description == \"Authentication failed during strong authentication request.\"\n ) or azure.signinlogs.properties.status.error_code == 500121\n )\n\n| stats\n Esql.event_count = COUNT(*),\n Esql.azure_signinlogs_properties.session_id_count_distinct = COUNT_DISTINCT(azure.signinlogs.properties.session_id),\n Esql.source_address_values = VALUES(source.address),\n Esql.azure_tenant_id_valuues = VALUES(azure.tenant_id),\n Esql_priv.azure_identity_values = VALUES(azure.signinlogs.identity),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = VALUES(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_app_id_values = VALUES(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = VALUES(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_authentication_requirement_values = VALUES(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_authentication_protocol_values = VALUES(azure.signinlogs.properties.authentication_protocol),\n Esql.azure_signinlogs_properties_client_app_used_values = VALUES(azure.signinlogs.properties.client_app_used),\n Esql.azure_signinlogs_properties_client_credential_type_values = VALUES(azure.signinlogs.properties.client_credential_type),\n Esql.azure_signinlogs_properties_conditional_access_status_values = VALUES(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_correlation_id_values = VALUES(azure.signinlogs.properties.correlation_id),\n Esql.azure_signinlogs_properties_is_interactive_values = VALUES(azure.signinlogs.properties.is_interactive),\n Esql.azure_signinlogs_properties_mfa_detail_auth_method_values = VALUES(azure.signinlogs.properties.mfa_detail.auth_method),\n Esql.azure_signinlogs_properties_resource_display_name_values = VALUES(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = VALUES(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_risk_state_values = VALUES(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_risk_detail_values = VALUES(azure.signinlogs.properties.risk_detail),\n Esql.azure_signinlogs_properties_status.error_code_values = VALUES(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_original_request_id_values = VALUES(azure.signinlogs.properties.original_request_id),\n Esql.user_id_values = VALUES(user.id)\n by user.id\n\n| where Esql.event_count >= 20 and Esql.azure_signinlogs_properties.session_id_count_distinct >= 10\n\n| keep\n Esql.event_count,\n Esql.azure_signinlogs_properties.session_id_count_distinct,\n Esql.source_address_values,\n Esql.azure_tenant_id_valuues,\n Esql_priv.azure_identity_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_authentication_protocol_values,\n Esql.azure_signinlogs_properties_client_app_used_values,\n Esql.azure_signinlogs_properties_client_credential_type_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_correlation_id_values,\n Esql.azure_signinlogs_properties_is_interactive_values,\n Esql.azure_signinlogs_properties_mfa_detail_auth_method_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_risk_detail_values,\n Esql.azure_signinlogs_properties_status.error_code_values,\n Esql.azure_signinlogs_properties_original_request_id_values,\n Esql.user_id_values\n", + "references": [ + "https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass", + "https://learn.microsoft.com/en-us/entra/identity/", + "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins" + ], + "risk_score": 47, + "rule_id": "3fac01b2-b811-11ef-b25b-f661ea17fbce", + "setup": "#### Required Entra ID Sign-In Logs\nThis rule requires the Entra ID sign-in logs via the Azure integration be enabled. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Entra ID logs integration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "3fac01b2-b811-11ef-b25b-f661ea17fbce_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5841b80f-a1f8-4c00-a966-d2cc4a7a82e4_1.json b/packages/security_detection_engine/kibana/security_rule/5841b80f-a1f8-4c00-a966-d2cc4a7a82e4_1.json new file mode 100644 index 00000000000..01f93f77cf2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5841b80f-a1f8-4c00-a966-d2cc4a7a82e4_1.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects unusual access to the web.config file, which contains sensitive credential information such as database connection strings, machineKey validation/decryption keys, and SAML/OAuth token settings. Attackers can use the information extracted to forge malicious __VIEWSTATE requests for persistent RCE on the web server or pivot to the SQL server using exposed connection strings.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-endpoint.events.file-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual Web Config File Access", + "new_terms_fields": [ + "process.executable", + "user.id" + ], + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Web Config File Access\nWeb.config files are crucial in Windows environments, storing sensitive data like database credentials and encryption keys. Adversaries target these files to extract information for attacks such as forging malicious requests or accessing databases. The detection rule identifies suspicious access patterns by monitoring file access events in specific directories, helping analysts spot potential credential theft or server exploitation attempts.\n\n### Possible investigation steps\n\n- Investigate the user account associated with the access event to verify if the account has legitimate reasons to access the web.config file or if it might be compromised.\n- Analyze recent activity from the same user or IP address to identify any other suspicious behavior or access patterns that could indicate a broader security incident.\n- Review system logs and network traffic around the time of the alert to identify any related anomalies or signs of exploitation attempts, such as unusual database queries or web server requests.\n\n### False positive analysis\n\n- Routine administrative tasks by IT personnel may trigger alerts when accessing web.config files for legitimate configuration updates. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.\n- Automated backup processes that access web.config files can be mistaken for suspicious activity. Identify and exclude these processes by their specific user accounts or service names.\n- Web application updates or deployments often involve accessing web.config files. Exclude these activities by correlating them with known deployment tools or scripts.\n- Security scanning tools that check web.config files for vulnerabilities might generate false positives. Whitelist these tools by their process names or IP addresses to prevent unnecessary alerts.\n- Monitoring or logging solutions that periodically read web.config files for audit purposes can be excluded by identifying their specific access patterns and excluding them from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected server to prevent further unauthorized access and potential lateral movement within the network.\n- Conduct a thorough review of the web.config file to identify any unauthorized changes or access patterns, focusing on exposed credentials and keys.\n- Rotate all credentials and keys found within the web.config file, including database connection strings and encryption keys, to mitigate the risk of credential theft.\n- Implement additional monitoring and logging for access to web.config files across all servers to detect future unauthorized access attempts.\n- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other potential indicators of compromise.\n- Review and update firewall rules and access controls to ensure that only authorized users and applications can access sensitive directories containing web.config files.\n- Conduct a post-incident analysis to identify gaps in security controls and enhance detection capabilities for similar threats in the future.\n", + "query": "event.category:file and host.os.type:windows and event.action:open and\n file.name:\"web.config\" and file.path : *VirtualDirectories*\n", + "references": [ + "https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5841b80f-a1f8-4c00-a966-d2cc4a7a82e4", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "5841b80f-a1f8-4c00-a966-d2cc4a7a82e4_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_4.json b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_4.json deleted file mode 100644 index bba4d630757..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_4.json +++ /dev/null @@ -1,104 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `CreateAccessKey` for the targeted user." - ], - "from": "now-6m", - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "user_agent.original", - "user.target.name", - "event.action", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements" - ] - }, - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM User Created Access Keys For Another User", - "note": "## Triage and analysis\n\n### Investigating AWS IAM User Created Access Keys For Another User\n\nAWS access keys created for IAM users or root user are long-term credentials that provide programmatic access to AWS.\nWith access to the `iam:CreateAccessKey` permission, a set of compromised credentials could be used to create a new\nset of credentials for another user for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `CreateAccessKey` operation where the user.name is different from the user.target.name.\n\n\n#### Possible investigation steps\n\n- Identify both related accounts and their role in the environment.\n- Review IAM permission policies for the user identities.\n- Identify the applications or users that should use these accounts.\n- Investigate other alerts associated with the accounts during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owners and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `CreateAccessKey` operation. Verify the `aws.cloudtrail.user_identity.arn` should use this operation against the `user.target.name` account.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the newly created credentials from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\"\n and event.action == \"CreateAccessKey\"\n and event.outcome == \"success\"\n and user.name != user.target.name\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n user.name,\n source.address,\n user.target.name,\n user_agent.original,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.response_elements,\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.type,\n", - "references": [ - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey", - "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence", - "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud", - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html" - ], - "risk_score": 47, - "rule_id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.001", - "name": "Additional Cloud Credentials", - "reference": "https://attack.mitre.org/techniques/T1098/001/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.001", - "name": "Additional Cloud Credentials", - "reference": "https://attack.mitre.org/techniques/T1098/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_3.json deleted file mode 100644 index 6c81dd5e9f4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6a309864-fc3f-11ee-b8cc-f661ea17fbce_3.json +++ /dev/null @@ -1,95 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well.", - "false_positives": [ - "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "EC2 AMI Shared with Another Account", - "note": "## Triage and analysis\n\n### Investigating EC2 AMI Shared with Another Account\n\nThis rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control.\n\n#### Possible Investigation Steps\n\n- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts.\n - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared.\n- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it.\n- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.\n- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources.\n- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments.\n- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing.\n\n### False Positive Analysis\n\n- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating.\n- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior.\n\n### Response and Remediation\n\n- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI.\n- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns.\n- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.\n- **Policy Update**: Review and possibly update your organization\u2019s policies on AMI sharing to tighten control and prevent unauthorized access.\n- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing.\n\n### Additional Information\n\nFor more information on managing and sharing AMIs, refer to the [Amazon EC2 User Guide on AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) and [Sharing AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html). Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team [here](https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/).\n\n", - "query": "event.dataset: \"aws.cloudtrail\" and event.provider: \"ec2.amazonaws.com\"\n and event.action: ModifyImageAttribute and event.outcome: success\n and aws.cloudtrail.request_parameters: (*imageId* and *add* and *userId*)\n", - "references": [ - "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html", - "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html", - "https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.request_parameters", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "6a309864-fc3f-11ee-b8cc-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS EC2", - "Use Case: Threat Detection", - "Tactic: Exfiltration", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 3 - }, - "id": "6a309864-fc3f-11ee-b8cc-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_1.json b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_1.json deleted file mode 100644 index a430d90bd7c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_1.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Port Scanning Activity from Compromised Host", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), port_count = count_distinct(destination.port), agent_count = count_distinct(agent.id) by process.executable, destination.ip\n| where agent_count == 1 and port_count > 100\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 21, - "rule_id": "6b341d03-1d63-41ac-841a-2009c86959ca", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1046", - "name": "Network Service Discovery", - "reference": "https://attack.mitre.org/techniques/T1046/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "6b341d03-1d63-41ac-841a-2009c86959ca_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/70558fd5-6448-4c65-804a-8567ce02c3a2_1.json b/packages/security_detection_engine/kibana/security_rule/70558fd5-6448-4c65-804a-8567ce02c3a2_1.json new file mode 100644 index 00000000000..15dc3cc8347 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/70558fd5-6448-4c65-804a-8567ce02c3a2_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each Google SecOps alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Google SecOps alerts in the app.", + "from": "now-2m", + "index": [ + "logs-google_secops.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "Google SecOps External Alerts", + "note": "Triage and analysis\n\n### Investigating Google SecOps External Alerts\n\nGoogle SecOps provides a robust framework for monitoring and managing security operations within cloud environments. The rule leverages specific event identifiers to flag suspicious alerts, enabling analysts to swiftly investigate potential threats and mitigate risks.\n\n### Possible investigation steps\n\n- Examine the timeline of events leading up to and following the alert to identify any unusual patterns or activities that may indicate malicious behavior.\n- Cross-reference the alert with other security logs and alerts to determine if it is part of a broader attack pattern or isolated incident.\n- Investigate the source and destination IP addresses involved in the alert to assess their legitimacy and check for any known malicious activity associated with them.\n- Analyze user activity associated with the alert to identify any unauthorized access or privilege escalation attempts.\n- Consult the Google SecOps investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts triggered by routine administrative actions can be false positives. Review the context of the alert to determine if it aligns with known maintenance activities.\n- Automated scripts or tools that interact with Google SecOps may generate alerts. Identify these scripts and consider creating exceptions for their expected behavior.\n- Frequent alerts from specific IP addresses or user accounts that are known to be secure can be excluded by adding them to an allowlist.\n- Alerts resulting from testing or development environments should be reviewed and, if deemed non-threatening, excluded from triggering further alerts.\n- Regularly update and review exception lists to ensure they reflect current non-threatening behaviors and do not inadvertently exclude genuine threats.\n\n### Response and remediation\n\n- Immediately isolate affected systems or accounts identified in the Google SecOps alert to prevent further unauthorized access or data exfiltration.\n- Conduct a thorough review of the alert details to identify any compromised credentials or access tokens and reset them promptly.\n- Implement network segmentation or access control measures to limit the spread of potential threats within the environment.\n- Review and update firewall rules and security group settings to block any suspicious IP addresses or domains associated with the alert.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.\n- Document the incident, including all actions taken, and update incident response plans to incorporate lessons learned from this event.\n- Enhance monitoring and detection capabilities by tuning existing alerts and deploying additional rules to detect similar activities in the future.\n", + "query": "event.kind: alert and data_stream.dataset: google_secops.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/google_secops" + ], + "related_integrations": [ + { + "package": "google_secops", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "event.risk_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "70558fd5-6448-4c65-804a-8567ce02c3a2", + "rule_name_override": "google_secops.alert.detection.ruleName", + "setup": "## Setup\n\n### Google SecOps Alert Integration\nThis rule is designed to capture alert events generated by the Google SecOps integration and promote them as Elastic detection alerts.\n\nTo capture Google SecOps alerts, install and configure the Google SecOps integration to ingest alert events into the `logs-google_secops.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same SecOps events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:google_secops.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: Google SecOps", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "70558fd5-6448-4c65-804a-8567ce02c3a2_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_1.json b/packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_1.json new file mode 100644 index 00000000000..da7e4ca6f3f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app.", + "from": "now-2m", + "index": [ + "logs-elastic_security.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "Elastic Security External Alerts", + "note": "## Triage and analysis\n\n### Investigating Elastic Security External Alerts\n\nThe Elastic Security integration facilitates transferring security alert data from another Elasticsearch instance to your own, enabling threats to be investigated in a centralized manner.\n\n### Possible investigation steps\n\n- Correlate the alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns.\n- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident.\n- Investigate the source and destination IP addresses involved in the alert to assess if they are known to be malicious or associated with previous threats.\n- Analyze any files or processes flagged in the alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary.\n- Consult the Elastic Security investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts triggered by routine software updates or patches can be false positives. Review the context of the alert to determine if it aligns with scheduled maintenance activities.\n- Legitimate administrative tools or scripts may trigger alerts. Identify and whitelist these tools if they are verified as non-threatening.\n- Frequent alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the Elastic Security configuration.\n- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations.\n- User behavior that is consistent with their role but triggers alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions.\n\n### Response and remediation\n\n- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network.\n- Analyze the specific alert details to identify the nature of the threat and any associated indicators of compromise (IOCs).\n- Remove or quarantine any malicious files or processes identified by the Elastic Security alert to neutralize the threat.\n- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint.\n- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior.\n- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation.\n- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future.\n", + "query": "event.kind: alert and data_stream.dataset: elastic_security.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/elastic_security" + ], + "related_integrations": [ + { + "package": "elastic_security", + "version": "^0.1.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "event.risk_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "720fc1aa-e195-4a1d-81d8-04edfe5313ed", + "rule_name_override": "rule.name", + "setup": "## Setup\n\n### Elastic Security Alert Integration\nThis rule is designed to capture alert events generated by the Elastic Security integration and promote them as Elastic detection alerts.\n\nTo capture Elastic Security alerts, install and configure the Elastic Security integration to ingest alert events into the `logs-elastic_security.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Elastic Security events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:elastic_security.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: Elastic Security", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "720fc1aa-e195-4a1d-81d8-04edfe5313ed_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/74147312-ba03-4bea-91d1-040d54c1e8c3_1.json b/packages/security_detection_engine/kibana/security_rule/74147312-ba03-4bea-91d1-040d54c1e8c3_1.json new file mode 100644 index 00000000000..6af5c684d54 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/74147312-ba03-4bea-91d1-040d54c1e8c3_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each Microsoft Sentinel alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Microsoft Sentinel alerts in the app.", + "from": "now-2m", + "index": [ + "logs-microsoft_sentinel.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "Microsoft Sentinel External Alerts", + "note": " Triage and analysis\n\n## Investigating Microsoft Sentinel External Alerts\n\nMicrosoft Sentinel is a cloud-native SIEM tool that aggregates security data for threat detection and response. The rule identifies each alert logged in Sentinel, enabling analysts to swiftly investigate potential threats.\n\n### Possible investigation steps\n\n- Examine the timeline of events leading up to the alert to identify any unusual or suspicious activities that may have occurred.\n- Cross-reference the alert with other related alerts or logs in Microsoft Sentinel to determine if this is part of a larger pattern or isolated incident.\n- Investigate the source and context of the alert to identify any patterns or anomalies that could indicate manipulation or false positives.\n- Consult the Microsoft Sentinel investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts triggered by routine administrative tasks can be false positives. Identify these tasks and create exceptions to prevent unnecessary alerts.\n- Frequent alerts from known safe IP addresses or domains may not indicate a threat. Whitelist these sources to reduce noise.\n- Alerts generated by automated scripts or scheduled tasks that are part of regular operations can be excluded by setting up filters for these specific activities.\n- Non-threatening alerts from internal network scans or vulnerability assessments should be reviewed and excluded if they are part of regular security practices.\n- Alerts from test environments or sandboxed systems can be false positives. Exclude these environments from alert generation to focus on genuine threats.\n\n### Response and remediation\n\n- Contain the threat by isolating affected systems from the network to prevent further spread or data exfiltration.\n- Review and terminate any suspicious processes or sessions identified in the alert to halt ongoing malicious activities.\n- Conduct a thorough analysis of the alert details to identify any compromised accounts or credentials and reset passwords immediately.\n- Apply relevant security patches or updates to affected systems to close any vulnerabilities exploited by the adversary.\n- Restore affected systems from clean backups to ensure the integrity and security of the environment.\n- Monitor network traffic and system logs closely for any signs of recurring or related suspicious activities.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional resources are needed.\n", + "query": "event.kind: alert and data_stream.dataset: microsoft_sentinel.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/microsoft_sentinel" + ], + "related_integrations": [ + { + "package": "microsoft_sentinel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "microsoft_sentinel.alert.properties.confidence_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "74147312-ba03-4bea-91d1-040d54c1e8c3", + "rule_name_override": "microsoft_sentinel.alert.properties.friendly_name", + "setup": "## Setup\n\n### Microsoft Sentinel Alert Integration\nThis rule is designed to capture alert events generated by the Microsoft Sentinel integration and promote them as Elastic detection alerts.\n\nTo capture Microsoft Sentinel alerts, install and configure the Microsoft Sentinel integration to ingest alert events into the `logs-microsoft_sentinel.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Sentinel events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:microsoft_sentinel.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: Microsoft Sentinel", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "74147312-ba03-4bea-91d1-040d54c1e8c3_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_1.json b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_1.json deleted file mode 100644 index 039883231d7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_1.json +++ /dev/null @@ -1,92 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Malware-Driven SSH Brute Force Attempt", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and\n destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and not\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.executable, destination.port\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 47, - "rule_id": "77122db4-5876-4127-b91b-6c179eb21f88", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Impact", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1496", - "name": "Resource Hijacking", - "reference": "https://attack.mitre.org/techniques/T1496/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "77122db4-5876-4127-b91b-6c179eb21f88_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_104.json b/packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_104.json deleted file mode 100644 index b58b4833af2..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_104.json +++ /dev/null @@ -1,89 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users.", - "false_positives": [ - "Key vault modifications may be done by a system or network administrator. Verify whether the username, hostname, and/or resource name should be making changes in your environment. Key vault modifications from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-25m", - "index": [ - "filebeat-*", - "logs-azure*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Azure Key Vault Modified", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Azure Key Vault Modified\n\nAzure Key Vault is a critical service for managing sensitive information like encryption keys and secrets. It ensures that only authorized users and applications can access these resources. However, adversaries may attempt to modify Key Vault settings to gain unauthorized access to credentials. The detection rule monitors for successful write operations to Key Vaults, flagging potential unauthorized modifications that could indicate credential access attempts.\n\n### Possible investigation steps\n\n- Review the Azure activity logs to identify the specific user or application that performed the write operation on the Key Vault by examining the user identity and application ID fields.\n- Check the timestamp of the write operation to determine if it aligns with expected maintenance windows or known changes, which could indicate legitimate activity.\n- Investigate the specific changes made to the Key Vault by reviewing the operation details to understand what was modified, such as access policies or secret values.\n- Correlate the activity with other security logs or alerts to identify any related suspicious behavior, such as failed login attempts or unusual access patterns from the same user or application.\n- Verify if the user or application that performed the write operation had legitimate access and permissions to modify the Key Vault by reviewing their role assignments and access policies.\n- Assess the potential impact of the modification by determining if any sensitive keys or secrets were exposed or altered, and evaluate the risk to the organization.\n\n### False positive analysis\n\n- Routine administrative updates to Key Vault configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrative accounts and exclude their activities from triggering alerts.\n- Automated scripts or applications that regularly update Key Vault settings as part of normal operations may cause false positives. Identify these scripts and whitelist their operations to prevent unnecessary alerts.\n- Scheduled maintenance activities that involve updating Key Vault settings can be mistaken for unauthorized modifications. Document these activities and create exceptions for the time frames during which they occur.\n- Integration with third-party services that require periodic updates to Key Vault settings might generate alerts. Verify these integrations and exclude their operations if they are deemed secure and necessary.\n\n### Response and remediation\n\n- Immediately revoke access to the affected Key Vault for any unauthorized users or applications identified during the investigation to prevent further unauthorized access.\n- Rotate all secrets, keys, and certificates stored in the compromised Key Vault to ensure that any potentially exposed credentials are no longer valid.\n- Conduct a thorough review of the Key Vault's access policies and permissions to ensure that only authorized users and applications have the necessary access, and implement stricter access controls if needed.\n- Enable logging and monitoring for the Key Vault to capture detailed access and modification events, ensuring that any future unauthorized attempts are quickly detected.\n- Notify the security team and relevant stakeholders about the incident, providing them with details of the unauthorized modifications and actions taken to remediate the issue.\n- If the unauthorized access is suspected to be part of a larger breach, escalate the incident to the incident response team for further investigation and potential involvement of law enforcement if necessary.\n- Review and update incident response plans and playbooks to incorporate lessons learned from this incident, ensuring a more effective response to similar threats in the future.", - "query": "event.dataset:azure.activitylogs and azure.activitylogs.operation_name:\"MICROSOFT.KEYVAULT/VAULTS/WRITE\" and event.outcome:(Success or success)\n", - "references": [ - "https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts", - "https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault", - "https://www.elastic.co/security-labs/detect-credential-access" - ], - "related_integrations": [ - { - "integration": "activitylogs", - "package": "azure", - "version": "^1.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "azure.activitylogs.operation_name", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec", - "setup": "The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Azure", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1552", - "name": "Unsecured Credentials", - "reference": "https://attack.mitre.org/techniques/T1552/", - "subtechnique": [ - { - "id": "T1552.001", - "name": "Credentials In Files", - "reference": "https://attack.mitre.org/techniques/T1552/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 104 - }, - "id": "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec_104", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_1.json b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_1.json deleted file mode 100644 index f6984908f08..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_1.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Subnet Scanning Activity from Compromised Host", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), dest_count = count_distinct(destination.ip), agent_count = count_distinct(agent.id) by process.executable\n| where agent_count == 1 and dest_count > 250\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 21, - "rule_id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1046", - "name": "Network Service Discovery", - "reference": "https://attack.mitre.org/techniques/T1046/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_1.json b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_1.json deleted file mode 100644 index 907665b8478..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_1.json +++ /dev/null @@ -1,99 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual Command Execution from Web Server Parent", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.command_line, process.parent.executable, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n) and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.command_line like \"* -c *\" and\n not (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.working_directory like \"/vscode/vscode-server/*\" or\n process.parent.executable like \"/vscode/vscode-server/*\" or\n process.parent.executable == \"/usr/bin/xfce4-terminal\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.command_line, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 47, - "rule_id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1505", - "name": "Server Software Component", - "reference": "https://attack.mitre.org/techniques/T1505/", - "subtechnique": [ - { - "id": "T1505.003", - "name": "Web Shell", - "reference": "https://attack.mitre.org/techniques/T1505/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_1.json b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_1.json deleted file mode 100644 index b6b7a29f38b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_1.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule leverages ES|QL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual File Transfer Utility Launched", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\n process.name in (\"scp\", \"ftp\", \"sftp\", \"vsftpd\", \"sftp-server\", \"rsync\")\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.executable, process.parent.executable, process.command_line\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 21, - "rule_id": "8eeeda11-dca6-4c3e-910f-7089db412d1c", - "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Exfiltration", - "Tactic: Execution", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "8eeeda11-dca6-4c3e-910f-7089db412d1c_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_1.json deleted file mode 100644 index 50b2cef8957..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/909bf7c8-d371-11ef-bcc3-f661ea17fbcd_1.json +++ /dev/null @@ -1,105 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a [Threshold](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-threshold-rule) rule that flags when this behavior is observed for a specific bucket more than 15 times in a short time-window.", - "false_positives": [ - "Legitimate use of Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt objects in an S3 bucket." - ], - "from": "now-9m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Excessive AWS S3 Object Encryption with SSE-C", - "note": "### Triage and Analysis\n\n#### Investigating Excessive AWS S3 Object Encryption with SSE-C\nThis rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys.\n\n##### Possible Investigation Steps\n\n1. **Identify the User and Source**:\n - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation.\n - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access.\n - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key.\n\n2. **Examine the Targeted Resources**:\n - Check `aws.cloudtrail.flattened.request_parameters.bucketName` to identify the bucket involved.\n - Analyze the object key from `aws.cloudtrail.flattened.request_parameters.key`.\n\n3. **Evaluate Encryption Behavior**:\n - Confirm the encryption details in `aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm` and `aws.cloudtrail.flattened.additional_eventdata.SSEApplied`.\n - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key.\n\n4. **Correlate with Recent Events**:\n - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP.\n - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects.\n - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note.\n\n5. **Validate Access Permissions**:\n - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects.\n\n6. **Assess Impact**:\n - Identify the number of encrypted objects in the bucket by examining other similar events.\n - Determine if this encryption aligns with standard business practices or constitutes a deviation.\n\n### False Positive Analysis\n\n- **Legitimate Use Cases**:\n - Confirm if SSE-C encryption is part of regular operations for compliance or data protection.\n - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Disable access keys or permissions for the user if unauthorized behavior is confirmed.\n - Rotate the bucket's encryption configuration to mitigate further misuse.\n\n2. **Data Recovery**:\n - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future SSE-C encryption attempts in critical buckets.\n - Review and tighten IAM policies for roles and users accessing S3.\n\n4. **Post-Incident Review**:\n - Audit logs for additional activities by the same user or IP.\n - Document findings and apply lessons learned to improve preventive measures.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"s3.amazonaws.com\"\n and event.action: \"PutObject\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: \"AES256\"\n and aws.cloudtrail.flattened.additional_eventdata.SSEApplied: \"SSE_C\"\n", - "references": [ - "https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c", - "https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.additional_eventdata.SSEApplied", - "type": "unknown" - }, - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm", - "type": "unknown" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "909bf7c8-d371-11ef-bcc3-f661ea17fbcd", - "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", - "severity": "high", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Resources: Investigation Guide", - "Use Case: Threat Detection", - "Tactic: Impact" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1486", - "name": "Data Encrypted for Impact", - "reference": "https://attack.mitre.org/techniques/T1486/" - } - ] - } - ], - "threshold": { - "field": [ - "aws.cloudtrail.flattened.request_parameters.bucketName" - ], - "value": 20 - }, - "timestamp_override": "event.ingested", - "type": "threshold", - "version": 1 - }, - "id": "909bf7c8-d371-11ef-bcc3-f661ea17fbcd_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_206.json b/packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_206.json deleted file mode 100644 index c76350afa82..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_206.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "A sudoers file specifies the commands that users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges.", - "from": "now-9m", - "history_window_start": "now-7d", - "index": [ - "auditbeat-*", - "logs-endpoint.events.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Sudoers File Modification", - "new_terms_fields": [ - "host.id", - "process.executable", - "file.path" - ], - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Sudoers File Modification\n\nThe sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific file path that triggered the alert, focusing on /etc/sudoers* or /private/etc/sudoers*.\n- Examine the process information associated with the change event, particularly the process.name and process.executable fields, to determine if the modification was made by a suspicious or unauthorized process.\n- Check the user account associated with the process that made the change to the sudoers file to assess if the account has a legitimate reason to modify the file.\n- Investigate recent login activity and user behavior for the account involved in the modification to identify any anomalies or signs of compromise.\n- Review system logs around the time of the alert to gather additional context on what other activities occurred on the system, which might indicate a broader attack or compromise.\n- Assess the current state of the sudoers file to identify any unauthorized or suspicious entries that could indicate privilege escalation attempts.\n\n### False positive analysis\n\n- System updates and package installations can trigger changes to the sudoers file. Exclude processes like dpkg, yum, dnf, and platform-python from triggering alerts as they are commonly involved in legitimate updates.\n- Configuration management tools such as Puppet and Chef may modify the sudoers file as part of their normal operations. Exclude process executables like /opt/chef/embedded/bin/ruby and /opt/puppetlabs/puppet/bin/ruby to prevent false positives.\n- Docker daemon processes might interact with the sudoers file during container operations. Exclude /usr/bin/dockerd to avoid unnecessary alerts related to Docker activities.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and operational tools, minimizing false positives while maintaining security vigilance.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.\n- Review the recent changes to the sudoers file to identify unauthorized modifications and revert them to the last known good configuration.\n- Conduct a thorough examination of system logs to identify any unauthorized access or actions performed using elevated privileges, focusing on the time frame of the detected change.\n- Reset passwords and review access permissions for all users with sudo privileges to ensure no unauthorized accounts have been added or existing accounts have been compromised.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected.\n- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify the sudoers file or other privilege escalation activities.\n- Review and update security policies and configurations to prevent similar incidents, ensuring that only authorized processes can modify the sudoers file.", - "query": "event.category:file and event.type:change and file.path:(/etc/sudoers* or /private/etc/sudoers*) and\nnot process.name:(dpkg or platform-python or puppet or yum or dnf) and\nnot process.executable:(/opt/chef/embedded/bin/ruby or /opt/puppetlabs/puppet/bin/ruby or /usr/bin/dockerd)\n", - "references": [ - "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "OS: macOS", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/", - "subtechnique": [ - { - "id": "T1548.003", - "name": "Sudo and Sudo Caching", - "reference": "https://attack.mitre.org/techniques/T1548/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 206 - }, - "id": "931e25a5-0f5e-4ae0-ba0d-9e94eff7e3a4_206", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_103.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_103.json deleted file mode 100644 index d2035820753..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_103.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", - "false_positives": [ - "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", - "Shared systems such as Kiosks and conference room computers may be used by multiple users." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Multiple Okta User Authentication Events with Client Address", - "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Client Address\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\nSince this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action == \"user.session.start\" OR event.action RLIKE \"user\\\\.authentication(.*)\")\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP okta.client.ip, okta.actor.alternate_id, okta.actor.id, event.action, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count > 5\n| SORT\n source_auth_count DESC\n", - "references": [ - "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 21, - "rule_id": "94e734c0-2cda-11ef-84e1-f661ea17fbce", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - }, - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.004", - "name": "Credential Stuffing", - "reference": "https://attack.mitre.org/techniques/T1110/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 103 - }, - "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_103.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_103.json deleted file mode 100644 index e1d09196585..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_103.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", - "false_positives": [ - "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", - "Shared systems such as Kiosks and conference room computers may be used by multiple users." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Multiple Okta User Authentication Events with Same Device Token Hash", - "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Same Device Token Hash\n\nThis rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.dt_hash != \"-\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.actor.id, okta.actor.alternate_id, okta.outcome.reason\n| STATS\n target_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id\n| WHERE\n target_auth_count > 20\n| SORT\n target_auth_count DESC\n", - "references": [ - "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 21, - "rule_id": "95b99adc-2cda-11ef-84e1-f661ea17fbce", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - }, - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.004", - "name": "Credential Stuffing", - "reference": "https://attack.mitre.org/techniques/T1110/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 103 - }, - "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_1.json b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_1.json deleted file mode 100644 index 476b7bdc410..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_1.json +++ /dev/null @@ -1,99 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual Process Spawned from Web Server Parent", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.executable, process.command_line, process.parent.executable, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n) and\nnot (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.parent.executable like \"/vscode/vscode-server/*\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.executable, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 47, - "rule_id": "976b2391-413f-4a94-acb4-7911f3803346", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1505", - "name": "Server Software Component", - "reference": "https://attack.mitre.org/techniques/T1505/", - "subtechnique": [ - { - "id": "T1505.003", - "name": "Web Shell", - "reference": "https://attack.mitre.org/techniques/T1505/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "976b2391-413f-4a94-acb4-7911f3803346_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_3.json b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_3.json deleted file mode 100644 index 9c693e89974..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_3.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target user." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to User", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to User\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachUserPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user for privilege escalation or another user as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachUserPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachUserPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?userName}=%{target.userName}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, target.userName\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "9aa4be8d-5828-417d-9f54-7cd304571b24", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "9aa4be8d-5828-417d-9f54-7cd304571b24_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9b35422b-9102-45a9-8610-2e0c22281c55_1.json b/packages/security_detection_engine/kibana/security_rule/9b35422b-9102-45a9-8610-2e0c22281c55_1.json new file mode 100644 index 00000000000..1c5f69662d6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9b35422b-9102-45a9-8610-2e0c22281c55_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each SentinelOne alert written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne alerts in the app.", + "from": "now-2m", + "index": [ + "logs-sentinel_one.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "SentinelOne Alert External Alerts", + "note": "## Triage and analysis\n\n### Investigating SentinelOne Alert External Alerts\n\nSentinelOne is a cybersecurity platform that provides endpoint protection by detecting and responding to threats in real-time. The rule identifies such threats by monitoring specific alert events, enabling analysts to swiftly investigate and mitigate potential security incidents.\n\n### Possible investigation steps\n\n- Correlate the alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns.\n- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident.\n- Investigate the source and destination IP addresses involved in the alert to assess if they are known to be malicious or associated with previous threats.\n- Analyze any files or processes flagged in the alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary.\n- Consult the SentinelOne investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts triggered by routine software updates or patches can be false positives. Review the context of the alert to determine if it aligns with scheduled maintenance activities.\n- Legitimate administrative tools or scripts may trigger alerts. Identify and whitelist these tools if they are verified as non-threatening.\n- Frequent alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the SentinelOne configuration.\n- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations.\n- User behavior that is consistent with their role but triggers alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions.\n\n### Response and remediation\n\n- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network.\n- Analyze the specific alert details to identify the nature of the threat and any associated indicators of compromise (IOCs).\n- Remove or quarantine any malicious files or processes identified by the SentinelOne alert to neutralize the threat.\n- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint.\n- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior.\n- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation.\n- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future.\n", + "query": "event.kind: event and data_stream.dataset: sentinel_one.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/sentinel_one" + ], + "related_integrations": [ + { + "package": "sentinel_one", + "version": "^1.29.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "event.risk_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "9b35422b-9102-45a9-8610-2e0c22281c55", + "rule_name_override": "rule.name", + "setup": "## Setup\n\n### SentinelOne Alert Integration\nThis rule is designed to capture alert events generated by the SentinelOne integration and promote them as Elastic detection alerts.\n\nTo capture SentinelOne alerts, install and configure the SentinelOne integration to ingest alert events into the `logs-sentinel_one.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same SentinelOne events. Consider adding a rule exception for the External Alert rule to exclude datastream.dataset: sentinel_one.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: SentinelOne", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "9b35422b-9102-45a9-8610-2e0c22281c55_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_211.json b/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_211.json deleted file mode 100644 index efdc0f63784..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/a60326d7-dca7-4fb7-93eb-1ca03a1febbd_211.json +++ /dev/null @@ -1,97 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies AWS CloudTrail events where an IAM role's trust policy has been updated. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker may attempt to modify this policy to gain the privileges of the role. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule, which means it will only trigger once for each unique value of the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.flattened.request_parameters.roleName` fields that has not been seen making this API request within the last 14 days.", - "false_positives": [ - "Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Policy updates from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS IAM Assume Role Policy Update", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.flattened.request_parameters.roleName" - ], - "note": "## Triage and analysis\n\n### Investigating AWS IAM Assume Role Policy Update\n\nAn IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.\n\nThe role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role.\n\n#### Possible investigation steps\n\n- Review the `aws.cloudtrail.user_identity.arn` field to determine the user identity that performed the action.\n- Review the `aws.cloudtrail.flattened.request_parameters.roleName` field to confirm the role that was updated.\n- Within the `aws.cloudtrail.request_parameters` field, review the `policyDocument` to understand the changes made to the trust policy.\n- If `aws.cloudtrail.user_identity.access_key_id` is present, investigate the access key used to perform the action as it may be compromised.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Contact the account and resource owners and confirm whether they are aware of this activity.\n- Check if this operation was approved and performed according to the organization's change management policy.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions \u2014 preferably with a combination of the user agent and user ID conditions \u2014 to cover administrator activities and infrastructure as code tooling.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Use AWS [policy versioning](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html) to restore the trust policy to the desired state.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"UpdateAssumeRolePolicy\"\n and event.outcome: \"success\"\n and not source.address: \"cloudformation.amazonaws.com\"\n", - "references": [ - "https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.40.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.address", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "a60326d7-dca7-4fb7-93eb-1ca03a1febbd", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Privilege Escalation" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 211 - }, - "id": "a60326d7-dca7-4fb7-93eb-1ca03a1febbd_211", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_2.json b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_2.json deleted file mode 100644 index f435a6550a1..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_2.json +++ /dev/null @@ -1,58 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data.", - "false_positives": [ - "Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS S3 Object Encryption Using External KMS Key", - "note": "\n## Triage and Analysis\n\n### Investigating AWS S3 Object Encryption Using External KMS Key\n\nThis rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data.\nThis rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule) to look for use of the `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the object was copied. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions.\n- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n\n### Response and Remediation:\n\n- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n// any successful copy event\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"CopyObject\"\n and event.outcome == \"success\"\n\n// abstract key account id, key id, encrypted object bucket name and object name\n| dissect aws.cloudtrail.request_parameters \"{%{?bucketName}=%{target.bucketName},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{key.account.id}:%{?key}/%{keyId},%{?Host}=%{?tls.client.server_name},%{?x-amz-server-side-encryption}=%{?server-side-encryption},%{?x-amz-copy-source}=%{?bucket.objectName},%{?key}=%{target.objectName}}\"\n\n// filter for s3 objects whose account id is different from the encryption key's account id\n// add exceptions based on key.account.id or keyId for known external accounts or encryption keys\n| where cloud.account.id != key.account.id\n\n// keep relevant fields\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, target.bucketName, key.account.id, keyId, target.objectName\n", - "references": [ - "https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/", - "https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/", - "https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/", - "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" - ], - "risk_score": 47, - "rule_id": "ab8f074c-5565-4bc4-991c-d49770e19fc9", - "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Data Source: AWS KMS", - "Use Case: Threat Detection", - "Tactic: Impact" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1486", - "name": "Data Encrypted for Impact", - "reference": "https://attack.mitre.org/techniques/T1486/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "ab8f074c-5565-4bc4-991c-d49770e19fc9_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/aeebe561-c338-4118-9924-8cb4e478aa58_1.json b/packages/security_detection_engine/kibana/security_rule/aeebe561-c338-4118-9924-8cb4e478aa58_1.json new file mode 100644 index 00000000000..f6da0eecb47 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/aeebe561-c338-4118-9924-8cb4e478aa58_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each CrowdStrike alert written to the configured indices. Enabling this rule allows you to immediately begin investigating CrowdStrike alerts in the app.", + "from": "now-2m", + "index": [ + "logs-crowdstrike.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "CrowdStrike External Alerts", + "note": "## Triage and analysis\n\n### Investigating CrowdStrike External Alerts\n\nCrowdStrike Falcon is a cloud-native endpoint protection platform that delivers real-time threat detection and response capabilities. The rule captures security alerts generated by Falcon and enables analysts to investigate threats rapidly based on behavioral indicators and threat intelligence.\n\n### Possible investigation steps\n\n- Review the associated process, file path, and command line to determine whether the activity is legitimate or suspicious.\n- Investigate the user account and host involved in the alert to validate whether the activity was authorized.\n- Cross-reference the alert with CrowdStrike Falcon console for additional context, including process tree, behavioral tags, and threat intelligence matches.\n- Check for any related alerts from the same host, user, or file hash to identify whether this is part of a larger attack chain.\n- Consult the Crowdstrike investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts involving known and trusted software tools (e.g., remote administration tools) may be false positives. Confirm intent before excluding.\n- Security assessments or penetration testing activities might mimic real threats. Validate the activity with responsible teams.\n- Scheduled jobs, IT scripts, or automation tools may trigger alerts if they behave similarly to malicious code.\n- Review alerts based on detection confidence levels and behavioral scoring to filter out low-confidence or known-benign triggers.\n\n### Response and remediation\n\n- Isolate affected endpoints to prevent lateral movement if malicious behavior is confirmed.\n- Quarantine any identified malicious files and block related hashes or domains.\n- Investigate how the threat entered the environment and close any exploited vulnerabilities.\n- Reset credentials for compromised user accounts or escalate to incident response.\n- Review CrowdStrike Falcon policies and detections to fine-tune future alerting and response coverage.\n- Document the findings and update detection logic or exceptions accordingly.\n", + "query": "event.kind: alert and data_stream.dataset: crowdstrike.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/crowdstrike" + ], + "related_integrations": [ + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "crowdstrike.alert.incident.score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "aeebe561-c338-4118-9924-8cb4e478aa58", + "rule_name_override": "crowdstrike.alert.name", + "setup": "## Setup\n\n### CrowdStrike Alert Integration\nThis rule is designed to capture alert events generated by the CrowdStrike integration and promote them as Elastic detection alerts.\n\nTo capture CrowdStrike alerts, install and configure the CrowdStrike integration to ingest alert events into the `logs-crowdstrike.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same CrowdStrike events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:crowdstrike.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: CrowdStrike", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "aeebe561-c338-4118-9924-8cb4e478aa58_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_1.json deleted file mode 100644 index d8ef632fd88..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c1a9ed70-d349-11ef-841c-f661ea17fbcd_1.json +++ /dev/null @@ -1,123 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that flags when this behavior is observed for the first time in the last 14 days by the user ARN and target bucket name.", - "false_positives": [ - "Legitimate use of Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt objects in an S3 bucket." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "@timestamp", - "event.action", - "event.outcome", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.user_identity.access_key_id", - "aws.cloudtrail.flattened.request_parameters.bucketName", - "aws.cloudtrail.flattened.request_parameters.key", - "aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm", - "aws.cloudtrail.flattened.additional_eventdata.SSEApplied", - "aws.cloudtrail.response_elements", - "source.ip", - "user_agent.original", - "cloud.region", - "cloud.account.id" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "Unusual AWS S3 Object Encryption with SSE-C", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.flattened.request_parameters.bucketName" - ], - "note": "### Triage and Analysis\n\n#### Investigating Unusual AWS S3 Object Encryption with SSE-C\nThis rule identifies the use of Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys.\n\n##### Possible Investigation Steps\n\n1. **Identify the User and Source**:\n - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation.\n - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access.\n - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key.\n\n2. **Examine the Targeted Resources**:\n - Check `aws.cloudtrail.flattened.request_parameters.bucketName` to identify the bucket involved.\n - Analyze the object key from `aws.cloudtrail.flattened.request_parameters.key`.\n\n3. **Evaluate Encryption Behavior**:\n - Confirm the encryption details in `aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm` and `aws.cloudtrail.flattened.additional_eventdata.SSEApplied`.\n - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key.\n\n4. **Correlate with Recent Events**:\n - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP.\n - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects.\n - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note.\n\n5. **Validate Access Permissions**:\n - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects.\n\n6. **Assess Impact**:\n - Identify the number of encrypted objects in the bucket by examining other similar events.\n - Determine if this encryption aligns with standard business practices or constitutes a deviation.\n\n### False Positive Analysis\n\n- **Legitimate Use Cases**:\n - Confirm if SSE-C encryption is part of regular operations for compliance or data protection.\n - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket.\n\n### Response and Remediation\n\n1. **Immediate Actions**:\n - Disable access keys or permissions for the user if unauthorized behavior is confirmed.\n - Rotate the bucket's encryption configuration to mitigate further misuse.\n\n2. **Data Recovery**:\n - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary.\n\n3. **Enhance Monitoring**:\n - Enable alerts for future SSE-C encryption attempts in critical buckets.\n - Review and tighten IAM policies for roles and users accessing S3.\n\n4. **Post-Incident Review**:\n - Audit logs for additional activities by the same user or IP.\n - Document findings and apply lessons learned to improve preventive measures.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"s3.amazonaws.com\"\n and event.action: \"PutObject\"\n and event.outcome: \"success\"\n and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: \"AES256\"\n and aws.cloudtrail.flattened.additional_eventdata.SSEApplied: \"SSE_C\"\n", - "references": [ - "https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c", - "https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.additional_eventdata.SSEApplied", - "type": "unknown" - }, - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm", - "type": "unknown" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "c1a9ed70-d349-11ef-841c-f661ea17fbcd", - "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", - "severity": "high", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Resources: Investigation Guide", - "Use Case: Threat Detection", - "Tactic: Impact" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1486", - "name": "Data Encrypted for Impact", - "reference": "https://attack.mitre.org/techniques/T1486/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 1 - }, - "id": "c1a9ed70-d349-11ef-841c-f661ea17fbcd_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_4.json deleted file mode 100644 index 92142b42b2b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_4.json +++ /dev/null @@ -1,122 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies discovery request `DescribeInstanceAttribute` with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies when `aws.cloudtrail.user_identity.arn` requests the user data for a specific `aws.cloudtrail.flattened.request_parameters.instanceId` from an EC2 instance in the last 14 days.", - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS EC2 User Data Retrieval for EC2 Instance", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.flattened.request_parameters.instanceId" - ], - "note": "## Triage and Analysis\n\n### Investigating AWS EC2 User Data Retrieval for EC2 Instance\n\nThis rule detects requests to retrieve the `userData` attribute of an EC2 instance using the `DescribeInstanceAttribute` API action. The `userData` field can contain sensitive information, such as hardcoded credentials or configuration scripts, that adversaries may exploit for further attacks.\n\n#### Possible Investigation Steps\n\n- **Identify the Target Instance**:\n - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceId` field to identify the EC2 instance targeted by the request. Confirm whether this instance should expose its `userData` and whether it is associated with sensitive workloads.\n - **Analyze userData**: If possible, retrieve and inspect the `userData` field to identify sensitive information like hardcoded credentials or configuration scripts.\n\n- **Review User Context**:\n - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to identify the user or role that executed the `DescribeInstanceAttribute` action. Investigate whether this user typically performs such actions.\n - **Access Patterns**: Validate whether the user or role has the necessary permissions and whether the frequency of this action aligns with expected behavior.\n - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to determine the key used to make the request as it may be compromised.\n\n- **Analyze Request Details**:\n - **Parameters**: Verify that the `attribute=userData` parameter was explicitly requested. This indicates intentional access to user data.\n - **Source IP and Geolocation**: Check the `source.address` and `source.geo` fields to validate whether the request originated from a trusted location or network. Unexpected geolocations can indicate adversarial activity.\n\n- **Review Source Tool**:\n - **User Agent**: Inspect the `user_agent.original` field to determine the tool or client used (e.g., Terraform, AWS CLI). Legitimate automation tools may trigger this activity, but custom or unknown user agents may indicate malicious intent.\n\n- **Check for Related Activity**:\n - **IAM Changes**: Correlate this event with any IAM changes or temporary credential creation to identify potential privilege escalation attempts.\n - **API Usage**: Look for other unusual API calls (e.g., `RunInstances`, `GetObject`, `AssumeRole`) by the same user or IP to detect lateral movement or data exfiltration attempts.\n\n- **Validate Intent**:\n - **Permissions and Justification**: Ensure that the user has the least privilege required to perform this action. Investigate whether there is a valid reason for accessing the `userData` field.\n\n### False Positive Analysis\n\n- **Automation**: This event is often triggered by legitimate automation tools, such as Terraform or custom scripts, that require access to `userData` during instance initialization.\n- **Maintenance Activity**: Verify whether this event aligns with expected administrative activities, such as debugging or instance configuration updates.\n\n### Response and Remediation\n\n- **Revoke Excessive Permissions**: If unauthorized, immediately remove `DescribeInstanceAttribute` permissions from the user or role.\n- **Quarantine the Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance to limit further exposure.\n- **Secure User Data**:\n - Avoid storing sensitive information, such as credentials, in `userData`. Use AWS Secrets Manager or Parameter Store instead.\n - Encrypt user data and ensure only authorized users can decrypt it.\n- **Audit IAM Policies**: Regularly review IAM policies to ensure they adhere to the principle of least privilege.\n- **Monitor and Detect**: Set up additional alerts for unexpected `DescribeInstanceAttribute` calls or other suspicious API activity.\n\n### Additional Information\n\nFor more details on managing EC2 user data securely, refer to the [AWS EC2 User Data Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"ec2.amazonaws.com\"\n and event.action: \"DescribeInstanceAttribute\"\n and event.outcome: \"success\"\n and aws.cloudtrail.request_parameters: (*attribute=userData* and *instanceId*)\n and not aws.cloudtrail.user_identity.invoked_by: (\n \"AWS Internal\" or\n \"cloudformation.amazonaws.com\"\n )\n", - "references": [ - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html", - "https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.40.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.request_parameters", - "type": "keyword" - }, - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.invoked_by", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "c1e79a70-fa6f-11ee-8bc8-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: Amazon EC2", - "Resources: Investigation Guide", - "Use Case: Log Auditing", - "Tactic: Discovery" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1552", - "name": "Unsecured Credentials", - "reference": "https://attack.mitre.org/techniques/T1552/", - "subtechnique": [ - { - "id": "T1552.005", - "name": "Cloud Instance Metadata API", - "reference": "https://attack.mitre.org/techniques/T1552/005/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 4 - }, - "id": "c1e79a70-fa6f-11ee-8bc8-f661ea17fbce_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_1.json b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_1.json deleted file mode 100644 index f5c99f66da9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_1.json +++ /dev/null @@ -1,92 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule leverages ES|QL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual Base64 Encoding/Decoding Activity", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n (process.name in (\"base64\", \"base64plain\", \"base64url\", \"base64mime\", \"base64pem\", \"base32\", \"base16\") and process.command_line like \"*-*d*\") or\n (process.name == \"openssl\" and process.args == \"enc\" and process.args in (\"-d\", \"-base64\", \"-a\")) or\n (process.name like \"python*\" and\n (process.args == \"base64\" and process.args in (\"-d\", \"-u\", \"-t\")) or\n (process.args == \"-c\" and process.command_line like \"*base64*\" and process.command_line like \"*b64decode*\")\n ) or\n (process.name like \"perl*\" and process.command_line like \"*decode_base64*\") or\n (process.name like \"ruby*\" and process.args == \"-e\" and process.command_line like \"*Base64.decode64*\")\n)\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.name, process.command_line\n| where agent_count == 1 and cc < 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 21, - "rule_id": "c5637438-e32d-4bb3-bc13-bd7932b3289f", - "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - }, - { - "id": "T1204", - "name": "User Execution", - "reference": "https://attack.mitre.org/techniques/T1204/", - "subtechnique": [ - { - "id": "T1204.002", - "name": "Malicious File", - "reference": "https://attack.mitre.org/techniques/T1204/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "c5637438-e32d-4bb3-bc13-bd7932b3289f_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_204.json b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_204.json deleted file mode 100644 index 9a3f13ba051..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_204.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Multiple Device Token Hashes for Single Okta Session", - "note": "## Triage and analysis\n\n### Investigating Multiple Device Token Hashes for Single Okta Session\n\nThis rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - Authentication events have been filtered out to focus on Okta activity via established sessions.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.\n - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.\n\n### Response and remediation:\n- Consider stopping all sessions for the user(s) involved in this action.\n- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n // ignore authentication events where session and device token hash change often\n AND NOT event.action IN (\n \"policy.evaluate_sign_on\",\n \"user.session.start\",\n \"user.authentication.sso\"\n )\n // ignore Okta system events and only allow registered users\n AND (\n okta.actor.alternate_id != \"system@okta.com\"\n AND okta.actor.alternate_id RLIKE \"[^@\\\\s]+\\\\@[^@\\\\s]+\"\n )\n AND okta.authentication_context.external_session_id != \"unknown\"\n| KEEP event.action, okta.actor.alternate_id, okta.authentication_context.external_session_id, okta.debug_context.debug_data.dt_hash\n| STATS\n dt_hash_counts = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id\n| WHERE\n dt_hash_counts >= 2\n| SORT\n dt_hash_counts DESC\n", - "references": [ - "https://developer.okta.com/docs/reference/api/system-log/", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 47, - "rule_id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd", - "setup": "## Setup\n\nThe Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access", - "Domain: SaaS" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1539", - "name": "Steal Web Session Cookie", - "reference": "https://attack.mitre.org/techniques/T1539/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 204 - }, - "id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd_204", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d3b6222f-537e-4b84-956a-3ebae2dcf811_1.json b/packages/security_detection_engine/kibana/security_rule/d3b6222f-537e-4b84-956a-3ebae2dcf811_1.json new file mode 100644 index 00000000000..1497e9aae78 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d3b6222f-537e-4b84-956a-3ebae2dcf811_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each Splunk alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Splunk alerts in the app.", + "from": "now-2m", + "index": [ + "logs-splunk.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "Splunk External Alerts", + "note": "## Triage and analysis\n\n### Investigating Splunk External Alerts\n\nSplunk monitors and analyzes data, often used in security environments to track and respond to potential threats. The rule identifies such manipulations by flagging alerts enabling timely investigation and response.\n\n### Possible investigation steps\n\n- Examine the specific indices where the alert was written to identify any unusual or unauthorized activity.\n- Cross-reference the alert with recent changes or activities in the Splunk environment to determine if the alert could be a result of legitimate administrative actions.\n- Investigate the source and context of the alert to identify any patterns or anomalies that could indicate manipulation or false positives.\n- Check for any related alerts or logs that might provide additional context or evidence of adversarial behavior.\n- Consult the Splunk investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts triggered by routine Splunk maintenance activities can be false positives. To manage these, identify and document regular maintenance schedules and create exceptions for alerts generated during these times.\n- Frequent alerts from specific indices that are known to contain non-threatening data can be excluded by adjusting the rule to ignore these indices, ensuring only relevant alerts are investigated.\n- Alerts generated by automated scripts or tools that interact with Splunk for legitimate purposes can be false positives. Review and whitelist these scripts or tools to prevent unnecessary alerts.\n- If certain user actions consistently trigger alerts but are verified as non-malicious, consider creating user-specific exceptions to reduce noise and focus on genuine threats.\n- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently exclude new or evolving threats.\n\n### Response and remediation\n\n- Immediately isolate affected systems to prevent further manipulation of Splunk alerts and potential spread of malicious activity.\n- Review and validate the integrity of the Splunk alert indices to ensure no unauthorized changes have been made.\n- Restore any compromised Splunk alert configurations from a known good backup to ensure accurate monitoring and alerting.\n- Conduct a thorough audit of user access and permissions within Splunk to identify and revoke any unauthorized access.\n- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems or data have been affected.\n- Implement enhanced monitoring on Splunk indices to detect any future unauthorized changes or suspicious activities.\n- Document the incident details and response actions taken for future reference and to improve incident response procedures.\n", + "query": "event.kind: alert and data_stream.dataset: splunk.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/splunk" + ], + "related_integrations": [ + { + "package": "splunk", + "version": "^0.1.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "event.risk_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "d3b6222f-537e-4b84-956a-3ebae2dcf811", + "rule_name_override": "splunk.alert.source", + "setup": "## Setup\n\n### Splunk Alert Integration\nThis rule is designed to capture alert events generated by the Splunk integration and promote them as Elastic detection alerts.\n\nTo capture Splunk alerts, install and configure the Splunk integration to ingest alert events into the `logs-splunk.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Splunk events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:splunk.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: Splunk", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "d3b6222f-537e-4b84-956a-3ebae2dcf811_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_2.json b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_2.json deleted file mode 100644 index 650972f74b9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_2.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target role." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to Role", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Role\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources. \nWith access to the `iam:AttachRolePolicy` permission, a set of compromised credentials could be used to attach\nthis policy to a compromised role for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachRolePolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachRolePolicy` permission and that the `role.name` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected role(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. \n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment. \n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-*\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachRolePolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?roleName}=%{role.name}}\"\n| where policyName == \"AdministratorAccess\"\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_2.json b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_2.json deleted file mode 100644 index 164d1359766..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_2.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user group." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to Group", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Group\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources. \nWith access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected group(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. \n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment. \n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-*\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachGroupPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?groupName}=%{group.name}}\"\n| where policyName == \"AdministratorAccess\"\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e43b7578-f3cc-4682-a8cf-f9d8a5fb07f1_1.json b/packages/security_detection_engine/kibana/security_rule/e43b7578-f3cc-4682-a8cf-f9d8a5fb07f1_1.json new file mode 100644 index 00000000000..350fa433bd4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e43b7578-f3cc-4682-a8cf-f9d8a5fb07f1_1.json @@ -0,0 +1,77 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each SentinelOne threat written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne threat alerts in the app.", + "from": "now-2m", + "index": [ + "logs-sentinel_one.threat-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "SentinelOne Threat External Alerts", + "note": "## Triage and analysis\n\n### Investigating SentinelOne Threat External Alerts\n\nSentinelOne is a cybersecurity platform that provides endpoint protection by detecting and responding to threats in real-time. The rule identifies such threats by monitoring specific threat events, enabling analysts to swiftly investigate and mitigate potential security incidents.\n\n### Possible investigation steps\n\n- Correlate the threat alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns.\n- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident.\n- Investigate the source and destination IP addresses involved in the threat to assess if they are known to be malicious or associated with previous threats.\n- Analyze any files or processes flagged in the threat alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary.\n- Consult the SentinelOne investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Threats triggered by routine software updates or patches can be false positives. Review the context of the threat to determine if it aligns with scheduled maintenance activities.\n- Legitimate administrative tools or scripts may trigger threat alerts. Identify and whitelist these tools if they are verified as non-threatening.\n- Frequent threat alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the SentinelOne configuration.\n- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations.\n- User behavior that is consistent with their role but triggers threat alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions.\n\n### Response and remediation\n\n- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network.\n- Analyze the specific threat alert details to identify the nature of the threat and any associated indicators of compromise (IOCs).\n- Remove or quarantine any malicious files or processes identified by the SentinelOne threat alert to neutralize the threat.\n- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint.\n- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior.\n- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation.\n- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future.\n", + "query": "event.kind: alert and data_stream.dataset: sentinel_one.threat\n", + "references": [ + "https://docs.elastic.co/en/integrations/sentinel_one" + ], + "related_integrations": [ + { + "package": "sentinel_one", + "version": "^1.29.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "event.risk_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "e43b7578-f3cc-4682-a8cf-f9d8a5fb07f1", + "rule_name_override": "message", + "setup": "## Setup\n\n### SentinelOne Threat Integration\nThis rule is designed to capture threat events generated by the SentinelOne integration and promote them as Elastic detection alerts.\n\nTo capture SentinelOne threat alerts, install and configure the SentinelOne integration to ingest threat events into the `logs-sentinel_one.threat-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same SentinelOne events. Consider adding a rule exception for the External Alert rule to exclude datastream.dataset: sentinel_one.threat to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "sentinel_one.threat.confidence_level", + "operator": "equals", + "severity": "medium", + "value": "suspicious" + }, + { + "field": "sentinel_one.threat.confidence_level", + "operator": "equals", + "severity": "high", + "value": "malicious" + } + ], + "tags": [ + "Data Source: SentinelOne", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "e43b7578-f3cc-4682-a8cf-f9d8a5fb07f1_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_3.json b/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_3.json new file mode 100644 index 00000000000..274f04bbfbf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_3.json @@ -0,0 +1,57 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlate Azure or Office 356 mail successful sign-in events with network security alerts by source.ip. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources.", + "false_positives": [ + "Custom network security rules that triggers on a proxy or gateway used by users to access Azure or O365." + ], + "from": "now-60m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft 365 or Entra ID Sign-in from a Suspicious Source", + "note": "## Triage and analysis\n\n### Investigating Microsoft 365 or Entra ID Sign-in from a Suspicious Source\n\n#### Possible investigation steps\n\n- Investiguate all the alerts associated with the source.ip.\n - Verify the network security alert details associated with this source.ip.\n - Verify all sign-in events associated with this source.ip.\n - Consider the source IP address and geolocation for the involved user account.\n - Consider the device used to sign in. Is it registered and compliant?\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Check if this operation was approved and performed according to the organization's change management policy.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).", + "query": "from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.*\n// query runs every 1 hour looking for activities occurred during last 8 hours to match on disparate events\n| where @timestamp > now() - 8 hours\n// filter for azure or m365 sign-in and external alerts with source.ip not null\n| where to_ip(source.ip) is not null\n and (event.dataset in (\"o365.audit\", \"azure.signinlogs\") or kibana.alert.rule.name == \"External Alerts\")\n and not cidr_match(\n to_ip(source.ip),\n \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\",\n \"192.0.0.8/32\", \"192.0.0.9/32\", \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\",\n \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\", \"224.0.0.0/4\",\n \"100.64.0.0/10\", \"192.175.48.0/24\", \"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\",\n \"240.0.0.0/4\", \"::1\", \"FE80::/10\", \"FF00::/8\"\n )\n\n// capture relevant raw fields\n| keep source.ip, event.action, event.outcome, event.dataset, kibana.alert.rule.name, event.category\n\n// classify each source ip based on alert type\n| eval\n Esql.source_ip_mail_access_case = case(event.dataset == \"o365.audit\" and event.action == \"MailItemsAccessed\" and event.outcome == \"success\", to_ip(source.ip), null),\n Esql.source_ip_azure_signin_case = case(event.dataset == \"azure.signinlogs\" and event.outcome == \"success\", to_ip(source.ip), null),\n Esql.source_ip_network_alert_case = case(kibana.alert.rule.name == \"external alerts\" and not event.dataset in (\"o365.audit\", \"azure.signinlogs\"), to_ip(source.ip), null)\n\n// aggregate by source ip\n| stats\n Esql.event_count = count(*),\n Esql.source_ip_mail_access_case_count_distinct = count_distinct(Esql.source_ip_mail_access_case),\n Esql.source_ip_azure_signin_case_count_distinct = count_distinct(Esql.source_ip_azure_signin_case),\n Esql.source_ip_network_alert_case_count_distinct = count_distinct(Esql.source_ip_network_alert_case),\n Esql.event_dataset_count_distinct = count_distinct(event.dataset),\n Esql.event_dataset_values = values(event.dataset),\n Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),\n Esql.event_category_values = values(event.category)\n by Esql.source_ip = to_ip(source.ip)\n\n// correlation condition\n| where\n Esql.source_ip_network_alert_case_count_distinct > 0\n and Esql.event_dataset_count_distinct >= 2\n and (Esql.source_ip_mail_access_case_count_distinct > 0 or Esql.source_ip_azure_signin_case_count_distinct > 0)\n and Esql.event_count <= 100\n", + "risk_score": 73, + "rule_id": "f0cc239b-67fa-46fc-89d4-f861753a40f5", + "setup": "The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Resources: Investigation Guide", + "Rule Type: Higher-Order Rule" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "f0cc239b-67fa-46fc-89d4-f861753a40f5_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_11.json b/packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_11.json new file mode 100644 index 00000000000..fb1ce9cc5c8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_11.json @@ -0,0 +1,108 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a user copies a Google spreadsheet, form, document or script from an external drive. Sequence logic has been added to also detect when a user grants a custom Google application permission via OAuth shortly after. An adversary may send a phishing email to the victim with a Drive object link where \"copy\" is included in the URI, thus copying the object to the victim's drive. If a container-bound script exists within the object, execution will require permission access via OAuth in which the user has to accept.", + "false_positives": [ + "Google Workspace users typically share Drive resources with a shareable link where parameters are edited to indicate when it is viewable or editable by the intended recipient. It is uncommon for a user in an organization to manually copy a Drive object from an external drive to their corporate drive. This may happen where users find a useful spreadsheet in a public drive, for example, and replicate it to their Drive. It is uncommon for the copied object to execute a container-bound script either unless the user was intentionally aware, suggesting the object uses container-bound scripts to accomplish a legitimate task." + ], + "from": "now-9m", + "index": [ + "filebeat-*", + "logs-google_workspace*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Google Workspace Object Copied to External Drive with App Consent", + "note": "## Triage and analysis\n\n### Investigating Google Workspace Object Copied to External Drive with App Consent\n\nGoogle Workspace users can share access to Drive objects such as documents, sheets, and forms via email delivery or a shared link. Shared link URIs have parameters like `view` or `edit` to indicate the recipient's permissions. The `copy` parameter allows the recipient to copy the object to their own Drive, which grants the object with the same privileges as the recipient. Specific objects in Google Drive allow container-bound scripts that run on Google's Apps Script platform. Container-bound scripts can contain malicious code that executes with the recipient's privileges if in their Drive.\n\nThis rule aims to detect when a user copies an external Drive object to their Drive storage and then grants permissions to a custom application via OAuth prompt.\n\n#### Possible investigation steps\n- Identify user account(s) associated by reviewing `user.name` or `source.user.email` in the alert.\n- Identify the name of the file copied by reviewing `file.name` as well as the `file.id` for triaging.\n- Identify the file type by reviewing `google_workspace.drive.file.type`.\n- With the information gathered so far, query across data for the file metadata to determine if this activity is isolated or widespread.\n- Within the OAuth token event, identify the application name by reviewing `google_workspace.token.app_name`.\n - Review the application ID as well from `google_workspace.token.client.id`.\n - This metadata can be used to report the malicious application to Google for permanent blacklisting.\n- Identify the permissions granted to the application by the user by reviewing `google_workspace.token.scope.data.scope_name`.\n - This information will help pivot and triage into what services may have been affected.\n- If a container-bound script was attached to the copied object, it will also exist in the user's drive.\n - This object should be removed from all users affected and investigated for a better understanding of the malicious code.\n\n### False positive analysis\n- Communicate with the affected user to identify if these actions were intentional\n- If a container-bound script exists, review code to identify if it is benign or malicious\n\n### Response and remediation\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n - Resetting passwords will revoke OAuth tokens which could have been stolen.\n- Reactivate multi-factor authentication for the user.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security defaults [provided by Google](https://cloud.google.com/security-command-center/docs/how-to-investigate-threats).\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n\n\n### Important Information Regarding Google Workspace Event Lag Times\n- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.\n- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.\n- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).\n- See the following references for further information:\n - https://support.google.com/a/answer/7061566\n - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html", + "query": "sequence by source.user.email with maxspan=3m\n[file where event.dataset == \"google_workspace.drive\" and event.action == \"copy\" and\n\n /* Should only match if the object lives in a Drive that is external to the user's GWS organization */\n google_workspace.drive.owner_is_team_drive == \"false\" and google_workspace.drive.copy_type == \"external\" and\n\n /* Google Script, Forms, Sheets and Document can have container-bound scripts */\n google_workspace.drive.file.type: (\"script\", \"form\", \"spreadsheet\", \"document\")]\n\n[any where event.dataset == \"google_workspace.token\" and event.action == \"authorize\" and\n\n /* Ensures application ID references custom app in Google Workspace and not GCP */\n google_workspace.token.client.id : \"*apps.googleusercontent.com\"]\n", + "references": [ + "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one", + "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two", + "https://developers.google.com/apps-script/guides/bound", + "https://support.google.com/a/users/answer/13004165#share_make_a_copy_links" + ], + "related_integrations": [ + { + "package": "google_workspace", + "version": "^2.31.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "google_workspace.drive.copy_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "google_workspace.drive.file.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "google_workspace.drive.owner_is_team_drive", + "type": "boolean" + }, + { + "ecs": false, + "name": "google_workspace.token.client.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.email", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "f33e68a4-bd19-11ed-b02f-f661ea17fbcc", + "setup": "The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Google Workspace", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/", + "subtechnique": [ + { + "id": "T1566.002", + "name": "Spearphishing Link", + "reference": "https://attack.mitre.org/techniques/T1566/002/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 11 + }, + "id": "f33e68a4-bd19-11ed-b02f-f661ea17fbcc_11", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_2.json deleted file mode 100644 index d808786dac9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f6d07a70-9ad0-11ef-954f-f661ea17fbcd_2.json +++ /dev/null @@ -1,121 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the AWS environment. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that uses the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.flattened.request_parameters.roleName` fields to check if the combination of the actor ARN and target role name has not been seen in the last 14 days.", - "false_positives": [ - "Legitimate IAM administrators may attach customer-managed policies to roles for various reasons, such as granting temporary permissions or updating existing policies. Ensure that the user attaching the policy is authorized to do so and that the action is expected." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "user_agent.original", - "aws.cloudtrail.flattened.request_parameters.policyArn", - "aws.cloudtrail.flattened.request_parameters.roleName", - "event.action", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters" - ] - }, - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS IAM Customer-Managed Policy Attached to Role by Rare User", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.flattened.request_parameters.roleName" - ], - "note": "## Triage and analysis\n\n### Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User\n\nThis rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access.\n\n#### Possible Investigation Steps\n\n- **Identify the Initiating User and Target Role**:\n - **User Identity**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the user who initiated the policy attachment. Confirm if this user typically has permissions to modify IAM roles and if their activity is consistent with their usual responsibilities.\n - **Target Role**: Review `aws.cloudtrail.flattened.request_parameters.roleName` to identify the role to which the policy was attached. Assess whether modifying this role is expected for this user or if this action is unusual in your environment.\n\n- **Analyze the Attached Policy**:\n - **Policy ARN**: Inspect the `aws.cloudtrail.flattened.request_parameters.policyArn` field to identify the specific customer-managed policy attached to the role. Evaluate if this policy grants sensitive permissions, especially permissions that could enable privileged actions or data access.\n - **Policy Permissions**: Examine the policy content to determine the scope of permissions granted. Policies enabling actions like `s3:*`, `ec2:*`, or `iam:*` could be leveraged for broader access, persistence, or lateral movement.\n\n- **Review Source and User Agent Details**:\n - **Source IP and Location**: Analyze the `source.address` and `source.geo` fields to confirm the IP address and geographic location where the policy attachment originated. Verify if this matches expected locations for the initiating user.\n - **User Agent Analysis**: Examine `user_agent.original` to determine if AWS CLI, SDK, or other tooling was used to perform this action. Tool identifiers like `aws-cli` or `boto3` may indicate automation, while others may suggest interactive sessions.\n\n- **Evaluate Anomalous Behavior Patterns**:\n - **User\u2019s Historical Activity**: Check if the initiating user has a history of attaching policies to roles. An unusual pattern in policy attachments could indicate suspicious behavior, especially if the user lacks authorization.\n - **Role Modification History**: Investigate if the targeted role is frequently modified by this or other users. Repeated, unauthorized modifications to a role could signal an attempt to maintain elevated access.\n\n- **Correlate with Related CloudTrail Events**:\n - **Other IAM or CloudTrail Activities**: Look for recent actions associated with the same user or role by reviewing `event.action` by `event.provider` to identify which AWS services were accessed. This may provide context on the user\u2019s intent or additional actions taken.\n - **Broader Suspicious Patterns**: Identify if similar anomalous events have recently occurred, potentially suggesting a coordinated or escalating attack pattern within the AWS account.\n\n### False Positive Analysis\n\n- **Authorized Administrative Actions**: IAM administrators may legitimately attach policies to roles as part of routine role management. Verify if the user is authorized and if the activity aligns with expected administrative tasks.\n- **Role-Specific Modifications**: Roles that frequently undergo policy updates may trigger this rule during standard operations. Consider monitoring for patterns or establishing known exceptions for specific users or roles where appropriate.\n\n### Response and Remediation\n\n- **Immediate Access Review**: If the policy attachment is unauthorized, consider detaching the policy and reviewing the permissions granted to the initiating user.\n- **Restrict Role Modification Permissions**: Limit which users or roles can attach policies to critical IAM roles. Apply least privilege principles to reduce the risk of unauthorized policy changes.\n- **Enhance Monitoring and Alerts**: Enable real-time alerts and monitoring on IAM policy modifications to detect similar actions promptly.\n- **Regular Policy Audits**: Conduct periodic audits of IAM policies and role permissions to ensure that unauthorized changes are quickly identified and addressed.\n\n### Additional Information\n\nFor more information on managing IAM policies and roles in AWS environments, refer to the [AWS IAM Documentation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) and AWS security best practices.\n", - "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"AttachRolePolicy\"\n and event.outcome: \"success\"\n and not aws.cloudtrail.flattened.request_parameters.policyArn: arn\\:aws\\:iam\\:\\:aws\\:policy*\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.policyArn", - "type": "unknown" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "f6d07a70-9ad0-11ef-954f-f661ea17fbcd", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Resources: Investigation Guide", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/", - "subtechnique": [ - { - "id": "T1548.005", - "name": "Temporary Elevated Cloud Access", - "reference": "https://attack.mitre.org/techniques/T1548/005/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 2 - }, - "id": "f6d07a70-9ad0-11ef-954f-f661ea17fbcd_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_3.json b/packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_3.json deleted file mode 100644 index e1d7d96bff6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/fd332492-0bc6-11ef-b5be-f661ea17fbcc_3.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the `withDecryption` parameter set to true. This is a [NewTerms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that detects the first occurrence of a specific AWS ARN accessing SecureString parameters with decryption within the last 10 days.", - "false_positives": [ - "Users may legitimately access AWS Systems Manager (SSM) parameters using the GetParameter, GetParameters, or DescribeParameters API actions with credentials in the request parameters. Ensure that the user has a legitimate reason to access the parameters and that the credentials are secured." - ], - "from": "now-9m", - "history_window_start": "now-10d", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS Systems Manager SecureString Parameter Request with Decryption Flag", - "new_terms_fields": [ - "aws.cloudtrail.user_identity.arn" - ], - "note": "## Triage and analysis\n\n### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag\n\nThis rule detects when an AWS resource accesses SecureString parameters within AWS Systems Manager (SSM) with the decryption flag set to true. SecureStrings are encrypted using a KMS key, and accessing these with decryption can indicate attempts to access sensitive data.\n\nAdversaries may target SecureStrings to retrieve sensitive information such as encryption keys, passwords, and other credentials that are stored securely. Accessing these parameters with decryption enabled is particularly concerning because it implies the adversary is attempting to bypass the encryption to obtain plain text values that can be immediately used or exfiltrated. This behavior might be part of a larger attack strategy aimed at escalating privileges or moving laterally within an environment to access protected data or critical infrastructure.\n\n#### Possible Investigation Steps\n\n- **Review the Access Event**: Identify the specific API call (`GetParameter` or `GetParameters`) that triggered the rule. Examine the `request_parameters` for `withDecryption` set to true and the name of the accessed parameter.\n- **Verify User Identity and Access Context**: Check the `user_identity` details to understand who accessed the parameter and their role within the organization. This includes checking the ARN and access key ID to determine if the access was authorized.\n - **User ID**: Review the `user.id` field to identify the specific user or role that initiated the API call. Note that the ARN associated may be an assumed role and may not directly correspond to a human user.\n- **Contextualize with User Behavior**: Assess whether the access pattern fits the user\u2019s normal behavior or job responsibilities. Investigate any out-of-pattern activities around the time of the event.\n- **Analyze Geographic and IP Context**: Using the `source.ip` and `source.geo` information, verify if the request came from a trusted location or if there are any anomalies that suggest a compromised account.\n- **Inspect Related CloudTrail Events**: Look for other related events in CloudTrail to see if there was unusual activity before or after this event, such as unusual login attempts, changes to permissions, or other API calls that could indicate broader unauthorized actions.\n\n### False Positive Analysis\n\n- **Legitimate Administrative Use**: Verify if the decryption of SecureString parameters is a common practice for the user\u2019s role, particularly if used in automation scripts or deployment processes like those involving Terraform or similar tools.\n- **Authorized Access**: Ensure that the user or role has a legitimate reason to access the SecureString parameters and that the access is part of their expected job responsibilities.\n\n### Response and Remediation\n\n- **Immediate Verification**: Contact the user or team responsible for the API call to verify their intent and authorization.\n- **Review and Revise Permissions**: If the access was unauthorized, review the permissions assigned to the user or role to ensure they align with the principle of least privilege.\n- **Audit Parameter Access Policies**: Ensure that policies governing access to SecureString parameters are strict and audit logs are enabled to track access with decryption.\n- **Incident Response**: If suspicious activity is confirmed, follow through with your organization's incident response plan to mitigate any potential security issues.\n- **Enhanced Monitoring and Alerting**: Strengthen monitoring rules to detect unusual accesses to SecureString parameters, especially those that involve decryption.\n\n### Additional Information\n\nThis rule focuses solely on SecureStrings in AWS Systems Manager (SSM) parameters. SecureStrings are encrypted using an AWS Key Management Service (KMS) key. When a user accesses a SecureString parameter, they can specify whether the parameter should be decrypted. If the user specifies that the parameter should be decrypted, the decrypted value is returned in the response.\n", - "query": "event.dataset: aws.cloudtrail\n and event.provider: \"ssm.amazonaws.com\"\n and event.action: (GetParameters or GetParameter)\n and event.outcome: success\n and aws.cloudtrail.flattened.request_parameters.withDecryption: true\n and not source.address: (\n \"cloudformation.amazonaws.com\" or\n \"servicecatalog.amazonaws.com\"\n )\n", - "references": [ - "https://docs.aws.amazon.com/vsts/latest/userguide/systemsmanager-getparameter.html", - "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.flattened.request_parameters.withDecryption", - "type": "unknown" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.address", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "fd332492-0bc6-11ef-b5be-f661ea17fbcc", - "setup": "This rule requires that AWS CloudTrail logs are ingested into the Elastic Stack. Ensure that the AWS integration is properly configured to collect AWS CloudTrail logs. This rule also requires event logging for AWS Systems Manager (SSM) API actions which can be enabled in CloudTrail's data events settings.\n", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS Systems Manager", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1555", - "name": "Credentials from Password Stores", - "reference": "https://attack.mitre.org/techniques/T1555/", - "subtechnique": [ - { - "id": "T1555.006", - "name": "Cloud Secrets Management Stores", - "reference": "https://attack.mitre.org/techniques/T1555/006/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 3 - }, - "id": "fd332492-0bc6-11ef-b5be-f661ea17fbcc_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 1c4f4dac9ec..588225a5ebd 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.9 +version: 9.0.10-beta.1 From 08fb97bc6b390256bc4ef254335db15b29caeaa4 Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 5 Aug 2025 02:37:26 -0400 Subject: [PATCH 09/13] [Security Rules] Update security rules package to v9.0.10 (#14807) --- packages/security_detection_engine/changelog.yml | 5 +++++ packages/security_detection_engine/manifest.yml | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index a293a9a632f..b1911c38052 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.10 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14807 - version: 9.0.10-beta.1 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 588225a5ebd..7a192fa9cee 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.10-beta.1 +version: 9.0.10 From a81610859b6728231ef7845db9e747a7dbfc439e Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Wed, 6 Aug 2025 00:22:01 -0400 Subject: [PATCH 10/13] [Security Rules] Update security rules package to v9.0.11-beta.1 (#14825) --- .../security_detection_engine/changelog.yml | 5 + ...83383af-b9a4-42b7-a463-29c40efe7797_3.json | 81 ++++++++++++ ...cd2f3e6-41da-40e6-b28b-466f688f00a6_6.json | 42 ++++++ ...d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json | 90 +++++++++++++ ...2d30a-5f3e-4b71-bc3d-4a0c4914b7e0_102.json | 63 +++++++++ ...e1af929-42ed-4262-a846-55a7c54e7c84_3.json | 43 ++++++ ...e524fa6-eed3-11ef-82b4-f661ea17fbce_3.json | 65 +++++++++ ...6acac42-b2f9-4802-9290-d6c30914db6e_2.json | 64 +++++++++ ...7261da3-a6d0-463c-aac8-ea1718afcd20_5.json | 50 +++++++ ...f6b23-3799-445e-9589-0018328a9e46_203.json | 125 ------------------ ...9be0164-63d2-11ef-8e38-f661ea17fbce_4.json | 52 ++++++++ ...f45720e-5ea8-11ef-90d2-f661ea17fbce_4.json | 58 ++++++++ ...fa350e0-0aa2-4055-bf8f-ab8b59233e59_5.json | 55 ++++++++ ...18264-2d6d-11ef-9413-f661ea17fbce_206.json | 78 +++++++++++ ...66bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_3.json | 43 ++++++ ...68dba-ce29-497b-8e13-b4fde1db5a2d_414.json | 79 +++++++++++ ...8371aa1-14ed-46cf-ab5b-2fc7d1942278_4.json | 57 ++++++++ ...d6f5332-42ea-11f0-b09a-f661ea17fbcd_2.json | 81 ++++++++++++ ...6e1bc-867a-11ee-b13e-f661ea17fbcd_307.json | 63 +++++++++ ...216949c-9300-4c53-b57a-221e364c6457_3.json | 43 ++++++ ...b3cfa-6c67-11ef-ab4d-f661ea17fbcc_106.json | 81 ++++++++++++ ...6188365-f88f-4f70-8c1d-0b9554186b9c_3.json | 64 +++++++++ ...75132c6-25d5-11f0-8745-f661ea17fbcd_3.json | 67 ++++++++++ ...93ef120-63d1-11ef-8e38-f661ea17fbce_5.json | 63 +++++++++ ...fac01b2-b811-11ef-b25b-f661ea17fbce_4.json | 66 +++++++++ ...021e78d-5293-48d3-adee-a70fa4c18fab_3.json | 40 ++++++ ...182e486-fc61-11ee-a05d-f661ea17fbce_7.json | 58 ++++++++ ...98e4094-60e7-11f0-8847-f661ea17fbcd_3.json | 59 +++++++++ ...f855297-c8e0-4097-9d97-d653f7e471c4_7.json | 43 ++++++ ...f0234fd-7f21-42af-8391-511d5fd11d5c_5.json | 93 +++++++++++++ ...4f17c52-6c6e-479e-ba72-236f3df18f3d_4.json | 81 ++++++++++++ ...756ee27-9152-479b-9b73-54b5bbda301c_2.json | 75 +++++++++++ ...b341d03-1d63-41ac-841a-2009c86959ca_5.json | 55 ++++++++ ...ddb6c33-00ce-4acd-832a-24b251512023_4.json | 81 ++++++++++++ ...13e0f5f-caf7-4dc2-88a7-3561f61f262a_2.json | 61 +++++++++ ...20fc1aa-e195-4a1d-81d8-04edfe5313ed_2.json | 89 +++++++++++++ ...25a048a-88c5-4fc7-8677-a44fc0031822_5.json | 52 ++++++++ ...4f45152-9aee-11ef-b0a5-f661ea17fbcd_3.json | 62 +++++++++ ...7122db4-5876-4127-b91b-6c179eb21f88_5.json | 94 +++++++++++++ ...fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json | 57 ++++++++ ...5e2d45e-a3df-4acf-83d3-21805f564ff4_3.json | 81 ++++++++++++ ...60f2a03-a1cf-48d6-a674-c6d62ae608a1_5.json | 55 ++++++++ ...94b7cc9-040b-427c-aca5-36b40d3667bf_4.json | 101 ++++++++++++++ ...a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_5.json | 101 ++++++++++++++ ...eeeda11-dca6-4c3e-910f-7089db412d1c_5.json | 59 +++++++++ ...734c0-2cda-11ef-84e1-f661ea17fbce_206.json | 78 +++++++++++ ...99adc-2cda-11ef-84e1-f661ea17fbce_206.json | 78 +++++++++++ ...76b2391-413f-4a94-acb4-7911f3803346_5.json | 101 ++++++++++++++ ...aa4be8d-5828-417d-9f54-7cd304571b24_7.json | 102 ++++++++++++++ ...edd1804-83c7-4e48-b97d-c776b4c97564_3.json | 81 ++++++++++++ ...f432a8b-9588-4550-838e-1f77285580d3_4.json | 81 ++++++++++++ ...b8f074c-5565-4bc4-991c-d49770e19fc9_6.json | 59 +++++++++ ...0450411-46e5-46d2-9b35-8b5dd9ba763e_3.json | 40 ++++++ ...0c98cfb-0745-4513-b6f9-08dddb033490_3.json | 81 ++++++++++++ ...1773d05-f349-45fb-9850-287b8f92f02d_5.json | 42 ++++++ ...04be7e0-b0fc-11ef-a826-f661ea17fbce_3.json | 60 +++++++++ ...07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json | 68 ++++++++++ ...5637438-e32d-4bb3-bc13-bd7932b3289f_5.json | 94 +++++++++++++ ...6655282-6c79-11ef-bbb5-f661ea17fbcc_2.json | 57 -------- ...6655282-6c79-11ef-bbb5-f661ea17fbcc_3.json | 58 -------- ...6655282-6c79-11ef-bbb5-f661ea17fbcc_4.json | 58 -------- ...82a2e-7e52-11ee-9aac-f661ea17fbcd_307.json | 56 ++++++++ ...ca64114-fb8b-11ef-86e2-f661ea17fbce_4.json | 82 ++++++++++++ ...43f2b43-02a1-4219-8ce9-10929a32a618_3.json | 81 ++++++++++++ ...de13d58-bc39-4aa0-87fd-b4bdbf4591da_6.json | 86 ++++++++++++ ...e67f85e-2d43-11f0-b8c9-f661ea17fbcc_3.json | 56 ++++++++ ...f919b5e-a0f6-4fd8-8598-e3ce79299e3b_6.json | 86 ++++++++++++ ...3bd85e9-7aff-46eb-b60e-20dfc9020d98_2.json | 60 +++++++++ ...903ce9a-5ce6-4246-bb14-75ed3ec2edf5_5.json | 81 ++++++++++++ ...2c653b7-7daf-4774-86f2-34cdbd1fc528_3.json | 42 ++++++ ...33e68a4-bd19-11ed-b02f-f661ea17fbcc_8.json | 108 --------------- ...38633f4-3b31-4c80-b13d-e77c70ce8254_3.json | 81 ++++++++++++ ...4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_5.json | 42 ++++++ ...6d8c743-0916-4483-8333-3c6f107e0caa_4.json | 81 ++++++++++++ ...770ce79-05fd-4d74-9866-1c5d66c9b34b_2.json | 54 ++++++++ ...9753455-8d55-4ad8-b70a-e07b6f18deea_2.json | 81 ++++++++++++ ...9abcddc-a05d-4345-a81d-000b79aa5525_4.json | 81 ++++++++++++ ...b16f9ef-cb03-4234-adc2-44641f3b71ee_3.json | 37 ++++++ .../security_detection_engine/manifest.yml | 2 +- 79 files changed, 4903 insertions(+), 407 deletions(-) create mode 100644 packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_102.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_5.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_203.json create mode 100644 packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_206.json create mode 100644 packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_414.json create mode 100644 packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_307.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_106.json create mode 100644 packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_206.json create mode 100644 packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_206.json create mode 100644 packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_5.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_307.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_8.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_3.json diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index b1911c38052..7d062a40db0 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.11-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14825 - version: 9.0.10 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_3.json b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_3.json new file mode 100644 index 00000000000..258b9a54a78 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating commands to evade detection, often using concatenated strings in dynamic invocations. This detection rule identifies such obfuscation by analyzing script patterns, specifically looking for concatenated strings within dynamic command invocations, which are indicative of attempts to bypass security measures like AMSI. By counting these patterns, the rule effectively flags suspicious scripts, aiding in the identification of potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content and purpose of the script, focusing on the concatenated strings and dynamic command invocations.\n- Check the `host.name` and `user.id` fields to identify the machine and user account associated with the execution of the suspicious script, which can help determine if the activity is expected or anomalous.\n- Analyze the `file.path` field to locate the script's source or storage location, which may provide additional context or indicate if the script is part of a known application or process.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related PowerShell activities, which might reveal a broader pattern of behavior.\n- Assess the `agent.id` field to determine the specific endpoint agent involved, which can assist in further endpoint-specific investigations or actions.\n\n### False positive analysis\n\n- Scripts with legitimate concatenated strings for dynamic command execution may trigger the rule. Review the script context to determine if the concatenation serves a valid administrative purpose.\n- Automated scripts from trusted sources that use concatenation for modularity or readability might be flagged. Consider adding these scripts to an allowlist if they are verified as safe.\n- Development or testing environments where PowerShell scripts are frequently modified and tested could generate false positives. Implement exceptions for known development hosts or user accounts.\n- Security tools or monitoring solutions that use PowerShell for legitimate operations may inadvertently match the pattern. Identify these tools and exclude their operations from the rule.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated commands.\n- Conduct a thorough review of the script block text and associated script block ID to understand the intent and potential impact of the obfuscated commands.\n- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and signed.\n- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that all data integrity checks are performed.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems have been compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques, leveraging insights from the MITRE ATT&CK framework.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*+*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"[.&]\\(\\s*(['\"][A-Za-z0-9.-]+['\"]\\s*\\+\\s*)+['\"][A-Za-z0-9.-]+['\"]\\s*\\)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "083383af-b9a4-42b7-a463-29c40efe7797", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "083383af-b9a4-42b7-a463-29c40efe7797_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_6.json b/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_6.json new file mode 100644 index 00000000000..cf63913a193 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_6.json @@ -0,0 +1,42 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.", + "false_positives": [ + "Legitimate misunderstanding by users or overly strict policies" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account that caused multiple policy violations over a session and whether it should perform this kind of action.\n- Investigate the user activity that might indicate a potential brute force attack.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Filter for compliance violations detected\n| where gen_ai.compliance.violation_detected\n\n// keep relevant ECS + model fields\n| keep\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// count violations by user, model, and account\n| stats\n Esql.ml_violations_count = count(*)\n by\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// Filter for repeated violations\n| where Esql.ml_violations_count > 1\n\n// sort descending by violation volume\n| sort Esql.ml_violations_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json new file mode 100644 index 00000000000..7d1705ba864 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json @@ -0,0 +1,90 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services.", + "false_positives": [ + "This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved." + ], + "from": "now-1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Session Reuse with Suspicious Graph Access", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Session Reuse with Suspicious Graph Access\n\nThis rule identifies when Microsoft Graph is accessed from a different IP than the one used for the original sign-in,\nbut using the same session ID within 5 minutes. This may suggest an adversary has stolen a session cookie or refresh/access\ntoken and is impersonating the user from an alternate host or location.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be\nperformed to the original sign-in and Graph events for further context.\n\n### Investigation Steps\n\n- Review the `user_id`, `session_id`, and `source_ip_list`. Confirm whether both IPs belong to the same user and geography.\n- Check for inconsistencies in `client_id_list` (e.g., unknown apps) or user agents across correlated events.\n- Investigate recent phishing reports or device infections for the `user_id`.\n- Pivot to Entra ID `auditlogs` to see if a device was registered or privileges were modified.\n- Review `graph_time` to determine what action was taken after the sign-in.\n- Use the `session_id` to correlate with other logs in the same time window to identify any additional suspicious activity.\n\n### False Positive Analysis\n- This pattern may occur if the user is switching between networks (e.g., corporate to mobile) or using a VPN.\n- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges.\n- However, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.\n- If the user is a developer or automation engineer, validate if this behavior was for testing purposes.\n- If the user is a system administrator, validate if this behavior was for administrative purposes.\n\n### Response Recommendations\n\n- If confirmed malicious, revoke all refresh/access tokens for the `user_id`.\n- Block the source IP(s) involved in the Graph access.\n- Notify the user and reset credentials.\n- Review session control policies and conditional access enforcement.\n- Monitor for follow-on activity, such as lateral movement or privilege escalation.\n- Review conditional access policies to ensure they are enforced correctly.\n", + "query": "from logs-azure.*\n| where\n (event.dataset == \"azure.signinlogs\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n and azure.signinlogs.properties.session_id is not null)\n or\n (event.dataset == \"azure.graphactivitylogs\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n and azure.graphactivitylogs.properties.c_sid is not null)\n\n| eval\n Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid),\n Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id),\n Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id),\n Esql.source_ip = source.ip,\n Esql.@timestamp = @timestamp,\n Esql.event_type_case = case(\n event.dataset == \"azure.signinlogs\", \"signin\",\n event.dataset == \"azure.graphactivitylogs\", \"graph\",\n \"other\"\n ),\n Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)\n\n| keep\n Esql.azure_signinlogs_properties_session_id_coalesce,\n Esql.source_ip,\n Esql.@timestamp,\n Esql.event_type_case,\n Esql.time_window_date_trunc,\n Esql.azure_signinlogs_properties_user_id_coalesce,\n Esql.azure_signinlogs_properties_app_id_coalesce\n\n| stats\n Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce),\n Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce),\n Esql.source_ip_values = values(Esql.source_ip),\n Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),\n Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce),\n Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce),\n Esql.event_type_case_values = values(Esql.event_type_case),\n Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case),\n Esql.@timestamp.min = min(Esql.@timestamp),\n Esql.@timestamp.max = max(Esql.@timestamp),\n Esql.signin_time_min = min(case(Esql.event_type_case == \"signin\", Esql.@timestamp, null)),\n Esql.graph_time_min = min(case(Esql.event_type_case == \"graph\", Esql.@timestamp, null)),\n Esql.event_count = count()\n by Esql.azure_signinlogs_properties_session_id_coalesce, Esql.time_window_date_trunc\n\n| eval\n Esql.event_duration_minutes_date_diff = date_diff(\"minutes\", Esql.@timestamp.min, Esql.@timestamp.max),\n Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff(\"minutes\", Esql.signin_time_min, Esql.graph_time_min)\n\n| where\n Esql.event_type_case_count_distinct > 1 and\n Esql.source_ip_count_distinct > 1 and\n Esql.event_duration_minutes_date_diff <= 5 and\n Esql.signin_time_min is not null and\n Esql.graph_time_min is not null and\n Esql.event_signin_to_graph_delay_minutes_date_diff >= 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://attack.mitre.org/techniques/T1078/004/" + ], + "risk_score": 73, + "rule_id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc", + "setup": "#### Required Microsoft Entra ID Sign-In and Graph Activity Logs\nThis rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Data Source: Microsoft Graph", + "Data Source: Microsoft Graph Activity Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion", + "Tactic: Initial Access" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_102.json b/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_102.json new file mode 100644 index 00000000000..c2672e838b6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_102.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts.", + "false_positives": [ + "Highly distributed environments (e.g., globally deployed automation or edge nodes) may cause a single IAM user to appear from multiple IPs. Review the geolocation, network context, and user agent patterns to rule out benign use." + ], + "from": "now-32m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Access Token Used from Multiple Addresses", + "note": "## Triage and Analysis\n\n### Investigating AWS Access Token Used from Multiple Addresses\n\nAccess tokens are bound to a single user. Usage from multiple IP addresses may indicate the token was stolen and used elsewhere. By correlating this with additional detection criteria like multiple user agents, different cities, and different networks, we can improve the fidelity of the rule and help to eliminate false positives associated with expected behavior, like dual-stack IPV4/IPV6 usage.\n\n#### Possible Investigation Steps\n\n- **Identify the IAM User**: Examine the `aws.cloudtrail.user_identity.arn` stored in `user_id` and correlate with the `source.ips` stored in `ip_list` and `unique_ips` count to determine how widely the token was used.\n- **Correlate Additional Detection Context**: Examine `activity_type` and `fidelity_score` to determine additional cities, networks or user agents associated with the token usage.\n- **Determine Access Key Type**: Examine the `access_key_id` to determine whether the token is short-term (beginning with ASIA) or long-term (beginning with AKIA).\n- **Check Recent MFA Events**: Determine whether the user recently enabled MFA, registered devices, or assumed a role using this token.\n- **Review Workload Context**: Confirm whether the user was expected to be active across multiple cities, networks or user agent environments.\n- **Trace Adversary Movement**: Pivot to related actions (e.g., `s3:ListBuckets`, `iam:ListUsers`, `sts:GetCallerIdentity`) to track further enumeration.\n\n### False Positive Analysis\n\n- Automation frameworks that rotate through multiple IPs or cloud functions with dynamic egress IPs may cause this alert to fire.\n- Confirm geolocation and workload context before escalating.\n\n### Response and Remediation\n\n- **Revoke the Token**: Disable or rotate the IAM credentials and invalidate the temporary session token.\n- **Audit the Environment**: Look for signs of lateral movement or data access during the token's validity.\n- **Strengthen Controls**: Require MFA for high-privilege actions, restrict access via policy conditions (e.g., IP range or device).\n\n### References\n\n- [IAM Long-Term Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)\n- [STS Temporary Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)\n- [Using MFA with Temporary Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)\n- [AWS Threat Detection Use Cases](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html)\n", + "query": "from logs-aws.cloudtrail* metadata _id, _version, _index\n| where @timestamp > now() - 30 minutes\n and event.dataset == \"aws.cloudtrail\"\n and aws.cloudtrail.user_identity.arn is not null\n and aws.cloudtrail.user_identity.type == \"IAMUser\"\n and source.ip is not null\n and not (\n user_agent.original like \"%Terraform%\" or\n user_agent.original like \"%Ansible%\" or\n user_agent.original like \"%Pulumni%\"\n )\n and `source.as.organization.name` != \"AMAZON-AES\"\n and event.provider not in (\n \"health.amazonaws.com\", \"monitoring.amazonaws.com\", \"notifications.amazonaws.com\",\n \"ce.amazonaws.com\", \"cost-optimization-hub.amazonaws.com\",\n \"servicecatalog-appregistry.amazonaws.com\", \"securityhub.amazonaws.com\"\n )\n\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql.aws_cloudtrail_user_identity_arn = aws.cloudtrail.user_identity.arn,\n Esql.aws_cloudtrail_user_identity_access_key_id = aws.cloudtrail.user_identity.access_key_id,\n Esql.source_ip = source.ip,\n Esql.user_agent_original = user_agent.original,\n Esql.source_ip_string = to_string(source.ip),\n Esql.source_ip_user_agent_pair = concat(Esql.source_ip_string, \" - \", user_agent.original),\n Esql.source_ip_city_pair = concat(Esql.source_ip_string, \" - \", source.geo.city_name),\n Esql.source_geo_city_name = source.geo.city_name,\n Esql.event_timestamp = @timestamp,\n Esql.source_network_org_name = `source.as.organization.name`\n\n| stats\n Esql.event_action_values = values(event.action),\n Esql.event_provider_values = values(event.provider),\n Esql.aws_cloudtrail_user_identity_access_key_id_values = values(Esql.aws_cloudtrail_user_identity_access_key_id),\n Esql.aws_cloudtrail_user_identity_arn_values = values(Esql.aws_cloudtrail_user_identity_arn),\n Esql.source_ip_values = values(Esql.source_ip),\n Esql.user_agent_original_values = values(Esql.user_agent_original),\n Esql.source_ip_user_agent_pair_values = values(Esql.source_ip_user_agent_pair),\n Esql.source_geo_city_name_values = values(Esql.source_geo_city_name),\n Esql.source_ip_city_pair_values = values(Esql.source_ip_city_pair),\n Esql.source_network_org_name_values = values(Esql.source_network_org_name),\n Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),\n Esql.user_agent_original_count_distinct = count_distinct(Esql.user_agent_original),\n Esql.source_geo_city_name_count_distinct = count_distinct(Esql.source_geo_city_name),\n Esql.source_network_org_name_count_distinct = count_distinct(Esql.source_network_org_name),\n Esql.timestamp_first_seen = min(Esql.event_timestamp),\n Esql.timestamp_last_seen = max(Esql.event_timestamp),\n Esql.event_count = count()\n by Esql.time_window_date_trunc, Esql.aws_cloudtrail_user_identity_access_key_id\n\n| eval\n Esql.activity_type = case(\n Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, \"multiple_ip_network_city_user_agent\",\n Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, \"multiple_ip_network_city\",\n Esql.source_ip_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, \"multiple_ip_and_city\",\n Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2, \"multiple_ip_and_network\",\n Esql.source_ip_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, \"multiple_ip_and_user_agent\",\n \"normal_activity\"\n ),\n Esql.activity_fidelity_score = case(\n Esql.activity_type == \"multiple_ip_network_city_user_agent\", \"high\",\n Esql.activity_type == \"multiple_ip_network_city\", \"high\",\n Esql.activity_type == \"multiple_ip_and_city\", \"medium\",\n Esql.activity_type == \"multiple_ip_and_network\", \"medium\",\n Esql.activity_type == \"multiple_ip_and_user_agent\", \"low\"\n )\n\n| keep\n Esql.time_window_date_trunc,\n Esql.activity_type,\n Esql.activity_fidelity_score,\n Esql.event_count,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.aws_cloudtrail_user_identity_arn_values,\n Esql.aws_cloudtrail_user_identity_access_key_id_values,\n Esql.event_action_values,\n Esql.event_provider_values,\n Esql.source_ip_values,\n Esql.user_agent_original_values,\n Esql.source_ip_user_agent_pair_values,\n Esql.source_geo_city_name_values,\n Esql.source_ip_city_pair_values,\n Esql.source_network_org_name_values,\n Esql.source_ip_count_distinct,\n Esql.user_agent_original_count_distinct,\n Esql.source_geo_city_name_count_distinct,\n Esql.source_network_org_name_count_distinct\n\n| where Esql.activity_type != \"normal_activity\"\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" + ], + "risk_score": 47, + "rule_id": "0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Data Source: AWS CloudTrail", + "Tactic: Initial Access", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 102 + }, + "id": "0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_102", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_3.json b/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_3.json new file mode 100644 index 00000000000..07636eb58a0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_3.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Denied Sensitive Information Policy Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Denied Sensitive Information Policy Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"sensitive information filters\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories.\n\n#### Possible investigation steps\n\n- Identify the user account that queried sensitive information and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-valued policy name field\n| mv_expand gen_ai.policy.name\n\n// Filter for blocked actions related to sensitive info policy\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.compliance.violation_detected == \"true\"\n and gen_ai.policy.name == \"sensitive_information_policy\"\n\n// keep only relevant fields\n| keep user.id\n\n// count how many times each user triggered a sensitive info block\n| stats\n Esql.ml_policy_blocked_sensitive_info_count = count()\n by user.id\n\n// Filter for users with more than 5 violations\n| where Esql.ml_policy_blocked_sensitive_info_count > 5\n\n// sort highest to lowest\n| sort Esql.ml_policy_blocked_sensitive_info_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "0e1af929-42ed-4262-a846-55a7c54e7c84", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "0e1af929-42ed-4262-a846-55a7c54e7c84_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_3.json new file mode 100644 index 00000000000..1af8466c6ad --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_3.json @@ -0,0 +1,65 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive.", + "false_positives": [ + "Legitimate users may download files from OneDrive using OAuth authentication. Ensure that the downloads are authorized and the user is known before taking action." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "M365 OneDrive Excessive File Downloads with OAuth Token", + "note": "## Triage and Analysis\n\n### Investigating M365 OneDrive Excessive File Downloads with OAuth Token\n\nThis rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique.\n\nThis rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested.\n\n#### Possible Investigation Steps\n\n- Review the `o365.audit.UserId` field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive.\n- Correlate `o365.audit.UserId` with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user.\n- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user.\n- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application.\n- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration.\n- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved.\n- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed.\n- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise.\n- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication.\n- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access.\n- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity.\n- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded.\n\n### False Positive Analysis\n\n- Verify if the user regularly downloads large batches of files as part of their job function.\n- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool.\n- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns.\n\n### Response and Remediation\n\n- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions.\n- Reset the affected user's password and require reauthentication to prevent continued unauthorized access.\n- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications.\n- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts.\n- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks.\n- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools.\n", + "query": "from logs-o365.audit-*\n| where\n @timestamp > now() - 14d and\n event.dataset == \"o365.audit\" and\n event.provider == \"OneDrive\" and\n event.action == \"FileDownloaded\" and\n o365.audit.AuthenticationType == \"OAuth\" and\n event.outcome == \"success\"\n| eval\n Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)\n| keep\n Esql.time_window_date_trunc,\n o365.audit.UserId,\n file.name,\n source.ip\n| stats\n Esql.file_name_count_distinct = count_distinct(file.name),\n Esql.event_count = count(*)\n by\n Esql.time_window_date_trunc,\n o365.audit.UserId,\n source.ip\n| where\n Esql.file_name_count_distinct >= 25\n", + "references": [ + "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/" + ], + "risk_score": 47, + "rule_id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: SharePoint", + "Data Source: OneDrive", + "Use Case: Threat Detection", + "Tactic: Collection", + "Tactic: Exfiltration", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_2.json b/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_2.json new file mode 100644 index 00000000000..55acd25f0ee --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_2.json @@ -0,0 +1,64 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a JavaScript file is uploaded or accessed in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend.", + "false_positives": [ + "Development or deployment pipelines that update static frontends frequently (e.g., React/Vue apps) may trigger this. Verify the user agent, source IP, and whether the modification was expected." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS S3 Static Site JavaScript File Uploaded", + "note": "## Triage and Analysis\n\n### Investigating AWS S3 Static Site JavaScript File Uploaded\n\nAn S3 `PutObject` action that targets a path like `static/js/` and uploads a `.js` file is a potential signal for web content modification. If done by an unexpected IAM user or outside of CI/CD workflows, it may indicate a compromise.\n\n#### Possible Investigation Steps\n\n- **Identify the Source User**: Check `aws.cloudtrail.user_identity.arn`, access key ID, and session type (`IAMUser`, `AssumedRole`, etc).\n- **Review File Content**: Use the S3 `GetObject` or CloudTrail `requestParameters` to inspect the uploaded file for signs of obfuscation or injection.\n- **Correlate to Other Events**: Review events from the same IAM user before and after the upload (e.g., `ListBuckets`, `GetCallerIdentity`, IAM activity).\n- **Look for Multiple Uploads**: Attackers may attempt to upload several files or modify multiple directories.\n\n### False Positive Analysis\n\n- This behavior may be expected during app deployments. Look at:\n - The `user_agent.original` to detect legitimate CI tools (like Terraform or GitHub Actions).\n - Timing patterns\u2014does this match a regular release window?\n - The origin IP and device identity.\n\n### Response and Remediation\n\n- **Revert Malicious Code**: Replace the uploaded JS file with a clean version and invalidate CloudFront cache if applicable.\n- **Revoke Access**: If compromise is confirmed, revoke the IAM credentials and disable the user.\n- **Audit IAM Policies**: Ensure that only deployment users can modify static site buckets.\n- **Enable Bucket Versioning**: This can allow for quick rollback and historical review.\n", + "query": "from logs-aws.cloudtrail* metadata _id, _version, _index\n\n| where\n // S3 object read/write activity\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action in (\"GetObject\", \"PutObject\")\n\n // IAM users or assumed roles only\n and aws.cloudtrail.user_identity.type in (\"IAMUser\", \"AssumedRole\")\n\n // Requests for static site bundles\n and aws.cloudtrail.request_parameters like \"*static/js/*.js*\"\n\n // Exclude IaC and automation tools\n and not (\n user_agent.original like \"*Terraform*\"\n or user_agent.original like \"*Ansible*\"\n or user_agent.original like \"*Pulumni*\"\n )\n\n// Extract fields from request parameters\n| dissect aws.cloudtrail.request_parameters\n \"%{{?bucket.name.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_name}, %{?host.key}=%{Esql_priv.aws_cloudtrail_request_parameters_host}, %{?bucket.object.location.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_object_location}}\"\n\n// Extract file name portion from full object path\n| dissect Esql.aws_cloudtrail_request_parameters_object_location \"%{}static/js/%{Esql.aws_cloudtrail_request_parameters_object_key}\"\n\n// Match on JavaScript files\n| where ends_with(Esql.aws_cloudtrail_request_parameters_object_key, \".js\")\n\n// Retain relevant ECS and dissected fields\n| keep\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.access_key_id,\n aws.cloudtrail.user_identity.type,\n aws.cloudtrail.request_parameters,\n Esql.aws_cloudtrail_request_parameters_bucket_name,\n Esql.aws_cloudtrail_request_parameters_object_key,\n user_agent.original,\n source.ip,\n event.action,\n @timestamp\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/", + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html" + ], + "risk_score": 47, + "rule_id": "16acac42-b2f9-4802-9290-d6c30914db6e", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Tactic: Impact", + "Use Case: Web Application Compromise", + "Use Case: Cloud Threat Detection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1565", + "name": "Data Manipulation", + "reference": "https://attack.mitre.org/techniques/T1565/", + "subtechnique": [ + { + "id": "T1565.001", + "name": "Stored Data Manipulation", + "reference": "https://attack.mitre.org/techniques/T1565/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "16acac42-b2f9-4802-9290-d6c30914db6e_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_5.json b/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_5.json new file mode 100644 index 00000000000..485ece5fd86 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_5.json @@ -0,0 +1,50 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.", + "false_positives": [ + "Legitimate misunderstanding by users or overly strict policies" + ], + "from": "now-60m", + "interval": "10m", + "investigation_fields": { + "field_names": [ + "user.id", + "cloud.account.id", + "gen_ai.request.model.id", + "total_denials" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User\n\nAmazon Bedrock is AWS\u2019s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.\n\nBedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.\n\n#### Possible investigation steps\n\n- Identify the user account that attempted to use denied models.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that attempted to use denied models, is a legitimate misunderstanding by users or overly strict policies.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Filter for access denied errors from GenAI responses\n| where gen_ai.response.error_code == \"AccessDeniedException\"\n\n// keep ECS and response fields\n| keep\n user.id,\n gen_ai.request.model.id,\n cloud.account.id,\n gen_ai.response.error_code\n\n// count total denials per user/model/account\n| stats\n Esql.ml_response_access_denied_count = count(*)\n by\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// Filter for users with repeated denials\n| where Esql.ml_response_access_denied_count > 3\n\n// sort by volume of denials\n| sort Esql.ml_response_access_denied_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0015", + "https://atlas.mitre.org/techniques/AML.T0034", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 73, + "rule_id": "17261da3-a6d0-463c-aac8-ea1718afcd20", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "high", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0015", + "Mitre Atlas: T0034" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "17261da3-a6d0-463c-aac8-ea1718afcd20_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_203.json b/packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_203.json deleted file mode 100644 index e0d5e0e9114..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/181f6b23-3799-445e-9589-0018328a9e46_203.json +++ /dev/null @@ -1,125 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the execution of scripts via HTML applications using Windows utilities rundll32.exe or mshta.exe. Adversaries may bypass process and/or signature-based defenses by proxying execution of malicious content with signed binaries.", - "from": "now-9m", - "index": [ - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*", - "logs-system.security*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Script Execution via Microsoft HTML Application", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Script Execution via Microsoft HTML Application\n\nMicrosoft HTML Applications (HTA) allow scripts to run in a trusted environment, often using utilities like `rundll32.exe` or `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns, such as unusual command lines or execution from common download locations, to flag potential abuse.\n\n### Possible investigation steps\n\n- Review the process command line details to identify any suspicious patterns or indicators of malicious activity, such as the presence of script execution commands like \"eval\", \"GetObject\", or \"WScript.Shell\".\n- Check the parent process executable path to determine if the process was spawned by a known legitimate application or if it deviates from expected behavior, especially if it is not from the specified exceptions like Citrix, Microsoft Office, or Quokka.Works GTInstaller.\n- Investigate the origin of the HTA file, particularly if it was executed from common download locations like the Downloads folder or temporary archive extraction paths, to assess if it was downloaded from the internet or extracted from an archive.\n- Analyze the process arguments and count to identify any unusual or unexpected parameters that could indicate malicious intent, especially if the process name is \"mshta.exe\" and the command line does not include typical HTA or HTM file references.\n- Correlate the event with other security logs and alerts from data sources like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and determine if this activity is part of a broader attack pattern.\n\n### False positive analysis\n\n- Execution of legitimate scripts by enterprise applications like Citrix, Microsoft Office, or Quokka.Works GTInstaller can trigger false positives. Users can mitigate this by adding these applications to the exclusion list in the detection rule.\n- Scripts executed by mshta.exe that do not involve malicious intent, such as internal web applications or administrative scripts, may be flagged. Users should review these scripts and, if deemed safe, exclude them based on specific command line patterns or parent processes.\n- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users can create exceptions for these sources by specifying trusted download paths or file hashes.\n- Temporary files created by legitimate software installations or updates in user temp directories can be misinterpreted as malicious. Users should monitor these activities and exclude known safe processes or directories from the detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further spread of the malicious script or unauthorized access.\n- Terminate any suspicious processes identified by the detection rule, specifically those involving `rundll32.exe` or `mshta.exe` with unusual command lines.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts.\n- Review and analyze the command lines and scripts executed to understand the scope and intent of the attack, and identify any additional compromised systems.\n- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated.\n- Implement network segmentation to limit the ability of similar threats to propagate across the network in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised.", - "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : (\"rundll32.exe\", \"mshta.exe\") and\n (\n (process.command_line :\n (\n \"*script*eval(*\",\n \"*script*GetObject*\",\n \"*.regread(*\",\n \"*WScript.Shell*\",\n \"*.run(*\",\n \"*).Exec()*\",\n \"*mshta*http*\",\n \"*mshtml*RunHTMLApplication*\",\n \"*mshtml*,#135*\",\n \"*StrReverse*\",\n \"*.RegWrite*\",\n /* Issue #379 */\n \"*window.close(*\",\n \"* Chr(*\"\n )\n and not process.parent.executable :\n (\"?:\\\\Program Files (x86)\\\\Citrix\\\\System32\\\\wfshell.exe\",\n \"?:\\\\Program Files (x86)\\\\Microsoft Office\\\\Office*\\\\MSACCESS.EXE\",\n \"?:\\\\Program Files\\\\Quokka.Works GTInstaller\\\\GTInstaller.exe\")\n ) or\n\n (process.name : \"mshta.exe\" and\n not process.command_line : (\"*.hta*\", \"*.htm*\", \"-Embedding\") and process.args_count >=2) or\n\n /* Execution of HTA file downloaded from the internet */\n (process.name : \"mshta.exe\" and process.command_line : \"*\\\\Users\\\\*\\\\Downloads\\\\*.hta*\") or\n\n /* Execution of HTA file from archive */\n (process.name : \"mshta.exe\" and\n process.args : (\"?:\\\\Users\\\\*\\\\Temp\\\\7z*\", \"?:\\\\Users\\\\*\\\\Temp\\\\Rar$*\", \"?:\\\\Users\\\\*\\\\Temp\\\\Temp?_*\", \"?:\\\\Users\\\\*\\\\Temp\\\\BNZ.*\"))\n )\n", - "related_integrations": [ - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "system", - "version": "^1.6.4" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.0.0" - }, - { - "package": "m365_defender", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args_count", - "type": "long" - }, - { - "ecs": true, - "name": "process.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.executable", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "181f6b23-3799-445e-9589-0018328a9e46", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Windows Security Event Logs", - "Data Source: Sysmon", - "Data Source: SentinelOne", - "Data Source: Microsoft Defender for Endpoint", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1218", - "name": "System Binary Proxy Execution", - "reference": "https://attack.mitre.org/techniques/T1218/", - "subtechnique": [ - { - "id": "T1218.005", - "name": "Mshta", - "reference": "https://attack.mitre.org/techniques/T1218/005/" - }, - { - "id": "T1218.011", - "name": "Rundll32", - "reference": "https://attack.mitre.org/techniques/T1218/011/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 203 - }, - "id": "181f6b23-3799-445e-9589-0018328a9e46_203", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_4.json new file mode 100644 index 00000000000..e711441058c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_4.json @@ -0,0 +1,52 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Service Quotas Multi-Region `GetServiceQuota` Requests", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS Service Quotas Multi-Region `GetServiceQuota` Requests\n\nAWS Service Quotas manage resource limits across AWS services, crucial for maintaining operational boundaries. Adversaries may exploit `GetServiceQuota` API calls to probe AWS infrastructure, seeking vulnerabilities for deploying threats like cryptocurrency miners. The detection rule identifies unusual multi-region queries for EC2 quotas, signaling potential credential compromise or unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs to identify the specific user or role associated with the `aws.cloudtrail.user_identity.arn` field that triggered the alert. Determine if this user or role should have access to multiple regions.\n- Examine the `cloud.region` field to identify which regions were accessed and verify if these regions are typically used by your organization. Investigate any unfamiliar regions for unauthorized activity.\n- Check the AWS IAM policies and permissions associated with the identified user or role to ensure they align with the principle of least privilege. Look for any recent changes or anomalies in permissions.\n- Investigate the source IP addresses and locations from which the `GetServiceQuota` API calls were made to determine if they match expected patterns for your organization. Look for any unusual or suspicious IP addresses.\n- Review recent activity logs for the identified user or role to detect any other unusual or unauthorized actions, such as attempts to launch EC2 instances or access other AWS services.\n- If a compromise is suspected, consider rotating the credentials for the affected user or role and implementing additional security measures, such as multi-factor authentication (MFA) and enhanced monitoring.\n\n### False positive analysis\n\n- Legitimate multi-region operations: Organizations with a global presence may have legitimate reasons for querying EC2 service quotas across multiple regions. To handle this, users can create exceptions for known accounts or roles that regularly perform such operations.\n- Automated infrastructure management tools: Some tools or scripts designed for infrastructure management might perform multi-region `GetServiceQuota` requests as part of their normal operation. Users should identify these tools and exclude their activity from triggering alerts by whitelisting their associated user identities or ARNs.\n- Testing and development activities: Developers or testers might intentionally perform multi-region queries during testing phases. Users can mitigate false positives by setting up temporary exceptions for specific time frames or user identities involved in testing.\n- Cloud service providers or partners: Third-party services or partners managing AWS resources on behalf of an organization might generate similar patterns. Users should establish trust relationships and exclude these entities from detection by verifying their activities and adding them to an exception list.\n\n### Response and remediation\n\n- Immediately isolate the AWS account or IAM user identified in the alert to prevent further unauthorized access. This can be done by disabling the access keys or suspending the account temporarily.\n- Conduct a thorough review of the AWS CloudTrail logs for the identified user or resource to determine the extent of the unauthorized activity and identify any other potentially compromised resources.\n- Rotate all access keys and passwords associated with the compromised account or IAM user to prevent further unauthorized access.\n- Implement additional security measures such as enabling multi-factor authentication (MFA) for all IAM users and roles to enhance account security.\n- Notify the security operations team and relevant stakeholders about the potential compromise and the steps being taken to remediate the issue.\n- If evidence of compromise is confirmed, consider engaging AWS Support or a third-party incident response team for further investigation and assistance.\n- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of future unauthorized access attempts.", + "query": "from logs-aws.cloudtrail-*\n\n// filter for GetServiceQuota API calls\n| where\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"servicequotas.amazonaws.com\"\n and event.action == \"GetServiceQuota\"\n\n// truncate the timestamp to a 30-second window\n| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp)\n\n// dissect request parameters to extract service and quota code\n| dissect aws.cloudtrail.request_parameters \"{%{?Esql.aws_cloudtrail_request_parameters_service_code_key}=%{Esql.aws_cloudtrail_request_parameters_service_code}, %{?quota_code_key}=%{Esql.aws_cloudtrail_request_parameters_quota_code}}\"\n\n// filter for EC2 service quota L-1216C47A (vCPU on-demand instances)\n| where Esql.aws_cloudtrail_request_parameters_service_code == \"ec2\" and Esql.aws_cloudtrail_request_parameters_quota_code == \"L-1216C47A\"\n\n// keep only the relevant fields\n| keep\n Esql.time_window_date_trunc,\n aws.cloudtrail.user_identity.arn,\n cloud.region,\n Esql.aws_cloudtrail_request_parameters_service_code,\n Esql.aws_cloudtrail_request_parameters_quota_code\n\n// count the number of unique regions and total API calls within the time window\n| stats\n Esql.cloud_region_count_distinct = count_distinct(cloud.region),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn\n\n// filter for API calls in more than 10 regions within the 30-second window\n| where\n Esql.cloud_region_count_distinct >= 10\n and Esql.event_count >= 10\n\n// sort by time window descending\n| sort Esql.time_window_date_trunc desc\n", + "references": [ + "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/", + "https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_GetServiceQuota.html" + ], + "risk_score": 21, + "rule_id": "19be0164-63d2-11ef-8e38-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Service Quotas", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "19be0164-63d2-11ef-8e38-f661ea17fbce_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_4.json new file mode 100644 index 00000000000..325b3346b35 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_4.json @@ -0,0 +1,58 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a federated user logs into the AWS Management Console without using multi-factor authentication (MFA). Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. This could also indicate the abuse of STS tokens to bypass MFA requirements.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Signin Single Factor Console Login with Federated User", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS Signin Single Factor Console Login with Federated User\n\nFederated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. The detection rule identifies instances where federated users log in without MFA, flagging potential security risks by analyzing specific AWS CloudTrail events and dissecting login data to check for the absence of MFA, thus helping to mitigate unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider, event.action, and aws.cloudtrail.user_identity.type fields to ensure the alert corresponds to a federated user login without MFA.\n- Identify the federated user involved by examining the aws.cloudtrail.user_identity.arn field to determine which user or service is associated with the login attempt.\n- Check the aws.cloudtrail.additional_eventdata field to verify the mfa_used value is \"No\" and assess if this is expected behavior for the identified user or service.\n- Investigate the source IP address and location of the login attempt to determine if it aligns with typical access patterns for the federated user.\n- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event.\n- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users.\n\n### False positive analysis\n\n- Federated users with specific roles or permissions may frequently log in without MFA due to operational requirements. Review these roles and consider adding them to an exception list if they are deemed non-threatening.\n- Automated processes or scripts using federated credentials might trigger this rule if they are not configured to use MFA. Verify these processes and, if legitimate, exclude them from the rule to prevent unnecessary alerts.\n- Temporary testing or development accounts might be set up without MFA for convenience. Ensure these accounts are monitored and, if necessary, excluded from the rule to avoid false positives.\n- Third-party integrations or services that rely on federated access without MFA could be flagged. Assess these integrations and whitelist them if they are secure and necessary for business operations.\n- Users accessing AWS from secure, controlled environments might not use MFA as part of a risk-based authentication strategy. Evaluate the security of these environments and consider excluding them if they meet your organization's security standards.\n\n### Response and remediation\n\n- Immediately revoke the temporary credentials associated with the federated user account to prevent further unauthorized access.\n- Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with the federated user account.\n- Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts.\n- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future.\n- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege.\n- Escalate the incident to the incident response team if any malicious activities are detected, and initiate a full security investigation to assess the impact and scope of the breach.\n- Monitor AWS CloudTrail and other relevant logs closely for any further unauthorized access attempts or anomalies related to federated user accounts.", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n| where\n event.provider == \"signin.amazonaws.com\"\n and event.action == \"GetSigninToken\"\n and aws.cloudtrail.event_type == \"AwsConsoleSignIn\"\n and aws.cloudtrail.user_identity.type == \"FederatedUser\"\n\n// Extract mobile version and MFA usage\n| dissect aws.cloudtrail.additional_eventdata\n \"{%{?mobile_version_key}=%{Esql.aws_cloudtrail_additional_eventdata_device_version}, %{?mfa_used_key}=%{Esql.aws_cloudtrail_additional_eventdata_auth_mfa_used}}\"\n\n// Only keep events where MFA was not used\n| where Esql.aws_cloudtrail_additional_eventdata_auth_mfa_used == \"No\"\n\n// keep relevant ECS and dissected fields\n| keep\n @timestamp,\n event.action,\n aws.cloudtrail.event_type,\n aws.cloudtrail.user_identity.type,\n Esql.aws_cloudtrail_additional_eventdata_device_version,\n Esql.aws_cloudtrail_additional_eventdata_auth_mfa_used\n", + "references": [ + "https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/" + ], + "risk_score": 47, + "rule_id": "1f45720e-5ea8-11ef-90d2-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Amazon Web Services", + "Data Source: AWS", + "Data Source: AWS Sign-In", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "1f45720e-5ea8-11ef-90d2-f661ea17fbce_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_5.json b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_5.json new file mode 100644 index 00000000000..a4a2192ad92 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_5.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "High Number of Egress Network Connections from Unusual Executable", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating High Number of Egress Network Connections from Unusual Executable\n\nIn Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment.\n- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious.\n- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity.\n- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host.\n- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns.\n- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement.\n\n### False positive analysis\n\n- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts.\n- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious.\n- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list.\n- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe.\n- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement.\n- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection.\n- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat.\n- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited.\n- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.\n", + "query": "from logs-endpoint.events.network-*\n| where\n @timestamp > now() - 1h and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\" and\n (\n process.executable like \"/tmp/*\" or\n process.executable like \"/var/tmp/*\" or\n process.executable like \"/dev/shm/*\" or\n process.name rlike \".*\"\n ) and not (\n cidr_match(destination.ip,\n \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\",\n \"192.0.0.0/24\", \"192.0.0.29/32\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\",\n \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\", \"198.18.0.0/15\",\n \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\", \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable like \"/nix/store/*\" or\n process.executable like \"/tmp/newroot/*\" or\n process.executable like \"/tmp/.mount*\" or\n process.executable like \"/tmp/go-build*\"\n )\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.name,\n process.executable,\n destination.ip,\n agent.id,\n host.name\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count > 15\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_206.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_206.json new file mode 100644 index 00000000000..50d5821f2de --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_206.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "High Number of Okta Device Token Cookies Generated for Authentication", + "note": "## Triage and analysis\n\n### Investigating High Number of Okta Device Token Cookies Generated for Authentication\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action rlike \"user\\.authentication(.*)\" or event.action == \"user.session.start\") and\n okta.debug_context.debug_data.request_uri == \"/api/v1/authn\" and\n okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| keep\n event.action,\n okta.debug_context.debug_data.dt_hash,\n okta.client.ip,\n okta.actor.alternate_id,\n okta.debug_context.debug_data.request_uri,\n okta.outcome.reason\n| stats\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)\n by\n okta.client.ip,\n okta.actor.alternate_id\n| where\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 30\n| sort\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 21, + "rule_id": "23f18264-2d6d-11ef-9413-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 206 + }, + "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_206", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_3.json b/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_3.json new file mode 100644 index 00000000000..4eaeeca9549 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_3.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Denied Topic Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Denied Topic Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account that queried denied topics and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-value policy name field\n| mv_expand gen_ai.policy.name\n\n// Filter for blocked topic policy violations\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.compliance.violation_detected == \"true\"\n and gen_ai.policy.name == \"topic_policy\"\n\n// keep only user info\n| keep user.id\n\n// count how many times each user triggered a blocked topic policy\n| stats\n Esql.ml_policy_blocked_topic_count = count()\n by user.id\n\n// Filter for excessive violations\n| where Esql.ml_policy_blocked_topic_count > 5\n\n// sort highest to lowest\n| sort Esql.ml_policy_blocked_topic_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_414.json b/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_414.json new file mode 100644 index 00000000000..e6e1723dffe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_414.json @@ -0,0 +1,79 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Willem D'Haese", + "Austin Songer" + ], + "description": "Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Microsoft 365 User Account Brute Force", + "note": "## Triage and Analysis\n\n### Investigating Potential Microsoft 365 User Account Brute Force\n\nIdentifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.\n\n### Possible investigation steps\n\n- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins).\n- Check `login_errors`: A consistent error such as `\"InvalidUserNameOrPassword\"` confirms a spray-style attack using one or a few passwords.\n- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers.\n- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation.\n- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins.\n- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded.\n- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA.\n\n### False positive analysis\n\n- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster.\n- Penetration testing or red team simulations may resemble spray activity.\n- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns.\n\n### Response and remediation\n\n- Initiate an internal incident ticket and inform the affected identity/IT team.\n- Temporarily disable impacted user accounts if compromise is suspected.\n- Investigate whether any login attempts succeeded after the spray window.\n- Block the offending IPs or ASN temporarily via firewall or conditional access policies.\n- Rotate passwords for all targeted accounts and audit for password reuse.\n- Enforce or verify MFA is enabled for all user accounts.\n- Consider deploying account lockout or progressive delay mechanisms if not already enabled.\n", + "query": "from logs-o365.audit-*\n| mv_expand event.category\n| eval\n Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp),\n Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId),\n Esql.o365_audit_LogonError = o365.audit.LogonError,\n Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType)\n| where\n event.dataset == \"o365.audit\" and\n event.category == \"authentication\" and\n event.provider in (\"AzureActiveDirectory\", \"Exchange\") and\n event.action in (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\") and\n Esql.o365_audit_ExtendedProperties_RequestType_lower rlike \"(oauth.*||.*login.*)\" and\n Esql.o365_audit_LogonError != \"IdsLocked\" and\n Esql.o365_audit_LogonError not in (\n \"EntitlementGrantsNotFound\",\n \"UserStrongAuthEnrollmentRequired\",\n \"UserStrongAuthClientAuthNRequired\",\n \"InvalidReplyTo\",\n \"SsoArtifactExpiredDueToConditionalAccess\",\n \"PasswordResetRegistrationRequiredInterrupt\",\n \"SsoUserAccountNotFoundInResourceTenant\",\n \"UserStrongAuthExpired\",\n \"CmsiInterrupt\"\n ) and\n Esql_priv.o365_audit_UserId_lower != \"not available\" and\n o365.audit.Target.Type in (\"0\", \"2\", \"6\", \"10\")\n| stats\n Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower),\n Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower),\n Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError),\n Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError),\n Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.timestamp_first_seen = min(@timestamp),\n Esql.timestamp_last_seen = max(@timestamp),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc\n| eval\n Esql.event_duration_seconds = date_diff(\"seconds\", Esql.timestamp_first_seen, Esql.timestamp_last_seen),\n Esql.brute_force_type = case(\n Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, \"password_spraying\",\n Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, \"credential_stuffing\",\n Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, \"password_guessing\",\n \"other\"\n )\n| keep\n Esql.time_window_date_trunc,\n Esql.o365_audit_UserId_lower_count_distinct,\n Esql_priv.o365_audit_UserId_lower_values,\n Esql.o365_audit_LogonError_values,\n Esql.o365_audit_LogonError_count_distinct,\n Esql.o365_audit_ExtendedProperties_RequestType_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.source_as_organization_name_count_distinct,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.event_duration_seconds,\n Esql.event_count,\n Esql.brute_force_type\n| where Esql.brute_force_type != \"other\"\n", + "references": [ + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 414 + }, + "id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d_414", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_4.json b/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_4.json new file mode 100644 index 00000000000..a42d626590e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_4.json @@ -0,0 +1,57 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Widespread Malware Infection Across Multiple Hosts", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Widespread Malware Infection Across Multiple Hosts\n\nEndpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific rule.name and event.code that triggered the alert, focusing on those with a high count of distinct host.id values.\n- Correlate the identified rule.name with known malware signatures or recent threat intelligence reports to understand the potential impact and behavior of the malware.\n- Examine the affected host.id entries to determine if there are any commonalities, such as shared network segments, user accounts, or software versions, that could indicate the initial infection vector.\n- Investigate the timeline of events for each affected host to identify any suspicious activities or anomalies preceding the alert, such as unusual file downloads or execution of unknown processes.\n- Check for any additional alerts or logs related to the same host.id entries to assess if there are other indicators of compromise or related malicious activities.\n- Coordinate with IT and security teams to isolate affected hosts if necessary, and initiate containment and remediation procedures based on the findings.\n\n### False positive analysis\n\n- Legitimate software updates or installations may trigger malware signatures, especially if they involve new or uncommon software. Users can create exceptions for known software update processes to prevent these alerts from being flagged as potential threats.\n- Security testing tools or penetration testing activities might mimic malware behavior, leading to false positives. Analysts should coordinate with IT and security teams to whitelist these activities during scheduled tests.\n- Custom scripts or administrative tools that perform automated tasks across multiple hosts can be mistaken for malicious activity. Identifying and excluding these scripts from the rule can reduce unnecessary alerts.\n- Frequent use of remote management tools that execute scripts or commands on multiple hosts may trigger alerts. Users should ensure these tools are recognized and excluded from the rule to avoid false positives.\n- Known benign applications that use shellcode or memory manipulation techniques for legitimate purposes should be reviewed and added to an exception list to prevent them from being flagged.\n\n### Response and remediation\n\n- Isolate affected hosts immediately to prevent further spread of the malware across the network. This can be done by disconnecting them from the network or using network segmentation techniques.\n- Conduct a thorough scan of the isolated hosts using updated antivirus or endpoint detection and response (EDR) tools to identify and remove the malicious files or processes associated with the detected signatures.\n- Analyze the identified malware to understand its behavior and entry points. This will help in determining if additional hosts may be compromised and require similar remediation actions.\n- Apply security patches and updates to all affected systems to close any vulnerabilities that the malware may have exploited.\n- Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning.\n- Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds.\n- Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response.", + "query": "from logs-endpoint.alerts-*\n| where event.code in (\"malicious_file\", \"memory_signature\", \"shellcode_thread\") and rule.name is not null\n| keep host.id, rule.name, event.code\n| stats Esql.host_id_count_distinct = count_distinct(host.id) by rule.name, event.code\n| where Esql.host_id_count_distinct >= 3\n", + "references": [ + "https://github.com/elastic/protections-artifacts/tree/main/yara/rules" + ], + "risk_score": 73, + "rule_id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "Data Source: Elastic Defend", + "Use Case: Threat Detection", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_2.json new file mode 100644 index 00000000000..32c56f658c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Exccessive Account Lockouts Detected", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Exccessive Account Lockouts Detected\n\nThis rule detects a high number of sign-in failures due to account lockouts (error code `50053`) in Microsoft Entra ID sign-in logs. These lockouts are typically caused by repeated authentication failures, often as a result of brute-force tactics such as password spraying, credential stuffing, or automated guessing. This detection is time-bucketed and aggregates attempts to identify bursts or coordinated campaigns targeting multiple users.\n\n### Possible investigation steps\n\n- Review `user_id_list` and `user_principal_name`: Check if targeted users include high-value accounts such as administrators, service principals, or shared inboxes.\n- Check `error_codes` and `result_description`: Validate that `50053` (account locked) is the consistent failure type. Messages indicating \"malicious IP\" activity suggest Microsoft\u2019s backend flagged the source.\n- Analyze `ip_list` and `source_orgs`: Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers). In the example, traffic originates from `MASSCOM`, which should be validated.\n- Inspect `device_detail_browser` and `user_agent`: Clients like `\"Python Requests\"` indicate scripted automation rather than legitimate login attempts.\n- Evaluate `unique_users` vs. `total_attempts`: A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying.\n- Correlate `client_app_display_name` and `incoming_token_type`: PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass.\n- Review `conditional_access_status` and `risk_state`: If Conditional Access was not applied and risk was not flagged, policy scope or coverage should be reviewed.\n- Validate time range (`first_seen`, `last_seen`): Determine whether the attack is a short burst or part of a longer campaign.\n\n### False positive analysis\n\n- Misconfigured clients, scripts, or services with outdated credentials may inadvertently cause lockouts.\n- Repeated lockouts from known internal IPs or during credential rotation windows could be benign.\n- Legacy applications without modern auth support may repeatedly fail and trigger Smart Lockout.\n- Specific known user agents (e.g., corporate service accounts).\n- Internal IPs or cloud-hosted automation with expected failure behavior.\n\n### Response and remediation\n\n- Investigate locked accounts immediately. Confirm if the account was successfully accessed prior to lockout.\n- Reset credentials for impacted users and enforce MFA before re-enabling accounts.\n- Block malicious IPs or ASN at the firewall, identity provider, or Conditional Access level.\n- Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols.\n- Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients.\n- Conduct credential hygiene audits to assess reuse and rotation for targeted accounts.\n", + "query": "from logs-azure.signinlogs*\n\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name)\n\n| where event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome == \"failure\"\n and azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n and azure.signinlogs.properties.status.error_code == 50053\n and azure.signinlogs.properties.user_principal_name is not null\n and azure.signinlogs.properties.user_principal_name != \"\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n\n| stats\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature),\n Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type),\n\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description),\n Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower),\n Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.@timestamp.min = min(@timestamp),\n Esql.@timestamp.max = max(@timestamp),\n Esql.event_count = count()\nby Esql.time_window_date_trunc\n\n| where Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15 and Esql.event_count >= 20\n\n| keep\n Esql.time_window_date_trunc,\n Esql.event_count,\n Esql.@timestamp.min,\n Esql.@timestamp.max,\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct,\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values,\n Esql.azure_signinlogs_result_description_count_distinct,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_properties_status_error_code_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values,\n Esql.azure_signinlogs_properties_app_display_name_lower_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_as_organization_name_count_distinct,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_device_id_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_user_id_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_result_signature_values,\n Esql.azure_signinlogs_result_type_values\n", + "references": [ + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/", + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://www.sprocketsecurity.com/blog/exploring-modern-password-spraying", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 73, + "rule_id": "2d6f5332-42ea-11f0-b09a-f661ea17fbcd", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "2d6f5332-42ea-11f0-b09a-f661ea17fbcd_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_307.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_307.json new file mode 100644 index 00000000000..199537f15f5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_307.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", + "from": "now-30m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Okta User Sessions Started from Different Geolocations", + "note": "## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action rlike \"user\\.authentication(.*)\" or event.action == \"user.session.start\") and\n okta.security_context.is_proxy != true and\n okta.actor.id != \"unknown\" and\n event.outcome == \"success\"\n| keep\n event.action,\n okta.security_context.is_proxy,\n okta.actor.id,\n okta.actor.alternate_id,\n event.outcome,\n client.geo.country_name\n| stats\n Esql.client_geo_country_name_count_distinct = count_distinct(client.geo.country_name)\n by okta.actor.id, okta.actor.alternate_id\n| where\n Esql.client_geo_country_name_count_distinct >= 2\n| sort\n Esql.client_geo_country_name_count_distinct desc\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 47, + "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 307 + }, + "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_307", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_3.json b/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_3.json new file mode 100644 index 00000000000..17e28128c7f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_3.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Word Policy Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Word Policy Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"word filters\" to prevent the model from generating content on profanity, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account whose prompts contained profanity and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multivalued policy names\n| mv_expand gen_ai.policy.name\n\n// Filter for blocked profanity-related policy violations\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.compliance.violation_detected == \"true\"\n and gen_ai.policy.name == \"word_policy\"\n\n// keep relevant user field\n| keep user.id\n\n// count blocked profanity attempts per user\n| stats\n Esql.ml_policy_blocked_profanity_count = count()\n by user.id\n\n// Filter for excessive policy violations\n| where Esql.ml_policy_blocked_profanity_count > 5\n\n// sort by violation volume\n| sort Esql.ml_policy_blocked_profanity_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "3216949c-9300-4c53-b57a-221e364c6457", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "3216949c-9300-4c53-b57a-221e364c6457_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_106.json b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_106.json new file mode 100644 index 00000000000..ca90bb1af09 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_106.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft 365 Brute Force via Entra ID Sign-Ins", + "note": "## Triage and analysis\n\n### Investigating Microsoft 365 Brute Force via Entra ID Sign-Ins\n\nIdentifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage.\n\n### Possible investigation steps\n\n- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`).\n- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities?\n- Review `login_errors`: Multiple identical errors (e.g., `\"Invalid grant...\"`) suggest automated abuse or tooling.\n- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure.\n- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts.\n- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction.\n- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious.\n- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode.\n- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts.\n- Check `conditional_access_status`: If \"notApplied\", determine whether conditional access is properly scoped.\n- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse.\n\n### False positive analysis\n\n- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures.\n- Red team exercises or pentesting can resemble brute-force patterns.\n- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session.\n\n### Response and remediation\n\n- Notify identity or security operations teams to investigate further.\n- Lock or reset affected user accounts if compromise is suspected.\n- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.\n- Review tenant-wide MFA and conditional access enforcement.\n- Audit targeted accounts for password reuse across systems or tenants.\n- Enable lockout or throttling policies for repeated failed login attempts.\n", + "query": "from logs-azure.signinlogs*\n\n| eval\n Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name),\n Esql.user_agent_original = user_agent.original\n\n| where event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and azure.signinlogs.properties.resource_display_name rlike \"(.*)365|SharePoint|Exchange|Teams|Office(.*)\"\n and event.outcome == \"failure\"\n and azure.signinlogs.properties.status.error_code != 50053\n and azure.signinlogs.properties.status.error_code in (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n and azure.signinlogs.properties.user_principal_name is not null\n and azure.signinlogs.properties.user_principal_name != \"\"\n and user_agent.original != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n\n| stats\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature),\n Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type),\n\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower),\n Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.@timestamp.min = min(@timestamp),\n Esql.@timestamp.max = max(@timestamp),\n Esql.event_count = count()\nby Esql.time_window_date_trunc\n\n| eval\n Esql.event_duration_seconds = date_diff(\"seconds\", Esql.@timestamp.min, Esql.@timestamp.max),\n Esql.event_bf_type = case(\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 10\n and Esql.event_count >= 30\n and Esql.azure_signinlogs_result_description_count_distinct <= 3\n and Esql.source_ip_count_distinct >= 5\n and Esql.event_duration_seconds <= 600\n and Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct > Esql.source_ip_count_distinct,\n \"credential_stuffing\",\n\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15\n and Esql.azure_signinlogs_result_description_count_distinct == 1\n and Esql.event_count >= 15\n and Esql.event_duration_seconds <= 1800,\n \"password_spraying\",\n\n (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct == 1\n and Esql.azure_signinlogs_result_description_count_distinct == 1\n and Esql.event_count >= 30\n and Esql.event_duration_seconds <= 300)\n or (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct <= 3\n and Esql.source_ip_count_distinct > 30\n and Esql.event_count >= 100),\n \"password_guessing\",\n\n \"other\"\n )\n\n| where Esql.event_bf_type != \"other\"\n\n| keep\n Esql.time_window_date_trunc,\n Esql.event_bf_type,\n Esql.event_duration_seconds,\n Esql.event_count,\n Esql.@timestamp.min,\n Esql.@timestamp.max,\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct,\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values,\n Esql.azure_signinlogs_result_description_count_distinct,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_properties_status_error_code_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values,\n Esql.azure_signinlogs_properties_app_display_name_lower_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_as_organization_name_count_distinct,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_device_id_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_user_id_values\n", + "references": [ + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 106 + }, + "id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_106", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_3.json b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_3.json new file mode 100644 index 00000000000..40ce099f640 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_3.json @@ -0,0 +1,64 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token.", + "from": "now-60m", + "interval": "59m", + "language": "esql", + "license": "Elastic License v2", + "name": "Suspicious Microsoft 365 UserLoggedIn via OAuth Code", + "note": "## Triage and analysis\n\n### Investigating Suspicious Microsoft 365 UserLoggedIn via OAuth Code\n\n### Possible Investigation Steps:\n\n- `o365.audit.UserId`: The identity value the application is acting on behalf of principal user.\n- `unique_ips`: Analyze the list of unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers, or anonymizing infrastructure (e.g., Tor or VPNs).\n- `target_time_window`: Use the truncated time window to pivot into raw events to reconstruct the full sequence of resource access events, including exact timestamps and service targets.\n- `azure.auditlogs` to check for device join or registration events around the same timeframe.\n- `azure.identityprotection` to identify correlated risk detections, such as anonymized IP access or token replay.\n- Any additional sign-ins from the `ips` involved, even outside the broker, to determine if tokens have been reused elsewhere.\n\n### False Positive Analysis\n\n- Developers or IT administrators working across environments may also produce similar behavior.\n\n### Response and Remediation\n\n- If confirmed unauthorized, revoke all refresh tokens for the affected user and remove any devices registered during this session.\n- Notify the user and determine whether the device join or authentication activity was expected.\n- Audit Conditional Access and broker permissions (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure policies enforce strict access controls.\n- Consider blocking token-based reauthentication to Microsoft Graph and DRS from suspicious locations or user agents.\n- Continue monitoring for follow-on activity like lateral movement or privilege escalation.\n", + "query": "from logs-o365.audit-*\n| where\n event.dataset == \"o365.audit\" and\n event.action == \"UserLoggedIn\" and\n source.ip is not null and\n o365.audit.UserId is not null and\n o365.audit.ApplicationId is not null and\n o365.audit.UserType in (\"0\", \"2\", \"3\", \"10\") and\n o365.audit.ApplicationId in (\"aebc6443-996d-45c2-90f0-388ff96faa56\", \"29d9ed98-a469-4536-ade2-f981bc1d605e\") and\n o365.audit.ObjectId in (\"00000003-0000-0000-c000-000000000000\")\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql.oauth_authorize_user_id_case = case(\n o365.audit.ExtendedProperties.RequestType == \"OAuth2:Authorize\" and o365.audit.ExtendedProperties.ResultStatusDetail == \"Redirect\",\n o365.audit.UserId,\n null\n ),\n Esql.oauth_token_user_id_case = case(\n o365.audit.ExtendedProperties.RequestType == \"OAuth2:Token\",\n o365.audit.UserId,\n null\n )\n| stats\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_ip_values = values(source.ip),\n Esql.o365_audit_ApplicationId_values = values(o365.audit.ApplicationId),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.oauth_token_count_distinct = count_distinct(Esql.oauth_token_user_id_case),\n Esql.oauth_authorize_count_distinct = count_distinct(Esql.oauth_authorize_user_id_case)\n by\n o365.audit.UserId,\n Esql.time_window_date_trunc,\n o365.audit.ApplicationId,\n o365.audit.ObjectId\n| keep\n Esql.time_window_date_trunc,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.o365_audit_ApplicationId_values,\n Esql.source_as_organization_name_values,\n Esql.oauth_token_count_distinct,\n Esql.oauth_authorize_count_distinct\n| where\n Esql.source_ip_count_distinct >= 2 and\n Esql.oauth_token_count_distinct > 0 and\n Esql.oauth_authorize_count_distinct > 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/" + ], + "risk_score": 73, + "rule_id": "36188365-f88f-4f70-8c1d-0b9554186b9c", + "setup": "## Setup\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Email", + "Domain: Identity", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "36188365-f88f-4f70-8c1d-0b9554186b9c_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_3.json b/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_3.json new file mode 100644 index 00000000000..d7dbb368e8d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_3.json @@ -0,0 +1,67 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker.", + "false_positives": [ + "Legitimate device registrations using Microsoft Authentication Broker may occur during corporate enrollment scenarios or bulk provisioning, but it is uncommon for multiple source IPs to register the same identity across Microsoft Graph, Device Registration Service (DRS), and Azure Active Directory (AAD) in a short time span." + ], + "from": "now-61m", + "interval": "60m", + "language": "esql", + "license": "Elastic License v2", + "name": "Suspicious Microsoft OAuth Flow via Auth Broker to DRS", + "note": "## Triage and analysis\n\n### Investigating Suspicious Microsoft OAuth Flow via Auth Broker to DRS\n\nThis rule identifies potential OAuth phishing behavior in Microsoft Entra ID where two OAuth authorization flows are observed in quick succession, sharing the same user principal and session ID but originating from different IP addresses. The client application is the Microsoft Authentication Broker, and the target resource is the Device Registration Service (DRS). This pattern is indicative of adversaries attempting to phish targets for OAuth sessions by tricking users into authenticating through a crafted URL, which then allows the attacker to obtain an authorization code and exchange it for access and refresh tokens.\n\n### Possible Investigation Steps:\n\n- `target`: The user principal name targeted by the authentication broker. Investigate whether this user has recently registered a device, signed in from new IPs, or had password resets or MFA changes.\n- `session_id`: Used to correlate all events in the OAuth flow. All sign-ins in the alert share the same session, suggesting shared or hijacked state.\n- `unique_token_id`: Lists tokens generated in the flow. If multiple IDs exist in the same session, this indicates token issuance from different locations.\n- `source_ip`, `city_name`, `country_name`, `region_name`: Review the IPs and geolocations involved. A mismatch in geographic origin within minutes can signal adversary involvement.\n- `user_agent`: Conflicting user agents (e.g., `python-requests` and `Chrome`) suggest one leg of the session was scripted or automated.\n- `os`: If multiple operating systems are observed in the same short session (e.g., macOS and Windows), this may suggest activity from different environments.\n- `incoming_token_type`: Look for values like `\"none\"` or `\"refreshToken\"` that can indicate abnormal or re-authenticated activity.\n- `token_session_status`: A value of `\"unbound\"` means the issued token is not tied to a device or CAE session, making it reusable from another IP.\n- `conditional_access_status`: If this is `\"notApplied\"`, it may indicate that expected access policies were not enforced.\n- `auth_count`: Number of events in the session. More than one indicates the session was reused within the time window.\n- `target_time_window`: Use this to pivot into raw sign-in logs to review the exact sequence and timing of the activity.\n- Search `azure.auditlogs` for any device join or registration activity around the `target_time_window`.\n- Review `azure.identityprotection` logs for anonymized IPs, impossible travel, or token replay alerts.\n- Search for other activity from the same IPs across all users to identify horizontal movement.\n\n### False Positive Analysis\n\n- A legitimate device join from a user switching networks (e.g., mobile hotspot to Wi-Fi) could explain multi-IP usage.\n- Some identity management agents or EDR tools may use MAB for background device registration flows.\n- Developers or IT administrators may access DRS across environments when testing.\n\n### Response and Remediation\n\n- If confirmed unauthorized, revoke all refresh tokens for the user and disable any suspicious registered devices.\n- Notify the user and verify if the authentication or device join was expected.\n- Review Conditional Access policies for the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure enforcement of MFA and device trust.\n- Consider restricting token-based reauthentication from anonymized infrastructure or unusual user agents.\n- Continue monitoring for follow-on activity, such as privilege escalation, token misuse, or lateral movement.\n", + "query": "from logs-azure.signinlogs* metadata _id, _version, _index\n| where\n event.dataset == \"azure.signinlogs\" and\n event.outcome == \"success\" and\n azure.signinlogs.properties.user_type == \"Member\" and\n azure.signinlogs.identity is not null and\n azure.signinlogs.properties.user_principal_name is not null and\n source.address is not null and\n azure.signinlogs.properties.app_id == \"29d9ed98-a469-4536-ade2-f981bc1d605e\" and // MAB\n azure.signinlogs.properties.resource_id == \"01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9\" // DRS\n\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql.azure_signinlogs_properties_session_id = azure.signinlogs.properties.session_id,\n Esql.is_browser_case = case(\n to_lower(azure.signinlogs.properties.device_detail.browser) rlike \"(chrome|firefox|edge|safari).*\", 1, 0\n )\n\n| stats\n Esql_priv.azure_signinlogs_properties_user_display_name_values = values(azure.signinlogs.properties.user_display_name),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_unique_token_identifier_values = values(azure.signinlogs.properties.unique_token_identifier),\n\n Esql.source_geo_city_name_values = values(source.geo.city_name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_region_name_values = values(source.geo.region_name),\n Esql.source_address_values = values(source.address),\n Esql.source_address_count_distinct = count_distinct(source.address),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n\n Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol),\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive),\n\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values = values(azure.signinlogs.properties.token_protection_status_details.sign_in_session_status),\n Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n\n Esql.azure_signinlogs_properties_app_owner_tenant_id_values = values(azure.signinlogs.properties.app_owner_tenant_id),\n Esql.azure_signinlogs_properties_resource_owner_tenant_id_values = values(azure.signinlogs.properties.resource_owner_tenant_id),\n\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_risk_level_aggregated_values = values(azure.signinlogs.properties.risk_level_aggregated),\n\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.user_agent_original_values = values(user_agent.original),\n Esql.is_browser_case_max = max(Esql.is_browser_case),\n\n Esql.event_count = count(*)\n by\n Esql.time_window_date_trunc,\n azure.signinlogs.properties.user_principal_name,\n azure.signinlogs.properties.session_id\n\n| keep\n Esql.time_window_date_trunc,\n Esql_priv.azure_signinlogs_properties_user_display_name_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_unique_token_identifier_values,\n Esql.source_geo_city_name_values,\n Esql.source_geo_country_name_values,\n Esql.source_geo_region_name_values,\n Esql.source_address_values,\n Esql.source_address_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.azure_signinlogs_properties_authentication_protocol_values,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_is_interactive_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values,\n Esql.azure_signinlogs_properties_session_id_count_distinct,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_app_owner_tenant_id_values,\n Esql.azure_signinlogs_properties_resource_owner_tenant_id_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_risk_level_aggregated_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.user_agent_original_values,\n Esql.is_browser_case_max,\n Esql.event_count\n\n| where\n Esql.source_address_count_distinct >= 2 and\n Esql.azure_signinlogs_properties_session_id_count_distinct == 1 and\n Esql.is_browser_case_max >= 1 and\n Esql.event_count >= 2\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/" + ], + "risk_score": 73, + "rule_id": "375132c6-25d5-11f0-8745-f661ea17fbcd", + "setup": "#### Required Microsoft Entra ID Sign-In Logs\nThis rule requires the Microsoft Entra ID Sign-In Logs integration be enabled and configured to collect sign-in logs. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Azure integration.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Initial Access" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/", + "subtechnique": [ + { + "id": "T1566.002", + "name": "Spearphishing Link", + "reference": "https://attack.mitre.org/techniques/T1566/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "375132c6-25d5-11f0-8745-f661ea17fbcd_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_5.json b/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_5.json new file mode 100644 index 00000000000..5ec57f63c64 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_5.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure.", + "false_positives": [ + "Legitimate use of the `DescribeInstances` API call by an AWS resource that requires information about instances in multiple regions.", + "Scheduled tasks or scripts that require information about instances in multiple regions." + ], + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "aws.cloudtrail.user_identity.arn", + "target_time_window", + "region_count", + "window_count" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS EC2 Multi-Region DescribeInstances API Calls", + "note": "## Triage and analysis\n\n### Investigating AWS EC2 Multi-Region DescribeInstances API Calls\n\nThis rule detects instances where a single AWS resource makes `DescribeInstances` API calls in over 10 regions within a 30-second window. This could indicate an adversary using compromised credentials or an exploited resource to enumerate AWS infrastructure across multiple regions. Attackers often leverage multi-region enumeration to assess the overall cloud environment and find potential targets for further exploitation.\n\n#### Possible Investigation Steps\n\n- **Identify the Resource and Actor**:\n - **Actor ARN**: Check `aws.cloudtrail.user_identity.arn` to determine the exact identity performing the enumeration. Validate if the user is expected to perform region-wide `DescribeInstances` actions across multiple regions or if it seems unusual.\n - **Account and Role Details**: Examine `cloud.account.id` and `aws.cloudtrail.user_identity.session_context.session_issuer` for information about the AWS account and specific role associated with the action.\n\n- **Analyze API Call Patterns**:\n - **Frequency and Scope**: Review `cloud.region` field and confirm if this specific resource commonly performs `DescribeInstances` calls across multiple regions.\n - **Time Window Context**: Compare the timing of the API calls within the `target_time_window` to determine if this burst pattern aligns with expected system usage or is potentially malicious.\n\n- **Check User Agent and Tooling**:\n - **Source and User Agent**: Verify `user_agent.original` to determine if the request was made through expected tooling (e.g., AWS CLI or SDK) or a third-party tool that might indicate non-standard access.\n - **Source IP Address**: Look into `source.address` to identify the origin of the calls. Unusual IP addresses, especially those outside expected ranges, may indicate compromised access.\n\n- **Evaluate for Potential Reconnaissance Behavior**:\n - **Account and Region Enumeration**: Adversaries may use region-wide `DescribeInstances` requests to discover resources within an account across different regions. Confirm if this access aligns with operational practices or represents excessive access.\n - **Permissions and Roles**: Investigate the permissions associated with the user role. Excessive permissions on a compromised role may allow broader enumeration, which should be restricted.\n\n- **Review Related CloudTrail Events**:\n - **Additional Describe or List Actions**: Identify any associated `Describe` or `List` API calls that may indicate further enumeration of other AWS services within the same timeframe.\n - **Potential Preceding Events**: Look for preceding login or access events from the same actor, as these may indicate potential credential compromise or unauthorized escalation of privileges.\n\n### False Positive Analysis\n\n- **Expected Enumeration**: Certain administrative or automation scripts may conduct broad `DescribeInstances` API calls for inventory purposes. Review usage patterns or consult relevant teams to validate the purpose.\n- **Automated Cloud Management**: Some automated services may perform regional checks for compliance or backup operations. If this rule is triggered repeatedly by a known service, consider whitelisting or tuning accordingly.\n\n### Response and Remediation\n\n- **Review IAM Policies and Role Permissions**: Limit the permissions of roles associated with this resource, restricting unnecessary multi-region enumeration access.\n- **Enforce Least Privilege Access**: Ensure that permissions for DescribeInstances are tightly controlled and restricted to specific roles or accounts that require multi-region access.\n- **Increase Monitoring and Alerts**: Set up additional monitoring on this role or account for further signs of unauthorized activity or lateral movement attempts.\n- **Access Review**: Conduct a review of users and entities with `DescribeInstances` permissions, especially for multi-region capabilities, and ensure these permissions are necessary for their functions.\n\n### Additional Information\n\nFor further information on AWS `DescribeInstances` permissions and best practices, refer to the [AWS DescribeInstances API documentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html).\n", + "query": "from logs-aws.cloudtrail-*\n\n// filter for DescribeInstances API calls\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"ec2.amazonaws.com\"\n and event.action == \"DescribeInstances\"\n\n// truncate the timestamp to a 30-second window\n| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp)\n\n// keep only the relevant raw fields\n| keep Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn, cloud.region\n\n// count the number of unique regions and total API calls within the 30-second window\n| stats\n Esql.cloud_region_count_distinct = count_distinct(cloud.region),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn\n\n// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window\n| where Esql.cloud_region_count_distinct >= 10 and Esql.event_count >= 10\n\n// sort the results by time window in descending order\n| sort Esql.time_window_date_trunc desc\n", + "references": [ + "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html" + ], + "risk_score": 21, + "rule_id": "393ef120-63d1-11ef-8e38-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: AWS EC2", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "393ef120-63d1-11ef-8e38-f661ea17fbce_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_4.json new file mode 100644 index 00000000000..c1d1b233fc5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_4.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code.", + "false_positives": [ + "Based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed TOTP code attempts in a short time-span over multiple sessions." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID MFA TOTP Brute Force Attempts", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID MFA TOTP Brute Force Attempts\n\nThis rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code.\n\n#### Possible Investigation Steps:\n\n - Check the source addresses associated with the failed TOTP attempts.\n - Determine if the source IP address is consistent with the user\u2019s typical login locations.\n - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user\u2019s normal activity).\n - Review the error code associated with the failed attempts. This can help identify if the failures are due to incorrect TOTP codes or other issues.\n - Verify that that auth metho reported is `OAth` as it indicates the use of TOTP codes.\n - Pivot into signin logs for the target user and check if auth via TOTP was successful which would indicate a successful brute force attempt.\n - Review conditional access policies applied to the user or group as reported by the sign-in logs.\n - Analyze the client application ID and display name to determine if the attempts are coming from a legitimate application or a potentially malicious script.\n - Adversaries may use legitimate FOCI applications to bypass security controls or make login attempts appear legitimate.\n - Review the resource ID access is being attempted against such as MyApps, Microsoft Graph, or other resources. This can help identify if the attempts are targeting specific applications or services.\n - The correlation IDs or session IDs can be used to trace the authentication attempts across different logs or systems. Note that for this specific behavior, unique session ID count is high and could be challenging to correlate.\n\n#### False Positive Analysis:\n\n - Verify if the failed attempts could result from the user\u2019s unfamiliarity with TOTP codes or issues with device synchronization.\n - Check if the user recently switched MFA methods or devices, which could explain multiple failures.\n - Determine if this is whitebox testing or a developer testing MFA integration.\n\n#### Response and Remediation:\n\n - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts.\n - Notify the user of suspicious activity and validate their access to the account.\n - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user.\n - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior.\n - Consider a different MFA method or additional security controls to prevent future bypass attempts.\n - Implement additional monitoring to track high-frequency authentication failures across the environment.\n - Audit historical logs for similar patterns involving other accounts to identify broader threats.\n - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity.\n", + "query": "from logs-azure.signinlogs* metadata _id, _version, _index\n\n| where\n // filter for Entra Sign-in Logs\n event.dataset == \"azure.signinlogs\"\n and azure.signinlogs.operation_name == \"Sign-in activity\"\n and azure.signinlogs.properties.user_type == \"Member\"\n\n // filter for MFA attempts with OATH conditional access attempts or TOTP\n and azure.signinlogs.properties.mfa_detail.auth_method == \"OATH verification code\"\n\n // filter on failures only from brute-force attempts\n and (\n (\n azure.signinlogs.result_signature == \"FAILURE\" and\n azure.signinlogs.result_description == \"Authentication failed during strong authentication request.\"\n ) or azure.signinlogs.properties.status.error_code == 500121\n )\n\n| stats\n Esql.event_count = count(*),\n Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id),\n Esql.source_address_values = values(source.address),\n Esql.azure_tenant_id_valuues = values(azure.tenant_id),\n Esql_priv.azure_identity_values = values(azure.signinlogs.identity),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol),\n Esql.azure_signinlogs_properties_client_app_used_values = values(azure.signinlogs.properties.client_app_used),\n Esql.azure_signinlogs_properties_client_credential_type_values = values(azure.signinlogs.properties.client_credential_type),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_correlation_id_values = values(azure.signinlogs.properties.correlation_id),\n Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive),\n Esql.azure_signinlogs_properties_mfa_detail_auth_method_values = values(azure.signinlogs.properties.mfa_detail.auth_method),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_risk_detail_values = values(azure.signinlogs.properties.risk_detail),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_original_request_id_values = values(azure.signinlogs.properties.original_request_id),\n Esql.user_id_values = values(user.id)\n by user.id\n\n| where Esql.event_count >= 20 and Esql.azure_signinlogs_properties_session_id_count_distinct >= 10\n\n| keep\n Esql.event_count,\n Esql.azure_signinlogs_properties_session_id_count_distinct,\n Esql.source_address_values,\n Esql.azure_tenant_id_valuues,\n Esql_priv.azure_identity_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_authentication_protocol_values,\n Esql.azure_signinlogs_properties_client_app_used_values,\n Esql.azure_signinlogs_properties_client_credential_type_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_correlation_id_values,\n Esql.azure_signinlogs_properties_is_interactive_values,\n Esql.azure_signinlogs_properties_mfa_detail_auth_method_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_risk_detail_values,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_original_request_id_values,\n Esql.user_id_values\n", + "references": [ + "https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass", + "https://learn.microsoft.com/en-us/entra/identity/", + "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins" + ], + "risk_score": 47, + "rule_id": "3fac01b2-b811-11ef-b25b-f661ea17fbce", + "setup": "#### Required Entra ID Sign-In Logs\nThis rule requires the Entra ID sign-in logs via the Azure integration be enabled. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Entra ID logs integration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "3fac01b2-b811-11ef-b25b-f661ea17fbce_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_3.json b/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_3.json new file mode 100644 index 00000000000..afa4a0b598f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_3.json @@ -0,0 +1,40 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions.", + "false_positives": [ + "Authorized model training", + "Legitimate high volume data exchanges during scheduled updates" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Azure OpenAI Model Theft", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Azure OpenAI Model Theft\n\nAzure OpenAI models are integral to many applications, providing advanced machine learning capabilities. Adversaries may exploit these models by making unauthorized API calls or transferring large volumes of data, potentially indicating model theft. The detection rule identifies such threats by monitoring audit logs for unusual access patterns or excessive data transfers, flagging activities that deviate from normal usage.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific resource group and resource name flagged in the alert to understand the context of the access patterns.\n- Analyze the timestamps associated with the suspicious activities to determine if they align with known operational periods or if they occur during unusual times.\n- Investigate the source of the API calls by identifying the IP addresses or user accounts involved in the \"ListKey\" operations to determine if they are authorized or known entities.\n- Examine the response length data to assess whether the volume of data transferred is consistent with legitimate use cases or if it suggests potential data exfiltration.\n- Cross-reference the flagged activities with other security logs or alerts to identify any correlated suspicious behavior or potential indicators of compromise.\n\n### False positive analysis\n\n- High-frequency legitimate API calls from automated scripts or applications may trigger the rule. Users can create exceptions for known scripts by identifying their specific access patterns and excluding them from the rule.\n- Large data transfers during scheduled model updates or backups can be mistaken for suspicious activity. Users should whitelist these operations by correlating them with scheduled maintenance windows or known update events.\n- Regular access by trusted internal teams for model evaluation or testing might appear as atypical patterns. Users can mitigate this by maintaining a list of authorized personnel and their expected access behaviors, then excluding these from the alert criteria.\n- Integration with other Azure services that require frequent access to OpenAI models could generate false positives. Users should document these integrations and adjust the rule to recognize and exclude these legitimate interactions.\n\n### Response and remediation\n\n- Immediately isolate the affected Azure resources by restricting network access to prevent further unauthorized API calls or data transfers.\n- Revoke and regenerate API keys associated with the compromised Azure OpenAI resources to prevent further unauthorized access.\n- Conduct a thorough review of audit logs to identify any additional unauthorized access attempts or data transfers, and document all findings for further analysis.\n- Notify the security operations team and relevant stakeholders about the potential model theft incident to ensure coordinated response efforts.\n- Implement additional monitoring on the affected resources to detect any further suspicious activities, focusing on access patterns and data transfer volumes.\n- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if any data exfiltration occurred.\n- Review and update access controls and permissions for Azure OpenAI resources to ensure they adhere to the principle of least privilege, reducing the risk of future unauthorized access.\n", + "query": "from logs-azure_openai.logs-*\n| where\n azure.open_ai.operation_name == \"ListKey\" and\n azure.open_ai.category == \"Audit\"\n| keep\n @timestamp,\n azure.open_ai.operation_name,\n azure.open_ai.category,\n azure.resource.group,\n azure.resource.name,\n azure.open_ai.properties.response_length\n| stats\n Esql.event_count = count(*),\n Esql.azure_open_ai_properties_response_length_max = max(azure.open_ai.properties.response_length)\n by\n azure.resource.group,\n azure.resource.name\n| where\n Esql.event_count >= 100 or\n Esql.azure_open_ai_properties_response_length_max >= 1000000\n| sort\n Esql.event_count desc\n", + "references": [ + "https://genai.owasp.org/llmrisk/llm10-model-theft", + "https://atlas.mitre.org/techniques/AML.T0044" + ], + "risk_score": 47, + "rule_id": "4021e78d-5293-48d3-adee-a70fa4c18fab", + "setup": "## Setup\n\nFor more information on\nstreaming events, see the Azure OpenAI documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: Azure OpenAI", + "Data Source: Azure Event Hubs", + "Use Case: Model Theft", + "Mitre Atlas: T0044", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "4021e78d-5293-48d3-adee-a70fa4c18fab_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_7.json b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_7.json new file mode 100644 index 00000000000..69aeb31dc74 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_7.json @@ -0,0 +1,58 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the snapshot into an environment they control, to access the data.", + "false_positives": [ + "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action." + ], + "from": "now-6m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS EC2 EBS Snapshot Shared or Made Public", + "note": "## Triage and analysis\n\n### Investigating AWS EC2 EBS Snapshot Shared or Made Public\n\nThis rule detects when an AWS EC2 EBS snapshot is shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this to copy the snapshot into an environment they control to access the data. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Review UserID**: Check the `userId` field to identify the AWS account with which the snapshot was shared. Verify if this account is authorized to access the data or if it belongs to a known third party. If this value is `all`, the snapshot is made public.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions.\n- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing EBS snapshots and securing AWS environments, refer to the [AWS EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security:\n- [AWS EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)\n- [AWS API ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)\n- [AWS EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where\n event.provider == \"ec2.amazonaws.com\"\n and event.action == \"ModifySnapshotAttribute\"\n and event.outcome == \"success\"\n\n// Extract snapshotId, attribute type, operation type, and userId\n| dissect aws.cloudtrail.request_parameters\n \"{%{?snapshotId}=%{Esql.aws_cloudtrail_request_parameters_snapshot_id},%{?attributeType}=%{Esql.aws_cloudtrail_request_parameters_attribute_type},%{?createVolumePermission}={%{Esql.aws_cloudtrail_request_parameters_operation_type}={%{?items}=[{%{?userId}=%{Esql_priv.aws_cloudtrail_request_parameters_user_id}}]}}}\"\n\n// Check for snapshot permission added for another AWS account\n| where\n Esql.aws_cloudtrail_request_parameters_operation_type == \"add\"\n and cloud.account.id != Esql_priv.aws_cloudtrail_request_parameters_user_id\n\n// keep ECS and derived fields\n| keep\n @timestamp,\n aws.cloudtrail.user_identity.arn,\n cloud.account.id,\n event.action,\n Esql.aws_cloudtrail_request_parameters_snapshot_id,\n Esql.aws_cloudtrail_request_parameters_attribute_type,\n Esql.aws_cloudtrail_request_parameters_operation_type,\n Esql_priv.aws_cloudtrail_request_parameters_user_id,\n source.ip\n", + "references": [ + "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html", + "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump", + "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" + ], + "risk_score": 21, + "rule_id": "4182e486-fc61-11ee-a05d-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "4182e486-fc61-11ee-a05d-f661ea17fbce_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_3.json b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_3.json new file mode 100644 index 00000000000..f39cede3318 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_3.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "OIDC Discovery URL Changed in Entra ID", + "note": "## Triage and analysis\n\n### Investigating OIDC Discovery URL Changed in Entra ID\n\nThis rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity.\n\n### Possible investigation steps\n- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.\n- Examine the `old_oidc_discovery` and `new_oidc_discovery` to confirm if the new `discoveryUrl` points to an unexpected or untrusted IdP.\n- Check that the discovery URLs have `.well-known/openid-configuration` endpoints, which are standard for OIDC providers.\n- Use `azure.auditlogs.properties.correlation_id` to pivot to related changes and activity from the same session.\n- Review any subsequent sign-in activity that may have originated from the new IdP.\n- Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity.\n\n### False positive analysis\n- Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements.\n- Validate any changes with the identity or security operations team before taking action.\n\n### Response and remediation\n- If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal.\n- Revoke tokens or sessions issued after the configuration change.\n- Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app).\n- Apply conditional access policies and change control procedures to protect IdP configuration changes.\n", + "query": "from logs-azure.auditlogs-* metadata _id, _version, _index\n| where event.action == \"Authentication Methods Policy Update\"\n| eval Esql.azure_auditlogs_properties_target_resources_modified_properties_new_value_replace = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, \"\\\\\\\\\", \"\")\n| eval Esql.azure_auditlogs_properties_target_resources_modified_properties_old_value_replace = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, \"\\\\\\\\\", \"\")\n| dissect Esql.azure_auditlogs_properties_target_resources_modified_properties_new_value_replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new}\\\"}%{}\"\n| dissect Esql.azure_auditlogs_properties_target_resources_modified_properties_old_value_replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old}\\\"}%{}\"\n| where Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new is not null and Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old is not null\n| where Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new != Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old\n| keep\n @timestamp,\n event.action,\n event.outcome,\n azure.tenant_id,\n azure.correlation_id,\n azure.auditlogs.properties.activity_datetime,\n azure.auditlogs.properties.operation_type,\n azure.auditlogs.properties.initiated_by.user.userPrincipalName,\n azure.auditlogs.properties.initiated_by.user.displayName,\n azure.auditlogs.properties.initiated_by.user.ipAddress,\n source.geo.city_name,\n source.geo.region_name,\n source.geo.country_name,\n Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new,\n Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old\n", + "references": [ + "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/" + ], + "risk_score": 73, + "rule_id": "498e4094-60e7-11f0-8847-f661ea17fbcd", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Audit Logs", + "Use Case: Identity and Access Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/", + "subtechnique": [ + { + "id": "T1556.009", + "name": "Conditional Access Policies", + "reference": "https://attack.mitre.org/techniques/T1556/009/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_7.json b/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_7.json new file mode 100644 index 00000000000..52a651a5a92 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_7.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Confidence Content Filter Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Confidence Content Filter Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts\nto prevent the model from generating content on specific, undesired subjects, and they can establish thresholds for harmful content categories.\n\n#### Possible investigation steps\n\n- Identify the user account whose prompts caused high confidence content filter blocks and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-value fields\n| mv_expand gen_ai.compliance.violation_code\n| mv_expand gen_ai.policy.confidence\n| mv_expand gen_ai.policy.name\n\n// Filter for high-confidence content policy blocks with targeted violations\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.policy.name == \"content_policy\"\n and gen_ai.policy.confidence like \"HIGH\"\n and gen_ai.compliance.violation_code in (\"HATE\", \"MISCONDUCT\", \"SEXUAL\", \"INSULTS\", \"PROMPT_ATTACK\", \"VIOLENCE\")\n\n// keep ECS + compliance fields\n| keep\n user.id,\n gen_ai.compliance.violation_code\n\n// count blocked violations per user per violation type\n| stats\n Esql.ml_policy_blocked_violation_count = count()\n by\n user.id,\n gen_ai.compliance.violation_code\n\n// Aggregate all violation types per user\n| stats\n Esql.ml_policy_blocked_violation_total_count = sum(Esql.ml_policy_blocked_violation_count)\n by\n user.id\n\n// Filter for users with more than 5 total violations\n| where Esql.ml_policy_blocked_violation_total_count > 5\n\n// sort by violation volume\n| sort Esql.ml_policy_blocked_violation_total_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "4f855297-c8e0-4097-9d97-d653f7e471c4", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "4f855297-c8e0-4097-9d97-d653f7e471c4_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_5.json b/packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_5.json new file mode 100644 index 00000000000..9ecee10e831 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_5.json @@ -0,0 +1,93 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a high number of failed S3 operations from a single source and account (or anonymous account) within a short timeframe. This activity can be indicative of attempting to cause an increase in billing to an account for excessive random operations, cause resource exhaustion, or enumerating bucket names for discovery.", + "false_positives": [ + "Known or internal account IDs or automation" + ], + "from": "now-6m", + "investigation_fields": { + "field_names": [ + "source.address", + "tls.client.server_name", + "cloud.account.id", + "failed_requests" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS S3 Bucket Enumeration or Brute Force", + "note": "## Triage and analysis\n\n### Investigating AWS S3 Bucket Enumeration or Brute Force\n\nAWS S3 buckets can be be brute forced to cause financial impact against the resource owner. What makes this even riskier is that even private, locked down buckets can still trigger a potential cost, even with an \"Access Denied\", while also being accessible from unauthenticated, anonymous accounts. This also appears to work on several or all [operations](https://docs.aws.amazon.com/cli/latest/reference/s3api/) (GET, PUT, list-objects, etc.). Additionally, buckets are trivially discoverable by default as long as the bucket name is known, making it vulnerable to enumeration for discovery.\n\nAttackers may attempt to enumerate names until a valid bucket is discovered and then pivot to cause financial impact, enumerate for more information, or brute force in other ways to attempt to exfil data.\n\n#### Possible investigation steps\n\n- Examine the history of the operation requests from the same `source.address` and `cloud.account.id` to determine if there is other suspicious activity.\n- Review similar requests and look at the `user.agent` info to ascertain the source of the requests (though do not overly rely on this since it is controlled by the requestor).\n- Review other requests to the same `aws.s3.object.key` as well as other `aws.s3.object.key` accessed by the same `cloud.account.id` or `source.address`.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Validate the activity is not related to planned patches, updates, or network administrator activity.\n- Examine the request parameters. These may indicate the source of the program or the nature of the task being performed when the error occurred.\n - Check whether the error is related to unsuccessful attempts to enumerate or access objects, data, or secrets.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Contact the account owner and confirm whether they are aware of this activity if suspicious.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the `source.address` and `cloud.account.id` - there are some valid operations from within AWS directly that can cause failures and false positives. Additionally, failed automation can also caeuse false positives, but should be identifiable by reviewing the `source.address` and `cloud.account.id`.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n- Check for PutBucketPolicy event actions as well to see if they have been tampered with. While we monitor for denied, a single successful action to add a backdoor into the bucket via policy updates (however they got permissions) may be critical to identify during TDIR.\n\n", + "query": "from logs-aws.cloudtrail*\n\n| where\n event.provider == \"s3.amazonaws.com\"\n and aws.cloudtrail.error_code == \"AccessDenied\"\n and tls.client.server_name is not null\n and cloud.account.id is not null\n\n// keep only relevant ECS fields\n| keep\n tls.client.server_name,\n source.address,\n cloud.account.id\n\n// count access denied requests per server_name, source, and account\n| stats\n Esql.event_count = count(*)\n by\n tls.client.server_name,\n source.address,\n cloud.account.id\n\n// Threshold: more than 40 denied requests\n| where Esql.event_count > 40\n", + "references": [ + "https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1", + "https://docs.aws.amazon.com/cli/latest/reference/s3api/" + ], + "risk_score": 21, + "rule_id": "5f0234fd-7f21-42af-8391-511d5fd11d5c", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Log Auditing", + "Tactic: Impact" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1657", + "name": "Financial Theft", + "reference": "https://attack.mitre.org/techniques/T1657/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "5f0234fd-7f21-42af-8391-511d5fd11d5c_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_4.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_4.json new file mode 100644 index 00000000000..7f7d0885d12 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Invalid Escape Sequences", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Invalid Escape Sequences\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques to evade detection. By inserting invalid escape sequences, attackers can obscure malicious scripts, bypassing static analysis and security tools like AMSI. The detection rule identifies such obfuscation by analyzing script patterns, specifically targeting unusual backtick usage, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script block that triggered the alert. Look for patterns of invalid escape sequences and assess whether they appear intentionally obfuscated.\n- Examine the `file.name` and `file.path` fields to determine the origin and location of the script. This can help identify whether the script is part of a legitimate application or potentially malicious.\n- Check the `host.name` and `agent.id` fields to identify the affected system and the agent responsible for logging the event. This information is crucial for understanding the scope of the potential threat.\n- Analyze the `user.id` field to ascertain which user executed the script. This can provide insights into whether the user has a history of executing suspicious scripts or if their account may be compromised.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related script blocks, which may reveal additional obfuscation or malicious activity.\n- Assess the `count` field to evaluate the extent of obfuscation detected. A higher count may indicate more aggressive obfuscation techniques, warranting further scrutiny.\n\n### False positive analysis\n\n- Scripts from Visual Studio Code's PowerShell extension may trigger false positives due to its shell integration. To handle this, exclude scripts containing the pattern \"$([char]0x1b)]633\" from detection.\n- PowerShell modules with names starting with \"TSS_\" may be flagged incorrectly. Exclude these by adding a condition to ignore files matching the pattern \"TSS_*.psm1\".\n- Legitimate scripts that use backticks for formatting or other non-obfuscation purposes might be detected. Review such scripts and, if verified as safe, add them to an exception list based on their script block ID or file path.\n- Regularly update the exclusion list to reflect changes in legitimate script usage patterns, ensuring that new false positives are addressed promptly.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. Disconnect the host from the network and disable remote access.\n\n- Analyze the script block text and file path to identify the source and nature of the obfuscated script. Determine if the script is part of a larger attack or if other systems are affected.\n\n- Remove or quarantine the identified malicious script and any associated files from the host. Ensure that all remnants of the obfuscated code are eliminated to prevent re-execution.\n\n- Conduct a thorough scan of the host using updated antivirus and antimalware tools to detect and remove any additional threats or indicators of compromise.\n\n- Review and update PowerShell execution policies and security settings to restrict the execution of scripts with invalid escape sequences. Implement stricter controls to prevent similar obfuscation techniques.\n\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and monitoring. Provide detailed logs and findings to assist in understanding the scope and impact of the threat.\n\n- Implement enhanced logging and monitoring for PowerShell activities across the network to detect and respond to similar obfuscation attempts promptly. Use the identified patterns to refine detection capabilities.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*`*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.name,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least 10 times\n| where Esql.script_block_pattern_count >= 10\n\n// Filter FPs, and due to the behavior of the like operator, allow null values\n| where (file.name not like \"TSS_*.psm1\" or file.name is null)\n\n// VSCode Shell integration\n| where not powershell.file.script_block_text like \"*$([char]0x1b)]633*\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_2.json b/packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_2.json new file mode 100644 index 00000000000..f6065c2ce3a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_2.json @@ -0,0 +1,75 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication.", + "from": "now-3660s", + "language": "esql", + "license": "Elastic License v2", + "name": "Rare Connection to WebDAV Target", + "note": "## Triage and analysis\n\n### Investigating Rare Connection to WebDAV Target\n\n### Possible investigation steps\n\n- Examine the reputation of the destination domain or IP address.\n- Verify if the target user opened any attachments or clicked links pointing to the same target within seconds from the alert timestamp.\n- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.\n\n### False positive analysis\n\n- User accessing legit WebDAV resources.\n\n### Response and remediation\n\n- Conduct a password reset for the target account that may have been compromised or are at risk, ensuring the use of strong, unique passwords.\n- Verify whether other users were targeted but did not open the lure..\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.\n- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture.", + "query": "from logs-*\n| where\n @timestamp > now() - 8 hours and\n event.category == \"process\" and\n event.type == \"start\" and\n process.name == \"rundll32.exe\" and\n process.command_line like \"*DavSetCookie*\"\n| keep host.id, process.command_line, user.name\n| grok\n process.command_line \"\"\"(?DavSetCookie .* http)\"\"\"\n| eval\n Esql.server_webdav_cookie_replace = replace(Esql.server_webdav_cookie, \"(DavSetCookie | http)\", \"\")\n| where\n Esql.server_webdav_cookie_replace is not null and\n Esql.server_webdav_cookie_replace rlike \"\"\"(([a-zA-Z0-9-]+\\.)+[a-zA-Z]{2,3}(@SSL.*)*|(\\d{1,3}\\.){3}\\d{1,3})\"\"\" and\n not Esql.server_webdav_cookie_replace in (\"www.google.com@SSL\", \"www.elastic.co@SSL\") and\n not Esql.server_webdav_cookie_replace rlike \"\"\"(10\\.(\\d{1,3}\\.){2}\\d{1,3}|172\\.(1[6-9]|2\\d|3[0-1])\\.(\\d{1,3}\\.)\\d{1,3}|192\\.168\\.(\\d{1,3}\\.)\\d{1,3})\"\"\"\n| stats\n Esql.event_count = count(*),\n Esql.host_id_count_distinct = count_distinct(host.id),\n Esql.host_id_values = values(host.id),\n Esql.user_name_values = values(user.name)\n by Esql.server_webdav_cookie_replace\n| where\n Esql.host_id_count_distinct == 1 and\n Esql.event_count <= 3\n", + "references": [ + "https://attack.mitre.org/techniques/T1187/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "risk_score": 47, + "rule_id": "6756ee27-9152-479b-9b73-54b5bbda301c", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1187", + "name": "Forced Authentication", + "reference": "https://attack.mitre.org/techniques/T1187/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "6756ee27-9152-479b-9b73-54b5bbda301c_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json new file mode 100644 index 00000000000..9845c436b7a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Port Scanning Activity from Compromised Host", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Port Scanning Activity from Compromised Host\n\nPort scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent.\n\n### Possible investigation steps\n\n- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields.\n- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host.\n- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious.\n- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in.\n- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations.\n- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation.\n\n### False positive analysis\n\n- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools.\n- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names.\n- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables.\n- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers.\n- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures.\n\n### Response and remediation\n\n- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement.\n- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities.\n- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts.\n- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited.\n- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access.\n- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n", + "query": "from logs-endpoint.events.network-*\n| where\n @timestamp > now() - 1h and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\"\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n destination.port,\n process.executable,\n destination.ip,\n agent.id,\n host.name\n| stats\n Esql.event_count = count(),\n Esql.destination_port_count_distinct = count_distinct(destination.port),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, destination.ip\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.destination_port_count_distinct > 100\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "6b341d03-1d63-41ac-841a-2009c86959ca", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1046", + "name": "Network Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1046/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "6b341d03-1d63-41ac-841a-2009c86959ca_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_4.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_4.json new file mode 100644 index 00000000000..7365d8eac71 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Special Character Overuse", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Special Character Overuse\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's flexibility to obfuscate scripts, using excessive special characters to evade detection. The detection rule identifies scripts with high special character density, indicating potential obfuscation, by analyzing script length and character patterns, thus aiding in uncovering malicious activities.\n\n### Possible investigation steps\n\n- Review the dedup_space_script_block field to understand the script's structure and identify any suspicious patterns or keywords that might indicate obfuscation techniques.\n- Analyze the replaced_with_fire field to assess the density and distribution of special characters, which can provide insights into the obfuscation methods used.\n- Examine the file.path and host.name fields to determine the origin and context of the script execution, which can help identify if the script was run on a critical system or by a privileged user.\n- Check the user.id and agent.id fields to verify the identity of the user or agent executing the script, which can help assess if the activity aligns with expected behavior or if it might be unauthorized.\n- Correlate the powershell.file.script_block_id with other logs or alerts to identify if similar scripts have been executed elsewhere in the environment, indicating a broader attack pattern.\n\n### False positive analysis\n\n- Scripts with legitimate use of special characters for formatting or encoding may trigger false positives. Review the script's purpose and context to determine if the use of special characters is justified.\n- Automated scripts that heavily rely on string manipulation or dynamic content generation might be flagged. Consider adding exceptions for known scripts or trusted sources to reduce unnecessary alerts.\n- PowerShell scripts used in development or testing environments often contain high special character density. Implement environment-based exclusions to prevent these from being flagged in non-production settings.\n- Scripts utilizing SecureString or other security-related encoding methods may appear obfuscated. Verify the script's origin and purpose, and whitelist these methods if they are part of standard security practices.\n- Regularly update the detection rule to refine the pattern matching and reduce false positives by incorporating feedback from security analysts and system administrators.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated metadata to understand the intent and potential impact of the obfuscated script.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// replace repeated spaces used for formatting after a new line with a single space to reduce FPs\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\n\\s+\"\"\", \"\\n \")\n\n// Look for scripts with more than 1000 chars\n| eval Esql.script_block_length = length(Esql.script_block_tmp)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n Esql.script_block_tmp,\n \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\.]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high whitespace and special character ratio\n| where Esql.script_block_ratio > 0.75\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "6ddb6c33-00ce-4acd-832a-24b251512023", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "6ddb6c33-00ce-4acd-832a-24b251512023_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_2.json b/packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_2.json new file mode 100644 index 00000000000..a234462d0f9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_2.json @@ -0,0 +1,61 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response.", + "false_positives": [ + "Access removal may be a part of normal operations and should be verified before taking action." + ], + "from": "now-6m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS EC2 EBS Snapshot Access Removed", + "note": "## Triage and analysis\n\n### Investigating AWS EC2 EBS Snapshot Access Removed\n\nThis rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack.\nRestricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they should have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities. In particular, use the `snapshotId` to see if this snapshot was shared with an unauthorized account.\n- **Review UserID**: Check the `userId` field to identify which user's permissions were removed. Verify if this account should be authorized to access the data or if the access removal is expected.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to restore it to its previous state.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions.\n- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing EBS snapshots and securing AWS environments, refer to the [AWS EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security:\n- [AWS EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)\n- [AWS API ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n// Filter for successful snapshot modifications\n| where\n event.provider == \"ec2.amazonaws.com\"\n and event.action == \"ModifySnapshotAttribute\"\n and event.outcome == \"success\"\n\n// dissect parameters to extract key fields\n| dissect aws.cloudtrail.request_parameters\n \"{%{?snapshotId}=%{Esql.aws_cloudtrail_request_parameters_snapshot_id},%{?attributeType}=%{Esql.aws_cloudtrail_request_parameters_attribute_type},%{?createVolumePermission}={%{Esql.aws_cloudtrail_request_parameters_operation_type}={%{?items}=[{%{?userId}=%{Esql_priv.aws_cloudtrail_request_parameters_user_id}}]}}}\"\n\n// Match on snapshot permission **removal**\n| where Esql.aws_cloudtrail_request_parameters_operation_type == \"remove\"\n\n// keep ECS and derived fields\n| keep\n @timestamp,\n aws.cloudtrail.user_identity.arn,\n cloud.account.id,\n event.action,\n Esql.aws_cloudtrail_request_parameters_snapshot_id,\n Esql.aws_cloudtrail_request_parameters_attribute_type,\n Esql.aws_cloudtrail_request_parameters_operation_type,\n Esql_priv.aws_cloudtrail_request_parameters_user_id,\n source.address\n", + "references": [ + "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html" + ], + "risk_score": 21, + "rule_id": "713e0f5f-caf7-4dc2-88a7-3561f61f262a", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1485", + "name": "Data Destruction", + "reference": "https://attack.mitre.org/techniques/T1485/" + }, + { + "id": "T1490", + "name": "Inhibit System Recovery", + "reference": "https://attack.mitre.org/techniques/T1490/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "713e0f5f-caf7-4dc2-88a7-3561f61f262a_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_2.json b/packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_2.json new file mode 100644 index 00000000000..efe497bc131 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/720fc1aa-e195-4a1d-81d8-04edfe5313ed_2.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app.", + "from": "now-2m", + "index": [ + "logs-elastic_security.alert-*" + ], + "interval": "1m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 1000, + "name": "Elastic Security External Alerts", + "note": "## Triage and analysis\n\n### Investigating Elastic Security External Alerts\n\nThe Elastic Security integration facilitates transferring security alert data from another Elasticsearch instance to your own, enabling threats to be investigated in a centralized manner.\n\n### Possible investigation steps\n\n- Correlate the alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns.\n- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident.\n- Investigate the source and destination IP addresses involved in the alert to assess if they are known to be malicious or associated with previous threats.\n- Analyze any files or processes flagged in the alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary.\n- Consult the Elastic Security investigation guide and resources tagged in the alert for specific guidance on handling similar threats.\n\n### False positive analysis\n\n- Alerts triggered by routine software updates or patches can be false positives. Review the context of the alert to determine if it aligns with scheduled maintenance activities.\n- Legitimate administrative tools or scripts may trigger alerts. Identify and whitelist these tools if they are verified as non-threatening.\n- Frequent alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the Elastic Security configuration.\n- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations.\n- User behavior that is consistent with their role but triggers alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions.\n\n### Response and remediation\n\n- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network.\n- Analyze the specific alert details to identify the nature of the threat and any associated indicators of compromise (IOCs).\n- Remove or quarantine any malicious files or processes identified by the Elastic Security alert to neutralize the threat.\n- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint.\n- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior.\n- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation.\n- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future.\n", + "query": "event.kind: alert and data_stream.dataset: elastic_security.alert\n", + "references": [ + "https://docs.elastic.co/en/integrations/elastic_security" + ], + "related_integrations": [ + { + "package": "elastic_security", + "version": "^0.1.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + } + ], + "risk_score": 47, + "risk_score_mapping": [ + { + "field": "event.risk_score", + "operator": "equals", + "value": "" + } + ], + "rule_id": "720fc1aa-e195-4a1d-81d8-04edfe5313ed", + "rule_name_override": "kibana.alert.rule.name", + "setup": "## Setup\n\n### Elastic Security Alert Integration\nThis rule is designed to capture alert events generated by the Elastic Security integration and promote them as Elastic detection alerts.\n\nTo capture Elastic Security alerts, install and configure the Elastic Security integration to ingest alert events into the `logs-elastic_security.alert-*` index pattern.\n\nIf this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Elastic Security events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:elastic_security.alert to avoid receiving duplicate alerts.\n\n### Additional notes\n\nFor information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).\n", + "severity": "medium", + "severity_mapping": [ + { + "field": "event.severity", + "operator": "equals", + "severity": "low", + "value": "21" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "medium", + "value": "47" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "high", + "value": "73" + }, + { + "field": "event.severity", + "operator": "equals", + "severity": "critical", + "value": "99" + } + ], + "tags": [ + "Data Source: Elastic Security", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Promotion: External Alerts" + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 2 + }, + "id": "720fc1aa-e195-4a1d-81d8-04edfe5313ed_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_5.json b/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_5.json new file mode 100644 index 00000000000..65aefda4ed3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_5.json @@ -0,0 +1,52 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.", + "false_positives": [ + "Legitimate misunderstanding by users on accessing the bedrock models." + ], + "from": "now-60m", + "interval": "10m", + "investigation_fields": { + "field_names": [ + "target_time_window", + "user.id", + "cloud.account.id", + "total_denials" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Detected Multiple Validation Exception Errors by a Single User", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Detected Multiple Validation Exception Errors by a Single User\n\nAmazon Bedrock is AWS\u2019s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.\n\nBedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.\n\n#### Possible investigation steps\n\n- Identify the user account that caused validation errors in accessing the Amazon Bedrock models.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that that caused validation errors is a legitimate misunderstanding by users on accessing the bedrock models.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n - Identify if any implication to resource billing.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Truncate timestamp to 1-minute window\n| eval Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)\n\n// Filter for validation exceptions in responses\n| where gen_ai.response.error_code == \"ValidationException\"\n\n// keep relevant ECS and derived fields\n| keep\n user.id,\n gen_ai.request.model.id,\n cloud.account.id,\n gen_ai.response.error_code,\n Esql.time_window_date_trunc\n\n// count number of denials by user/account/time window\n| stats\n Esql.ml_response_validation_error_count = count(*)\n by\n Esql.time_window_date_trunc,\n user.id,\n cloud.account.id\n\n// Filter for excessive errors\n| where Esql.ml_response_validation_error_count > 3\n", + "references": [ + "https://atlas.mitre.org/techniques/AML.T0015", + "https://atlas.mitre.org/techniques/AML.T0034", + "https://atlas.mitre.org/techniques/AML.T0046", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 73, + "rule_id": "725a048a-88c5-4fc7-8677-a44fc0031822", + "setup": "## Setup\n\nThis rule requires that AWS Bedrock Integration be configured. For more information, see the AWS Bedrock integration documentation:\n\nhttps://www.elastic.co/docs/current/integrations/aws_bedrock\n", + "severity": "high", + "tags": [ + "Domain: LLM", + "Data Source: AWS", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0015", + "Mitre Atlas: T0034", + "Mitre Atlas: T0046", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "725a048a-88c5-4fc7-8677-a44fc0031822_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_3.json b/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_3.json new file mode 100644 index 00000000000..537cdad2327 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_3.json @@ -0,0 +1,62 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a single AWS resource is running multiple `Describe` and `List` API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure.", + "false_positives": [ + "Administrators or automated systems may legitimately perform multiple `Describe` and `List` API calls in a short time frame. Verify the user identity and the purpose of the API calls to determine if the behavior is expected." + ], + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "time_window", + "aws.cloudtrail.user_identity.arn", + "unique_api_count" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Discovery API Calls via CLI from a Single Resource", + "note": "## Triage and analysis\n\n### Investigating AWS Discovery API Calls via CLI from a Single Resource\n\nThis rule detects multiple discovery-related API calls (`Describe`, `List`, or `Get` actions) within a short time window (30 seconds) from a single AWS resource. High volumes of such calls may indicate attempts to enumerate AWS infrastructure for reconnaissance purposes, which is often a tactic used by adversaries with compromised credentials or unauthorized access.\n\n#### Possible Investigation Steps\n\n- **Identify the Actor and Resource**:\n - **User Identity and Resource**: Examine `aws.cloudtrail.user_identity.arn` to identify the actor making the discovery requests. Verify the user or resource associated with these actions to ensure they are recognized and expected.\n - **User Agent and Tooling**: Check `user_agent.name` to confirm whether the `aws-cli` tool was used for these requests. Use of the CLI in an atypical context might indicate unauthorized or automated access.\n\n- **Evaluate the Context and Scope of API Calls**:\n - **API Action Types**: Look into the specific actions under `event.action` for API calls like `Describe*`, `List*`, or `Get*`. Note if these calls are targeting sensitive services, such as `EC2`, `IAM`, or `S3`, which may suggest an attempt to identify high-value assets.\n - **Time Pattern Analysis**: Review the `time_window` and `unique_api_count` to assess whether the frequency of these calls is consistent with normal patterns for this resource or user.\n\n- **Analyze Potential Compromise Indicators**:\n - **Identity Type**: Review `aws.cloudtrail.user_identity.type` to determine if the calls originated from an assumed role, a root user, or a service role. Unusual identity types for discovery operations may suggest misuse or compromise.\n - **Source IP and Geographic Location**: Examine the `source.ip` and `source.geo` fields to identify any unusual IP addresses or locations associated with the activity, which may help confirm or rule out external access.\n\n- **Examine Related CloudTrail Events**:\n - **Pivot for Related Events**: Identify any additional IAM or CloudTrail events tied to the same actor ARN. Activities such as `AssumeRole`, `GetSessionToken`, or `CreateAccessKey` in proximity to these discovery calls may signal an attempt to escalate privileges.\n - **Look for Anomalous Patterns**: Determine if this actor or resource has performed similar discovery actions previously, or if these actions coincide with other alerts related to credential use or privilege escalation.\n\n### False Positive Analysis\n\n- **Expected Discovery Activity**: Regular discovery or enumeration API calls may be conducted by security, automation, or monitoring scripts to maintain an inventory of resources. Validate if this activity aligns with known automation or inventory tasks.\n- **Routine Admin or Automated Access**: If specific roles or resources, such as automation tools or monitoring services, regularly trigger this rule, consider adding exceptions for these known, benign users to reduce false positives.\n\n### Response and Remediation\n\n- **Confirm Authorized Access**: If the discovery activity appears unauthorized, consider immediate steps to restrict the user or resource\u2019s permissions.\n- **Review and Remove Unauthorized API Calls**: If the actor is not authorized to perform discovery actions, investigate and potentially disable their permissions or access keys to prevent further misuse.\n- **Enhance Monitoring for Discovery Patterns**: Consider additional logging or alerting for high-frequency discovery API calls, especially if triggered from new or unrecognized resources.\n- **Policy Review and Updates**: Review IAM policies associated with the actor, ensuring restrictive permissions and MFA enforcement where possible to prevent unauthorized discovery.\n\n### Additional Information\n\nFor further guidance on AWS infrastructure discovery and best practices, refer to [AWS CloudTrail documentation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html) and MITRE ATT&CK\u2019s [Cloud Infrastructure Discovery](https://attack.mitre.org/techniques/T1580/).\n", + "query": "from logs-aws.cloudtrail*\n\n// create time window buckets of 10 seconds\n| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp)\n| where\n event.dataset == \"aws.cloudtrail\"\n\n // filter on CloudTrail audit logs for IAM, EC2, S3, etc.\n and event.provider in (\n \"iam.amazonaws.com\",\n \"ec2.amazonaws.com\",\n \"s3.amazonaws.com\",\n \"rds.amazonaws.com\",\n \"lambda.amazonaws.com\",\n \"dynamodb.amazonaws.com\",\n \"kms.amazonaws.com\",\n \"cloudfront.amazonaws.com\",\n \"elasticloadbalancing.amazonaws.com\"\n )\n\n // ignore AWS service actions\n and aws.cloudtrail.user_identity.type != \"AWSService\"\n\n // filter for aws-cli specifically\n and user_agent.name == \"aws-cli\"\n\n // exclude DescribeCapacityReservations events related to AWS Config\n and not event.action in (\"DescribeCapacityReservations\")\n\n// filter for Describe, Get, List, and Generate API calls\n| where true in (\n starts_with(event.action, \"Describe\"),\n starts_with(event.action, \"Get\"),\n starts_with(event.action, \"List\"),\n starts_with(event.action, \"Generate\")\n)\n\n// extract owner, identity type, and actor from the ARN\n| dissect aws.cloudtrail.user_identity.arn \"%{}::%{Esql_priv.aws_cloudtrail_user_identity_arn_owner}:%{Esql.aws_cloudtrail_user_identity_arn_type}/%{Esql.aws_cloudtrail_user_identity_arn_roles}\"\n| where starts_with(Esql.aws_cloudtrail_user_identity_arn_roles, \"AWSServiceRoleForConfig\") != true\n\n// keep relevant fields (preserving ECS fields and computed time window)\n| keep @timestamp, Esql.time_window_date_trunc, event.action, aws.cloudtrail.user_identity.arn\n\n// count the number of unique API calls per time window and actor\n| stats\n Esql.event_action_count_distinct = count_distinct(event.action)\n by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn\n\n// filter for more than 5 unique API calls per 10s window\n| where Esql.event_action_count_distinct > 5\n\n// sort the results by the number of unique API calls in descending order\n| sort Esql.event_action_count_distinct desc\n", + "references": [ + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/" + ], + "risk_score": 21, + "rule_id": "74f45152-9aee-11ef-b0a5-f661ea17fbcd", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: AWS EC2", + "Data Source: AWS IAM", + "Data Source: AWS S3", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "74f45152-9aee-11ef-b0a5-f661ea17fbcd_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_5.json b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_5.json new file mode 100644 index 00000000000..1c179ffbf5a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_5.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Malware-Driven SSH Brute Force Attempt", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Malware-Driven SSH Brute Force Attempt\n\nSSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths.\n- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information.\n- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations.\n- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise.\n- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware.\n- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts.\n\n### False positive analysis\n\n- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list.\n- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule.\n- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers.\n- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions.\n\n### Response and remediation\n\n- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems.\n- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise.\n- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software.\n- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security.\n- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats.\n- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly.\n- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\" and\n destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and\n not cidr_match(\n destination.ip,\n \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\",\n \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\",\n \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\", \"198.18.0.0/15\",\n \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\", \"FE80::/10\", \"FF00::/8\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, destination.port\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count > 15\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "77122db4-5876-4127-b91b-6c179eb21f88", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Impact", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1496", + "name": "Resource Hijacking", + "reference": "https://attack.mitre.org/techniques/T1496/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "77122db4-5876-4127-b91b-6c179eb21f88_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json new file mode 100644 index 00000000000..e774c83eb25 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json @@ -0,0 +1,57 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.", + "false_positives": [ + "Administrators may legitimately access, delete, and replace objects in S3 buckets. Ensure that the sequence of events is not part of a legitimate operation before taking action." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential AWS S3 Bucket Ransomware Note Uploaded", + "note": "## Triage and analysis\n\n### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded\n\nThis rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `PutObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the ransom note was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Inspect the Ransom Note**: Review the `aws.cloudtrail.request_parameters` for the `PutObject` action to identify the characteristics of the uploaded ransom note. Look for common ransomware file extensions such as `.txt`, `.note`, `.ransom`, or `.html`.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects before placing the ransom note.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `PutObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the upload was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the activity was unauthorized, remove the uploaded ransom notes from the S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `PutObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [AWS S3 Ransomware Batch Deletion](https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", + "query": "from logs-aws.cloudtrail-*\n\n// any successful uploads via S3 API requests\n| where\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutObject\"\n and event.outcome == \"success\"\n\n// extract object key from API request parameters\n| dissect aws.cloudtrail.request_parameters \"%{?ignore_values}key=%{Esql.aws_cloudtrail_request_parameters_object_key}}\"\n\n// regex match against common ransomware naming patterns\n| where\n Esql.aws_cloudtrail_request_parameters_object_key rlike \"(.*)(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue)(.*)\"\n and not Esql.aws_cloudtrail_request_parameters_object_key rlike \"(.*)(AWSLogs|CloudTrail|access-logs)(.*)\"\n\n// keep relevant ECS and derived fields\n| keep\n tls.client.server_name,\n aws.cloudtrail.user_identity.arn,\n Esql.aws_cloudtrail_request_parameters_object_key\n\n// aggregate by server name, actor, and object key\n| stats\n Esql.event_count = count(*)\n by\n tls.client.server_name,\n aws.cloudtrail.user_identity.arn,\n Esql.aws_cloudtrail_request_parameters_object_key\n\n// filter for rare single uploads (likely test/detonation)\n| where Esql.event_count == 1\n", + "references": [ + "https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf", + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/", + "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" + ], + "risk_score": 47, + "rule_id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce", + "setup": "AWS S3 data types need to be enabled in the CloudTrail trail configuration.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1485", + "name": "Data Destruction", + "reference": "https://attack.mitre.org/techniques/T1485/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_3.json b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_3.json new file mode 100644 index 00000000000..d08d7ca8857 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Character Array Reconstruction", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Character Array Reconstruction\n\nPowerShell, a powerful scripting language, is often targeted by adversaries for obfuscation to bypass security measures. By reconstructing strings from character arrays, attackers evade static analysis and detection. The detection rule identifies scripts using such obfuscation by searching for patterns indicative of character array manipulation, thus flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on the obfuscated parts indicated by the presence of the \"char\" keyword and the \ud83d\udd25 character.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context about the environment and potential risk.\n- Check the user.id and agent.id fields to identify the user and agent responsible for executing the script, which can help assess whether the activity is expected or suspicious.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related script blocks, providing a broader view of the script's behavior.\n- Investigate the count field to assess the extent of obfuscation, as a higher count may indicate more complex or extensive obfuscation techniques being used.\n\n### False positive analysis\n\n- Scripts used for legitimate administrative tasks may use character arrays for performance optimization or to handle special characters. Review the script's purpose and context to determine if it aligns with known administrative functions.\n- PowerShell scripts from trusted sources or vendors might use character arrays for legitimate obfuscation to protect intellectual property. Verify the script's origin and check for digital signatures or hashes to confirm authenticity.\n- Automated scripts generated by development tools or frameworks could include character array manipulation as part of their standard output. Identify and whitelist these tools if they are commonly used in your environment.\n- Security tools or monitoring solutions might use character arrays in their scripts for legitimate purposes. Cross-reference with known security software and consider excluding these from the detection rule if they are verified as safe.\n- Regularly update the exclusion list to include new trusted scripts or tools as they are introduced into the environment, ensuring that legitimate activities are not flagged as false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the script block text and associated logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential credential compromise.\n- Update endpoint protection and ensure that AMSI and other security features are fully enabled and configured to detect similar threats.\n- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contain the \"char\" keyword using MATCH, boosts the query performance\n| where powershell.file.script_block_text : \"char\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(char\\[\\]\\]\\(\\d+,\\d+[^)]+|(\\s?\\(\\[char\\]\\d+\\s?\\)\\+){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "85e2d45e-a3df-4acf-83d3-21805f564ff4", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "85e2d45e-a3df-4acf-83d3-21805f564ff4_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_5.json b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_5.json new file mode 100644 index 00000000000..f81fd10bfad --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_5.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Subnet Scanning Activity from Compromised Host", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Subnet Scanning Activity from Compromised Host\n\nSubnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections.\n- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external.\n- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access.\n- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host.\n- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes.\n\n### False positive analysis\n\n- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list.\n- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID.\n- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved.\n- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID.\n- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID.\n\n### Response and remediation\n\n- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker.\n- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities.\n- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed.\n- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists.\n- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps.\n- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise.\n- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id, host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\"\n| stats\n Esql.event_count = count(),\n Esql.destination_ip_count_distinct = count_distinct(destination.ip),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.destination_ip_count_distinct > 250\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1046", + "name": "Network Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1046/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_4.json b/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_4.json new file mode 100644 index 00000000000..2799214300d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_4.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule detects unusual file creations from a web server parent process. Adversaries may attempt to create files from a web server parent process to establish persistence, execute malicious scripts, or exfiltrate data. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual File Creation by Web Server", + "query": "from logs-endpoint.events.file-*\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n user.name,\n user.id,\n process.name,\n process.executable,\n file.path,\n agent.id,\n host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"change\" and\n event.action in (\"rename\", \"creation\") and (\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\")\n ) and (\n process.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.name like \"php-*\" or\n process.name like \"python*\" or\n process.name like \"ruby*\" or\n process.name like \"perl*\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, file.path\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "894b7cc9-040b-427c-aca5-36b40d3667bf", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "894b7cc9-040b-427c-aca5-36b40d3667bf_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_5.json b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_5.json new file mode 100644 index 00000000000..a7c6d840684 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_5.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Command Execution from Web Server Parent", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Command Execution from Web Server Parent\n\nWeb servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent.\n- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise.\n- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited.\n- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user.\n- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack.\n- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue.\n\n### False positive analysis\n\n- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule.\n- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs.\n- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables.\n- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule.\n- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation.\n\n- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes.\n\n- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies.\n\n- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches.\n\n- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration.\n\n- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections.\n\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps.\n", + "query": "from logs-endpoint.events.process-*\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.parent.name,\n user.name,\n user.id,\n process.working_directory,\n process.name,\n process.command_line,\n process.parent.executable,\n agent.id,\n host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n ) and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\n process.command_line like \"* -c *\" and not (\n process.working_directory like \"/home/*\" or\n process.working_directory == \"/\" or\n process.working_directory like \"/vscode/vscode-server/*\" or\n process.parent.executable like \"/vscode/vscode-server/*\" or\n process.parent.executable == \"/usr/bin/xfce4-terminal\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.command_line, process.working_directory, process.parent.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_5.json b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_5.json new file mode 100644 index 00000000000..484b74ecbae --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_5.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual File Transfer Utility Launched", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual File Transfer Utility Launched\n\nFile transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious.\n- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity.\n- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context.\n- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution.\n- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule.\n\n### False positive analysis\n\n- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs.\n- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives.\n- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts.\n- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration.\n- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access.\n- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers.\n- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer.\n- Change credentials and access keys associated with the compromised system to prevent further unauthorized access.\n- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems.\n- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system.\n- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.\n", + "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id, host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and\n process.name in (\"scp\", \"ftp\", \"sftp\", \"vsftpd\", \"sftp-server\", \"rsync\")\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, process.parent.executable, process.command_line\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "8eeeda11-dca6-4c3e-910f-7089db412d1c", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "8eeeda11-dca6-4c3e-910f-7089db412d1c_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_206.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_206.json new file mode 100644 index 00000000000..7f21bb6876f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_206.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Okta User Authentication Events with Client Address", + "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Client Address\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\nSince this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action == \"user.session.start\" or event.action rlike \"user\\.authentication(.*)\") and\n okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| keep\n okta.client.ip,\n okta.actor.alternate_id,\n okta.actor.id,\n event.action,\n okta.outcome.reason\n| stats\n Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)\n by\n okta.client.ip,\n okta.actor.alternate_id\n| where\n Esql.okta_actor_id_count_distinct > 5\n| sort\n Esql.okta_actor_id_count_distinct desc\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 21, + "rule_id": "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 206 + }, + "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_206", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_206.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_206.json new file mode 100644 index 00000000000..be2097504a3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_206.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Okta User Authentication Events with Same Device Token Hash", + "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Same Device Token Hash\n\nThis rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action rlike \"user\\.authentication(.*)\" or event.action == \"user.session.start\") and\n okta.debug_context.debug_data.dt_hash != \"-\" and\n okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| keep\n event.action,\n okta.debug_context.debug_data.dt_hash,\n okta.actor.id,\n okta.actor.alternate_id,\n okta.outcome.reason\n| stats\n Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)\n by\n okta.debug_context.debug_data.dt_hash,\n okta.actor.alternate_id\n| where\n Esql.okta_actor_id_count_distinct > 20\n| sort\n Esql.okta_actor_id_count_distinct desc\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 21, + "rule_id": "95b99adc-2cda-11ef-84e1-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 206 + }, + "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_206", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_5.json b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_5.json new file mode 100644 index 00000000000..effb4763ecf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_5.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Process Spawned from Web Server Parent", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Process Spawned from Web Server Parent\n\nWeb servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment.\n- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories.\n- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account.\n- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced.\n- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise.\n- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited.\n\n### False positive analysis\n\n- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening.\n- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts.\n- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories.\n- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows.\n- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.\n- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations.\n- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary.\n- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup.\n- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access.\n- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.\n", + "query": "from logs-endpoint.events.process-*\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.parent.name,\n user.name,\n user.id,\n process.working_directory,\n process.name,\n process.executable,\n process.command_line,\n process.parent.executable,\n agent.id,\n host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n ) and not (\n process.working_directory like \"/home/*\" or\n process.working_directory == \"/\" or\n process.parent.executable like \"/vscode/vscode-server/*\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, process.working_directory, process.parent.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 47, + "rule_id": "976b2391-413f-4a94-acb4-7911f3803346", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "976b2391-413f-4a94-acb4-7911f3803346_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_7.json b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_7.json new file mode 100644 index 00000000000..1e9eb26d63e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_7.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target user." + ], + "from": "now-6m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "source.address", + "aws.cloudtrail.user_identity.arn", + "user_agent.original", + "target.userName", + "event.action", + "policyName", + "event.outcome", + "cloud.region", + "event.provider", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM AdministratorAccess Policy Attached to User", + "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to User\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachUserPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user for privilege escalation or another user as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachUserPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n| where\n event.provider == \"iam.amazonaws.com\"\n and event.action == \"AttachUserPolicy\"\n and event.outcome == \"success\"\n\n// Extract policy name and user name from request parameters\n| dissect aws.cloudtrail.request_parameters\n \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{Esql.aws_cloudtrail_request_parameters_policy_name},%{?userName}=%{Esql_priv.aws_cloudtrail_request_parameters_target_user_name}}\"\n\n// Filter for AdministratorAccess policy\n| where Esql.aws_cloudtrail_request_parameters_policy_name == \"AdministratorAccess\"\n\n// keep ECS and parsed fields\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n Esql.aws_cloudtrail_request_parameters_policy_name,\n Esql_priv.aws_cloudtrail_request_parameters_target_user_name,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.user_identity.arn,\n related.user,\n user_agent.original,\n user.name,\n source.address\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" + ], + "risk_score": 47, + "rule_id": "9aa4be8d-5828-417d-9f54-7cd304571b24", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "9aa4be8d-5828-417d-9f54-7cd304571b24_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_3.json b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_3.json new file mode 100644 index 00000000000..47d93c8121e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "PowerShell Obfuscation via Negative Index String Reversal", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating PowerShell Obfuscation via Negative Index String Reversal\n\nPowerShell, a powerful scripting language, can be exploited by adversaries using obfuscation techniques like negative index string reversal to evade detection. This method manipulates strings or arrays by iterating in reverse, bypassing static analysis tools. The detection rule identifies scripts with obfuscation patterns by analyzing script length and specific indexing patterns, flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` to understand the script's intent and identify any suspicious or malicious behavior.\n- Check the `host.name` and `user.id` fields to determine the affected system and user, assessing if they are high-value targets or have a history of similar alerts.\n- Analyze the `file.path` to identify the location of the script and assess if it is in a common or suspicious directory.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` to trace the execution flow and determine if this script is part of a larger, potentially malicious sequence.\n- Correlate the `agent.id` with other logs to see if there are additional related activities or alerts from the same endpoint.\n- Examine the `count` of detected patterns to assess the level of obfuscation and potential threat severity.\n\n### False positive analysis\n\n- Scripts containing the keyword \"GENESIS-5654\" are known false positives and are automatically excluded from triggering alerts. Ensure that any legitimate scripts using this keyword are documented to prevent unnecessary investigations.\n- Legitimate administrative scripts that use negative indexing for valid purposes may trigger false positives. Review these scripts and consider adding them to an exception list if they are frequently flagged but verified as non-malicious.\n- Automated scripts generated by trusted software that use similar obfuscation patterns for performance or compatibility reasons can be excluded by identifying unique identifiers or patterns within these scripts and updating the exclusion criteria accordingly.\n- Regularly update the exclusion list to include new patterns or identifiers from trusted sources as they are identified, ensuring that legitimate activities are not hindered by the detection rule.\n- Collaborate with IT and security teams to maintain a list of known safe scripts and their characteristics, which can be referenced when analyzing potential false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the PowerShell script block text and related logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential unauthorized access.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"\\$\\w+\\[\\-\\s?1\\.\\.\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n// FP Patterns\n| where not powershell.file.script_block_text like \"*GENESIS-5654*\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "9edd1804-83c7-4e48-b97d-c776b4c97564", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "9edd1804-83c7-4e48-b97d-c776b4c97564_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_4.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_4.json new file mode 100644 index 00000000000..1009007a52d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Dynamic IEX Reconstruction via Method String Access", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Dynamic IEX Reconstruction via Method String Access\n\nPowerShell's flexibility allows dynamic command execution, which adversaries exploit by obfuscating commands like Invoke-Expression (IEX). They manipulate method strings to reconstruct IEX, evading static detection. The detection rule identifies scripts using this obfuscation by analyzing patterns in method string access, flagging suspicious activity for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script that triggered the alert. Look for any suspicious patterns or obfuscation techniques.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and user.id fields to identify the machine and user account involved in executing the script, which can help assess whether the activity aligns with expected behavior.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other PowerShell activities on the host, providing a broader view of the script's execution context.\n- Investigate the agent.id field to verify the endpoint's security posture and ensure that it is up-to-date with the latest security patches and configurations.\n\n### False positive analysis\n\n- Scripts with legitimate use of string manipulation methods like IndexOf or SubString may trigger false positives if they are part of complex PowerShell scripts used in administrative tasks. To manage this, review the context of the script and consider adding exceptions for known safe scripts or users.\n- Automated scripts from trusted software that perform extensive string operations for configuration or data processing might be flagged. Identify these scripts and exclude them by their script block ID or file path to prevent unnecessary alerts.\n- Development environments where PowerShell is used for testing or debugging purposes may generate alerts due to frequent use of string manipulation. Implement exclusions based on host names or user IDs associated with these environments to reduce noise.\n- Security tools or monitoring solutions that use PowerShell for log analysis or system checks might inadvertently match the detection pattern. Verify the source of the script and whitelist these tools by agent ID or specific script characteristics.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and script block ID from the alert to understand the scope and intent of the obfuscation technique used.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any additional threats.\n- Restore the affected system from a known good backup if the integrity of the system is compromised and cannot be assured.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "9f432a8b-9588-4550-838e-1f77285580d3_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_6.json b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_6.json new file mode 100644 index 00000000000..246bee4530a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_6.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data.", + "false_positives": [ + "Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before taking action." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS S3 Object Encryption Using External KMS Key", + "note": "## Triage and analysis\n\n### Investigating AWS S3 Object Encryption Using External KMS Key\n\nThis rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data.\nThis rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule) to look for use of the `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the object was copied. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions.\n- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n\n### Response and Remediation:\n\n- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n// any successful S3 copy event\n| where\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"CopyObject\"\n and event.outcome == \"success\"\n\n// dissect request parameters to extract KMS key info and target object info\n| dissect aws.cloudtrail.request_parameters\n \"{%{?bucketName}=%{Esql.aws_cloudtrail_request_parameters_target_bucket_name},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{Esql.aws_cloudtrail_request_parameters_kms_key_account_id}:%{?key}/%{Esql.aws_cloudtrail_request_parameters_kms_key_id},%{?Host}=%{?tls.client.server.name},%{?x-amz-server-side-encryption}=%{?server_side_encryption},%{?x-amz-copy-source}=%{?bucket.object.name},%{?key}=%{Esql.aws_cloudtrail_request_parameters_target_object_key}}\"\n\n// detect cross-account key usage\n| where cloud.account.id != Esql.aws_cloudtrail_request_parameters_kms_key_account_id\n\n// keep ECS and dissected fields\n| keep\n @timestamp,\n aws.cloudtrail.user_identity.arn,\n cloud.account.id,\n event.action,\n Esql.aws_cloudtrail_request_parameters_target_bucket_name,\n Esql.aws_cloudtrail_request_parameters_kms_key_account_id,\n Esql.aws_cloudtrail_request_parameters_kms_key_id,\n Esql.aws_cloudtrail_request_parameters_target_object_key\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/", + "https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/", + "https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/", + "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" + ], + "risk_score": 47, + "rule_id": "ab8f074c-5565-4bc4-991c-d49770e19fc9", + "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Data Source: AWS KMS", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "ab8f074c-5565-4bc4-991c-d49770e19fc9_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_3.json b/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_3.json new file mode 100644 index 00000000000..c66774d1c47 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_3.json @@ -0,0 +1,40 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls.", + "false_positives": [ + "Unexpected system errors", + "Legitimate spikes in usage due to business processes" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Denial of Azure OpenAI ML Service", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Denial of Azure OpenAI ML Service\n\nAzure OpenAI ML services enable scalable deployment of machine learning models, crucial for AI-driven applications. Adversaries may exploit these services by overwhelming them with excessive or malformed requests, leading to service degradation or outages. The detection rule identifies such threats by monitoring for high-frequency, large-size requests, which are indicative of potential denial-of-service attacks.\n\n### Possible investigation steps\n\n- Review the logs for the specific time window identified by the target_time_window field to understand the context and volume of requests.\n- Identify the specific Azure resource involved using the azure.resource.name field to determine if the service is critical or sensitive.\n- Examine the cloud.account.id field to ascertain if the requests are originating from a known or trusted account, or if they are potentially malicious.\n- Analyze the request patterns, focusing on the avg_request_size and count fields, to determine if the requests are consistent with normal usage or indicative of a potential attack.\n- Check for any recent changes or updates to the Azure OpenAI ML service configuration or deployment that might have affected its performance or security posture.\n- Correlate the findings with other security logs or alerts to identify any related suspicious activities or broader attack patterns.\n\n### False positive analysis\n\n- High-volume legitimate usage patterns can trigger false positives, such as during scheduled batch processing or data analysis tasks. Users can mitigate this by setting exceptions for known time windows or specific resource names associated with these activities.\n- Large input sizes from legitimate applications, like those processing extensive datasets or complex queries, may be misidentified as threats. Users should identify and whitelist these applications by their resource names or account IDs.\n- Testing and development environments often generate high-frequency requests as part of load testing or performance tuning. Users can exclude these environments by filtering out specific resource names or account IDs associated with non-production activities.\n- Automated scripts or integrations that interact with the Azure OpenAI ML service at high frequencies for valid business processes might be flagged. Users should document and exclude these scripts by identifying their unique request patterns or resource identifiers.\n\n### Response and remediation\n\n- Immediately throttle or block the IP addresses or accounts responsible for the high-frequency, large-size requests to prevent further service degradation.\n- Notify the Azure OpenAI service administrators and relevant stakeholders about the detected potential denial-of-service attack for awareness and further action.\n- Review and adjust rate limiting and request size policies on the Azure OpenAI ML service to mitigate the impact of similar attacks in the future.\n- Conduct a post-incident analysis to identify any vulnerabilities or misconfigurations that allowed the attack to occur and address them promptly.\n- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger threat campaign.\n- Implement additional monitoring and alerting for unusual patterns of requests, focusing on high volume and frequency, to enhance early detection of similar threats.\n- Coordinate with the cloud provider's support team to ensure any necessary infrastructure adjustments or protections are in place to prevent recurrence.\n", + "query": "from logs-azure_openai.logs-*\n| eval\n Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)\n| where azure.open_ai.operation_name == \"ChatCompletions_Create\"\n| keep\n azure.open_ai.properties.request_length,\n azure.resource.name,\n cloud.account.id,\n Esql.time_window_date_trunc\n| stats\n Esql.event_count = count(*),\n Esql.azure_open_ai_properties_request_length_avg = avg(azure.open_ai.properties.request_length)\n by\n Esql.time_window_date_trunc,\n azure.resource.name\n| where\n Esql.event_count >= 10 and\n Esql.azure_open_ai_properties_request_length_avg >= 5000\n| sort Esql.event_count desc\n", + "references": [ + "https://genai.owasp.org/llmrisk/llm04-model-denial-of-service", + "https://atlas.mitre.org/techniques/AML.T0029" + ], + "risk_score": 47, + "rule_id": "b0450411-46e5-46d2-9b35-8b5dd9ba763e", + "setup": "## Setup\n\nFor more information on streaming events, see the Azure OpenAI documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: Azure OpenAI", + "Data Source: Azure Event Hubs", + "Use Case: Denial of Service", + "Mitre Atlas: T0029", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "b0450411-46e5-46d2-9b35-8b5dd9ba763e_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_3.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_3.json new file mode 100644 index 00000000000..7fd823b2cec --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Dynamic IEX Reconstruction via Environment Variables", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Dynamic IEX Reconstruction via Environment Variables\n\nPowerShell's Invoke-Expression (IEX) command is a powerful tool for executing strings as code, often exploited by attackers to run obfuscated scripts. Adversaries may dynamically reconstruct IEX using environment variables to evade static detection. The detection rule identifies scripts that manipulate environment variables to form IEX commands, focusing on patterns of character slicing and joining, which are indicative of obfuscation techniques. By analyzing script length and specific patterns, the rule effectively flags potential misuse, aiding in defense against such evasion tactics.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on how environment variables are manipulated to reconstruct the IEX command.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context on whether the activity is expected or suspicious.\n- Analyze the user.id and agent.id fields to identify the user and agent responsible for executing the script, checking for any anomalies or unauthorized access.\n- Investigate the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related PowerShell activities on the host.\n- Assess the count field to understand the extent of obfuscation patterns detected, which can indicate the complexity and potential maliciousness of the script.\n\n### False positive analysis\n\n- Scripts with legitimate use of environment variables for configuration management may trigger the rule. Users can create exceptions for specific scripts or processes known to use environment variables in a non-threatening manner.\n- Automated scripts that dynamically construct commands for legitimate administrative tasks might be flagged. Review the script's purpose and source, and whitelist trusted scripts or processes.\n- Development environments where scripts are frequently tested and modified may produce false positives. Implement monitoring exclusions for development machines or specific user accounts involved in script testing.\n- Scripts using environment variables for localization or language settings can be mistakenly identified. Identify and exclude scripts that are part of standard localization processes.\n- PowerShell scripts from trusted vendors or software packages that use environment variables for legitimate functionality should be reviewed and excluded from detection if verified as safe.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit lateral movement.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and associated file paths to understand the scope and intent of the script, focusing on any obfuscated commands or environment variable manipulations.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation patterns in PowerShell scripts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement additional monitoring for unusual PowerShell activity and environment variable manipulations to enhance detection of similar threats in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "b0c98cfb-0745-4513-b6f9-08dddb033490", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_5.json b/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_5.json new file mode 100644 index 00000000000..82523b7a4df --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_5.json @@ -0,0 +1,42 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions.", + "false_positives": [ + "Authorized heavy usage of the system that is business justified and monitored." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Abuse of Resources by High Token Count and Large Response Sizes", + "note": "## Triage and analysis\n\n### Investigating Potential Abuse of Resources by High Token Count and Large Response Sizes\n\nAmazon Bedrock is AWS\u2019s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.\n\nBedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.\n\n#### Possible investigation steps\n\n- Identify the user account that used high prompt token counts and whether it should perform this kind of action.\n- Investigate large response sizes and the number of requests made by the user account.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that used high prompt and large response sizes, has a business justification for the heavy usage of the system.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n - Identify potential resource exhaustion and impact on billing.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// keep token usage data\n| keep\n user.id,\n gen_ai.usage.prompt_tokens,\n gen_ai.usage.completion_tokens\n\n// Aggregate usage metrics\n| stats\n Esql.ml_usage_prompt_tokens_max = max(gen_ai.usage.prompt_tokens),\n Esql.ml_invocations_total_count = count(*),\n Esql.ml_usage_completion_tokens_avg = avg(gen_ai.usage.completion_tokens)\n by\n user.id\n\n// Filter for suspicious usage patterns\n| where\n Esql.ml_usage_prompt_tokens_max > 5000\n and Esql.ml_invocations_total_count > 10\n and Esql.ml_usage_completion_tokens_avg > 500\n\n// Calculate a custom risk factor\n| eval Esql.ml_risk_score =\n (Esql.ml_usage_prompt_tokens_max / 1000) *\n Esql.ml_invocations_total_count *\n (Esql.ml_usage_completion_tokens_avg / 500)\n\n// Filter on risk score\n| where Esql.ml_risk_score > 10\n\n// sort high risk users to top\n| sort Esql.ml_risk_score desc\n", + "references": [ + "https://atlas.mitre.org/techniques/AML.T0051", + "https://owasp.org/www-project-top-10-for-large-language-model-applications/", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "b1773d05-f349-45fb-9850-287b8f92f02d", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Use Case: Potential Overload", + "Use Case: Resource Exhaustion", + "Mitre Atlas: LLM04", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "b1773d05-f349-45fb-9850-287b8f92f02d_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_3.json new file mode 100644 index 00000000000..8c05ee76aa1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_3.json @@ -0,0 +1,60 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an AWS IAM login profile is added to a root user account and is self-assigned. Adversaries, with temporary access to the root account, may add a login profile to the root user account to maintain access even if the original access key is rotated or disabled.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM Login Profile Added for Root", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating AWS IAM Login Profile Added for Root\n\nAWS IAM allows management of user access and permissions within AWS environments. A login profile enables console access using a password. Adversaries may exploit temporary root access to create a login profile, ensuring persistent access even if keys are rotated. The detection rule identifies such actions by monitoring specific API calls and conditions, flagging unauthorized profile additions to root accounts.\n\n### Possible investigation steps\n\n- Review the @timestamp field to determine when the CreateLoginProfile action occurred and correlate it with any other suspicious activities around the same time.\n- Examine the aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id fields to identify the specific root account and access key involved in the action.\n- Investigate the source.address field to trace the IP address from which the CreateLoginProfile request originated, checking for any unusual or unauthorized locations.\n- Analyze the aws.cloudtrail.request_parameters and aws.cloudtrail.response_elements fields to understand the specifics of the login profile creation and verify if any unexpected parameters were used.\n- Check the cloud.account.id to confirm which AWS account was affected and assess if there are any other security incidents or alerts associated with this account.\n- Review the event.action field to ensure that no other unauthorized actions were performed by the root account around the same time.\n\n### False positive analysis\n\n- Administrative actions by trusted personnel may trigger the rule if they are performing legitimate maintenance or security tasks. To manage this, create exceptions for known administrative accounts by filtering their access key IDs.\n- Automated scripts or tools used for account management might inadvertently match the rule's conditions. Identify these scripts and exclude their specific access key IDs or user agents from the detection criteria.\n- Testing environments where root access is used for simulation or development purposes can cause false positives. Implement a tagging system for test environments and exclude logs with these tags from triggering the rule.\n- Third-party integrations that require root access for initial setup or configuration might be flagged. Document these integrations and adjust the rule to recognize and exclude their specific access patterns.\n\n### Response and remediation\n\n- Immediately revoke any active sessions and access keys associated with the root account to prevent further unauthorized access.\n- Reset the root account password and ensure that multi-factor authentication (MFA) is enabled for the root user to enhance security.\n- Review AWS CloudTrail logs to identify any other suspicious activities or changes made by the root account during the time of the incident.\n- Conduct a thorough audit of IAM policies and permissions to ensure that no other unauthorized changes have been made and that least privilege principles are enforced.\n- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.\n- Implement additional monitoring and alerting for root account activities to detect any future unauthorized access attempts promptly.\n- Consider engaging AWS Support or a third-party security expert if the incident's scope is beyond internal capabilities or if further forensic analysis is required.\n\n## Investigating AWS IAM Login Profile Added for Root\n\nThis rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment.\n\n### Possible Investigation Steps\n\n- **Identify the Source and Context of the Action**:\n - Examine the `source.address` field to identify the IP address from which the request originated.\n - Check the geographic location (`source.address`) to determine if the access is from an expected or unexpected region.\n - Look at the `user_agent.original` field to identify the tool or browser used for this action.\n - For example, a user agent like `Mozilla/5.0` might indicate interactive access, whereas `aws-cli` or SDKs suggest scripted activity.\n\n- **Confirm Root User and Request Details**:\n - Validate the root user's identity through `aws.cloudtrail.user_identity.arn` and ensure this activity aligns with legitimate administrative actions.\n - Review `aws.cloudtrail.user_identity.access_key_id` to identify if the action was performed using temporary or permanent credentials. This access key could be used to pivot into other actions.\n\n- **Analyze the Login Profile Creation**:\n - Review the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields for details of the created login profile.\n - For example, confirm the `userName` of the profile and whether `passwordResetRequired` is set to `true`.\n - Compare the `@timestamp` of this event with other recent actions by the root account to identify potential privilege escalation or abuse.\n\n- **Correlate with Other Events**:\n - Investigate for related IAM activities, such as:\n - `CreateAccessKey` or `AttachUserPolicy` events targeting the root account.\n - Unusual data access, privilege escalation, or management console logins.\n - Check for any anomalies involving the same `source.address` or `aws.cloudtrail.user_identity.access_key_id` in the environment.\n\n- **Evaluate Policy and Permissions**:\n - Verify the current security policies for the root account:\n - Ensure password policies enforce complexity and rotation requirements.\n - Check if MFA is enforced on the root account.\n - Assess the broader IAM configuration for deviations from least privilege principles.\n\n### False Positive Analysis\n\n- **Routine Administrative Tasks**: Adding a login profile might be a legitimate action during certain administrative processes. Verify with the relevant AWS administrators if this event aligns with routine account maintenance or emergency recovery scenarios.\n\n- **Automation**: If the action is part of an approved automation process (e.g., account recovery workflows), consider excluding these activities from alerting using specific user agents, IP addresses, or session attributes.\n\n### Response and Remediation\n\n- **Immediate Access Review**:\n - Disable the newly created login profile (`aws iam delete-login-profile`) if it is determined to be unauthorized.\n - Rotate or disable the credentials associated with the root account to prevent further abuse.\n\n- **Enhance Monitoring and Alerts**:\n - Enable real-time monitoring and alerting for IAM actions involving the root account.\n - Increase the logging verbosity for root account activities.\n\n- **Review and Update Security Policies**:\n - Enforce MFA for all administrative actions, including root account usage.\n - Restrict programmatic access to the root account by disabling access keys unless absolutely necessary.\n\n- **Conduct Post-Incident Analysis**:\n - Investigate how the credentials for the root account were compromised or misused.\n - Strengthen the security posture by implementing account-specific guardrails and continuous monitoring.\n\n### Additional Resources\n\n- AWS documentation on [Login Profile Management](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html).\n", + "query": "from logs-aws.cloudtrail* metadata _id, _version, _index\n| where\n // filter for CloudTrail logs from IAM\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"iam.amazonaws.com\"\n\n // filter for successful CreateLoginProfile API call\n and event.action == \"CreateLoginProfile\"\n and event.outcome == \"success\"\n\n // filter for Root member account\n and aws.cloudtrail.user_identity.type == \"Root\"\n\n // filter for an access key existing which sources from AssumeRoot\n and aws.cloudtrail.user_identity.access_key_id is not null\n\n // filter on the request parameters not including UserName which assumes self-assignment\n and not to_lower(aws.cloudtrail.request_parameters) like \"*username*\"\n| keep\n @timestamp,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.response_elements,\n aws.cloudtrail.user_identity.type,\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.access_key_id,\n cloud.account.id,\n event.action,\n source.address\n", + "risk_score": 73, + "rule_id": "c04be7e0-b0fc-11ef-a826-f661ea17fbce", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "c04be7e0-b0fc-11ef-a826-f661ea17fbce_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json new file mode 100644 index 00000000000..0f39962d979 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information.", + "false_positives": [ + "Service accounts or applications that frequently access Azure Key Vault for configuration or operational purposes may trigger this rule.", + "Automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or application configuration, may also lead to false positives.", + "Security teams performing routine audits or assessments that involve retrieving keys or secrets from Key Vaults may trigger this rule if they perform multiple retrievals in a short time frame." + ], + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "Excessive Secret or Key Retrieval from Azure Key Vault", + "note": "## Triage and analysis\n\n### Investigating Excessive Secret or Key Retrieval from Azure Key Vault\n\nAzure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts.\n\n### Possible investigation steps\n- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious.\n- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies.\n- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources.\n- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault.\n- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.\n- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity.\n- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents.\n- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies.\n\n### False positive analysis\n- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.\n- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n\n### Response and remediation\n- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals.\n- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault.\n- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals.\n- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts.\n- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets.\n- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments.\n", + "query": "from logs-azure.platformlogs-* metadata _id, _index\n\n// Filter for Azure Key Vault read operations\n| where event.dataset == \"azure.platformlogs\"\n and event.action in (\n \"VaultGet\",\n \"KeyGet\",\n \"KeyList\",\n \"KeyListVersions\",\n \"KeyGetDeleted\",\n \"KeyListDeleted\",\n \"SecretGet\",\n \"SecretList\",\n \"SecretListVersions\",\n \"SecretGetDeleted\",\n \"SecretListDeleted\",\n \"CertificateGet\",\n \"CertificateList\",\n \"CertificateListVersions\",\n \"CertificateGetDeleted\",\n \"CertificateListDeleted\",\n \"CertificatePolicyGet\",\n \"CertificateContactsGet\",\n \"CertificateIssuerGet\",\n \"CertificateIssuersList\"\n )\n\n// Truncate timestamps into 1-minute windows\n| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp)\n\n// Aggregate identity, geo, resource, and activity info\n| stats\n Esql_priv.azure_platformlogs_identity_claim_upn_values = values(azure.platformlogs.identity.claim.upn),\n Esql.azure_platformlogs_identity_claim_upn_count_distinct = count_distinct(azure.platformlogs.identity.claim.upn),\n Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid),\n Esql.azure_platformlogs_identity_claim_objectid_values = values(azure.platformlogs.identity.claim.objectid),\n\n Esql.source_ip_values = values(source.ip),\n Esql.geo_city_values = values(geo.city_name),\n Esql.geo_region_values = values(geo.region_name),\n Esql.geo_country_values = values(geo.country_name),\n Esql.source_as_organization_name_values = values(source.as.organization.name),\n\n Esql.event_action_values = values(event.action),\n Esql.event_count = count(*),\n Esql.event_action_count_distinct = count_distinct(event.action),\n Esql.azure_resource_name_count_distinct = count_distinct(azure.resource.name),\n Esql.azure_resource_name_values = values(azure.resource.name),\n Esql.azure_platformlogs_result_type_values = values(azure.platformlogs.result_type),\n Esql.cloud_region_values = values(cloud.region),\n\n Esql.agent_name_values = values(agent.name),\n Esql.azure_subscription_id_values = values(azure.subscription_id),\n Esql.azure_resource_group_values = values(azure.resource.group),\n Esql.azure_resource_id_values = values(azure.resource.id)\n\nby Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn\n\n// keep relevant fields\n| keep\n Esql.time_window_date_trunc,\n Esql_priv.azure_platformlogs_identity_claim_upn_values,\n Esql.azure_platformlogs_identity_claim_upn_count_distinct,\n Esql.azure_platformlogs_identity_claim_appid_values,\n Esql.azure_platformlogs_identity_claim_objectid_values,\n Esql.source_ip_values,\n Esql.geo_city_values,\n Esql.geo_region_values,\n Esql.geo_country_values,\n Esql.source_as_organization_name_values,\n Esql.event_action_values,\n Esql.event_count,\n Esql.event_action_count_distinct,\n Esql.azure_resource_name_count_distinct,\n Esql.azure_resource_name_values,\n Esql.azure_platformlogs_result_type_values,\n Esql.cloud_region_values,\n Esql.agent_name_values,\n Esql.azure_subscription_id_values,\n Esql.azure_resource_group_values,\n Esql.azure_resource_id_values\n\n// Filter for suspiciously high volume of distinct Key Vault reads by a single actor\n| where Esql.azure_platformlogs_identity_claim_upn_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_action_count_distinct >= 2\n\n| sort Esql.time_window_date_trunc desc\n", + "references": [ + "https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html" + ], + "risk_score": 43, + "rule_id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd", + "setup": "#### Required Azure Key Vault Diagnostic Logs\n\nTo ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:\n- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Storage", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Azure Platform Logs", + "Data Source: Azure Key Vault", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1555", + "name": "Credentials from Password Stores", + "reference": "https://attack.mitre.org/techniques/T1555/", + "subtechnique": [ + { + "id": "T1555.006", + "name": "Cloud Secrets Management Stores", + "reference": "https://attack.mitre.org/techniques/T1555/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_5.json b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_5.json new file mode 100644 index 00000000000..98771df7111 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_5.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Base64 Encoding/Decoding Activity", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Base64 Encoding/Decoding Activity\nBase64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.\n\n### Possible investigation steps\n\n- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.\n- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.\n- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.\n- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.\n- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.\n- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.\n- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.\n\n### False positive analysis\n\n- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.\n- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.\n- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.\n- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.\n- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.\n\n### Response and remediation\n\n- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.\n- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.\n- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.\n- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.\n- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.\n- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.\n", + "query": "from logs-endpoint.events.process-*\n| where\n @timestamp > now() - 1h and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and (\n (\n process.name in (\"base64\", \"base64plain\", \"base64url\", \"base64mime\", \"base64pem\", \"base32\", \"base16\") and\n process.command_line like \"*-*d*\"\n ) or\n (\n process.name == \"openssl\" and\n process.args == \"enc\" and\n process.args in (\"-d\", \"-base64\", \"-a\")\n ) or\n (\n process.name like \"python*\" and (\n (\n process.args == \"base64\" and\n process.args in (\"-d\", \"-u\", \"-t\")\n ) or\n (\n process.args == \"-c\" and\n process.command_line like \"*base64*\" and\n process.command_line like \"*b64decode*\"\n )\n )\n ) or\n (\n process.name like \"perl*\" and\n process.command_line like \"*decode_base64*\"\n ) or\n (\n process.name like \"ruby*\" and\n process.args == \"-e\" and\n process.command_line like \"*Base64.decode64*\"\n )\n )\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.name,\n process.args,\n process.command_line,\n agent.id,\n host.name\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.name, process.command_line\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 15\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "risk_score": 21, + "rule_id": "c5637438-e32d-4bb3-bc13-bd7932b3289f", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + }, + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "c5637438-e32d-4bb3-bc13-bd7932b3289f_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_2.json b/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_2.json deleted file mode 100644 index 0f89f9944a9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_2.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-30m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source", - "note": "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.", - "query": "from logs-azure.signinlogs*\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and to_lower(azure.signinlogs.properties.resource_display_name) rlike \"(.*)365(.*)\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome != \"success\"\n\n // For tuning, review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// keep only relevant fields\n| keep event.dataset, event.category, azure.signinlogs.properties.resource_display_name, azure.signinlogs.category, event.outcome, azure.signinlogs.properties.user_principal_name, source.ip\n\n// Count the number of unique targets per source IP\n| stats\n target_count = count_distinct(azure.signinlogs.properties.user_principal_name) by source.ip\n\n// Filter for at least 10 distinct failed login attempts from a single source\n| where target_count >= 10\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" - ], - "risk_score": 47, - "rule_id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_3.json b/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_3.json deleted file mode 100644 index 187ebaa4bcc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_3.json +++ /dev/null @@ -1,58 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-30m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source\n\nAzure Entra ID, integral to Microsoft 365, manages identity and access, ensuring secure authentication. Adversaries exploit this by attempting numerous failed logins to breach accounts. The detection rule identifies such brute-force attempts by monitoring failed logins from a single IP within a short timeframe, flagging potential unauthorized access efforts.\n\n### Possible investigation steps\n\n- Review the source IP address identified in the alert to determine if it is associated with known malicious activity or if it belongs to a legitimate user or organization.\n- Examine the list of user principal names targeted by the failed login attempts to identify any patterns or specific users that may be at higher risk.\n- Check the azure.signinlogs.properties.resource_display_name to understand which Microsoft 365 services were targeted, such as Exchange, SharePoint, or Teams, and assess the potential impact on those services.\n- Investigate the error codes in azure.signinlogs.properties.status.error_code for additional context on why the login attempts failed, which may provide insights into the attacker's methods.\n- Correlate the failed login attempts with any successful logins from the same source IP or user accounts to identify potential unauthorized access.\n- Assess the risk and exposure of the affected user accounts and consider implementing additional security measures, such as multi-factor authentication, if not already in place.\n\n### False positive analysis\n\n- High volume of legitimate login attempts from a single IP, such as a corporate proxy or VPN, can trigger false positives. To mitigate, exclude known IP addresses of trusted network infrastructure from the rule.\n- Automated scripts or applications performing frequent login operations on behalf of users may be misidentified as brute force attempts. Identify and whitelist these applications by their source IPs or user agents.\n- Shared workstations or kiosks where multiple users log in from the same IP address can result in false positives. Implement user-based exclusions for these environments to prevent unnecessary alerts.\n- Frequent password resets or account recovery processes can generate multiple failed login attempts. Monitor and exclude these activities by correlating with password reset logs or helpdesk tickets.\n- Training or testing environments where multiple failed logins are expected should be excluded by identifying and filtering out the associated IP ranges or user accounts.\n\n### Response and remediation\n\n- Immediately block the source IP address identified in the alert to prevent further unauthorized access attempts.\n- Reset passwords for all affected user accounts that experienced failed login attempts from the flagged IP address to ensure account security.\n- Enable multi-factor authentication (MFA) for the affected accounts if not already in place, to add an additional layer of security against unauthorized access.\n- Review and update conditional access policies to restrict access from suspicious or untrusted locations, enhancing security posture.\n- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.\n- Monitor the affected accounts and source IP for any additional suspicious activity, ensuring no further attempts are made.\n- Document the incident details, including the source IP, affected accounts, and actions taken, for future reference and compliance purposes.\n\nThis rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.", - "query": "from logs-azure.signinlogs*\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and to_lower(azure.signinlogs.properties.resource_display_name) rlike \"(.*)365(.*)\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome != \"success\"\n\n // For tuning, review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// keep only relevant fields\n| keep event.dataset, event.category, azure.signinlogs.properties.resource_display_name, azure.signinlogs.category, event.outcome, azure.signinlogs.properties.user_principal_name, source.ip\n\n// Count the number of unique targets per source IP\n| stats\n target_count = count_distinct(azure.signinlogs.properties.user_principal_name) by source.ip\n\n// Filter for at least 10 distinct failed login attempts from a single source\n| where target_count >= 10\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" - ], - "risk_score": 47, - "rule_id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_4.json b/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_4.json deleted file mode 100644 index 2feca777219..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c6655282-6c79-11ef-bbb5-f661ea17fbcc_4.json +++ /dev/null @@ -1,58 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-30m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Deprecated - Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Deprecated - Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source\n\nAzure Entra ID, integral to Microsoft 365, manages identity and access, ensuring secure authentication. Adversaries exploit this by attempting numerous failed logins to breach accounts. The detection rule identifies such brute-force attempts by monitoring failed logins from a single IP within a short timeframe, flagging potential unauthorized access efforts.\n\n### Possible investigation steps\n\n- Review the source IP address identified in the alert to determine if it is associated with known malicious activity or if it belongs to a legitimate user or organization.\n- Examine the list of user principal names targeted by the failed login attempts to identify any patterns or specific users that may be at higher risk.\n- Check the azure.signinlogs.properties.resource_display_name to understand which Microsoft 365 services were targeted, such as Exchange, SharePoint, or Teams, and assess the potential impact on those services.\n- Investigate the error codes in azure.signinlogs.properties.status.error_code for additional context on why the login attempts failed, which may provide insights into the attacker's methods.\n- Correlate the failed login attempts with any successful logins from the same source IP or user accounts to identify potential unauthorized access.\n- Assess the risk and exposure of the affected user accounts and consider implementing additional security measures, such as multi-factor authentication, if not already in place.\n\n### False positive analysis\n\n- High volume of legitimate login attempts from a single IP, such as a corporate proxy or VPN, can trigger false positives. To mitigate, exclude known IP addresses of trusted network infrastructure from the rule.\n- Automated scripts or applications performing frequent login operations on behalf of users may be misidentified as brute force attempts. Identify and whitelist these applications by their source IPs or user agents.\n- Shared workstations or kiosks where multiple users log in from the same IP address can result in false positives. Implement user-based exclusions for these environments to prevent unnecessary alerts.\n- Frequent password resets or account recovery processes can generate multiple failed login attempts. Monitor and exclude these activities by correlating with password reset logs or helpdesk tickets.\n- Training or testing environments where multiple failed logins are expected should be excluded by identifying and filtering out the associated IP ranges or user accounts.\n\n### Response and remediation\n\n- Immediately block the source IP address identified in the alert to prevent further unauthorized access attempts.\n- Reset passwords for all affected user accounts that experienced failed login attempts from the flagged IP address to ensure account security.\n- Enable multi-factor authentication (MFA) for the affected accounts if not already in place, to add an additional layer of security against unauthorized access.\n- Review and update conditional access policies to restrict access from suspicious or untrusted locations, enhancing security posture.\n- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.\n- Monitor the affected accounts and source IP for any additional suspicious activity, ensuring no further attempts are made.\n- Document the incident details, including the source IP, affected accounts, and actions taken, for future reference and compliance purposes.\n\nThis rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.", - "query": "from logs-azure.signinlogs*\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and to_lower(azure.signinlogs.properties.resource_display_name) rlike \"(.*)365(.*)\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome != \"success\"\n\n // For tuning, review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// keep only relevant fields\n| keep event.dataset, event.category, azure.signinlogs.properties.resource_display_name, azure.signinlogs.category, event.outcome, azure.signinlogs.properties.user_principal_name, source.ip\n\n// Count the number of unique targets per source IP\n| stats\n target_count = count_distinct(azure.signinlogs.properties.user_principal_name) by source.ip\n\n// Filter for at least 10 distinct failed login attempts from a single source\n| where target_count >= 10\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" - ], - "risk_score": 47, - "rule_id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "c6655282-6c79-11ef-bbb5-f661ea17fbcc_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_307.json b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_307.json new file mode 100644 index 00000000000..a403b779a5e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_307.json @@ -0,0 +1,56 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Device Token Hashes for Single Okta Session", + "note": "## Triage and analysis\n\n### Investigating Multiple Device Token Hashes for Single Okta Session\n\nThis rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - Authentication events have been filtered out to focus on Okta activity via established sessions.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.\n - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.\n\n### Response and remediation:\n- Consider stopping all sessions for the user(s) involved in this action.\n- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n not event.action in (\n \"policy.evaluate_sign_on\",\n \"user.session.start\",\n \"user.authentication.sso\"\n ) and\n okta.actor.alternate_id != \"system@okta.com\" and\n okta.actor.alternate_id rlike \"[^@\\s]+\\@[^@\\s]+\" and\n okta.authentication_context.external_session_id != \"unknown\"\n| keep\n event.action,\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id,\n okta.debug_context.debug_data.dt_hash\n| stats\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)\n by\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id\n| where\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 2\n| sort\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "risk_score": 47, + "rule_id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd", + "setup": "## Setup\n\nThe Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Domain: SaaS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1539", + "name": "Steal Web Session Cookie", + "reference": "https://attack.mitre.org/techniques/T1539/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 307 + }, + "id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd_307", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_4.json new file mode 100644 index 00000000000..6bf5eb9fa69 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_4.json @@ -0,0 +1,82 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Sign-In Brute Force Activity", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Sign-In Brute Force Activity\n\nThis rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response.\n\n### Possible investigation steps\n\n- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`).\n- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted.\n- Review `login_errors`: Repetitive error types like `\"Invalid Grant\"` or `\"User Not Found\"` suggest automated attacks.\n- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.).\n- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks.\n- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation.\n- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools.\n- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms.\n- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts.\n- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly.\n\n### False positive analysis\n\n- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures.\n- Internal red team activity or penetration tests may mimic brute-force behaviors.\n- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured.\n\n### Response and remediation\n\n- Notify your identity security team for further analysis.\n- Investigate and lock or reset impacted accounts if compromise is suspected.\n- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access.\n- Confirm MFA and Conditional Access are enforced for all user types.\n- Audit targeted accounts for credential reuse across services.\n- Implement account lockout or throttling for failed sign-in attempts where possible.\n", + "query": "from logs-azure.signinlogs*\n\n// Define a time window for grouping and maintain the original event timestamp\n| eval Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp)\n\n// Filter relevant failed authentication events with specific error codes\n| where event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome == \"failure\"\n and azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n and azure.signinlogs.properties.status.error_code in (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n and azure.signinlogs.properties.user_principal_name is not null and azure.signinlogs.properties.user_principal_name != \"\"\n and user_agent.original != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n\n| stats\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature),\n Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type),\n\n Esql.azure_signinlogs_properties_user_id_count_distinct = count_distinct(azure.signinlogs.properties.user_id),\n Esql.azure_signinlogs_properties_user_id_list = values(azure.signinlogs.properties.user_id),\n Esql.azure_signinlogs_result_description_values_all = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_incoming_token_type_values_all = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_app_display_name_values_all = values(azure.signinlogs.properties.app_display_name),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.timestamp_first_seen = min(@timestamp),\n Esql.timestamp_last_seen = max(@timestamp),\n Esql.event_count = count()\nby Esql.time_window_date_trunc\n\n| eval\n Esql.duration_seconds = date_diff(\"seconds\", Esql.timestamp_first_seen, Esql.timestamp_last_seen),\n Esql.brute_force_type = case(\n Esql.azure_signinlogs_properties_user_id_count_distinct >= 10 and Esql.event_count >= 30 and Esql.azure_signinlogs_result_description_count_distinct <= 3\n and Esql.source_ip_count_distinct >= 5\n and Esql.duration_seconds <= 600\n and Esql.azure_signinlogs_properties_user_id_count_distinct > Esql.source_ip_count_distinct,\n \"credential_stuffing\",\n\n Esql.azure_signinlogs_properties_user_id_count_distinct >= 15 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 15 and Esql.duration_seconds <= 1800,\n \"password_spraying\",\n\n (Esql.azure_signinlogs_properties_user_id_count_distinct == 1 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 30 and Esql.duration_seconds <= 300)\n or (Esql.azure_signinlogs_properties_user_id_count_distinct <= 3 and Esql.source_ip_count_distinct > 30 and Esql.event_count >= 100),\n \"password_guessing\",\n\n \"other\"\n )\n\n| keep\n Esql.time_window_date_trunc,\n Esql.brute_force_type,\n Esql.duration_seconds,\n Esql.event_count,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.azure_signinlogs_properties_user_id_count_distinct,\n Esql.azure_signinlogs_properties_user_id_list,\n Esql.azure_signinlogs_result_description_values_all,\n Esql.azure_signinlogs_result_description_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values_all,\n Esql.azure_signinlogs_properties_app_display_name_values_all,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.source_as_organization_name_count_distinct,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_device_id_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_user_id_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_result_signature_values,\n Esql.azure_signinlogs_result_type_values\n\n| where Esql.brute_force_type != \"other\"\n", + "references": [ + "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign", + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/", + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "cca64114-fb8b-11ef-86e2-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "cca64114-fb8b-11ef-86e2-f661ea17fbce_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_3.json b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_3.json new file mode 100644 index 00000000000..3fb05ff724a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like backtick-escaped variable expansion to evade detection. This method involves disguising malicious scripts to bypass security measures. The detection rule identifies scripts with excessive length and specific obfuscation patterns, flagging potential threats for further analysis.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content of the script and identify any suspicious or malicious commands.\n- Examine the `file.path` and `file.name` fields to determine the origin and context of the script execution, which may provide insights into whether the script is part of a legitimate process or potentially malicious activity.\n- Check the `host.name` and `agent.id` fields to identify the affected system and correlate with other security events or logs from the same host for additional context.\n- Analyze the `user.id` field to determine which user account executed the script, and assess whether this activity aligns with the user's typical behavior or role.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution flow of the script and identify any related script blocks that may have been executed in sequence.\n- Consider the `count` field to evaluate the extent of obfuscation used in the script, which may indicate the level of sophistication or intent behind the script.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use backtick-escaped variable expansion for complex string manipulations. Review the script's context and purpose to determine if it aligns with expected administrative tasks.\n- Automated scripts generated by trusted software might include obfuscation patterns as part of their normal operation. Verify the source and integrity of the software to ensure it is from a reputable vendor.\n- Developers and IT professionals may use obfuscation techniques during testing or development phases. Establish a process to whitelist known development environments or user accounts to reduce unnecessary alerts.\n- PowerShell scripts that are part of legitimate security tools or monitoring solutions may trigger the rule. Identify and exclude these tools by their file path or script block ID to prevent false positives.\n- Regularly update the list of known false positives based on historical data and feedback from users to refine the detection rule and improve its accuracy.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of the potentially malicious script across the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated scripts.\n- Conduct a thorough review of the script block text and associated file paths to identify and remove any malicious scripts or files from the system.\n- Reset credentials for any user accounts involved in the alert to mitigate the risk of compromised credentials being used for further attacks.\n- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or additional compromised systems.\n- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of obfuscation techniques or related suspicious activities.\n- Update endpoint protection and intrusion detection systems with indicators of compromise (IOCs) derived from the analysis to improve detection capabilities for similar threats in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\$\\{(\\w++`){2,}\\w++\\}\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.name,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "d43f2b43-02a1-4219-8ce9-10929a32a618", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "d43f2b43-02a1-4219-8ce9-10929a32a618_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_6.json b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_6.json new file mode 100644 index 00000000000..85ced1ee1a3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_6.json @@ -0,0 +1,86 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target role." + ], + "from": "now-6m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM AdministratorAccess Policy Attached to Role", + "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Role\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachRolePolicy` permission, a set of compromised credentials could be used to attach\nthis policy to a compromised role for privilege escalation or as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachRolePolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachRolePolicy` permission and that the `role.name` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected role(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n| where\n event.provider == \"iam.amazonaws.com\"\n and event.action == \"AttachRolePolicy\"\n and event.outcome == \"success\"\n\n// Extract policy name and role name from request parameters\n| dissect aws.cloudtrail.request_parameters\n \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{Esql.aws_cloudtrail_request_parameters_policy_name},%{?roleName}=%{Esql.aws_cloudtrail_request_parameters_role_name}}\"\n\n// Filter for AdministratorAccess policy attachment\n| where Esql.aws_cloudtrail_request_parameters_policy_name == \"AdministratorAccess\"\n\n// keep relevant ECS and dynamic fields\n| keep\n @timestamp,\n event.provider,\n event.action,\n event.outcome,\n Esql.aws_cloudtrail_request_parameters_policy_name,\n Esql.aws_cloudtrail_request_parameters_role_name\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" + ], + "risk_score": 47, + "rule_id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_3.json b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_3.json new file mode 100644 index 00000000000..9849dc8420c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_3.json @@ -0,0 +1,56 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Microsoft 365 User Account Lockouts in Short Time Window", + "note": "## Triage and Analysis\n\n### Investigating Multiple Microsoft 365 User Account Lockouts in Short Time Window\n\nDetects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context.\n\n### Investigation Steps\n\n- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)?\n- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers.\n- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation.\n- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly?\n- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs.\n- Correlate with any recent detection of password spraying or credential stuffing activity.\n- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.).\n- Check for any successful logins from the same IP or ASN after the lockouts.\n\n### False Positive Analysis\n\n- Automated systems with stale credentials may cause repeated failed logins.\n- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts.\n- Red team exercises or penetration tests may resemble the same lockout pattern.\n- Some organizations may have a high volume of lockouts due to user behavior or legacy systems.\n\n### Response Recommendations\n\n- Notify affected users and confirm whether activity was expected or suspicious.\n- Lock or reset credentials for impacted accounts.\n- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.\n- Strengthen lockout and retry delay policies if necessary.\n- Review the originating application(s) involved via `request_types`.\n", + "query": "from logs-o365.audit-*\n| mv_expand event.category\n| eval\n Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)\n| where\n event.dataset == \"o365.audit\" and\n event.category == \"authentication\" and\n event.provider in (\"AzureActiveDirectory\", \"Exchange\") and\n event.action in (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\") and\n to_lower(o365.audit.ExtendedProperties.RequestType) rlike \"(oauth.*||.*login.*)\" and\n o365.audit.LogonError == \"IdsLocked\" and\n to_lower(o365.audit.UserId) != \"not available\" and\n o365.audit.Target.Type in (\"0\", \"2\", \"6\", \"10\") and\n source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n| stats\n Esql_priv.o365_audit_UserId_count_distinct = count_distinct(to_lower(o365.audit.UserId)),\n Esql_priv.o365_audit_UserId_values = values(to_lower(o365.audit.UserId)),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.o365_audit_ExtendedProperties_RequestType_values = values(to_lower(o365.audit.ExtendedProperties.RequestType)),\n Esql.timestamp_first_seen = min(@timestamp),\n Esql.timestamp_last_seen = max(@timestamp),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc\n| eval\n Esql.event_duration_seconds = date_diff(\"seconds\", Esql.timestamp_first_seen, Esql.timestamp_last_seen)\n| keep\n Esql.time_window_date_trunc,\n Esql_priv.o365_audit_UserId_count_distinct,\n Esql_priv.o365_audit_UserId_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_as_organization_name_count_distinct,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.o365_audit_ExtendedProperties_RequestType_values,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.event_count,\n Esql.event_duration_seconds\n| where\n Esql_priv.o365_audit_UserId_count_distinct >= 10 and\n Esql.event_count >= 10 and\n Esql.event_duration_seconds <= 300\n", + "references": [ + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "risk_score": 47, + "rule_id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_6.json b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_6.json new file mode 100644 index 00000000000..c7660f2e4ab --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_6.json @@ -0,0 +1,86 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user group." + ], + "from": "now-6m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM AdministratorAccess Policy Attached to Group", + "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Group\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected group(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n| where\n event.provider == \"iam.amazonaws.com\"\n and event.action == \"AttachGroupPolicy\"\n and event.outcome == \"success\"\n\n// Extract policy and group details from request parameters\n| dissect aws.cloudtrail.request_parameters\n \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{Esql.aws_cloudtrail_request_parameters_policy_name},%{?groupName}=%{Esql.aws_cloudtrail_request_parameters_group_name}}\"\n\n// Filter for attachment of AdministratorAccess policy\n| where Esql.aws_cloudtrail_request_parameters_policy_name == \"AdministratorAccess\"\n\n// keep ECS and derived fields\n| keep\n @timestamp,\n event.provider,\n event.action,\n event.outcome,\n Esql.aws_cloudtrail_request_parameters_policy_name,\n Esql.aws_cloudtrail_request_parameters_group_name\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" + ], + "risk_score": 47, + "rule_id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_2.json b/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_2.json new file mode 100644 index 00000000000..4960bbbf652 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_2.json @@ -0,0 +1,60 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources.", + "false_positives": [ + "Users authenticating from multiple devices and using the deviceCode protocol or the Visual Studio Code client." + ], + "from": "now-60m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties\n\n### Possible investigation steps\n\n- Review the sign-in logs to assess the context and reputation of the source.ip address.\n- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.\n- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise.\n- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.\n- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.\n\n### Response and remediation\n\n- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions.\n- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.\n- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.\n- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.\n- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.\n- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.\n- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event.", + "query": "from logs-azure.signinlogs* metadata _id, _version, _index\n\n// Scheduled to run every hour, reviewing events from past hour\n| where\n @timestamp > now() - 1 hours\n and event.dataset == \"azure.signinlogs\"\n and source.ip is not null\n and azure.signinlogs.identity is not null\n and to_lower(event.outcome) == \"success\"\n\n// keep relevant raw fields\n| keep\n @timestamp,\n azure.signinlogs.identity,\n source.ip,\n azure.signinlogs.properties.authentication_requirement,\n azure.signinlogs.properties.app_id,\n azure.signinlogs.properties.resource_display_name,\n azure.signinlogs.properties.authentication_protocol,\n azure.signinlogs.properties.app_display_name\n\n// case classifications for identity usage\n| eval\n Esql.azure_signinlogs_properties_authentication_device_code_case = case(\n azure.signinlogs.properties.authentication_protocol == \"deviceCode\"\n and azure.signinlogs.properties.authentication_requirement != \"multiFactorAuthentication\",\n azure.signinlogs.identity,\n null),\n\n Esql.azure_signinlogs_auth_visual_studio_case = case(\n azure.signinlogs.properties.app_id == \"aebc6443-996d-45c2-90f0-388ff96faa56\"\n and azure.signinlogs.properties.resource_display_name == \"Microsoft Graph\",\n azure.signinlogs.identity,\n null),\n\n Esql.azure_signinlogs_auth_other_case = case(\n azure.signinlogs.properties.authentication_protocol != \"deviceCode\"\n and azure.signinlogs.properties.app_id != \"aebc6443-996d-45c2-90f0-388ff96faa56\",\n azure.signinlogs.identity,\n null)\n\n// Aggregate metrics by user identity\n| stats\n Esql.event_count = count(*),\n Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct = count_distinct(Esql.azure_signinlogs_properties_authentication_device_code_case),\n Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct = count_distinct(Esql.azure_signinlogs_auth_visual_studio_case),\n Esql.azure_signinlogs_properties_auth_other_count_distinct = count_distinct(Esql.azure_signinlogs_auth_other_case),\n Esql.azure_signinlogs_properties_source_ip_count_distinct = count_distinct(source.ip),\n Esql.azure_signinlogs_properties_source_ip_values = values(source.ip),\n Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement)\n by azure.signinlogs.identity\n\n// Detect multiple unique IPs for one user with signs of deviceCode or VSC OAuth usage\n| where\n Esql.azure_signinlogs_properties_source_ip_count_distinct >= 2\n and (\n Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct > 0\n or Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct > 0\n )\n", + "references": [ + "https://learn.microsoft.com/en-us/entra/identity/", + "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins", + "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/" + ], + "risk_score": 73, + "rule_id": "e3bd85e9-7aff-46eb-b60e-20dfc9020d98", + "setup": "#### Required Azure Entra Sign-In Logs\nThis rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "e3bd85e9-7aff-46eb-b60e-20dfc9020d98_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_5.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_5.json new file mode 100644 index 00000000000..f3339a3d799 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_5.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Reordering", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via String Reordering\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.\n\n### Possible investigation steps\n\n- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.\n- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.\n- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.\n- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.\n\n### False positive analysis\n\n- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name \"framework_cache.psm1\" is excluded from the detection rule.\n- PowerShell scripts that include specific sentinel patterns, such as \"sentinelbreakpoints\" or paths like \":::::\\windows\\sentinel\", combined with variables like \"$local:Bypassed\" or \"origPSExecutionPolicyPreference\", are known to be benign. These should be excluded to reduce noise.\n- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.\n- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.\n- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*{0}*\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.name,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least four times\n| where Esql.script_block_pattern_count >= 4\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| where (file.name not like \"framework_cache.psm1\" or file.name is null)\n\n| where not\n // https://wtfbins.wtf/17\n (\n (powershell.file.script_block_text like \"*sentinelbreakpoints*\" or\n powershell.file.script_block_text like \"*:::::\\\\\\\\windows\\\\\\\\sentinel*\")\n and\n (powershell.file.script_block_text like \"*$local:Bypassed*\" or\n powershell.file.script_block_text like \"*origPSExecutionPolicyPreference*\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_3.json b/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_3.json new file mode 100644 index 00000000000..3e1f8e96475 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_3.json @@ -0,0 +1,42 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system.", + "false_positives": [ + "Users testing new model deployments or updated compliance policies without Amazon Bedrock guardrails." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session\n\nUsing Amazon Bedrock Guardrails during model invocation is critical for ensuring the safe, reliable, and ethical use of AI models.\nGuardrails help manage risks associated with AI usage and ensure the output aligns with desired policies and standards.\n\n#### Possible investigation steps\n\n- Identify the user account that caused multiple model violations over a session without desired guardrail configuration and whether it should perform this kind of action.\n- Investigate the user activity that might indicate a potential brute force attack.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Create 1-minute time buckets\n| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp)\n\n// Filter for invocations without guardrails\n| where gen_ai.guardrail_id is null and user.id is not null\n\n// keep only relevant fields\n| keep\n @timestamp,\n Esql.time_window_date_trunc,\n gen_ai.guardrail_id,\n user.id\n\n// count number of unsafe invocations per user\n| stats\n Esql.ml_invocations_no_guardrails_count = count()\n by user.id\n\n// Filter for suspicious volume\n| where Esql.ml_invocations_no_guardrails_count > 5\n\n// sort descending\n| sort Esql.ml_invocations_no_guardrails_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 47, + "rule_id": "f2c653b7-7daf-4774-86f2-34cdbd1fc528", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "f2c653b7-7daf-4774-86f2-34cdbd1fc528_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_8.json b/packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_8.json deleted file mode 100644 index 08c1ac2e9ac..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f33e68a4-bd19-11ed-b02f-f661ea17fbcc_8.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a user copies a Google spreadsheet, form, document or script from an external drive. Sequence logic has been added to also detect when a user grants a custom Google application permission via OAuth shortly after. An adversary may send a phishing email to the victim with a Drive object link where \"copy\" is included in the URI, thus copying the object to the victim's drive. If a container-bound script exists within the object, execution will require permission access via OAuth in which the user has to accept.", - "false_positives": [ - "Google Workspace users typically share Drive resources with a shareable link where parameters are edited to indicate when it is viewable or editable by the intended recipient. It is uncommon for a user in an organization to manually copy a Drive object from an external drive to their corporate drive. This may happen where users find a useful spreadsheet in a public drive, for example, and replicate it to their Drive. It is uncommon for the copied object to execute a container-bound script either unless the user was intentionally aware, suggesting the object uses container-bound scripts to accomplish a legitimate task." - ], - "from": "now-9m", - "index": [ - "filebeat-*", - "logs-google_workspace*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Google Workspace Object Copied to External Drive with App Consent", - "note": "## Triage and analysis\n\n### Investigating Google Workspace Object Copied to External Drive with App Consent\n\nGoogle Workspace users can share access to Drive objects such as documents, sheets, and forms via email delivery or a shared link. Shared link URIs have parameters like `view` or `edit` to indicate the recipient's permissions. The `copy` parameter allows the recipient to copy the object to their own Drive, which grants the object with the same privileges as the recipient. Specific objects in Google Drive allow container-bound scripts that run on Google's Apps Script platform. Container-bound scripts can contain malicious code that executes with the recipient's privileges if in their Drive.\n\nThis rule aims to detect when a user copies an external Drive object to their Drive storage and then grants permissions to a custom application via OAuth prompt.\n\n#### Possible investigation steps\n- Identify user account(s) associated by reviewing `user.name` or `source.user.email` in the alert.\n- Identify the name of the file copied by reviewing `file.name` as well as the `file.id` for triaging.\n- Identify the file type by reviewing `google_workspace.drive.file.type`.\n- With the information gathered so far, query across data for the file metadata to determine if this activity is isolated or widespread.\n- Within the OAuth token event, identify the application name by reviewing `google_workspace.token.app_name`.\n - Review the application ID as well from `google_workspace.token.client.id`.\n - This metadata can be used to report the malicious application to Google for permanent blacklisting.\n- Identify the permissions granted to the application by the user by reviewing `google_workspace.token.scope.data.scope_name`.\n - This information will help pivot and triage into what services may have been affected.\n- If a container-bound script was attached to the copied object, it will also exist in the user's drive.\n - This object should be removed from all users affected and investigated for a better understanding of the malicious code.\n\n### False positive analysis\n- Communicate with the affected user to identify if these actions were intentional\n- If a container-bound script exists, review code to identify if it is benign or malicious\n\n### Response and remediation\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n - Resetting passwords will revoke OAuth tokens which could have been stolen.\n- Reactivate multi-factor authentication for the user.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security defaults [provided by Google](https://cloud.google.com/security-command-center/docs/how-to-investigate-threats).\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n\n\n### Important Information Regarding Google Workspace Event Lag Times\n- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.\n- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.\n- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).\n- See the following references for further information:\n - https://support.google.com/a/answer/7061566\n - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html", - "query": "sequence by source.user.email with maxspan=3m\n[file where event.dataset == \"google_workspace.drive\" and event.action == \"copy\" and\n\n /* Should only match if the object lives in a Drive that is external to the user's GWS organization */\n google_workspace.drive.owner_is_team_drive == \"false\" and google_workspace.drive.copy_type == \"external\" and\n\n /* Google Script, Forms, Sheets and Document can have container-bound scripts */\n google_workspace.drive.file.type: (\"script\", \"form\", \"spreadsheet\", \"document\")]\n\n[any where event.dataset == \"google_workspace.token\" and event.action == \"authorize\" and\n\n /* Ensures application ID references custom app in Google Workspace and not GCP */\n google_workspace.token.client.id : \"*apps.googleusercontent.com\"]\n", - "references": [ - "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one", - "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two", - "https://developers.google.com/apps-script/guides/bound", - "https://support.google.com/a/users/answer/13004165#share_make_a_copy_links" - ], - "related_integrations": [ - { - "package": "google_workspace", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "google_workspace.drive.copy_type", - "type": "unknown" - }, - { - "ecs": false, - "name": "google_workspace.drive.file.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "google_workspace.drive.owner_is_team_drive", - "type": "boolean" - }, - { - "ecs": false, - "name": "google_workspace.token.client.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "source.user.email", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "f33e68a4-bd19-11ed-b02f-f661ea17fbcc", - "setup": "The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Google Workspace", - "Tactic: Initial Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1566", - "name": "Phishing", - "reference": "https://attack.mitre.org/techniques/T1566/", - "subtechnique": [ - { - "id": "T1566.002", - "name": "Spearphishing Link", - "reference": "https://attack.mitre.org/techniques/T1566/002/" - } - ] - } - ] - } - ], - "type": "eql", - "version": 8 - }, - "id": "f33e68a4-bd19-11ed-b02f-f661ea17fbcc_8", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_3.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_3.json new file mode 100644 index 00000000000..37bcc7049b2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_3.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Reverse Keywords", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Reverse Keywords\n\nPowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic.\n- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious.\n- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution.\n- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine.\n- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.\n- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.\n- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.\n- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.\n- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.\n- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.\n- Restore affected systems from a known good backup if malicious activity has altered system integrity.\n- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contains these keywords using MATCH, boosts the query performance,\n// match will ignore the | and look for the individual words\n| where powershell.file.script_block_text : \"rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n agent.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f38633f4-3b31-4c80-b13d-e77c70ce8254", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_5.json b/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_5.json new file mode 100644 index 00000000000..5a3067c9220 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_5.json @@ -0,0 +1,42 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.", + "false_positives": [ + "Legitimate misunderstanding by users or overly strict policies" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account and the user request that caused multiple policy violations and whether it should perform this kind of action.\n- Investigate the user activity that might indicate a potential brute force attack.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that caused multiple policy violations, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Filter for policy-blocked requests\n| where gen_ai.policy.action == \"BLOCKED\"\n\n// count number of policy matches per request (multi-valued)\n| eval Esql.ml_policy_violations_mv_count = mv_count(gen_ai.policy.name)\n\n// Filter for requests with more than one policy match\n| where Esql.ml_policy_violations_mv_count > 1\n\n// keep relevant fields\n| keep\n gen_ai.policy.action,\n Esql.ml_policy_violations_mv_count,\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// Aggregate requests with multiple violations\n| stats\n Esql.ml_policy_violations_total_unique_requests_count = count(*)\n by\n Esql.ml_policy_violations_mv_count,\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// sort by number of unique requests\n| sort Esql.ml_policy_violations_total_unique_requests_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "risk_score": 21, + "rule_id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "low", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_4.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_4.json new file mode 100644 index 00000000000..86924ba1ef9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Concatenation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via String Concatenation\n\nPowerShell is a powerful scripting language used for task automation and configuration management. Adversaries exploit its flexibility to obfuscate malicious scripts, often using string concatenation to evade detection. The detection rule identifies scripts with excessive concatenation patterns, flagging potential obfuscation by analyzing script length and pattern frequency, thus aiding in uncovering hidden threats.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and purpose of the script, focusing on the sections identified by the string concatenation patterns.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and agent.id fields to identify the affected system and correlate with other security events or alerts from the same host for broader context.\n- Investigate the user.id field to determine which user executed the script, assessing their role and whether they have a legitimate reason to run such scripts.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution flow and sequence of the script blocks, which may reveal additional obfuscation or malicious behavior.\n- Cross-reference the _id and _index fields with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.\n\n### False positive analysis\n\n- Scripts with legitimate string concatenation for logging or configuration purposes may trigger the rule. Review the script context to determine if the concatenation is part of a benign operation.\n- Automated scripts generated by development tools might use string concatenation extensively. Identify these tools and consider excluding their output directories or specific script patterns from the rule.\n- PowerShell scripts used in complex data processing tasks may naturally contain high levels of string concatenation. Analyze the script's purpose and, if deemed safe, add exceptions for specific script block IDs or paths.\n- Frequent administrative scripts that concatenate strings for dynamic command execution could be flagged. Verify the script's source and function, then whitelist known safe scripts by user ID or host name.\n- Consider adjusting the threshold for pattern detection if legitimate scripts frequently exceed the current limit, ensuring that the rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts across the network. Disconnect it from the network and any shared resources.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of potentially obfuscated scripts.\n- Conduct a thorough examination of the script block text and associated files to identify and remove any malicious code or artifacts. Use a secure, isolated environment for analysis.\n- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be easily remediated.\n- Update and run a full antivirus and antimalware scan on the affected system to ensure no additional threats are present.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.\n- Implement enhanced monitoring and logging for PowerShell activities across the network to detect similar obfuscation attempts in the future, ensuring that alerts are configured to notify the appropriate personnel promptly.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 47, + "rule_id": "f6d8c743-0916-4483-8333-3c6f107e0caa", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f6d8c743-0916-4483-8333-3c6f107e0caa_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_2.json b/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_2.json new file mode 100644 index 00000000000..65021c8d05b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_2.json @@ -0,0 +1,54 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script blocks associated with multiple distinct detections, indicating likely malicious behavior.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Malicious PowerShell Based on Alert Correlation", + "note": "## Triage and analysis\n\n### Investigating Potential Malicious PowerShell Based on Alert Correlation\n\nThis detection rule aggregates alert data to identify PowerShell Scripts that have triggered various PowerShell-related detection logic, thereby producing higher-fidelity results.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n### Possible investigation steps\n\n- Analyzing the detections triggered by the script should offer insight into the suspicious behaviors it exhibits. This information can be found in the `distinct_alerts` field.\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine the script's execution context, such as the user account, privileges, the role of the system on which it was executed, and any relevant timestamps.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate the origin of the PowerShell script, including its source, download method, and any associated URLs or IP addresses.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the script using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n### False positive analysis\n\n- This rule is unlikely to trigger on legitimate activity. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Reimage the host operating system or restore the compromised files to clean versions.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "from .alerts-security.* metadata _id\n\n// Filter for PowerShell related alerts\n| where kibana.alert.rule.name like \"*PowerShell*\"\n\n// as alerts don't have non-ECS fields, parse the script block ID using grok\n| grok message \"ScriptBlock ID: (?.+)\"\n| where Esql.script_block_id is not null\n\n// keep relevant fields for further processing\n| keep kibana.alert.rule.name, Esql.script_block_id, _id\n\n// count distinct alerts and filter for matches above the threshold\n| stats\n Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name),\n Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),\n Esql._id_values = values(_id)\n by Esql.script_block_id\n\n// Apply detection threshold\n| where Esql.kibana_alert_rule_name_count_distinct >= 5\n", + "risk_score": 73, + "rule_id": "f770ce79-05fd-4d74-9866-1c5d66c9b34b", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "f770ce79-05fd-4d74-9866-1c5d66c9b34b_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_2.json b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_2.json new file mode 100644 index 00000000000..097f266ed76 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_2.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Special Character Proportion", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n// Excludes spaces, #, = and - as they are heavily used in scripts for formatting\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[^0-9A-Za-z\\s#=-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high special character ratio\n| where Esql.script_block_ratio > 0.25\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f9753455-8d55-4ad8-b70a-e07b6f18deea", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "f9753455-8d55-4ad8-b70a-e07b6f18deea_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_4.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_4.json new file mode 100644 index 00000000000..41ca72a8b5d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Numeric Character Proportion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via High Numeric Character Proportion\n\nPowerShell is a powerful scripting language used for system administration, but adversaries exploit its capabilities to obfuscate malicious scripts. Obfuscation often involves encoding payloads using numeric characters, making detection challenging. The detection rule identifies scripts with a high proportion of numeric characters, signaling potential obfuscation. By analyzing script length and numeric density, it flags suspicious activity, aiding in defense evasion detection.\n\n### Possible investigation steps\n\n- Review the script block text from the alert to understand the context and identify any obvious signs of obfuscation or malicious intent.\n- Examine the file path and host name fields to determine the origin and location of the script execution, which can help assess the potential impact and scope.\n- Check the user ID and agent ID fields to identify the user and system involved, which may provide insights into whether the activity is expected or suspicious.\n- Analyze the powershell.sequence and powershell.total fields to understand the sequence of script execution and the total number of scripts executed, which can indicate whether this is part of a larger pattern of behavior.\n- Investigate any related logs or alerts from the same host or user to identify patterns or correlations that might suggest broader malicious activity.\n\n### False positive analysis\n\n- Scripts with legitimate numeric-heavy content such as data processing or mathematical calculations may trigger the rule. To handle this, identify and whitelist specific scripts or script patterns that are known to be safe.\n- Automated scripts that generate or manipulate large datasets often contain high numeric content. Consider creating exceptions for scripts executed by trusted users or from known safe directories.\n- PowerShell scripts used for legitimate software installations or updates might include encoded data blocks. Review and exclude these scripts by verifying their source and purpose.\n- Scripts containing large hexadecimal strings for legitimate purposes, such as cryptographic operations, may be flagged. Use the exclusion pattern to filter out these known safe operations.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate scripts that may be introduced.\n\n### Response and remediation\n\n- Immediately isolate the affected host to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Review the PowerShell script block text and script block ID to identify any malicious payloads or encoded strings. If confirmed malicious, remove or quarantine the script.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to detect and remove any additional threats or remnants of the obfuscated script.\n- Analyze the file path and user ID associated with the script execution to determine if unauthorized access or privilege escalation occurred. Revoke any suspicious user access and reset credentials if necessary.\n- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other alerts to assess the scope and impact of the threat across the network.\n- Implement enhanced monitoring and logging for PowerShell activities on all endpoints to detect similar obfuscation attempts in the future, focusing on scripts with high numeric character proportions.\n- Review and update endpoint protection policies to restrict the execution of scripts with high numeric density, ensuring compliance with security best practices and reducing the risk of obfuscation-based attacks.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_ratio,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high numeric character ratio\n| where Esql.script_block_ratio > 0.30\n\n// Exclude noisy patterns such as 64-character hash lists\n| where not powershell.file.script_block_text rlike \"\"\".*\\\"[a-fA-F0-9]{64}\\\"\\,.*\"\"\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_3.json b/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_3.json new file mode 100644 index 00000000000..1342bef83ba --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_3.json @@ -0,0 +1,37 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions.", + "false_positives": [ + "Queries that are designed to expect empty responses or benign system errors" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Azure OpenAI Insecure Output Handling", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Azure OpenAI Insecure Output Handling\n\nAzure OpenAI integrates AI capabilities into applications, enabling natural language processing tasks. However, improper output handling can lead to vulnerabilities, such as data leaks or unauthorized code execution. Adversaries might exploit these by crafting inputs that cause the API to mishandle responses. The detection rule identifies anomalies by flagging instances where API responses are unexpectedly empty, suggesting potential misuse or misconfiguration, especially when such events occur frequently.\n\n### Possible investigation steps\n\n- Review the logs for the specific Azure resource name flagged in the alert to understand the context and frequency of zero-length responses.\n- Examine the request lengths associated with the zero-length responses to identify any patterns or anomalies in the input data that might be causing the issue.\n- Check the cloud account ID associated with the alert to determine if there are any known issues or recent changes in configuration that could affect output handling.\n- Investigate the operation name \"ChatCompletions_Create\" to ensure that the API is being used as intended and that there are no unauthorized or unexpected uses.\n- Assess the overall environment for any recent updates or changes in the Azure OpenAI configuration that might have impacted output handling.\n\n### False positive analysis\n\n- Frequent legitimate requests with zero response length can occur during testing or development phases. To manage this, exclude known test environments or accounts from the detection rule by adding exceptions for specific cloud.account.id or azure.resource.name values.\n- Some applications may intentionally send requests that do not require a response, resulting in zero response length. Identify these applications and adjust the rule to exclude their specific azure.resource.name.\n- Network issues or temporary service disruptions can lead to zero-length responses. Monitor for patterns of such occurrences and consider excluding specific time frames or network segments if they are known to cause false positives.\n- Automated scripts or bots that interact with the API might generate zero-length responses as part of their normal operation. Identify these scripts and exclude their associated identifiers from the rule to prevent false alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected Azure OpenAI resource to prevent further exploitation. This can be done by temporarily disabling the API or restricting access to it.\n- Review and validate the input handling mechanisms of the affected API to ensure they are robust against malformed or malicious inputs that could lead to insecure output handling.\n- Conduct a thorough audit of recent API requests and responses to identify any unauthorized access or data leaks. Pay special attention to requests with zero response length.\n- Implement additional logging and monitoring for the affected API to capture detailed information about requests and responses, which can help in identifying patterns or repeated attempts of exploitation.\n- Notify the security team and relevant stakeholders about the incident, providing them with detailed findings and any potential impact on data security.\n- If unauthorized access or data leakage is confirmed, follow the organization's incident response plan to notify affected parties and comply with any regulatory requirements.\n- Enhance detection capabilities by integrating anomaly detection tools that can identify unusual patterns in API usage, such as frequent zero-length responses, to prevent similar threats in the future.\n", + "query": "from logs-azure_openai.logs-*\n| where\n azure.open_ai.properties.response_length == 0 and\n azure.open_ai.result_signature == \"200\" and\n azure.open_ai.operation_name == \"ChatCompletions_Create\"\n| keep\n azure.open_ai.properties.request_length,\n azure.open_ai.result_signature,\n cloud.account.id,\n azure.resource.name\n| stats\n Esql.event_count = count(*)\n by\n azure.resource.name\n| where\n Esql.event_count >= 10\n| sort\n Esql.event_count desc\n", + "references": [ + "https://genai.owasp.org/llmrisk/llm02-insecure-output-handling" + ], + "risk_score": 21, + "rule_id": "fb16f9ef-cb03-4234-adc2-44641f3b71ee", + "setup": "## Setup\n\nFor more information on streaming events, see the Azure OpenAI documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs\n", + "severity": "low", + "tags": [ + "Domain: LLM", + "Data Source: Azure OpenAI", + "Data Source: Azure Event Hubs", + "Use Case: Insecure Output Handling", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "fb16f9ef-cb03-4234-adc2-44641f3b71ee_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 7a192fa9cee..813ef646095 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.10 +version: 9.0.11-beta.1 From 1f58773c3050e1ffce22df86d9d68662d3086132 Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Wed, 6 Aug 2025 02:33:22 -0400 Subject: [PATCH 11/13] [Security Rules] Update security rules package to v9.0.11 (#14831) --- packages/security_detection_engine/changelog.yml | 5 +++++ packages/security_detection_engine/manifest.yml | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 7d062a40db0..f6fc0e8f8da 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.11 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14831 - version: 9.0.11-beta.1 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 813ef646095..6aeed6c584a 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.11-beta.1 +version: 9.0.11 From e22fda4f7b13743ace2ed4ac826e85ed0ebe9f60 Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 19 Aug 2025 01:27:50 -0400 Subject: [PATCH 12/13] [Security Rules] Update security rules package to v9.0.12-beta.1 (#14966) --- .../security_detection_engine/changelog.yml | 5 + ...cd2f3e6-41da-40e6-b28b-466f688f00a6_3.json | 41 ---- ...d3d2254-2b4a-11f0-a019-f661ea17fbcc_4.json | 93 ++++++++ ...7261da3-a6d0-463c-aac8-ea1718afcd20_2.json | 41 ---- ...9be0164-63d2-11ef-8e38-f661ea17fbce_1.json | 49 ----- ...f45720e-5ea8-11ef-90d2-f661ea17fbce_1.json | 56 ----- ...fa350e0-0aa2-4055-bf8f-ab8b59233e59_2.json | 55 ----- ...ab79b-239b-4aa5-8e54-fc50623ee8e4_314.json | 123 +++++++++++ ...18264-2d6d-11ef-9413-f661ea17fbce_203.json | 77 ------- ...68dba-ce29-497b-8e13-b4fde1db5a2d_312.json | 57 ----- ...8371aa1-14ed-46cf-ab5b-2fc7d1942278_1.json | 55 ----- ...6e1bc-867a-11ee-b13e-f661ea17fbcd_304.json | 63 ------ ...2144184-7bfa-4541-9c3f-b65f16d24df9_1.json | 122 +++++++++++ ...5ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_4.json | 58 ----- ...93ef120-63d1-11ef-8e38-f661ea17fbce_2.json | 49 ----- ...fac01b2-b811-11ef-b25b-f661ea17fbce_1.json | 65 ------ ...ef0d3-8259-40c9-a5b6-d48354712e49_314.json | 137 ++++++++++++ ...182e486-fc61-11ee-a05d-f661ea17fbce_4.json | 57 ----- ...1c1af-79d4-4d37-9efa-6e0240640242_314.json | 117 ++++++++++ ...f855297-c8e0-4097-9d97-d653f7e471c4_4.json | 42 ---- ...aab7b-b51c-441a-89ce-4387b3aea886_212.json | 139 ++++++++++++ ...a876e0d-d39a-49b9-8ad8-19c9b622203b_1.json | 106 +++++++++ ...4a95d-5a08-48eb-80db-4c3a63ec78a8_318.json | 207 ++++++++++++++++++ ...f0234fd-7f21-42af-8391-511d5fd11d5c_2.json | 85 ------- ...4f17c52-6c6e-479e-ba72-236f3df18f3d_5.json | 81 +++++++ ...83649-f908-4a5b-a1e0-54090a1d3a32_121.json | 141 ++++++++++++ ...b341d03-1d63-41ac-841a-2009c86959ca_2.json | 55 ----- ...ddb6c33-00ce-4acd-832a-24b251512023_1.json | 79 ------- ...41894-66c3-4df7-ad6b-2c5074eb3df8_214.json | 131 +++++++++++ ...25a048a-88c5-4fc7-8677-a44fc0031822_2.json | 42 ---- ...7122db4-5876-4127-b91b-6c179eb21f88_2.json | 94 -------- ...fda9bb2-fd28-11ee-85f9-f661ea17fbce_3.json | 56 ----- ...e23e6-2094-4f0e-8c01-22d30f3506c6_313.json | 124 +++++++++++ ...f249e-4348-47ba-9741-1202a09556ad_207.json | 131 +++++++++++ ...60f2a03-a1cf-48d6-a674-c6d62ae608a1_2.json | 55 ----- ...94b7cc9-040b-427c-aca5-36b40d3667bf_1.json | 101 --------- ...a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_2.json | 101 --------- ...eeeda11-dca6-4c3e-910f-7089db412d1c_2.json | 59 ----- ...734c0-2cda-11ef-84e1-f661ea17fbce_203.json | 77 ------- ...99adc-2cda-11ef-84e1-f661ea17fbce_203.json | 77 ------- ...76b2391-413f-4a94-acb4-7911f3803346_2.json | 101 --------- ...aa4be8d-5828-417d-9f54-7cd304571b24_4.json | 102 --------- ...f432a8b-9588-4550-838e-1f77285580d3_1.json | 79 ------- ...f432a8b-9588-4550-838e-1f77285580d3_5.json | 81 +++++++ ...b8f074c-5565-4bc4-991c-d49770e19fc9_3.json | 59 ----- ...0c98cfb-0745-4513-b6f9-08dddb033490_4.json | 81 +++++++ ...1773d05-f349-45fb-9850-287b8f92f02d_2.json | 40 ---- ...18975f5-676c-4091-b626-81e8938aa2ee_3.json | 122 +++++++++++ ...5637438-e32d-4bb3-bc13-bd7932b3289f_2.json | 94 -------- ...82a2e-7e52-11ee-9aac-f661ea17fbcd_304.json | 55 ----- ...ca64114-fb8b-11ef-86e2-f661ea17fbce_1.json | 63 ------ ...9602e-9db0-48e3-9391-ae3bf241acd8_416.json | 101 +++++++++ ...de13d58-bc39-4aa0-87fd-b4bdbf4591da_3.json | 86 -------- ...f919b5e-a0f6-4fd8-8598-e3ce79299e3b_3.json | 86 -------- ...903ce9a-5ce6-4246-bb14-75ed3ec2edf5_2.json | 79 ------- ...903ce9a-5ce6-4246-bb14-75ed3ec2edf5_6.json | 81 +++++++ ...6953a-4615-4707-a1ca-dc53bf69dcd5_212.json | 117 ++++++++++ ...38633f4-3b31-4c80-b13d-e77c70ce8254_4.json | 81 +++++++ ...4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_2.json | 41 ---- ...6d8c743-0916-4483-8333-3c6f107e0caa_1.json | 79 ------- ...753455-8d55-4ad8-b70a-e07b6f18deea_3.json} | 16 +- ...9abcddc-a05d-4345-a81d-000b79aa5525_1.json | 79 ------- ...9abcddc-a05d-4345-a81d-000b79aa5525_5.json | 81 +++++++ .../security_detection_engine/manifest.yml | 2 +- 64 files changed, 2412 insertions(+), 2697 deletions(-) delete mode 100644 packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/203ab79b-239b-4aa5-8e54-fc50623ee8e4_314.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_203.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_312.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_304.json create mode 100644 packages/security_detection_engine/kibana/security_rule/32144184-7bfa-4541-9c3f-b65f16d24df9_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_314.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4bd1c1af-79d4-4d37-9efa-6e0240640242_314.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_4.json create mode 100644 packages/security_detection_engine/kibana/security_rule/52aaab7b-b51c-441a-89ce-4387b3aea886_212.json create mode 100644 packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_318.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_5.json create mode 100644 packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_121.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6ea41894-66c3-4df7-ad6b-2c5074eb3df8_214.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_313.json create mode 100644 packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_207.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_1.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_203.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_203.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_5.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_3.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c18975f5-676c-4091-b626-81e8938aa2ee_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_304.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cd89602e-9db0-48e3-9391-ae3bf241acd8_416.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_3.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_6.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f036953a-4615-4707-a1ca-dc53bf69dcd5_212.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_4.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_2.json delete mode 100644 packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_1.json rename packages/security_detection_engine/kibana/security_rule/{64f17c52-6c6e-479e-ba72-236f3df18f3d_1.json => f9753455-8d55-4ad8-b70a-e07b6f18deea_3.json} (55%) delete mode 100644 packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_5.json diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index f6fc0e8f8da..d219d90fa95 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.12-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14966 - version: 9.0.11 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_3.json b/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_3.json deleted file mode 100644 index 2e01b814adb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_3.json +++ /dev/null @@ -1,41 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.", - "false_positives": [ - "Legitimate misunderstanding by users or overly strict policies" - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session", - "query": "from logs-aws_bedrock.invocation-*\n| where gen_ai.compliance.violation_detected\n| keep user.id, gen_ai.request.model.id, cloud.account.id\n| stats violations = count(*) by user.id, gen_ai.request.model.id, cloud.account.id\n| where violations > 1\n| sort violations desc\n", - "references": [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" - ], - "risk_score": 47, - "rule_id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6", - "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", - "severity": "medium", - "tags": [ - "Domain: LLM", - "Data Source: AWS Bedrock", - "Data Source: AWS S3", - "Resources: Investigation Guide", - "Use Case: Policy Violation", - "Mitre Atlas: T0051", - "Mitre Atlas: T0054" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_4.json b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_4.json new file mode 100644 index 00000000000..338b0e5b8b2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_4.json @@ -0,0 +1,93 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.", + "false_positives": [ + "This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved." + ], + "from": "now-31m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Suspicious Session Reuse to Graph Access", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Suspicious Session Reuse to Graph Access\n\nIdentifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be\nperformed to the original sign-in and Graph events for further context.\n\n### Investigation Steps\n\n- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields.\n - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events.\n- Review the session ID and user ID to identify the user account involved in the suspicious activity.\n- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user.\n - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary.\n - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph.\n- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise.\n- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access.\n- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate.\n\n### False Positive Analysis\n- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile).\n- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.\n\n### Response Recommendations\n\n- If confirmed malicious, revoke all refresh/access tokens for the user principal.\n- Block the source IP(s) involved in the Graph access.\n- Notify the user and reset credentials.\n- Review session control policies and conditional access enforcement.\n- Monitor for follow-on activity, such as lateral movement or privilege escalation.\n- Review conditional access policies to ensure they are enforced correctly.\n", + "query": "from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index\n| where\n (event.dataset == \"azure.signinlogs\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n and azure.signinlogs.properties.session_id is not null)\n or\n (event.dataset == \"azure.graphactivitylogs\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n and azure.graphactivitylogs.properties.c_sid is not null)\n\n| eval\n Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid),\n Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id),\n Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id),\n Esql.source_ip = source.ip,\n Esql.@timestamp = @timestamp,\n Esql.event_type_case = case(\n event.dataset == \"azure.signinlogs\", \"signin\",\n event.dataset == \"azure.graphactivitylogs\", \"graph\",\n \"other\"\n ),\n Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)\n\n| keep\n Esql.azure_signinlogs_properties_session_id_coalesce,\n Esql.source_ip,\n Esql.@timestamp,\n Esql.event_type_case,\n Esql.time_window_date_trunc,\n Esql.azure_signinlogs_properties_user_id_coalesce,\n Esql.azure_signinlogs_properties_app_id_coalesce\n\n| stats\n Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce),\n Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce),\n Esql.source_ip_values = values(Esql.source_ip),\n Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),\n Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce),\n Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce),\n Esql.event_type_case_values = values(Esql.event_type_case),\n Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case),\n Esql.@timestamp.min = min(Esql.@timestamp),\n Esql.@timestamp.max = max(Esql.@timestamp),\n Esql.signin_time_min = min(case(Esql.event_type_case == \"signin\", Esql.@timestamp, null)),\n Esql.graph_time_min = min(case(Esql.event_type_case == \"graph\", Esql.@timestamp, null)),\n Esql.event_count = count()\n by Esql.azure_signinlogs_properties_session_id_coalesce, Esql.time_window_date_trunc\n\n| eval\n Esql.event_duration_minutes_date_diff = date_diff(\"minutes\", Esql.@timestamp.min, Esql.@timestamp.max),\n Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff(\"minutes\", Esql.signin_time_min, Esql.graph_time_min)\n\n| where\n Esql.event_type_case_count_distinct > 1 and\n Esql.source_ip_count_distinct > 1 and\n Esql.event_duration_minutes_date_diff <= 5 and\n Esql.signin_time_min is not null and\n Esql.graph_time_min is not null and\n Esql.event_signin_to_graph_delay_minutes_date_diff >= 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://attack.mitre.org/techniques/T1078/004/" + ], + "risk_score": 47, + "rule_id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc", + "setup": "#### Required Microsoft Entra ID Sign-In and Graph Activity Logs\nThis rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Domain: API", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Data Source: Microsoft Graph", + "Data Source: Microsoft Graph Activity Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion", + "Tactic: Initial Access" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_2.json b/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_2.json deleted file mode 100644 index 9eb53cd32e2..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_2.json +++ /dev/null @@ -1,41 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.", - "false_positives": [ - "Legitimate misunderstanding by users or overly strict policies" - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User", - "query": "from logs-aws_bedrock.invocation-*\n| where gen_ai.response.error_code == \"AccessDeniedException\"\n| keep user.id, gen_ai.request.model.id, cloud.account.id, gen_ai.response.error_code\n| stats total_denials = count(*) by user.id, gen_ai.request.model.id, cloud.account.id\n| where total_denials > 3\n| sort total_denials desc\n", - "references": [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0015", - "https://atlas.mitre.org/techniques/AML.T0034", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" - ], - "risk_score": 73, - "rule_id": "17261da3-a6d0-463c-aac8-ea1718afcd20", - "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", - "severity": "high", - "tags": [ - "Domain: LLM", - "Data Source: AWS Bedrock", - "Data Source: AWS S3", - "Resources: Investigation Guide", - "Use Case: Policy Violation", - "Mitre Atlas: T0015", - "Mitre Atlas: T0034" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "17261da3-a6d0-463c-aac8-ea1718afcd20_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_1.json deleted file mode 100644 index 17263c5cc98..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_1.json +++ /dev/null @@ -1,49 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Service Quotas Multi-Region `GetServiceQuota` Requests", - "query": "from logs-aws.cloudtrail-*\n\n// filter for GetServiceQuota API calls\n| where event.dataset == \"aws.cloudtrail\" and event.provider = \"servicequotas.amazonaws.com\" and event.action == \"GetServiceQuota\"\n\n// truncate the timestamp to a 30-second window\n| eval target_time_window = DATE_TRUNC(30 seconds, @timestamp)\n\n// pre-process the request parameters to extract the service code and quota code\n| dissect aws.cloudtrail.request_parameters \"{%{?service_code_key}=%{service_code}, %{?quota_code_key}=%{quota_code}}\"\n\n// filter for EC2 service quota L-1216C47A (vCPU on-demand instances)\n| where service_code == \"ec2\" and quota_code == \"L-1216C47A\"\n\n// count the number of unique regions and total API calls within the 30-second window\n| stats region_count = count_distinct(cloud.region), window_count = count(*) by target_time_window, aws.cloudtrail.user_identity.arn\n\n// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window\n| where region_count >= 10 and window_count >= 10\n\n// sort the results by time windows in descending order\n| sort target_time_window desc\n", - "references": [ - "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/", - "https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_GetServiceQuota.html" - ], - "risk_score": 21, - "rule_id": "19be0164-63d2-11ef-8e38-f661ea17fbce", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: AWS Service Quotas", - "Use Case: Threat Detection", - "Tactic: Discovery" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "19be0164-63d2-11ef-8e38-f661ea17fbce_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_1.json deleted file mode 100644 index f6a7b4c998f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_1.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a federated user logs into the AWS Management Console without using multi-factor authentication (MFA). Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. This could also indicate the abuse of STS tokens to bypass MFA requirements.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Signin Single Factor Console Login with Federated User", - "query": "from logs-aws.cloudtrail-*\n| where\n event.provider == \"signin.amazonaws.com\"\n and event.action == \"GetSigninToken\"\n and aws.cloudtrail.event_type == \"AwsConsoleSignIn\"\n and aws.cloudtrail.user_identity.type == \"FederatedUser\"\n| dissect aws.cloudtrail.additional_eventdata \"{%{?mobile_version_key}=%{mobile_version}, %{?mfa_used_key}=%{mfa_used}}\"\n| where mfa_used == \"No\"\n", - "references": [ - "https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/" - ], - "risk_score": 47, - "rule_id": "1f45720e-5ea8-11ef-90d2-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Amazon Web Services", - "Data Source: AWS", - "Data Source: AWS Sign-In", - "Use Case: Threat Detection", - "Tactic: Initial Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.004", - "name": "Cloud Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "1f45720e-5ea8-11ef-90d2-f661ea17fbce_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_2.json b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_2.json deleted file mode 100644 index 152141d2b4b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_2.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "High Number of Egress Network Connections from Unusual Executable", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating High Number of Egress Network Connections from Unusual Executable\n\nIn Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment.\n- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious.\n- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity.\n- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host.\n- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns.\n- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement.\n\n### False positive analysis\n\n- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts.\n- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious.\n- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list.\n- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe.\n- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement.\n- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection.\n- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat.\n- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited.\n- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.\n", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and (\n (\n process.executable like \"/tmp/*\" or\n process.executable like \"/var/tmp/*\" or\n process.executable like \"/dev/shm/*\"\n ) or\n (process.name like \".*\")\n) and not (\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable like \"/nix/store/*\" or\n process.executable like \"/tmp/newroot/*\" or\n process.executable like \"/tmp/.mount*\" or\n process.executable like \"/tmp/go-build*\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 47, - "rule_id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/203ab79b-239b-4aa5-8e54-fc50623ee8e4_314.json b/packages/security_detection_engine/kibana/security_rule/203ab79b-239b-4aa5-8e54-fc50623ee8e4_314.json new file mode 100644 index 00000000000..1920a83be56 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/203ab79b-239b-4aa5-8e54-fc50623ee8e4_314.json @@ -0,0 +1,123 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation or modification of a local trusted root certificate in Windows. The install of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic.", + "false_positives": [ + "Certain applications may install root certificates for the purpose of inspecting SSL traffic." + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Creation or Modification of Root Certificate", + "note": "## Triage and analysis\n\n### Investigating Creation or Modification of Root Certificate\n\nRoot certificates are the primary level of certifications that tell a browser that the communication is trusted and legitimate. This verification is based upon the identification of a certification authority. Windows adds several trusted root certificates so browsers can use them to communicate with websites.\n\n[Check out this post](https://www.thewindowsclub.com/what-are-root-certificates-windows) for more details on root certificates and the involved cryptography.\n\nThis rule identifies the creation or modification of a root certificate by monitoring registry modifications. The installation of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed by the subject process such as network connections, other registry or file modifications, and any spawned child processes.\n- If one of the processes is suspicious, retrieve it and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled task creation.\n - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.\n - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This detection may be triggered by certain applications that install root certificates for the purpose of inspecting SSL traffic. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove the malicious certificate from the root certificate store.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and registry.value : \"Blob\" and\n registry.path :\n (\n \"HKLM\\\\Software\\\\Microsoft\\\\SystemCertificates\\\\Root\\\\Certificates\\\\*\\\\Blob\",\n \"HKLM\\\\Software\\\\Microsoft\\\\SystemCertificates\\\\AuthRoot\\\\Certificates\\\\*\\\\Blob\",\n \"HKLM\\\\Software\\\\Policies\\\\Microsoft\\\\SystemCertificates\\\\Root\\\\Certificates\\\\*\\\\Blob\",\n \"HKLM\\\\Software\\\\Policies\\\\Microsoft\\\\SystemCertificates\\\\AuthRoot\\\\Certificates\\\\*\\\\Blob\",\n \"\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\SystemCertificates\\\\Root\\\\Certificates\\\\*\\\\Blob\",\n \"\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\SystemCertificates\\\\AuthRoot\\\\Certificates\\\\*\\\\Blob\",\n \"\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Policies\\\\Microsoft\\\\SystemCertificates\\\\Root\\\\Certificates\\\\*\\\\Blob\",\n \"\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Policies\\\\Microsoft\\\\SystemCertificates\\\\AuthRoot\\\\Certificates\\\\*\\\\Blob\",\n \"MACHINE\\\\Software\\\\Microsoft\\\\SystemCertificates\\\\Root\\\\Certificates\\\\*\\\\Blob\",\n \"MACHINE\\\\Software\\\\Microsoft\\\\SystemCertificates\\\\AuthRoot\\\\Certificates\\\\*\\\\Blob\",\n \"MACHINE\\\\Software\\\\Policies\\\\Microsoft\\\\SystemCertificates\\\\Root\\\\Certificates\\\\*\\\\Blob\",\n \"MACHINE\\\\Software\\\\Policies\\\\Microsoft\\\\SystemCertificates\\\\AuthRoot\\\\Certificates\\\\*\\\\Blob\"\n ) and\n not process.executable : (\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\ProgramData\\\\bomgar-*\\\\*\\\\sra-pin.exe\",\n \"?:\\\\ProgramData\\\\bomgar-*\\\\*\\\\bomgar-scc.exe\",\n \"?:\\\\ProgramData\\\\CTES\\\\Ctes.exe\",\n \"?:\\\\ProgramData\\\\CTES\\\\Components\\\\SNG\\\\AbtSngSvc.exe\",\n \"?:\\\\ProgramData\\\\CTES\\\\Components\\\\SVC\\\\CtesHostSvc.exe\",\n \"?:\\\\ProgramData\\\\Lenovo\\\\Vantage\\\\Addins\\\\LenovoHardwareScanAddin\\\\*\\\\LdeApi.Server.exe\",\n \"?:\\\\ProgramData\\\\Logishrd\\\\LogiOptionsPlus\\\\Plugins\\\\64\\\\certmgr.exe\",\n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\*.exe\",\n \"?:\\\\ProgramData\\\\Quest\\\\KACE\\\\modules\\\\clientidentifier\\\\clientidentifier.exe\",\n \"?:\\\\ProgramData\\\\Sophos\\\\AutoUpdate\\\\Cache\\\\sophos_autoupdate1.dir\\\\*.exe\",\n \"?:\\\\ProgramData\\\\tychoncloud\\\\bin\\\\OVAL\\\\tvs.exe\",\n \"?:\\\\Windows\\\\CCM\\\\CcmEval.exe\",\n \"?:\\\\Windows\\\\CCM\\\\CcmExec.exe\",\n \"?:\\\\Windows\\\\ccmsetup\\\\autoupgrade\\\\ccmsetup*.exe\",\n \"?:\\\\Windows\\\\ccmsetup\\\\cache\\\\ccmsetup.exe\",\n \"?:\\\\Windows\\\\ccmsetup\\\\ccmsetup.exe\",\n \"?:\\\\Windows\\\\Cluster\\\\clussvc.exe\",\n \"?:\\\\Windows\\\\ImmersiveControlPanel\\\\SystemSettings.exe\",\n \"?:\\\\Windows\\\\Lenovo\\\\ImController\\\\PluginHost86\\\\Lenovo.Modern.ImController.PluginHost.Device.exe\",\n \"?:\\\\Windows\\\\Lenovo\\\\ImController\\\\Service\\\\Lenovo.Modern.ImController.exe\",\n \"?:\\\\Windows\\\\Sysmon.exe\",\n \"?:\\\\Windows\\\\Sysmon64.exe\",\n \"?:\\\\Windows\\\\UUS\\\\amd64\\\\MoUsoCoreWorker.exe\",\n \"?:\\\\Windows\\\\UUS\\\\amd64\\\\WaaSMedicAgent.exe\",\n \"?:\\\\Windows\\\\UUS\\\\Packages\\\\Preview\\\\amd64\\\\MoUsoCoreWorker.exe\",\n \"?:\\\\Windows\\\\WinSxS\\\\*.exe\"\n ) and\n not\n (\n process.executable : (\n \"?:\\\\Windows\\\\System32\\\\*.exe\",\n \"?:\\\\Windows\\\\SysWOW64\\\\*.exe\"\n ) and\n not process.name : (\n \"rundll32.exe\", \"mshta.exe\", \"powershell.exe\", \"pwsh.exe\", \"cmd.exe\", \"expand.exe\",\n \"regsvr32.exe\", \"cscript.exe\", \"wscript.exe\", \"wmiprvse.exe\", \"certutil.exe\", \"xcopy.exe\"\n )\n )\n", + "references": [ + "https://posts.specterops.io/code-signing-certificate-cloning-attacks-and-defenses-6f98657fc6ec", + "https://www.ired.team/offensive-security/persistence/t1130-install-root-certificate" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "203ab79b-239b-4aa5-8e54-fc50623ee8e4", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1553", + "name": "Subvert Trust Controls", + "reference": "https://attack.mitre.org/techniques/T1553/", + "subtechnique": [ + { + "id": "T1553.004", + "name": "Install Root Certificate", + "reference": "https://attack.mitre.org/techniques/T1553/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 314 + }, + "id": "203ab79b-239b-4aa5-8e54-fc50623ee8e4_314", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_203.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_203.json deleted file mode 100644 index 3ed3cc487bb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_203.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", - "false_positives": [ - "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", - "Shared systems such as Kiosks and conference room computers may be used by multiple users." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "High Number of Okta Device Token Cookies Generated for Authentication", - "note": "## Triage and analysis\n\n### Investigating High Number of Okta Device Token Cookies Generated for Authentication\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.request_uri == \"/api/v1/authn\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count >= 30\n| SORT\n source_auth_count DESC\n", - "references": [ - "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 21, - "rule_id": "23f18264-2d6d-11ef-9413-f661ea17fbce", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - }, - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.004", - "name": "Credential Stuffing", - "reference": "https://attack.mitre.org/techniques/T1110/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 203 - }, - "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_203", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_312.json b/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_312.json deleted file mode 100644 index a0f0065aedd..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_312.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic", - "Willem D'Haese", - "Austin Songer" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed login attempts or login sources within a 30-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Attempts to Brute Force a Microsoft 365 User Account", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Attempts to Brute Force a Microsoft 365 User Account\n\nMicrosoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses.\n- Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources.\n- Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts.\n- Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity.\n- Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents.\n- Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat.\n\n### False positive analysis\n\n- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities.\n- Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses.\n- Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses.\n- Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity.\n- Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts.\n- Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation.\n- Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies.\n- Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources.\n- Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices.\n- Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected.", - "query": "from logs-o365.audit-*\n// truncate the timestamp to a 30-minute window\n| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)\n| mv_expand event.category\n| where event.dataset == \"o365.audit\"\n and event.category == \"authentication\"\n\n // filter only on Entra ID or Exchange audit logs in O365 integration\n and event.provider in (\"AzureActiveDirectory\", \"Exchange\")\n\n // filter only for UserLoginFailed or partial failures\n and event.action in (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\")\n\n // ignore specific logon errors\n and not o365.audit.LogonError in (\n \"EntitlementGrantsNotFound\",\n \"UserStrongAuthEnrollmentRequired\",\n \"UserStrongAuthClientAuthNRequired\",\n \"InvalidReplyTo\",\n \"SsoArtifactExpiredDueToConditionalAccess\",\n \"PasswordResetRegistrationRequiredInterrupt\",\n \"SsoUserAccountNotFoundInResourceTenant\",\n \"UserStrongAuthExpired\",\n \"CmsiInterrupt\"\n)\n\n // ignore unavailable\n and o365.audit.UserId != \"Not Available\"\n\n // filters out non user or application logins based on target\n and o365.audit.Target.Type in (\"0\", \"2\", \"3\", \"5\", \"6\", \"10\")\n\n // filters only for logins from user or application, ignoring oauth:token\n and to_lower(o365.audit.ExtendedProperties.RequestType) rlike \"(.*)login(.*)\"\n\n// keep only relevant fields\n| keep event.provider, event.dataset, event.category, o365.audit.UserId, event.action, source.ip, o365.audit.LogonError, o365.audit.ExtendedProperties.RequestType, o365.audit.Target.Type, target_time_window\n\n// count the number of login sources and failed login attempts\n| stats\n login_source_count = count(source.ip),\n failed_login_count = count(*) by target_time_window, o365.audit.UserId\n\n// filter for users with more than 20 login sources or failed login attempts\n| where (login_source_count >= 20 or failed_login_count >= 20)\n", - "references": [ - "https://blueteamblog.com/7-ways-to-monitor-your-office-365-logs-using-siem", - "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties" - ], - "risk_score": 47, - "rule_id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Microsoft 365", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 312 - }, - "id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d_312", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_1.json b/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_1.json deleted file mode 100644 index 48a5de187a5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_1.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Widespread Malware Infection Across Multiple Hosts", - "query": "from logs-endpoint.alerts-*\n| where event.code in (\"malicious_file\", \"memory_signature\", \"shellcode_thread\") and rule.name is not null\n| stats hosts = count_distinct(host.id) by rule.name, event.code\n| where hosts >= 3\n", - "references": [ - "https://github.com/elastic/protections-artifacts/tree/main/yara/rules" - ], - "risk_score": 73, - "rule_id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "Data Source: Elastic Defend", - "Use Case: Threat Detection", - "Tactic: Execution", - "Rule Type: Higher-Order Rule" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1204", - "name": "User Execution", - "reference": "https://attack.mitre.org/techniques/T1204/", - "subtechnique": [ - { - "id": "T1204.002", - "name": "Malicious File", - "reference": "https://attack.mitre.org/techniques/T1204/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_304.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_304.json deleted file mode 100644 index ac89d2429d6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_304.json +++ /dev/null @@ -1,63 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", - "from": "now-30m", - "interval": "15m", - "language": "esql", - "license": "Elastic License v2", - "name": "Okta User Sessions Started from Different Geolocations", - "note": "\n## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.security_context.is_proxy != true and okta.actor.id != \"unknown\"\n AND event.outcome == \"success\"\n| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id\n| STATS\n geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)\n BY okta.actor.id, okta.actor.alternate_id\n| WHERE\n geo_auth_counts >= 2\n", - "references": [ - "https://developer.okta.com/docs/reference/api/system-log/", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 47, - "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", - "severity": "medium", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Initial Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.004", - "name": "Cloud Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 304 - }, - "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_304", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/32144184-7bfa-4541-9c3f-b65f16d24df9_1.json b/packages/security_detection_engine/kibana/security_rule/32144184-7bfa-4541-9c3f-b65f16d24df9_1.json new file mode 100644 index 00000000000..19f3ecc6bf5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/32144184-7bfa-4541-9c3f-b65f16d24df9_1.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of ASPX files in specific directories that are commonly targeted by attackers to deploy web shells.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.file-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-m365_defender.event-*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Web Shell ASPX File Creation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Web Shell ASPX File Creation\n\nWeb shells are malicious scripts uploaded to web servers, often exploiting vulnerabilities in web applications. ASPX files, used in Windows environments, can be manipulated by attackers to maintain persistence and execute arbitrary commands. Adversaries target specific directories for deploying these files. The detection rule identifies suspicious ASPX file creation in these directories, excluding legitimate processes, to flag potential web shell activity.\n\n### Possible investigation steps\n\n- Review the file path where the ASPX file was created to confirm it matches the targeted directory pattern: \"?:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\*\". This can help determine if the file is in a location commonly exploited for web shells.\n- Examine the process that created the ASPX file, ensuring it is not the legitimate \"?:\\Windows\\System32\\msiexec.exe\". Investigate the actual process responsible for the file creation to assess its legitimacy and potential malicious intent.\n- Check the timestamp of the file creation event to correlate it with other suspicious activities or alerts on the host, which might provide additional context or evidence of compromise.\n- Investigate the contents of the ASPX file to identify any malicious code or scripts that could indicate a web shell. Look for patterns or code snippets commonly associated with web shell functionality.\n- Analyze network activity from the host around the time of the ASPX file creation to identify any unusual outbound connections or data transfers that might suggest communication with a command and control server.\n- Review historical alerts and logs for the host to identify any previous suspicious activities or patterns that could indicate ongoing compromise or persistence mechanisms.\n\n### False positive analysis\n\n- Routine updates or installations of legitimate web server components may trigger alerts. Users can create exceptions for known update processes or installation paths to reduce false positives.\n- Development or testing environments often generate ASPX files as part of normal operations. Exclude directories or processes associated with these environments to prevent unnecessary alerts.\n- Automated scripts or tools used for web server maintenance might create ASPX files. Identify and whitelist these scripts to avoid false detections.\n- Legitimate third-party applications that integrate with web server extensions may create ASPX files. Monitor and whitelist these applications to ensure they do not trigger false positives.\n- Scheduled tasks or system processes that interact with web server directories can be mistaken for malicious activity. Review and exclude these tasks if they are verified as non-threatening.\n\n### Response and remediation\n\n- Isolate the affected server from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious processes associated with the creation of the ASPX file, especially those not originating from legitimate executables like msiexec.exe.\n- Remove the identified ASPX file from the targeted directory to eliminate the potential web shell.\n- Conduct a thorough scan of the server using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes.\n- Review server logs and network traffic for signs of unauthorized access or data exfiltration, and document any findings for further analysis.\n- Restore the server from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts.\n- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures, such as patching vulnerabilities or enhancing monitoring capabilities.\n", + "query": "file where host.os.type == \"windows\" and event.type != \"deletion\" and\n file.extension : \"aspx\" and\n file.path : \"?:\\\\Program Files\\\\Common Files\\\\Microsoft Shared\\\\Web Server Extensions\\\\*\" and\n not process.executable: \"?:\\\\Windows\\\\System32\\\\msiexec.exe\"\n", + "references": [ + "https://blog.viettelcybersecurity.com/toolshell-a-critical-sharepoint-vulnerability-chain-under-active-exploitation/", + "https://www.sentinelone.com/blog/sharepoint-toolshell-zero-day-exploited-in-the-wild-targets-enterprise-servers/", + "https://www.rapid7.com/blog/post/2024/10/30/investigating-a-sharepoint-compromise-ir-tales-from-the-field/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.extension", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "32144184-7bfa-4541-9c3f-b65f16d24df9", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "32144184-7bfa-4541-9c3f-b65f16d24df9_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_4.json b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_4.json deleted file mode 100644 index c1f459c2fcc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_4.json +++ /dev/null @@ -1,58 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Azure Entra Sign-in Brute Force against Microsoft 365 Accounts\n\nAzure Entra ID, integral to Microsoft 365, manages user identities and access. Adversaries exploit this by attempting numerous login attempts to breach accounts, targeting services like Exchange and Teams. The detection rule identifies such threats by analyzing failed login patterns within a 30-minute window, flagging unusual activity from multiple sources or excessive failed attempts, thus highlighting potential brute-force attacks.\n\n### Possible investigation steps\n\n- Review the `azure.signinlogs.properties.user_principal_name` to identify the specific user account targeted by the brute-force attempts.\n- Examine the `source.ip` field to determine the origin of the failed login attempts and assess if multiple IP addresses are involved, indicating a distributed attack.\n- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted during the login attempts.\n- Analyze the `target_time_window` to confirm the timeframe of the attack and correlate it with other security events or alerts that may have occurred simultaneously.\n- Investigate the `azure.signinlogs.properties.status.error_code` for specific error codes that might provide additional context on the nature of the failed login attempts.\n- Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat.\n\n### False positive analysis\n\n- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery processes. To mitigate this, consider excluding known IP addresses associated with IT support or helpdesk operations.\n- Automated scripts or applications that frequently access Microsoft 365 services using non-interactive logins may be misidentified as brute force attempts. Identify and whitelist these applications by their user principal names or IP addresses.\n- Users traveling or working remotely may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exclusions for known travel patterns or use conditional access policies to manage these scenarios.\n- Bulk operations performed by administrators, such as batch account updates or migrations, can result in numerous failed logins. Exclude these activities by recognizing the specific user principal names or IP addresses involved in such operations.\n- Frequent logins from shared IP addresses, such as those from corporate VPNs or proxy servers, might be flagged. Consider excluding these IP ranges if they are known and trusted within the organization.\n\n### Response and remediation\n\n- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.\n- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique.\n- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources.\n- Enable multi-factor authentication (MFA) for the affected accounts and any other accounts that do not have it enabled to add an additional layer of security.\n- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation.\n- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats.\n- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats.\n\nThis rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.", - "query": "from logs-azure.signinlogs*\n// truncate the timestamp to a 30-minute window\n| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and to_lower(azure.signinlogs.properties.resource_display_name) rlike \"(.*)365(.*)\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome != \"success\"\n and not (azure.signinlogs.category == \"NonInteractiveUserSignInLogs\"\n and azure.signinlogs.properties.status.error_code in (70043, 70044, 50057)\n and azure.signinlogs.properties.incoming_token_type in (\"primaryRefreshToken\", \"refreshToken\")) \n // for tuning review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// keep only relevant fields\n| keep target_time_window, event.dataset, event.category, azure.signinlogs.properties.resource_display_name, azure.signinlogs.category, event.outcome, azure.signinlogs.properties.user_principal_name, source.ip\n\n// count the number of login sources and failed login attempts\n| stats\n login_source_count = count(source.ip),\n failed_login_count = count(*) by target_time_window, azure.signinlogs.properties.user_principal_name\n\n// filter for users with more than 20 login sources or failed login attempts\n| where (login_source_count >= 20 or failed_login_count >= 20)\n", - "references": [ - "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" - ], - "risk_score": 47, - "rule_id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_2.json deleted file mode 100644 index 1152b745e87..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_2.json +++ /dev/null @@ -1,49 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS EC2 Multi-Region DescribeInstances API Calls", - "query": "from logs-aws.cloudtrail-*\n\n// filter for DescribeInstances API calls\n| where event.dataset == \"aws.cloudtrail\" and event.provider == \"ec2.amazonaws.com\" and event.action == \"DescribeInstances\"\n\n// truncate the timestamp to a 30-second window\n| eval target_time_window = DATE_TRUNC(30 seconds, @timestamp)\n\n// keep only the relevant fields\n| keep target_time_window, aws.cloudtrail.user_identity.arn, cloud.region\n\n// count the number of unique regions and total API calls within the 30-second window\n| stats region_count = count_distinct(cloud.region), window_count = count(*) by target_time_window, aws.cloudtrail.user_identity.arn\n\n// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window\n| where region_count >= 10 and window_count >= 10\n\n// sort the results by time windows in descending order\n| sort target_time_window desc\n", - "references": [ - "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html" - ], - "risk_score": 21, - "rule_id": "393ef120-63d1-11ef-8e38-f661ea17fbce", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: AWS EC2", - "Use Case: Threat Detection", - "Tactic: Discovery" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "393ef120-63d1-11ef-8e38-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_1.json deleted file mode 100644 index 957d918475c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_1.json +++ /dev/null @@ -1,65 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span. Adversaries with valid credentials, when attempting to login to Azure portal or other Azure services, may be prompted to provide a TOTP code as part of the MFA process. If successful, adversaries can bypass MFA and gain unauthorized access to Azure resources.", - "false_positives": [ - "Based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed TOTP code attempts in a short time-span." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra MFA TOTP Brute Force Attempts", - "note": "## Triage and Analysis\n\n### Investigating Azure Entra MFA TOTP Brute Force Attempts\n\nThis rule detects high-frequency failed TOTP code attempts for a single user in a short time span. Such behavior could indicate an adversary attempting to bypass multi-factor authentication (MFA) protections using valid credentials. Understanding the context of the user's typical behavior and identifying anomalies in the log data are critical to determining the nature of the activity.\n\n#### Possible Investigation Steps:\n\n**Review the Source IP Address**:\n - Check the `source.ip` or `azure.signinlogs.caller_ip_address` field.\n - Determine if the IP address is associated with the user\u2019s typical login locations.\n - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user\u2019s normal activity).\n\n**Analyze User Activity**:\n - Identify the user from the `azure.signinlogs.properties.sign_in_identifier` field.\n - Determine if the user is currently active from another device or session. Session hijacking could explain parallel activity with failed attempts.\n - Review past logs for the user to determine whether MFA failures or other anomalies are consistent or new.\n\n**Inspect the Authentication Method**:\n - Evaluate the `azure.signinlogs.properties.mfa_detail.auth_method` field: `OATH verification code`.\n - Confirm if the user typically uses TOTP codes or another MFA method (e.g., push notifications).\n - Verify if there are any recent changes to the user\u2019s MFA settings that may explain multiple failed attempts.\n\n**Evaluate the User Agent**:\n - Check the `user_agent.original` field.\n - Identify if the user agent matches a typical browser or a potentially malicious script (e.g., Python-based).\n - Look for deviations in operating system or browser versions from the user\u2019s normal activity.\n\n**Analyze Conditional Access Policies**:\n - Review the `azure.signinlogs.properties.applied_conditional_access_policies` for enforced grant controls.\n - Verify if MFA failures are tied to legitimate security policies (`display_name: Require multifactor authentication for admins`).\n\n**Correlate with Other Events**:\n - Search for other authentication attempts involving the same `azure.signinlogs.caller_ip_address`, `user_principal_name`, or `azure.signinlogs.properties.app_id`.\n - Look for suspicious activity patterns, such as password resets, privilege escalation, or account lockouts.\n\n\n#### False Positive Analysis:\n\n- **Unintentional User Behavior**:\n - Verify if the failed attempts could result from the user\u2019s unfamiliarity with TOTP codes or issues with device synchronization.\n - Check if the user recently switched MFA methods or devices, which could explain multiple failures.\n - Determine if this is whitebox testing or a developer testing MFA integration.\n\n- **Administrative Actions**:\n - Determine if the activity is related to legitimate administrative testing or configuration changes in the MFA system.\n\n#### Response and Remediation:\n\n- **Immediate Actions**:\n - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts.\n - Notify the user of suspicious activity and validate their access to the account.\n - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user.\n\n- **Strengthen Authentication Policies**:\n - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior.\n - Consider a different MFA method or additional security controls to prevent future bypass attempts.\n\n- **Monitor and Audit**:\n - Implement additional monitoring to track high-frequency authentication failures across the environment.\n - Audit historical logs for similar patterns involving other accounts to identify broader threats.\n\n- **Educate and Train Users**:\n - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity.\n", - "query": "from logs-azure.signinlogs* metadata _id, _version, _index\n| where\n // filter for Entra Sign-In Logs\n event.dataset == \"azure.signinlogs\"\n and azure.signinlogs.operation_name == \"Sign-in activity\"\n\n // filter for MFA attempts with OATH conditional access attempts or TOTP\n and azure.signinlogs.properties.authentication_requirement == \"multiFactorAuthentication\"\n and azure.signinlogs.properties.mfa_detail.auth_method == \"OATH verification code\"\n\n // filter on failures only from brute-force attempts\n and azure.signinlogs.properties.conditional_access_status == \"failure\"\n and azure.signinlogs.result_description == \"Authentication failed during strong authentication request.\"\n| keep azure.signinlogs.properties.sign_in_identifier\n| stats\n // aggregate by the sign-in account or principal\n failed_totp_code_attempts = count(*) by azure.signinlogs.properties.sign_in_identifier\n| where\n // filter on high frequency for a single user\n failed_totp_code_attempts > 30\n", - "references": [ - "https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass", - "https://learn.microsoft.com/en-us/entra/identity/", - "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins" - ], - "risk_score": 47, - "rule_id": "3fac01b2-b811-11ef-b25b-f661ea17fbce", - "setup": "#### Required Azure Entra Sign-In Logs\nThis rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration.\n", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.001", - "name": "Password Guessing", - "reference": "https://attack.mitre.org/techniques/T1110/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "3fac01b2-b811-11ef-b25b-f661ea17fbce_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_314.json b/packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_314.json new file mode 100644 index 00000000000..2971b17a1ec --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_314.json @@ -0,0 +1,137 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.registry-*", + "endgame-*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Unusual Persistence via Services Registry", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Persistence via Services Registry\n\nWindows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity.\n\n### Possible investigation steps\n\n- Review the specific registry paths and values that triggered the alert, focusing on \"ServiceDLL\" and \"ImagePath\" within the specified registry paths to identify any unauthorized or suspicious modifications.\n- Examine the process responsible for the registry change, paying attention to the process name and executable path, to determine if it is a known legitimate process or potentially malicious.\n- Cross-reference the process executable path against the list of known legitimate paths excluded in the query to ensure it is not a false positive.\n- Investigate the historical behavior of the process and any associated files or network activity to identify patterns indicative of malicious intent or persistence mechanisms.\n- Check for any recent changes or anomalies in the system's service configurations that could correlate with the registry modifications, indicating potential unauthorized service creation or alteration.\n- Consult threat intelligence sources or databases to determine if the process or registry changes are associated with known malware or adversary techniques.\n\n### False positive analysis\n\n- Legitimate software installations or updates may modify service registry keys directly. Users can create exceptions for known software update processes by excluding their executables from the detection rule.\n- System maintenance tools like Process Explorer may trigger false positives when they interact with service registry keys. Exclude these tools by adding their process names and paths to the exception list.\n- Drivers installed by trusted hardware peripherals might alter service registry keys. Users should identify and exclude these driver paths if they are known to be safe and frequently updated.\n- Custom enterprise applications that require direct registry modifications for service management can be excluded by specifying their executable paths in the rule exceptions.\n- Regular system processes such as svchost.exe or services.exe are already excluded, but ensure any custom scripts or automation tools that mimic these processes are also accounted for in the exceptions.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate any suspicious processes identified in the alert that are not part of legitimate applications or services.\n- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the service configurations.\n- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts.\n- Review and update endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases.", + "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.value : (\"ServiceDLL\", \"ImagePath\") and\n registry.path : (\n \"HKLM\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ServiceDLL\",\n \"HKLM\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath\",\n \"\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ServiceDLL\",\n \"\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath\",\n \"MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ServiceDLL\",\n \"MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath\"\n ) and not registry.data.strings : (\n \"?:\\\\windows\\\\system32\\\\Drivers\\\\*.sys\",\n \"\\\\SystemRoot\\\\System32\\\\drivers\\\\*.sys\",\n \"\\\\??\\\\?:\\\\Windows\\\\system32\\\\Drivers\\\\*.SYS\",\n \"\\\\??\\\\?:\\\\Windows\\\\syswow64\\\\*.sys\",\n \"system32\\\\DRIVERS\\\\USBSTOR\", \n \"system32\\\\drivers\\\\*.sys\", \n \"C:\\\\WindowsAzure\\\\GuestAgent*.exe\", \n \"\\\"C:\\\\Program Files\\\\Common Files\\\\McAfee\\\\*\", \n \"C:\\\\Program Files (x86)\\\\VERITAS\\\\VxPBX\\\\bin\\\\pbx_exchange.exe\", \n \"\\\"C:\\\\Program Files (x86)\\\\VERITAS\\\\VxPBX\\\\bin\\\\pbx_exchange.exe\\\"\",\n \"\\\"C:\\\\ProgramData\\\\McAfee\\\\Agent\\\\Current\\\\*\") and\n not (process.name : \"procexp??.exe\" and registry.data.strings : \"?:\\\\*\\\\procexp*.sys\") and\n not process.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\winsxs\\\\*\\\\TiWorker.exe\",\n \"?:\\\\Windows\\\\System32\\\\drvinst.exe\",\n \"?:\\\\Windows\\\\System32\\\\services.exe\",\n \"?:\\\\Windows\\\\System32\\\\msiexec.exe\",\n \"?:\\\\Windows\\\\System32\\\\regsvr32.exe\",\n \"?:\\\\Windows\\\\System32\\\\WaaSMedicAgent.exe\", \n \"?:\\\\Windows\\\\UUS\\\\amd64\\\\WaaSMedicAgent.exe\"\n )\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "403ef0d3-8259-40c9-a5b6-d48354712e49", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/", + "subtechnique": [ + { + "id": "T1543.003", + "name": "Windows Service", + "reference": "https://attack.mitre.org/techniques/T1543/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 314 + }, + "id": "403ef0d3-8259-40c9-a5b6-d48354712e49_314", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_4.json b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_4.json deleted file mode 100644 index 8043b858c39..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_4.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the snapshot into an environment they control, to access the data.", - "false_positives": [ - "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS EC2 EBS Snapshot Shared or Made Public", - "note": "\n## Triage and analysis\n\n### Investigating AWS EC2 EBS Snapshot Shared or Made Public\n\nThis rule detects when an AWS EC2 EBS snapshot is shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this to copy the snapshot into an environment they control to access the data. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Review UserID**: Check the `userId` field to identify the AWS account with which the snapshot was shared. Verify if this account is authorized to access the data or if it belongs to a known third party. If this value is `all`, the snapshot is made public.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions.\n- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing EBS snapshots and securing AWS environments, refer to the [AWS EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security:\n- [AWS EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)\n- [AWS API ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)\n- [AWS EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"ec2.amazonaws.com\" and event.action == \"ModifySnapshotAttribute\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?snapshotId}=%{snapshotId},%{?attributeType}=%{attributeType},%{?createVolumePermission}={%{operationType}={%{?items}=[{%{?userId}=%{userId}}]}}}\"\n| where operationType == \"add\" and cloud.account.id != userId\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, snapshotId, attributeType, operationType, userId\n", - "references": [ - "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html", - "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump", - "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" - ], - "risk_score": 21, - "rule_id": "4182e486-fc61-11ee-a05d-f661ea17fbce", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS EC2", - "Use Case: Threat Detection", - "Tactic: Exfiltration", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [ - { - "id": "T1537", - "name": "Transfer Data to Cloud Account", - "reference": "https://attack.mitre.org/techniques/T1537/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "4182e486-fc61-11ee-a05d-f661ea17fbce_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4bd1c1af-79d4-4d37-9efa-6e0240640242_314.json b/packages/security_detection_engine/kibana/security_rule/4bd1c1af-79d4-4d37-9efa-6e0240640242_314.json new file mode 100644 index 00000000000..b5b742daf9e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4bd1c1af-79d4-4d37-9efa-6e0240640242_314.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies processes running from an Alternate Data Stream. This is uncommon for legitimate processes and sometimes done by adversaries to hide malware.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process-*", + "winlogbeat-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Unusual Process Execution Path - Alternate Data Stream", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Process Execution Path - Alternate Data Stream\n\nAlternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be exploited by adversaries to conceal malicious code. This technique is often used for defense evasion, as it hides malware within legitimate files. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the process details, including the process name and path, to determine if it is a known legitimate application or potentially malicious.\n- Examine the process arguments, specifically looking for the pattern \"?:\\\\*:*\", to understand the context of the execution and identify any suspicious or unusual characteristics.\n- Check the parent process of the flagged process to assess if it was initiated by a legitimate or expected source.\n- Investigate the user account associated with the process execution to determine if the activity aligns with the user's typical behavior or if it appears anomalous.\n- Correlate the event with other security logs or alerts from data sources like Sysmon, Microsoft Defender for Endpoint, or Crowdstrike to gather additional context and identify any related suspicious activities.\n- Search for any known indicators of compromise (IOCs) related to the process or file path in threat intelligence databases to assess if the activity is associated with known threats.\n\n### False positive analysis\n\n- Legitimate software installations or updates may use alternate data streams to execute processes. Users can create exceptions for known software update paths to prevent unnecessary alerts.\n- Some backup or file synchronization tools might utilize alternate data streams for metadata storage. Identify these tools and exclude their execution paths from the detection rule.\n- Certain system administration scripts or tools may leverage alternate data streams for legitimate purposes. Review and whitelist these scripts if they are verified as non-threatening.\n- Developers might use alternate data streams during software development for testing purposes. Ensure development environments are accounted for in the exception list to avoid false positives.\n- Security tools themselves may use alternate data streams for scanning or monitoring activities. Verify and exclude these tools from the detection rule to reduce noise.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potential malware.\n- Terminate any suspicious processes identified as running from an Alternate Data Stream to halt malicious activity.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any hidden malware.\n- Examine the file system for any additional Alternate Data Streams and remove or quarantine any suspicious files.\n- Restore any affected files or systems from known good backups to ensure system integrity.\n- Monitor the network for any unusual outbound traffic from the affected system that may indicate data exfiltration attempts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.args : \"?:\\\\*:*\" and\n (\n process.args_count == 1 and\n\n /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */\n not process.command_line regex~ \"\"\"\\\".*\\.exe[^\\\"].*\"\"\"\n )\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + } + ], + "risk_score": 47, + "rule_id": "4bd1c1af-79d4-4d37-9efa-6e0240640242", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1564", + "name": "Hide Artifacts", + "reference": "https://attack.mitre.org/techniques/T1564/", + "subtechnique": [ + { + "id": "T1564.004", + "name": "NTFS File Attributes", + "reference": "https://attack.mitre.org/techniques/T1564/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 314 + }, + "id": "4bd1c1af-79d4-4d37-9efa-6e0240640242_314", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_4.json b/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_4.json deleted file mode 100644 index 1bb8d735daa..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_4.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects repeated high-confidence 'BLOCKED' actions coupled with specific violation codes such as 'MISCONDUCT', indicating persistent misuse or attempts to probe the model's ethical boundaries.", - "false_positives": [ - "New model deployments.", - "Testing updates to compliance policies." - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual High Confidence Misconduct Blocks Detected", - "note": "## Triage and analysis\n\n### Investigating Amazon Bedrock Guardrail High Confidence Misconduct Blocks.\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account that queried denied topics and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws_bedrock.invocation-*\n| MV_EXPAND gen_ai.compliance.violation_code\n| MV_EXPAND gen_ai.policy.confidence\n| where gen_ai.policy.action == \"BLOCKED\" and gen_ai.policy.confidence LIKE \"HIGH\" and gen_ai.compliance.violation_code LIKE \"MISCONDUCT\"\n| keep user.id\n| stats high_confidence_blocks = count() by user.id\n| where high_confidence_blocks > 5\n| sort high_confidence_blocks desc\n", - "references": [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" - ], - "risk_score": 73, - "rule_id": "4f855297-c8e0-4097-9d97-d653f7e471c4", - "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", - "severity": "high", - "tags": [ - "Domain: LLM", - "Data Source: AWS Bedrock", - "Data Source: AWS S3", - "Use Case: Policy Violation", - "Mitre Atlas: T0051", - "Mitre Atlas: T0054" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "4f855297-c8e0-4097-9d97-d653f7e471c4_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/52aaab7b-b51c-441a-89ce-4387b3aea886_212.json b/packages/security_detection_engine/kibana/security_rule/52aaab7b-b51c-441a-89ce-4387b3aea886_212.json new file mode 100644 index 00000000000..235dab876f2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/52aaab7b-b51c-441a-89ce-4387b3aea886_212.json @@ -0,0 +1,139 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies unusual instances of rundll32.exe making outbound network connections. This may indicate adversarial Command and Control activity.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.process-*", + "logs-endpoint.events.network-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Unusual Network Connection via RunDLL32", + "note": "## Triage and analysis\n\n### Investigating Unusual Network Connection via RunDLL32\n\nRunDLL32 is a built-in Windows utility and also a vital component used by the operating system itself. The functionality provided by RunDLL32 to execute Dynamic Link Libraries (DLLs) is widely abused by attackers, because it makes it hard to differentiate malicious activity from normal operations.\n\nThis rule looks for external network connections established using RunDLL32 when the utility is being executed with no arguments, which can potentially indicate command and control activity.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate the target host that RunDLL32 is communicating with.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n- Identify the target computer and its role in the IT environment.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "sequence by host.id, process.entity_id with maxspan=1m\n [process where host.os.type == \"windows\" and event.type == \"start\" and process.name : \"rundll32.exe\" and\n (\n process.args_count == 1 and\n\n /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */\n not process.command_line regex~ \"\"\"\\\".*\\.exe[^\\\"].*\"\"\"\n )]\n [network where host.os.type == \"windows\" and process.name : \"rundll32.exe\" and\n not cidrmatch(destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\",\n \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\", \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\",\n \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\", \"224.0.0.0/4\",\n \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\")]\n", + "references": [ + "https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml", + "https://redcanary.com/threat-detection-report/techniques/rundll32/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "52aaab7b-b51c-441a-89ce-4387b3aea886", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Command and Control", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Sysmon" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1218", + "name": "System Binary Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1218/", + "subtechnique": [ + { + "id": "T1218.011", + "name": "Rundll32", + "reference": "https://attack.mitre.org/techniques/T1218/011/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/", + "subtechnique": [ + { + "id": "T1071.001", + "name": "Web Protocols", + "reference": "https://attack.mitre.org/techniques/T1071/001/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 212 + }, + "id": "52aaab7b-b51c-441a-89ce-4387b3aea886_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_1.json b/packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_1.json new file mode 100644 index 00000000000..f76bc678a74 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_1.json @@ -0,0 +1,106 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Command Line Obfuscation via Whitespace Padding", + "note": "## Triage and analysis\n\n### Investigating Command Line Obfuscation via Whitespace Padding\n\nThis rule identifies process execution events where the command line value contains a long sequence of whitespace\ncharacters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections\nby padding their malicious command with unnecessary whitespace characters.\n\n#### Possible investigation steps\n\n- Analyze the command line of the process in question for evidence of malicious code execution.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file\nmodifications, and any spawned child processes.\n- Retrieve the process executable and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.\n - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- Alerts derived from this rule are not inherently malicious. Analysts can dismiss the alert if they don't find enough\nevidence of further suspicious activity.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n attackers could use to reinfect the system.\n- Remove the malicious certificate from the root certificate store.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n", + "query": "FROM logs-* metadata _id, _version, _index \n| where event.category == \"process\" and event.type == \"start\" and event.action != \"fork\"\n// more than 100 spaces in process.command_line\n| eval multi_spaces = LOCATE(process.command_line, space(100)) \n| where multi_spaces > 0 \n| keep user.name, host.id, host.name, process.command_line, process.executable, process.parent.executable\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "auditd_manager", + "version": "^1.18.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "risk_score": 47, + "rule_id": "5a876e0d-d39a-49b9-8ad8-19c9b622203b", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "OS: macOS", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "5a876e0d-d39a-49b9-8ad8-19c9b622203b_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_318.json b/packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_318.json new file mode 100644 index 00000000000..f53ce4d6cff --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_318.json @@ -0,0 +1,207 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched.", + "filters": [ + { + "meta": { + "negate": false + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\Sys?????\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\Sys?????\\\\PrintConfig.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\Sys?????\\\\x5lrs.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\DRIVERS\\\\x64\\\\*.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\DRIVERS\\\\W32X86\\\\*.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\PRTPROCS\\\\x64\\\\*.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\{????????-????-????-????-????????????}\\\\*.dll" + } + } + } + } + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.file-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious PrintSpooler Service Executable File Creation", + "new_terms_fields": [ + "host.id", + "file.path" + ], + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious PrintSpooler Service Executable File Creation\n\nThe Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation.\n\n### Possible investigation steps\n\n- Review the alert details to confirm the presence of a file creation event with the extension \"dll\" associated with the \"spoolsv.exe\" process on a Windows host.\n- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation.\n- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity.\n- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes.\n- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits.\n- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats.\n\n### False positive analysis\n\n- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list.\n- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list.\n- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening.\n- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.\n- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity.\n- Remove the malicious DLL file from the system to prevent re-execution and further exploitation.\n- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary.\n- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.\n- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms.\n- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response.", + "query": "event.category : \"file\" and host.os.type : \"windows\" and event.type : \"creation\" and\n process.name : \"spoolsv.exe\" and file.extension : \"dll\"\n", + "references": [ + "https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/", + "https://www.thezdi.com/blog/2020/7/8/cve-2020-1300-remote-code-execution-through-microsoft-windows-cab-files" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.extension", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Endgame", + "Use Case: Vulnerability", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1068", + "name": "Exploitation for Privilege Escalation", + "reference": "https://attack.mitre.org/techniques/T1068/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 318 + }, + "id": "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_318", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_2.json b/packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_2.json deleted file mode 100644 index 1e54c20c605..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/5f0234fd-7f21-42af-8391-511d5fd11d5c_2.json +++ /dev/null @@ -1,85 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a high number of failed S3 operations from a single source and account (or anonymous account) within a short timeframe. This activity can be indicative of attempting to cause an increase in billing to an account for excessive random operations, cause resource exhaustion, or enumerating bucket names for discovery.", - "false_positives": [ - "Known or internal account IDs or automation" - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS S3 Bucket Enumeration or Brute Force", - "note": "## Triage and analysis\n\n### Investigating AWS S3 Bucket Enumeration or Brute Force\n\nAWS S3 buckets can be be brute forced to cause financial impact against the resource owner. What makes this even riskier is that even private, locked down buckets can still trigger a potential cost, even with an \"Access Denied\", while also being accessible from unauthenticated, anonymous accounts. This also appears to work on several or all [operations](https://docs.aws.amazon.com/cli/latest/reference/s3api/) (GET, PUT, list-objects, etc.). Additionally, buckets are trivially discoverable by default as long as the bucket name is known, making it vulnerable to enumeration for discovery.\n\nAttackers may attempt to enumerate names until a valid bucket is discovered and then pivot to cause financial impact, enumerate for more information, or brute force in other ways to attempt to exfil data.\n\n#### Possible investigation steps\n\n- Examine the history of the operation requests from the same `source.address` and `cloud.account.id` to determine if there is other suspicious activity.\n- Review similar requests and look at the `user.agent` info to ascertain the source of the requests (though do not overly rely on this since it is controlled by the requestor).\n- Review other requests to the same `aws.s3.object.key` as well as other `aws.s3.object.key` accessed by the same `cloud.account.id` or `source.address`.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Validate the activity is not related to planned patches, updates, or network administrator activity.\n- Examine the request parameters. These may indicate the source of the program or the nature of the task being performed when the error occurred.\n - Check whether the error is related to unsuccessful attempts to enumerate or access objects, data, or secrets.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Contact the account owner and confirm whether they are aware of this activity if suspicious.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the `source.address` and `cloud.account.id` - there are some valid operations from within AWS directly that can cause failures and false positives. Additionally, failed automation can also caeuse false positives, but should be identifiable by reviewing the `source.address` and `cloud.account.id`.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n- Check for PutBucketPolicy event actions as well to see if they have been tampered with. While we monitor for denied, a single successful action to add a backdoor into the bucket via policy updates (however they got permissions) may be critical to identify during TDIR.\n\n", - "query": "from logs-aws.cloudtrail*\n| where event.provider == \"s3.amazonaws.com\" and aws.cloudtrail.error_code == \"AccessDenied\"\n| stats failed_requests = count(*) by tls.client.server_name, source.address, cloud.account.id\n // can modify the failed request count or tweak time window to fit environment\n // can add `not cloud.account.id in (KNOWN)` or specify in exceptions\n| where failed_requests > 40\n", - "references": [ - "https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1", - "https://docs.aws.amazon.com/cli/latest/reference/s3api/" - ], - "risk_score": 21, - "rule_id": "5f0234fd-7f21-42af-8391-511d5fd11d5c", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Resources: Investigation Guide", - "Use Case: Log Auditing", - "Tactic: Impact" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1657", - "name": "Financial Theft", - "reference": "https://attack.mitre.org/techniques/T1657/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1580", - "name": "Cloud Infrastructure Discovery", - "reference": "https://attack.mitre.org/techniques/T1580/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0009", - "name": "Collection", - "reference": "https://attack.mitre.org/tactics/TA0009/" - }, - "technique": [ - { - "id": "T1530", - "name": "Data from Cloud Storage", - "reference": "https://attack.mitre.org/techniques/T1530/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "5f0234fd-7f21-42af-8391-511d5fd11d5c_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_5.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_5.json new file mode 100644 index 00000000000..7bb2284c84f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_5.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Invalid Escape Sequences", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Invalid Escape Sequences\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques to evade detection. By inserting invalid escape sequences, attackers can obscure malicious scripts, bypassing static analysis and security tools like AMSI. The detection rule identifies such obfuscation by analyzing script patterns, specifically targeting unusual backtick usage, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script block that triggered the alert. Look for patterns of invalid escape sequences and assess whether they appear intentionally obfuscated.\n- Examine the `file.name` and `file.path` fields to determine the origin and location of the script. This can help identify whether the script is part of a legitimate application or potentially malicious.\n- Check the `host.name` and `agent.id` fields to identify the affected system and the agent responsible for logging the event. This information is crucial for understanding the scope of the potential threat.\n- Analyze the `user.id` field to ascertain which user executed the script. This can provide insights into whether the user has a history of executing suspicious scripts or if their account may be compromised.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related script blocks, which may reveal additional obfuscation or malicious activity.\n- Assess the `count` field to evaluate the extent of obfuscation detected. A higher count may indicate more aggressive obfuscation techniques, warranting further scrutiny.\n\n### False positive analysis\n\n- Scripts from Visual Studio Code's PowerShell extension may trigger false positives due to its shell integration. To handle this, exclude scripts containing the pattern \"$([char]0x1b)]633\" from detection.\n- PowerShell modules with names starting with \"TSS_\" may be flagged incorrectly. Exclude these by adding a condition to ignore files matching the pattern \"TSS_*.psm1\".\n- Legitimate scripts that use backticks for formatting or other non-obfuscation purposes might be detected. Review such scripts and, if verified as safe, add them to an exception list based on their script block ID or file path.\n- Regularly update the exclusion list to reflect changes in legitimate script usage patterns, ensuring that new false positives are addressed promptly.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. Disconnect the host from the network and disable remote access.\n\n- Analyze the script block text and file path to identify the source and nature of the obfuscated script. Determine if the script is part of a larger attack or if other systems are affected.\n\n- Remove or quarantine the identified malicious script and any associated files from the host. Ensure that all remnants of the obfuscated code are eliminated to prevent re-execution.\n\n- Conduct a thorough scan of the host using updated antivirus and antimalware tools to detect and remove any additional threats or indicators of compromise.\n\n- Review and update PowerShell execution policies and security settings to restrict the execution of scripts with invalid escape sequences. Implement stricter controls to prevent similar obfuscation techniques.\n\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and monitoring. Provide detailed logs and findings to assist in understanding the scope and impact of the threat.\n\n- Implement enhanced logging and monitoring for PowerShell activities across the network to detect and respond to similar obfuscation attempts promptly. Use the identified patterns to refine detection capabilities.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*`*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.name,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least 10 times\n| where Esql.script_block_pattern_count >= 10\n\n| where file.name not like \"TSS_*.psm1\"\n // ESQL requires this condition, otherwise it only returns matches where file.name exists.\n or file.name is null\n\n// VSCode Shell integration\n| where not powershell.file.script_block_text like \"*$([char]0x1b)]633*\"\n\n| where not file.directory == \"C:\\\\Program Files\\\\MVPSI\\\\JAMS\\\\Agent\\\\Temp\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_121.json b/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_121.json new file mode 100644 index 00000000000..0721d93b20e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_121.json @@ -0,0 +1,141 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.network-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Connection to Commonly Abused Web Services", + "note": "## Triage and analysis\n\n### Investigating Connection to Commonly Abused Web Services\n\nAdversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise.\n\nThis rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n> This investigation guide uses the [Investigate Markdown Plugin](https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html) introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n - !{investigate{\"label\":\"Alerts associated with the user in the last 48h\",\"providers\":[[{\"excluded\":false,\"field\":\"event.kind\",\"queryType\":\"phrase\",\"value\":\"signal\",\"valueType\":\"string\"},{\"excluded\":false,\"field\":\"user.id\",\"queryType\":\"phrase\",\"value\":\"{{user.id}}\",\"valueType\":\"string\"}]],\"relativeFrom\":\"now-48h/h\",\"relativeTo\":\"now\"}}\n - !{investigate{\"label\":\"Alerts associated with the host in the last 48h\",\"providers\":[[{\"excluded\":false,\"field\":\"event.kind\",\"queryType\":\"phrase\",\"value\":\"signal\",\"valueType\":\"string\"},{\"excluded\":false,\"field\":\"host.name\",\"queryType\":\"phrase\",\"value\":\"{{host.name}}\",\"valueType\":\"string\"}]],\"relativeFrom\":\"now-48h/h\",\"relativeTo\":\"now\"}}\n- Verify whether the digital signature exists in the executable.\n- Identify the operation type (upload, download, tunneling, etc.).\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - !{investigate{\"label\":\"Investigate the Subject Process Network Events\",\"providers\":[[{\"excluded\":false,\"field\":\"event.category\",\"queryType\":\"phrase\",\"value\":\"network\",\"valueType\":\"string\"},{\"excluded\":false,\"field\":\"process.entity_id\",\"queryType\":\"phrase\",\"value\":\"{{process.entity_id}}\",\"valueType\":\"string\"}]]}}\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This rule has a high chance to produce false positives because it detects communication with legitimate services. Noisy false positives can be added as exceptions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "network where host.os.type == \"windows\" and network.protocol == \"dns\" and\n process.name != null and user.id not in (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\") and\n /* Add new WebSvc domains here */\n dns.question.name :\n (\n \"raw.githubusercontent.*\",\n \"pastebin.*\",\n \"paste4btc.com\",\n \"paste.ee\",\n \"ghostbin.com\",\n \"drive.google.com\",\n \"?.docs.live.net\",\n \"api.dropboxapi.*\",\n \"content.dropboxapi.*\",\n \"dl.dropboxusercontent.*\",\n \"api.onedrive.com\",\n \"*.onedrive.org\",\n \"onedrive.live.com\",\n \"filebin.net\",\n \"*.ngrok.io\",\n \"ngrok.com\",\n \"*.portmap.*\",\n \"*serveo.net\",\n \"*localtunnel.me\",\n \"*pagekite.me\",\n \"*localxpose.io\",\n \"*notabug.org\",\n \"rawcdn.githack.*\",\n \"paste.nrecom.net\",\n \"zerobin.net\",\n \"controlc.com\",\n \"requestbin.net\",\n \"slack.com\",\n \"api.slack.com\",\n \"slack-redir.net\",\n \"slack-files.com\",\n \"cdn.discordapp.com\",\n \"discordapp.com\",\n \"discord.com\",\n \"apis.azureedge.net\",\n \"cdn.sql.gg\",\n \"?.top4top.io\",\n \"top4top.io\",\n \"www.uplooder.net\",\n \"*.cdnmegafiles.com\",\n \"transfer.sh\",\n \"gofile.io\",\n \"updates.peer2profit.com\",\n \"api.telegram.org\",\n \"t.me\",\n \"meacz.gq\",\n \"rwrd.org\",\n \"*.publicvm.com\",\n \"*.blogspot.com\",\n \"api.mylnikov.org\",\n \"file.io\",\n \"stackoverflow.com\",\n \"*files.1drv.com\",\n \"api.anonfile.com\",\n \"*hosting-profi.de\",\n \"ipbase.com\",\n \"ipfs.io\",\n \"*up.freeo*.space\",\n \"api.mylnikov.org\",\n \"script.google.com\",\n \"script.googleusercontent.com\",\n \"api.notion.com\",\n \"graph.microsoft.com\",\n \"*.sharepoint.com\",\n \"mbasic.facebook.com\",\n \"login.live.com\",\n \"api.gofile.io\",\n \"api.anonfiles.com\",\n \"api.notion.com\",\n \"api.trello.com\",\n \"gist.githubusercontent.com\",\n \"files.pythonhosted.org\",\n \"g.live.com\",\n \"*.zulipchat.com\",\n \"webhook.site\",\n \"run.mocky.io\",\n \"mockbin.org\", \n \"www.googleapis.com\", \n \"googleapis.com\",\n \"global.rel.tunnels.api.visualstudio.com\",\n \"*.devtunnels.ms\", \n \"api.github.com\") and\n \n /* Insert noisy false positives here */\n not (\n (\n process.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Windows\\\\system32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\WWAHost.exe\",\n \"?:\\\\Windows\\\\System32\\\\smartscreen.exe\",\n \"?:\\\\Windows\\\\System32\\\\MicrosoftEdgeCP.exe\",\n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\BraveSoftware\\\\*\\\\Application\\\\brave.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Vivaldi\\\\Application\\\\vivaldi.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Opera*\\\\opera.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Fiddler\\\\Fiddler.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Microsoft VS Code\\\\Code.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Microsoft\\\\OneDrive\\\\OneDrive.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\PowerToys\\\\PowerToys.exe\",\n \"?:\\\\Windows\\\\system32\\\\mobsync.exe\",\n \"?:\\\\Windows\\\\SysWOW64\\\\mobsync.exe\", \n \"?:\\\\Windows\\\\System32\\\\wsl.exe\", \n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\"\n )\n ) or\n \n /* Discord App */\n (process.name : \"Discord.exe\" and (process.code_signature.subject_name : \"Discord Inc.\" and\n process.code_signature.trusted == true) and dns.question.name : (\"discord.com\", \"cdn.discordapp.com\", \"discordapp.com\")\n ) or \n\n /* MS Sharepoint */\n (process.name : \"Microsoft.SharePoint.exe\" and (process.code_signature.subject_name : \"Microsoft Corporation\" and\n process.code_signature.trusted == true) and dns.question.name : \"onedrive.live.com\"\n ) or \n\n /* Firefox */\n (process.name : \"firefox.exe\" and (process.code_signature.subject_name : \"Mozilla Corporation\" and\n process.code_signature.trusted == true)\n ) or \n\n /* Dropbox */\n (process.name : \"Dropbox.exe\" and (process.code_signature.subject_name : \"Dropbox, Inc\" and\n process.code_signature.trusted == true) and dns.question.name : (\"api.dropboxapi.com\", \"*.dropboxusercontent.com\")\n ) or \n\n /* Obsidian - Plugins are stored on raw.githubusercontent.com */\n (process.name : \"Obsidian.exe\" and (process.code_signature.subject_name : \"Dynalist Inc\" and\n process.code_signature.trusted == true) and dns.question.name : \"raw.githubusercontent.com\"\n ) or \n\n /* WebExperienceHostApp */\n (process.name : \"WebExperienceHostApp.exe\" and (process.code_signature.subject_name : \"Microsoft Windows\" and\n process.code_signature.trusted == true) and dns.question.name : (\"onedrive.live.com\", \"skyapi.onedrive.live.com\")\n ) or\n\n /* IntelliJ IDEA connecting to raw.githubusercontent.com m */\n (process.code_signature.subject_name : \"JetBrains s.r.o.\" and\n process.code_signature.trusted == true and dns.question.name : \"raw.githubusercontent.com\") or \n\n (process.code_signature.subject_name : \"Microsoft *\" and process.code_signature.trusted == true and\n dns.question.name : (\"*.sharepoint.com\", \"graph.microsoft.com\", \"g.live.com\", \"login.live.com\", \"login.live.com\")) or\n\n (process.code_signature.trusted == true and\n process.code_signature.subject_name :\n (\"Johannes Schindelin\",\n \"Redis Inc.\",\n \"Slack Technologies, LLC\",\n \"Cisco Systems, Inc.\",\n \"Dropbox, Inc\",\n \"Amazon.com Services LLC\", \n \"Island Technology Inc.\", \n \"GitHub, Inc.\", \n \"Red Hat, Inc\"))\n )\n", + "references": [ + "https://www.elastic.co/security-labs/operation-bleeding-bear", + "https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "dns.question.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "network.protocol", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.subject_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.trusted", + "type": "boolean" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "66883649-f908-4a5b-a1e0-54090a1d3a32", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Resources: Investigation Guide", + "Data Source: Elastic Defend" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1102", + "name": "Web Service", + "reference": "https://attack.mitre.org/techniques/T1102/" + }, + { + "id": "T1568", + "name": "Dynamic Resolution", + "reference": "https://attack.mitre.org/techniques/T1568/", + "subtechnique": [ + { + "id": "T1568.002", + "name": "Domain Generation Algorithms", + "reference": "https://attack.mitre.org/techniques/T1568/002/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1567", + "name": "Exfiltration Over Web Service", + "reference": "https://attack.mitre.org/techniques/T1567/", + "subtechnique": [ + { + "id": "T1567.001", + "name": "Exfiltration to Code Repository", + "reference": "https://attack.mitre.org/techniques/T1567/001/" + }, + { + "id": "T1567.002", + "name": "Exfiltration to Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1567/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 121 + }, + "id": "66883649-f908-4a5b-a1e0-54090a1d3a32_121", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_2.json b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_2.json deleted file mode 100644 index fb6a73f6216..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_2.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Port Scanning Activity from Compromised Host", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Port Scanning Activity from Compromised Host\n\nPort scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent.\n\n### Possible investigation steps\n\n- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields.\n- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host.\n- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious.\n- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in.\n- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations.\n- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation.\n\n### False positive analysis\n\n- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools.\n- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names.\n- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables.\n- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers.\n- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures.\n\n### Response and remediation\n\n- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement.\n- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities.\n- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts.\n- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited.\n- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access.\n- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), port_count = count_distinct(destination.port), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.ip\n| where agent_count == 1 and port_count > 100\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 21, - "rule_id": "6b341d03-1d63-41ac-841a-2009c86959ca", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1046", - "name": "Network Service Discovery", - "reference": "https://attack.mitre.org/techniques/T1046/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "6b341d03-1d63-41ac-841a-2009c86959ca_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_1.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_1.json deleted file mode 100644 index c1458dcd696..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential PowerShell Obfuscation via Special Character Overuse", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\.]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of numbers and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 75%+ proportion of numbers\n| WHERE proportion > 0.75\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "risk_score": 21, - "rule_id": "6ddb6c33-00ce-4acd-832a-24b251512023", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "6ddb6c33-00ce-4acd-832a-24b251512023_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ea41894-66c3-4df7-ad6b-2c5074eb3df8_214.json b/packages/security_detection_engine/kibana/security_rule/6ea41894-66c3-4df7-ad6b-2c5074eb3df8_214.json new file mode 100644 index 00000000000..7bfca2cbd0e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ea41894-66c3-4df7-ad6b-2c5074eb3df8_214.json @@ -0,0 +1,131 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies suspicious instances of the Windows Error Reporting process (WerFault.exe or Wermgr.exe) with matching command-line and process executable values performing outgoing network connections. This may be indicative of a masquerading attempt to evade suspicious child process behavior detections.", + "false_positives": [ + "Legit Application Crash with rare Werfault commandline value" + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.process-*", + "logs-endpoint.events.network-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Windows Error Manager Masquerading", + "note": "## Triage and analysis\n\n### Investigating Potential Windows Error Manager Masquerading\n\nBy examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation.\n\nThis rule identifies a potential malicious process masquerading as `wermgr.exe` or `WerFault.exe`, by looking for a process creation with no arguments followed by a network connection.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "sequence by host.id, process.entity_id with maxspan = 5s\n [process where host.os.type == \"windows\" and event.type:\"start\" and process.name : (\"wermgr.exe\", \"WerFault.exe\") and\n (process.args_count == 1 and\n /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */\n not process.command_line regex~ \"\"\"\\\".*\\.exe[^\\\"].*\"\"\")]\n [network where host.os.type == \"windows\" and process.name : (\"wermgr.exe\", \"WerFault.exe\") and network.protocol != \"dns\" and\n network.direction : (\"outgoing\", \"egress\") and destination.ip !=\"::1\" and destination.ip !=\"127.0.0.1\"\n ]\n", + "references": [ + "https://twitter.com/SBousseaden/status/1235533224337641473", + "https://www.hexacorn.com/blog/2019/09/20/werfault-command-line-switches-v0-1/", + "https://app.any.run/tasks/26051d84-b68e-4afb-8a9a-76921a271b81/", + "https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "network.direction", + "type": "keyword" + }, + { + "ecs": true, + "name": "network.protocol", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6ea41894-66c3-4df7-ad6b-2c5074eb3df8", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Sysmon" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1036", + "name": "Masquerading", + "reference": "https://attack.mitre.org/techniques/T1036/", + "subtechnique": [ + { + "id": "T1036.005", + "name": "Match Legitimate Resource Name or Location", + "reference": "https://attack.mitre.org/techniques/T1036/005/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 214 + }, + "id": "6ea41894-66c3-4df7-ad6b-2c5074eb3df8_214", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_2.json b/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_2.json deleted file mode 100644 index db4cf2daafa..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_2.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.", - "false_positives": [ - "Legitimate misunderstanding by users or overly strict policies" - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Bedrock Detected Multiple Validation Exception Errors by a Single User", - "query": "from logs-aws_bedrock.invocation-*\n// truncate the timestamp to a 1-minute window\n| eval target_time_window = DATE_TRUNC(1 minutes, @timestamp)\n| where gen_ai.response.error_code == \"ValidationException\"\n| keep user.id, gen_ai.request.model.id, cloud.account.id, gen_ai.response.error_code, target_time_window\n// count the number of users causing validation errors within a 1 minute window\n| stats total_denials = count(*) by target_time_window, user.id, cloud.account.id\n| where total_denials > 3\n", - "references": [ - "https://atlas.mitre.org/techniques/AML.T0015", - "https://atlas.mitre.org/techniques/AML.T0034", - "https://atlas.mitre.org/techniques/AML.T0046", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" - ], - "risk_score": 73, - "rule_id": "725a048a-88c5-4fc7-8677-a44fc0031822", - "setup": "## Setup\n\nThis rule requires that AWS Bedrock Integration be configured. For more information, see the AWS Bedrock integration documentation:\n\nhttps://www.elastic.co/docs/current/integrations/aws_bedrock\n", - "severity": "high", - "tags": [ - "Domain: LLM", - "Data Source: AWS", - "Data Source: AWS Bedrock", - "Data Source: AWS S3", - "Use Case: Policy Violation", - "Mitre Atlas: T0015", - "Mitre Atlas: T0034", - "Mitre Atlas: T0046" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "725a048a-88c5-4fc7-8677-a44fc0031822_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_2.json b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_2.json deleted file mode 100644 index b6b22279659..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_2.json +++ /dev/null @@ -1,94 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Malware-Driven SSH Brute Force Attempt", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Malware-Driven SSH Brute Force Attempt\n\nSSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths.\n- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information.\n- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations.\n- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise.\n- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware.\n- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts.\n\n### False positive analysis\n\n- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list.\n- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule.\n- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers.\n- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions.\n\n### Response and remediation\n\n- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems.\n- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise.\n- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software.\n- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security.\n- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats.\n- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly.\n- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure.\n", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and\n destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and not\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.port\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 47, - "rule_id": "77122db4-5876-4127-b91b-6c179eb21f88", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Impact", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1496", - "name": "Resource Hijacking", - "reference": "https://attack.mitre.org/techniques/T1496/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "77122db4-5876-4127-b91b-6c179eb21f88_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_3.json deleted file mode 100644 index 983adc9c55c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_3.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.", - "false_positives": [ - "Administrators may legitimately access, delete, and replace objects in S3 buckets. Ensure that the sequence of events is not part of a legitimate operation before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential AWS S3 Bucket Ransomware Note Uploaded", - "note": "\n## Triage and Analysis\n\n### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded\n\nThis rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `PutObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the ransom note was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Inspect the Ransom Note**: Review the `aws.cloudtrail.request_parameters` for the `PutObject` action to identify the characteristics of the uploaded ransom note. Look for common ransomware file extensions such as `.txt`, `.note`, `.ransom`, or `.html`.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects before placing the ransom note.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `PutObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the upload was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the activity was unauthorized, remove the uploaded ransom notes from the S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `PutObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [AWS S3 Ransomware Batch Deletion](https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", - "query": "from logs-aws.cloudtrail-*\n\n// any successful uploads via S3 API requests\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutObject\"\n and event.outcome == \"success\"\n\n// abstract object name from API request parameters\n| dissect aws.cloudtrail.request_parameters \"%{?ignore_values}key=%{object_name}}\"\n\n// regex on common ransomware note extensions\n| where object_name rlike \"(.*)(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue)(.*)\"\n and not object_name rlike \"(.*)(AWSLogs|CloudTrail|access-logs)(.*)\"\n\n// keep relevant fields\n| keep tls.client.server_name, aws.cloudtrail.user_identity.arn, object_name\n\n// aggregate by S3 bucket, resource and object name\n| stats note_upload_count = count(*) by tls.client.server_name, aws.cloudtrail.user_identity.arn, object_name\n\n// filter for single occurrence to eliminate common upload operations\n| where note_upload_count == 1\n", - "references": [ - "https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf", - "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/", - "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" - ], - "risk_score": 47, - "rule_id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce", - "setup": "AWS S3 data types need to be enabled in the CloudTrail trail configuration.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Use Case: Threat Detection", - "Tactic: Impact" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1485", - "name": "Data Destruction", - "reference": "https://attack.mitre.org/techniques/T1485/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_313.json b/packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_313.json new file mode 100644 index 00000000000..22ab4cc0f42 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_313.json @@ -0,0 +1,124 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies attempts to disable PowerShell Script Block Logging via registry modification. Attackers may disable this logging to conceal their activities in the host and evade detection.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "PowerShell Script Block Logging Disabled", + "note": "## Triage and analysis\n\n### Investigating PowerShell Script Block Logging Disabled\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making it available in various environments and creating an attractive way for attackers to execute code.\n\nPowerShell Script Block Logging is a feature of PowerShell that records the content of all script blocks that it processes, giving defenders visibility of PowerShell scripts and sequences of executed commands.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check whether it makes sense for the user to use PowerShell to complete tasks.\n- Investigate if PowerShell scripts were run after logging was disabled.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Related rules\n\n- PowerShell Suspicious Discovery Related Windows API Functions - 61ac3638-40a3-44b2-855a-985636ca985e\n- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889\n- PowerShell Suspicious Script with Audio Capture Capabilities - 2f2f4939-0b34-40c2-a0a3-844eb7889f43\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad\n- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a\n- PowerShell Suspicious Script with Screenshot Capabilities - 959a7353-1129-4aa7-9084-30746b256a70\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.path : (\n \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows\\\\PowerShell\\\\ScriptBlockLogging\\\\EnableScriptBlockLogging\",\n \"\\\\REGISTRY\\\\MACHINE\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows\\\\PowerShell\\\\ScriptBlockLogging\\\\EnableScriptBlockLogging\",\n \"MACHINE\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows\\\\PowerShell\\\\ScriptBlockLogging\\\\EnableScriptBlockLogging\"\n ) and registry.data.strings : (\"0\", \"0x00000000\") and\n not (\n process.executable : (\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\DeviceEnroller.exe\",\n \"?:\\\\Windows\\\\system32\\\\omadmclient.exe\",\n \"?:\\\\Program Files (x86)\\\\N-able Technologies\\\\AutomationManagerAgent\\\\AutomationManager.AgentService.exe\"\n ) and user.id == \"S-1-5-18\"\n )\n", + "references": [ + "https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "818e23e6-2094-4f0e-8c01-22d30f3506c6", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + }, + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.002", + "name": "Disable Windows Event Logging", + "reference": "https://attack.mitre.org/techniques/T1562/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 313 + }, + "id": "818e23e6-2094-4f0e-8c01-22d30f3506c6_313", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_207.json b/packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_207.json new file mode 100644 index 00000000000..76e7d98142c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_207.json @@ -0,0 +1,131 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell.", + "from": "now-9m", + "index": [ + "logs-crowdstrike.fdr*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Windows Powershell Arguments", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Windows Powershell Arguments\n\nPowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent.\n- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source.\n- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString.\n- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised.\n- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise.\n- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected.\n\n### False positive analysis\n\n- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist.\n- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule.\n- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule.\n- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts.\n- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.\n- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts.\n- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity.\n- Restore any affected files or system components from known good backups to ensure system integrity and functionality.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.\n- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : \"powershell.exe\" and\n\n not (\n user.id == \"S-1-5-18\" and\n /* Don't apply the user.id exclusion to Sysmon for compatibility */\n not event.dataset : (\"windows.sysmon_operational\", \"windows.sysmon\")\n ) and\n\n (\n process.command_line : (\n \"*^*^*^*^*^*^*^*^*^*\",\n \"*`*`*`*`*\",\n \"*+*+*+*+*+*+*\",\n \"*[char[]](*)*-join*\",\n \"*Base64String*\",\n \"*[*Convert]*\",\n \"*.Compression.*\",\n \"*-join($*\",\n \"*.replace*\",\n \"*MemoryStream*\",\n \"*WriteAllBytes*\",\n \"* -enc *\",\n \"* -ec *\",\n \"* /e *\",\n \"* /enc *\",\n \"* /ec *\",\n \"*WebClient*\",\n \"*DownloadFile*\",\n \"*DownloadString*\",\n \"* iex*\",\n \"* iwr*\",\n \"* aQB3AHIAIABpA*\",\n \"*Reflection.Assembly*\",\n \"*Assembly.GetType*\",\n \"*$env:temp\\\\*start*\",\n \"*powercat*\",\n \"*nslookup -q=txt*\",\n \"*$host.UI.PromptForCredential*\",\n \"*Net.Sockets.TCPClient*\",\n \"*curl *;Start*\",\n \"powershell.exe \\\"<#*\",\n \"*ssh -p *\",\n \"*http*|iex*\",\n \"*@SSL\\\\DavWWWRoot\\\\*.ps1*\",\n \"*.lnk*.Seek(0x*\",\n \"*[string]::join(*\",\n \"*[Array]::Reverse($*\",\n \"* hidden $(gc *\",\n \"*=wscri& set*\",\n \"*http'+'s://*\",\n \"*.content|i''Ex*\",\n \"*//:sptth*\",\n \"*//:ptth*\",\n \"*h''t''t''p*\",\n \"*'tp'':''/'*\",\n \"*$env:T\\\"E\\\"MP*\",\n \"*;cmd /c $?\",\n \"*s''t''a''r*\",\n \"*$*=Get-Content*AppData*.SubString(*$*\",\n \"*=cat *AppData*.substring(*);*$*\",\n \"*-join'';*|powershell*\",\n \"*.Content;sleep *|powershell*\",\n \"*h\\''t\\''tp:\\''*\",\n \"*-e aQB3AHIAIABp*\",\n \"*iwr *https*).Content*\",\n \"*$env:computername*http*\",\n \"*;InVoKe-ExpRESsIoN $COntent.CONTENt;*\",\n \"*WebClient*example.com*\",\n \"*=iwr $*;iex $*\"\n ) or\n\n (process.args : \"-c\" and process.args : \"&{'*\") or\n\n (process.args : \"-Outfile\" and process.args : \"Start*\") or\n\n (process.args : \"-bxor\" and process.args : \"0x*\") or\n\n process.args : \"$*$*;set-alias\" or\n\n (\n process.parent.name : (\"explorer.exe\", \"cmd.exe\") and\n process.command_line : (\"*-encodedCommand*\", \"*Invoke-webrequest*\", \"*WebClient*\", \"*Reflection.Assembly*\"))\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^1.51.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "83bf249e-4348-47ba-9741-1202a09556ad", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Windows Security Event Logs", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 207 + }, + "id": "83bf249e-4348-47ba-9741-1202a09556ad_207", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_2.json b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_2.json deleted file mode 100644 index f4a142591e8..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_2.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Subnet Scanning Activity from Compromised Host", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Subnet Scanning Activity from Compromised Host\n\nSubnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections.\n- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external.\n- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access.\n- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host.\n- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes.\n\n### False positive analysis\n\n- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list.\n- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID.\n- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved.\n- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID.\n- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID.\n\n### Response and remediation\n\n- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker.\n- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities.\n- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed.\n- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists.\n- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps.\n- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise.\n- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected.\n", - "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), dest_count = count_distinct(destination.ip), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable\n| where agent_count == 1 and dest_count > 250\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 21, - "rule_id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1046", - "name": "Network Service Discovery", - "reference": "https://attack.mitre.org/techniques/T1046/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_1.json b/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_1.json deleted file mode 100644 index 2e4b2e54d12..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_1.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "building_block_type": "default", - "description": "This rule detects unusual file creations from a web server parent process. Adversaries may attempt to create files from a web server parent process to establish persistence, execute malicious scripts, or exfiltrate data. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual File Creation by Web Server", - "query": "from logs-endpoint.events.file-*\n| keep @timestamp, host.os.type, event.type, event.action, user.name, user.id, process.name, process.executable, file.path, agent.id\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"change\" and event.action in (\"rename\", \"creation\") and (\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\")\n ) and (\n process.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.name like \"php-*\" or\n process.name like \"python*\" or\n process.name like \"ruby*\" or\n process.name like \"perl*\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id) by process.executable, file.path\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "risk_score": 47, - "rule_id": "894b7cc9-040b-427c-aca5-36b40d3667bf", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Rule Type: BBR" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1505", - "name": "Server Software Component", - "reference": "https://attack.mitre.org/techniques/T1505/", - "subtechnique": [ - { - "id": "T1505.003", - "name": "Web Shell", - "reference": "https://attack.mitre.org/techniques/T1505/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "894b7cc9-040b-427c-aca5-36b40d3667bf_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_2.json b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_2.json deleted file mode 100644 index 3fbfbb895bc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_2.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual Command Execution from Web Server Parent", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Command Execution from Web Server Parent\n\nWeb servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent.\n- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise.\n- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited.\n- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user.\n- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack.\n- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue.\n\n### False positive analysis\n\n- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule.\n- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs.\n- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables.\n- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule.\n- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation.\n\n- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes.\n\n- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies.\n\n- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches.\n\n- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration.\n\n- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections.\n\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps.\n", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.command_line, process.parent.executable, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n) and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.command_line like \"* -c *\" and\n not (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.working_directory like \"/vscode/vscode-server/*\" or\n process.parent.executable like \"/vscode/vscode-server/*\" or\n process.parent.executable == \"/usr/bin/xfce4-terminal\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.command_line, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 47, - "rule_id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1505", - "name": "Server Software Component", - "reference": "https://attack.mitre.org/techniques/T1505/", - "subtechnique": [ - { - "id": "T1505.003", - "name": "Web Shell", - "reference": "https://attack.mitre.org/techniques/T1505/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_2.json b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_2.json deleted file mode 100644 index 1b09d1dd712..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_2.json +++ /dev/null @@ -1,59 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule leverages ES|QL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual File Transfer Utility Launched", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual File Transfer Utility Launched\n\nFile transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious.\n- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity.\n- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context.\n- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution.\n- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule.\n\n### False positive analysis\n\n- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs.\n- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives.\n- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts.\n- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration.\n- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access.\n- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers.\n- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer.\n- Change credentials and access keys associated with the compromised system to prevent further unauthorized access.\n- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems.\n- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system.\n- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.\n", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\n process.name in (\"scp\", \"ftp\", \"sftp\", \"vsftpd\", \"sftp-server\", \"rsync\")\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.parent.executable, process.command_line\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 21, - "rule_id": "8eeeda11-dca6-4c3e-910f-7089db412d1c", - "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Exfiltration", - "Tactic: Execution", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0010", - "name": "Exfiltration", - "reference": "https://attack.mitre.org/tactics/TA0010/" - }, - "technique": [] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "8eeeda11-dca6-4c3e-910f-7089db412d1c_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_203.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_203.json deleted file mode 100644 index 21bdcdb26c8..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_203.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", - "false_positives": [ - "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", - "Shared systems such as Kiosks and conference room computers may be used by multiple users." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Multiple Okta User Authentication Events with Client Address", - "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Client Address\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\nSince this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action == \"user.session.start\" OR event.action RLIKE \"user\\\\.authentication(.*)\")\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP okta.client.ip, okta.actor.alternate_id, okta.actor.id, event.action, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count > 5\n| SORT\n source_auth_count DESC\n", - "references": [ - "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 21, - "rule_id": "94e734c0-2cda-11ef-84e1-f661ea17fbce", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - }, - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.004", - "name": "Credential Stuffing", - "reference": "https://attack.mitre.org/techniques/T1110/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 203 - }, - "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_203", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_203.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_203.json deleted file mode 100644 index 8e28a98d21d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_203.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", - "false_positives": [ - "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", - "Shared systems such as Kiosks and conference room computers may be used by multiple users." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Multiple Okta User Authentication Events with Same Device Token Hash", - "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Same Device Token Hash\n\nThis rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.dt_hash != \"-\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.actor.id, okta.actor.alternate_id, okta.outcome.reason\n| STATS\n target_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id\n| WHERE\n target_auth_count > 20\n| SORT\n target_auth_count DESC\n", - "references": [ - "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 21, - "rule_id": "95b99adc-2cda-11ef-84e1-f661ea17fbce", - "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - }, - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.004", - "name": "Credential Stuffing", - "reference": "https://attack.mitre.org/techniques/T1110/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 203 - }, - "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_203", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_2.json b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_2.json deleted file mode 100644 index 120126ac25c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_2.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual Process Spawned from Web Server Parent", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Process Spawned from Web Server Parent\n\nWeb servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment.\n- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories.\n- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account.\n- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced.\n- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise.\n- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited.\n\n### False positive analysis\n\n- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening.\n- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts.\n- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories.\n- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows.\n- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.\n- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations.\n- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary.\n- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup.\n- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access.\n- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.\n", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.executable, process.command_line, process.parent.executable, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\" or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n) and\nnot (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.parent.executable like \"/vscode/vscode-server/*\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 47, - "rule_id": "976b2391-413f-4a94-acb4-7911f3803346", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1505", - "name": "Server Software Component", - "reference": "https://attack.mitre.org/techniques/T1505/", - "subtechnique": [ - { - "id": "T1505.003", - "name": "Web Shell", - "reference": "https://attack.mitre.org/techniques/T1505/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "976b2391-413f-4a94-acb4-7911f3803346_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_4.json b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_4.json deleted file mode 100644 index 395634e3f55..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_4.json +++ /dev/null @@ -1,102 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target user." - ], - "from": "now-6m", - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "user_agent.original", - "target.userName", - "event.action", - "policyName", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters" - ] - }, - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to User", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to User\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachUserPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user for privilege escalation or another user as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachUserPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachUserPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?userName}=%{target.userName}}\"\n| where policyName == \"AdministratorAccess\"\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n policyName,\n target.userName,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.user_identity.arn,\n related.user,\n user_agent.original,\n user.name,\n source.address\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "9aa4be8d-5828-417d-9f54-7cd304571b24", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "9aa4be8d-5828-417d-9f54-7cd304571b24_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_1.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_1.json deleted file mode 100644 index 4faf0482ee4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Dynamic IEX Reconstruction via Method String Access", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|SubString|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^2.5.0" - } - ], - "risk_score": 21, - "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "9f432a8b-9588-4550-838e-1f77285580d3_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_5.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_5.json new file mode 100644 index 00000000000..d8c7a7c9d85 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_5.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Dynamic IEX Reconstruction via Method String Access", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Dynamic IEX Reconstruction via Method String Access\n\nPowerShell's flexibility allows dynamic command execution, which adversaries exploit by obfuscating commands like Invoke-Expression (IEX). They manipulate method strings to reconstruct IEX, evading static detection. The detection rule identifies scripts using this obfuscation by analyzing patterns in method string access, flagging suspicious activity for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script that triggered the alert. Look for any suspicious patterns or obfuscation techniques.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and user.id fields to identify the machine and user account involved in executing the script, which can help assess whether the activity aligns with expected behavior.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other PowerShell activities on the host, providing a broader view of the script's execution context.\n- Investigate the agent.id field to verify the endpoint's security posture and ensure that it is up-to-date with the latest security patches and configurations.\n\n### False positive analysis\n\n- Scripts with legitimate use of string manipulation methods like IndexOf or SubString may trigger false positives if they are part of complex PowerShell scripts used in administrative tasks. To manage this, review the context of the script and consider adding exceptions for known safe scripts or users.\n- Automated scripts from trusted software that perform extensive string operations for configuration or data processing might be flagged. Identify these scripts and exclude them by their script block ID or file path to prevent unnecessary alerts.\n- Development environments where PowerShell is used for testing or debugging purposes may generate alerts due to frequent use of string manipulation. Implement exclusions based on host names or user IDs associated with these environments to reduce noise.\n- Security tools or monitoring solutions that use PowerShell for log analysis or system checks might inadvertently match the detection pattern. Verify the source of the script and whitelist these tools by agent ID or specific script characteristics.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and script block ID from the alert to understand the scope and intent of the obfuscation technique used.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any additional threats.\n- Restore the affected system from a known good backup if the integrity of the system is compromised and cannot be assured.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n| where not (\n file.directory like \"C:\\\\\\\\Program Files\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\" or\n file.directory like \"C:\\\\\\\\Users\\\\\\\\*\\\\\\\\Documents\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "9f432a8b-9588-4550-838e-1f77285580d3_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_3.json b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_3.json deleted file mode 100644 index 40aad3ce14c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_3.json +++ /dev/null @@ -1,59 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data.", - "false_positives": [ - "Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS S3 Object Encryption Using External KMS Key", - "note": "\n## Triage and analysis\n\n### Investigating AWS S3 Object Encryption Using External KMS Key\n\nThis rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data.\nThis rule uses [ES|QL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule) to look for use of the `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the object was copied. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions.\n- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n\n### Response and Remediation:\n\n- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n// any successful copy event\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"CopyObject\"\n and event.outcome == \"success\"\n\n// abstract key account id, key id, encrypted object bucket name and object name\n| dissect aws.cloudtrail.request_parameters \"{%{?bucketName}=%{target.bucketName},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{key.account.id}:%{?key}/%{keyId},%{?Host}=%{?tls.client.server_name},%{?x-amz-server-side-encryption}=%{?server-side-encryption},%{?x-amz-copy-source}=%{?bucket.objectName},%{?key}=%{target.objectName}}\"\n\n// filter for s3 objects whose account id is different from the encryption key's account id\n// add exceptions based on key.account.id or keyId for known external accounts or encryption keys\n| where cloud.account.id != key.account.id\n\n// keep relevant fields\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, target.bucketName, key.account.id, keyId, target.objectName\n", - "references": [ - "https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/", - "https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/", - "https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/", - "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" - ], - "risk_score": 47, - "rule_id": "ab8f074c-5565-4bc4-991c-d49770e19fc9", - "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Data Source: AWS KMS", - "Use Case: Threat Detection", - "Tactic: Impact", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "T1486", - "name": "Data Encrypted for Impact", - "reference": "https://attack.mitre.org/techniques/T1486/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "ab8f074c-5565-4bc4-991c-d49770e19fc9_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_4.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_4.json new file mode 100644 index 00000000000..243f0e7039f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Dynamic IEX Reconstruction via Environment Variables", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential Dynamic IEX Reconstruction via Environment Variables\n\nPowerShell's Invoke-Expression (IEX) command is a powerful tool for executing strings as code, often exploited by attackers to run obfuscated scripts. Adversaries may dynamically reconstruct IEX using environment variables to evade static detection. The detection rule identifies scripts that manipulate environment variables to form IEX commands, focusing on patterns of character slicing and joining, which are indicative of obfuscation techniques. By analyzing script length and specific patterns, the rule effectively flags potential misuse, aiding in defense against such evasion tactics.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on how environment variables are manipulated to reconstruct the IEX command.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context on whether the activity is expected or suspicious.\n- Analyze the user.id and agent.id fields to identify the user and agent responsible for executing the script, checking for any anomalies or unauthorized access.\n- Investigate the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related PowerShell activities on the host.\n- Assess the count field to understand the extent of obfuscation patterns detected, which can indicate the complexity and potential maliciousness of the script.\n\n### False positive analysis\n\n- Scripts with legitimate use of environment variables for configuration management may trigger the rule. Users can create exceptions for specific scripts or processes known to use environment variables in a non-threatening manner.\n- Automated scripts that dynamically construct commands for legitimate administrative tasks might be flagged. Review the script's purpose and source, and whitelist trusted scripts or processes.\n- Development environments where scripts are frequently tested and modified may produce false positives. Implement monitoring exclusions for development machines or specific user accounts involved in script testing.\n- Scripts using environment variables for localization or language settings can be mistakenly identified. Identify and exclude scripts that are part of standard localization processes.\n- PowerShell scripts from trusted vendors or software packages that use environment variables for legitimate functionality should be reviewed and excluded from detection if verified as safe.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit lateral movement.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and associated file paths to understand the scope and intent of the script, focusing on any obfuscated commands or environment variable manipulations.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation patterns in PowerShell scripts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement additional monitoring for unusual PowerShell activity and environment variable manipulations to enhance detection of similar threats in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 47, + "rule_id": "b0c98cfb-0745-4513-b6f9-08dddb033490", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_2.json b/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_2.json deleted file mode 100644 index 6cea85b92c7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_2.json +++ /dev/null @@ -1,40 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions.", - "false_positives": [ - "Authorized heavy usage of the system that is business justified and monitored." - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential Abuse of Resources by High Token Count and Large Response Sizes", - "query": "from logs-aws_bedrock.invocation-*\n| keep user.id, gen_ai.usage.prompt_tokens, gen_ai.usage.completion_tokens\n| stats max_tokens = max(gen_ai.usage.prompt_tokens),\n total_requests = count(*),\n avg_response_size = avg(gen_ai.usage.completion_tokens)\n by user.id\n// tokens count depends on specific LLM, as is related to how embeddings are generated.\n| where max_tokens > 5000 and total_requests > 10 and avg_response_size > 500\n| eval risk_factor = (max_tokens / 1000) * total_requests * (avg_response_size / 500)\n| where risk_factor > 10\n| sort risk_factor desc\n", - "references": [ - "https://atlas.mitre.org/techniques/AML.T0051", - "https://owasp.org/www-project-top-10-for-large-language-model-applications/", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" - ], - "risk_score": 47, - "rule_id": "b1773d05-f349-45fb-9850-287b8f92f02d", - "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", - "severity": "medium", - "tags": [ - "Domain: LLM", - "Data Source: AWS Bedrock", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "Use Case: Potential Overload", - "Use Case: Resource Exhaustion", - "Mitre Atlas: LLM04" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "b1773d05-f349-45fb-9850-287b8f92f02d_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c18975f5-676c-4091-b626-81e8938aa2ee_3.json b/packages/security_detection_engine/kibana/security_rule/c18975f5-676c-4091-b626-81e8938aa2ee_3.json new file mode 100644 index 00000000000..9f7eedf1caf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c18975f5-676c-4091-b626-81e8938aa2ee_3.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies attempt to perform session hijack via COM object registry modification by setting the RunAs value to Interactive User.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.registry-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential RemoteMonologue Attack", + "note": "## Triage and analysis\n\n### Investigating Potential RemoteMonologue Attack\n\n\n### Possible investigation steps\n\n- Review the registry event logs to confirm the modification of the RunAs value in the specified registry paths, ensuring the change was not part of a legitimate administrative action.\n- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information.\n- Check for any recent remote authentication attempts or sessions on the affected host to determine if this activity is associated with lateral movement or not.\n- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections.\n\n### False positive analysis\n\n- Software updates or installations that modify COM settings.\n- Automated scripts or management tools that adjust COM configurations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Modify the registry value back to its secure state, ensuring that \"RunAs\" value is not set to \"Interactive User\".\n- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled.\n- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities.\n", + "query": "registry where host.os.type == \"windows\" and event.action != \"deletion\" and\n registry.value == \"RunAs\" and registry.data.strings : \"Interactive User\" and\n\n not \n (\n (\n process.executable : (\n \"C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\4.*\\\\MsMpEng.exe\",\n \"C:\\\\Program Files\\\\Windows Defender\\\\MsMpEng.exe\"\n ) and\n registry.path : \"*\\\\SOFTWARE\\\\Classes\\\\AppID\\\\{1111A26D-EF95-4A45-9F55-21E52ADF9887}\\\\RunAs\"\n ) or\n (\n process.executable : (\n \"C:\\\\Program Files\\\\TeamViewer\\\\TeamViewer.exe\",\n \"C:\\\\Program Files (x86)\\\\TeamViewer\\\\TeamViewer.exe\"\n ) and\n registry.path : \"*\\\\SOFTWARE\\\\Classes\\\\AppID\\\\{850A928D-5456-4865-BBE5-42635F1EBCA1}\\\\RunAs\"\n ) or\n (\n process.executable : \"C:\\\\Windows\\\\System32\\\\svchost.exe\" and\n registry.path : \"*\\\\S-1-*Classes\\\\AppID\\\\{D3E34B21-9D75-101A-8C3D-00AA001A1652}\\\\RunAs\"\n ) or\n (\n process.executable : \"C:\\\\Windows\\\\System32\\\\SecurityHealthService.exe\" and\n registry.path : (\n \"*\\\\SOFTWARE\\\\Classes\\\\AppID\\\\{1D278EEF-5C38-4F2A-8C7D-D5C13B662567}\\\\RunAs\",\n \"*\\\\SOFTWARE\\\\Classes\\\\AppID\\\\{7E55A26D-EF95-4A45-9F55-21E52ADF9878}\\\\RunAs\"\n )\n ) or\n (\n process.executable : \"C:\\\\Windows\\\\System32\\\\SecurityHealthService.exe\" and\n registry.path : (\n \"*\\\\SOFTWARE\\\\Classes\\\\AppID\\\\{1D278EEF-5C38-4F2A-8C7D-D5C13B662567}\\\\RunAs\",\n \"*\\\\SOFTWARE\\\\Classes\\\\AppID\\\\{7E55A26D-EF95-4A45-9F55-21E52ADF9878}\\\\RunAs\"\n )\n ) or\n registry.path : (\n \"HKLM\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\ClickToRun\\\\VREGISTRY_*\",\n \"\\\\REGISTRY\\\\MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\ClickToRun\\\\VREGISTRY_*\"\n ) or\n (process.executable : \"C:\\\\windows\\\\System32\\\\msiexec.exe\" and user.id : \"S-1-5-18\")\n )\n", + "references": [ + "https://www.ibm.com/think/x-force/remotemonologue-weaponizing-dcom-ntlm-authentication-coercions#1", + "https://github.com/xforcered/RemoteMonologue" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.9.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "c18975f5-676c-4091-b626-81e8938aa2ee", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Data Source: Sysmon", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + }, + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "c18975f5-676c-4091-b626-81e8938aa2ee_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_2.json b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_2.json deleted file mode 100644 index a130896a70c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_2.json +++ /dev/null @@ -1,94 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule leverages ES|QL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", - "from": "now-61m", - "interval": "1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Unusual Base64 Encoding/Decoding Activity", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Unusual Base64 Encoding/Decoding Activity\nBase64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.\n\n### Possible investigation steps\n\n- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.\n- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.\n- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.\n- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.\n- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.\n- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.\n- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.\n\n### False positive analysis\n\n- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.\n- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.\n- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.\n- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.\n- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.\n\n### Response and remediation\n\n- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.\n- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.\n- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.\n- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.\n- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.\n- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.\n", - "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n (process.name in (\"base64\", \"base64plain\", \"base64url\", \"base64mime\", \"base64pem\", \"base32\", \"base16\") and process.command_line like \"*-*d*\") or\n (process.name == \"openssl\" and process.args == \"enc\" and process.args in (\"-d\", \"-base64\", \"-a\")) or\n (process.name like \"python*\" and\n (process.args == \"base64\" and process.args in (\"-d\", \"-u\", \"-t\")) or\n (process.args == \"-c\" and process.command_line like \"*base64*\" and process.command_line like \"*b64decode*\")\n ) or\n (process.name like \"perl*\" and process.command_line like \"*decode_base64*\") or\n (process.name like \"ruby*\" and process.args == \"-e\" and process.command_line like \"*Base64.decode64*\")\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.name, process.command_line\n| where agent_count == 1 and cc < 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "risk_score": 21, - "rule_id": "c5637438-e32d-4bb3-bc13-bd7932b3289f", - "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - }, - { - "id": "T1204", - "name": "User Execution", - "reference": "https://attack.mitre.org/techniques/T1204/", - "subtechnique": [ - { - "id": "T1204.002", - "name": "Malicious File", - "reference": "https://attack.mitre.org/techniques/T1204/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "c5637438-e32d-4bb3-bc13-bd7932b3289f_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_304.json b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_304.json deleted file mode 100644 index 32bb617d8dd..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_304.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Multiple Device Token Hashes for Single Okta Session", - "note": "## Triage and analysis\n\n### Investigating Multiple Device Token Hashes for Single Okta Session\n\nThis rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.\n\n#### Possible investigation steps:\n- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - Authentication events have been filtered out to focus on Okta activity via established sessions.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.\n - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.\n\n### Response and remediation:\n- Consider stopping all sessions for the user(s) involved in this action.\n- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", - "query": "FROM logs-okta*\n| WHERE\n event.dataset == \"okta.system\"\n // ignore authentication events where session and device token hash change often\n AND NOT event.action IN (\n \"policy.evaluate_sign_on\",\n \"user.session.start\",\n \"user.authentication.sso\"\n )\n // ignore Okta system events and only allow registered users\n AND (\n okta.actor.alternate_id != \"system@okta.com\"\n AND okta.actor.alternate_id RLIKE \"[^@\\\\s]+\\\\@[^@\\\\s]+\"\n )\n AND okta.authentication_context.external_session_id != \"unknown\"\n| KEEP event.action, okta.actor.alternate_id, okta.authentication_context.external_session_id, okta.debug_context.debug_data.dt_hash\n| STATS\n dt_hash_counts = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id\n| WHERE\n dt_hash_counts >= 2\n| SORT\n dt_hash_counts DESC\n", - "references": [ - "https://developer.okta.com/docs/reference/api/system-log/", - "https://developer.okta.com/docs/reference/api/event-types/", - "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", - "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", - "https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US", - "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", - "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" - ], - "risk_score": 47, - "rule_id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd", - "setup": "## Setup\n\nThe Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Use Case: Identity and Access Audit", - "Data Source: Okta", - "Tactic: Credential Access", - "Domain: SaaS" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1539", - "name": "Steal Web Session Cookie", - "reference": "https://attack.mitre.org/techniques/T1539/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 304 - }, - "id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd_304", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_1.json deleted file mode 100644 index 3fd8ec482a6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_1.json +++ /dev/null @@ -1,63 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential brute-force (password spraying) attempts against Azure Entra ID user accounts by detecting a high number of failed non-interactive single-factor authentication (SFA) login attempts within a 10-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Azure Entra ID services. Non-interactive SFA login attempts bypass conditional-access policies (CAP) and multi-factor authentication (MFA) requirements, making them a high-risk vector for unauthorized access. Adversaries may attempt this to identify which accounts are still valid from acquired credentials via phishing, infostealers, or other means.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." - ], - "from": "now-30m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "Azure Entra ID Password Spraying (Non-Interactive SFA)", - "note": "## Triage and analysis\n\n### Investigating Azure Entra ID Password Spraying (Non-Interactive SFA)\n\nThis rule identifies repeated failed authentication attempts using non-interactive authentication, which is often leveraged for automated attacks or legacy authentication methods. Successful compromise of an account could lead to unauthorized access, privilege escalation, or lateral movement within the environment.\n\n**This is an ES|QL rule with aggregations that truncate results in the alert document. It is recommended to pivot investigation into the raw documents for further triage and analysis.**\n\n### Possible investigation steps\n\n- Identify the source IP address from which the failed login attempts originated by reviewing `source.ip`. Determine if the IP is associated with known malicious activity using threat intelligence sources or if it belongs to a corporate VPN, proxy, or automation process.\n- Analyze affected user accounts by reviewing `azure.signinlogs.properties.user_principal_name` to determine if they belong to privileged roles or high-value users. Look for patterns indicating multiple failed attempts across different users, which could suggest a password spraying attempt.\n- Examine the authentication method used in `azure.signinlogs.properties.authentication_details` to identify which authentication protocols were attempted and why they failed. Legacy authentication methods may be more susceptible to brute-force attacks.\n- Review the authentication error codes found in `azure.signinlogs.properties.status.error_code` to understand why the login attempts failed. Common errors include `50126` for invalid credentials, `50053` for account lockouts, `50055` for expired passwords, and `50056` for users without a password.\n- Correlate failed logins with other sign-in activity by looking at `event.outcome`. Identify if there were any successful logins from the same user shortly after multiple failures or if there are different geolocations or device fingerprints associated with the same account.\n- Review `azure.signinlogs.properties.app_id` to identify which applications were initiating the authentication attempts. Determine if these applications are Microsoft-owned, third-party, or custom applications and if they are authorized to access the resources.\n- Check for any conditional access policies that may have been triggered by the failed login attempts by reviewing `azure.signinlogs.properties.authentication_requirement`. This can help identify if the failed attempts were due to policy enforcement or misconfiguration.\n\n## False positive analysis\n\n### Common benign scenarios\n- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`.\n- Corporate proxies or VPNs may cause multiple users to authenticate from the same IP, appearing as repeated failed attempts under `source.ip`.\n- User account lockouts from forgotten passwords or misconfigured applications may show multiple authentication failures in `azure.signinlogs.properties.status.error_code`.\n\n### How to reduce false positives\n- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`.\n- Exlcude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication.\n- Ignore principals with a history of failed logins due to legitimate reasons, such as expired passwords or account lockouts, by filtering `azure.signinlogs.properties.user_principal_name`.\n- Correlate sign-in failures with password reset events or normal user behavior before triggering an alert.\n\n## Response and remediation\n\n### Immediate actions\n- Block the source IP address in `source.ip` if determined to be malicious.\n- Reset passwords for all affected user accounts listed in `azure.signinlogs.properties.user_principal_name` and enforce stronger password policies.\n- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`.\n- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks.\n- Review conditional access policies to ensure they are correctly configured to block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`.\n- Review Conditional Access policies to enforce risk-based authentication and block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`.\n\n### Long-term mitigation\n- Implement a zero-trust security model by enforcing least privilege access and continuous authentication.\n- Regularly review and update conditional access policies to ensure they are effective against evolving threats.\n- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`.\n- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks.\n- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft.\n", - "query": "from logs-azure.signinlogs*\n| keep\n @timestamp,\n event.dataset,\n event.category,\n azure.signinlogs.properties.is_interactive,\n azure.signinlogs.properties.authentication_requirement,\n azure.signinlogs.properties.resource_display_name,\n azure.signinlogs.properties.status.error_code,\n azure.signinlogs.properties.resource_service_principal_id,\n azure.signinlogs.category,\n event.outcome,\n azure.signinlogs.properties.user_principal_name,\n source.ip\n// truncate the timestamp to a 10-minute window\n| eval target_time_window = DATE_TRUNC(10 minutes, @timestamp)\n| WHERE\n event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.properties.is_interactive == false\n and azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n and event.outcome != \"success\"\n and azure.signinlogs.properties.status.error_code in (50053, 50126, 50055, 50056, 50064, 50144)\n // for tuning review azure.signinlogs.properties.status.error_code\n // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes\n\n// count the number of unique user login attempts\n| stats\n unique_user_login_count = count_distinct(azure.signinlogs.properties.resource_service_principal_id) by\n target_time_window,\n azure.signinlogs.properties.user_principal_name,\n azure.signinlogs.properties.status.error_code\n\n// filter for >= 20 failed SFA auth attempts with the same error codes\n| where unique_user_login_count >= 20\n", - "references": [ - "https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf" - ], - "risk_score": 47, - "rule_id": "cca64114-fb8b-11ef-86e2-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Azure", - "Data Source: Entra ID", - "Data Source: Entra ID Sign-in", - "Use Case: Identity and Access Audit", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/", - "subtechnique": [ - { - "id": "T1110.003", - "name": "Password Spraying", - "reference": "https://attack.mitre.org/techniques/T1110/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "cca64114-fb8b-11ef-86e2-f661ea17fbce_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cd89602e-9db0-48e3-9391-ae3bf241acd8_416.json b/packages/security_detection_engine/kibana/security_rule/cd89602e-9db0-48e3-9391-ae3bf241acd8_416.json new file mode 100644 index 00000000000..0168e33e0d4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cd89602e-9db0-48e3-9391-ae3bf241acd8_416.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the account.", + "false_positives": [ + "If the behavior of deactivating MFA for Okta user accounts is expected, consider adding exceptions to this rule to filter false positives." + ], + "from": "now-12h", + "index": [ + "filebeat-*", + "logs-okta.system*" + ], + "interval": "6h", + "language": "eql", + "license": "Elastic License v2", + "name": "MFA Deactivation with no Re-Activation for Okta User Account", + "note": "## Triage and analysis\n\n### Investigating MFA Deactivation with no Re-Activation for Okta User Account\n\nMFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence.\n\nThis rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours.\n\n#### Possible investigation steps:\n\n- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity.\n- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target.\n- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user. \n- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity.\n - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user.\n- Examine related administrative activity by the actor for privilege misuse or suspicious changes.\n\n#### False positive steps:\n\n- Determine with the target user if MFA deactivation was expected.\n- Determine if MFA is required for the target user account.\n\n#### Response and remediation:\n\n- If the MFA deactivation was not expected, consider deactivating the user\n - This should be followed by resetting the user's password and re-enabling MFA.\n- If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives.\n- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.\n- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.\n- Check if the compromised account was used to access or alter any sensitive data, applications or systems.\n- Review the client user-agent to determine if it's a known custom application that can be whitelisted.\n", + "query": "sequence by okta.target.id with maxspan=12h\n [any where event.dataset == \"okta.system\" and okta.event_type in (\"user.mfa.factor.deactivate\", \"user.mfa.factor.reset_all\")\n and okta.outcome.reason != \"User reset SECURITY_QUESTION factor\" and okta.outcome.result == \"SUCCESS\"]\n ![any where event.dataset == \"okta.system\" and okta.event_type == \"user.mfa.factor.activate\"]\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.5.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.event_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.outcome.reason", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.outcome.result", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.target.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "cd89602e-9db0-48e3-9391-ae3bf241acd8", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "low", + "tags": [ + "Tactic: Persistence", + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Domain: Cloud", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/", + "subtechnique": [ + { + "id": "T1556.006", + "name": "Multi-Factor Authentication", + "reference": "https://attack.mitre.org/techniques/T1556/006/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 416 + }, + "id": "cd89602e-9db0-48e3-9391-ae3bf241acd8_416", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_3.json b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_3.json deleted file mode 100644 index c6f39a132c7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_3.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target role." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to Role", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Role\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachRolePolicy` permission, a set of compromised credentials could be used to attach\nthis policy to a compromised role for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachRolePolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachRolePolicy` permission and that the `role.name` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected role(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachRolePolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?roleName}=%{role.name}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, role.name\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_3.json b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_3.json deleted file mode 100644 index eccf69f6f7f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_3.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user group." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to Group", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Group\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected group(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachGroupPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?groupName}=%{group.name}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, group.name\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_2.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_2.json deleted file mode 100644 index 8a2dcf57912..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_2.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential PowerShell Obfuscation via String Reordering", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n| WHERE powershell.file.script_block_text LIKE \"*{0}*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count > 3\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "risk_score": 21, - "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_6.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_6.json new file mode 100644 index 00000000000..e7b3ed0c911 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_6.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Reordering", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via String Reordering\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.\n\n### Possible investigation steps\n\n- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.\n- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.\n- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.\n- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.\n\n### False positive analysis\n\n- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name \"framework_cache.psm1\" is excluded from the detection rule.\n- PowerShell scripts that include specific sentinel patterns, such as \"sentinelbreakpoints\" or paths like \":::::\\windows\\sentinel\", combined with variables like \"$local:Bypassed\" or \"origPSExecutionPolicyPreference\", are known to be benign. These should be excluded to reduce noise.\n- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.\n- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.\n- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*{0}*\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least four times\n| where Esql.script_block_pattern_count >= 4\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| where not file.directory == \"C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\icinga-powershell-framework\\\\cache\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory IS NULL\n\n| where not (powershell.file.script_block_text LIKE \"*GitBranchStatus*\" AND \n powershell.file.script_block_text LIKE \"*$s.BranchBehindStatusSymbol.Text*\")\n| where not\n // https://wtfbins.wtf/17\n (\n (powershell.file.script_block_text like \"*sentinelbreakpoints*\" or\n powershell.file.script_block_text like \"*:::::\\\\\\\\windows\\\\\\\\sentinel*\")\n and\n (powershell.file.script_block_text like \"*$local:Bypassed*\" or\n powershell.file.script_block_text like \"*origPSExecutionPolicyPreference*\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f036953a-4615-4707-a1ca-dc53bf69dcd5_212.json b/packages/security_detection_engine/kibana/security_rule/f036953a-4615-4707-a1ca-dc53bf69dcd5_212.json new file mode 100644 index 00000000000..b1fec75e4dc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f036953a-4615-4707-a1ca-dc53bf69dcd5_212.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies child processes of unusual instances of RunDLL32 where the command line parameters were suspicious. Misuse of RunDLL32 could indicate malicious activity.", + "from": "now-60m", + "index": [ + "logs-endpoint.events.process-*", + "winlogbeat-*", + "logs-windows.sysmon_operational-*" + ], + "interval": "30m", + "language": "eql", + "license": "Elastic License v2", + "name": "Unusual Child Processes of RunDLL32", + "note": "## Triage and analysis\n\n### Investigating Unusual Child Processes of RunDLL32\n\nBy examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation.\n\nRunDLL32 is a legitimate Windows utility used to load and execute functions within dynamic-link libraries (DLLs). However, adversaries may abuse RunDLL32 to execute malicious code, bypassing security measures and evading detection. This rule identifies potential abuse by looking for an unusual process creation with no arguments followed by the creation of a child process.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.\n- Investigate the behavior of child processes, such as network connections, registry or file modifications, and any spawned processes.\n- Inspect the host for suspicious or abnormal behavior in the alert timeframe.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Related Rules\n\n- Unusual Network Connection via RunDLL32 - 52aaab7b-b51c-441a-89ce-4387b3aea886\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "sequence with maxspan=1h\n [process where host.os.type == \"windows\" and event.type == \"start\" and\n (process.name : \"rundll32.exe\" or process.pe.original_file_name == \"RUNDLL32.EXE\") and\n (process.args_count == 1 and\n /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */\n not process.command_line regex~ \"\"\"\\\".*\\.exe[^\\\"].*\"\"\")\n ] by process.entity_id\n [process where host.os.type == \"windows\" and event.type == \"start\" and process.parent.name : \"rundll32.exe\"\n ] by process.parent.entity_id\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^9.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pe.original_file_name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "f036953a-4615-4707-a1ca-dc53bf69dcd5", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1218", + "name": "System Binary Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1218/", + "subtechnique": [ + { + "id": "T1218.011", + "name": "Rundll32", + "reference": "https://attack.mitre.org/techniques/T1218/011/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 212 + }, + "id": "f036953a-4615-4707-a1ca-dc53bf69dcd5_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_4.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_4.json new file mode 100644 index 00000000000..faca3f70e87 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_4.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Reverse Keywords", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Reverse Keywords\n\nPowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic.\n- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious.\n- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution.\n- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine.\n- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.\n- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.\n- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.\n- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.\n- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.\n- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.\n- Restore affected systems from a known good backup if malicious activity has altered system integrity.\n- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contains these keywords using MATCH, boosts the query performance,\n// match will ignore the | and look for the individual words\n| where powershell.file.script_block_text : \"rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n agent.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f38633f4-3b31-4c80-b13d-e77c70ce8254", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_2.json b/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_2.json deleted file mode 100644 index c8d266fcdfa..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_2.json +++ /dev/null @@ -1,41 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.", - "false_positives": [ - "Legitimate misunderstanding by users or overly strict policies" - ], - "from": "now-60m", - "interval": "10m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request", - "query": "from logs-aws_bedrock.invocation-*\n| where gen_ai.policy.action == \"BLOCKED\"\n| eval policy_violations = mv_count(gen_ai.policy.name)\n| where policy_violations > 1\n| keep gen_ai.policy.action, policy_violations, user.id, gen_ai.request.model.id, cloud.account.id, user.id\n| stats total_unique_request_violations = count(*) by policy_violations, user.id, gen_ai.request.model.id, cloud.account.id\n| sort total_unique_request_violations desc\n", - "references": [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" - ], - "risk_score": 21, - "rule_id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c", - "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", - "severity": "low", - "tags": [ - "Domain: LLM", - "Data Source: AWS Bedrock", - "Data Source: AWS S3", - "Resources: Investigation Guide", - "Use Case: Policy Violation", - "Mitre Atlas: T0051", - "Mitre Atlas: T0054" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_1.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_1.json deleted file mode 100644 index 206e19b58be..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential PowerShell Obfuscation via String Concatenation", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 2\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "risk_score": 21, - "rule_id": "f6d8c743-0916-4483-8333-3c6f107e0caa", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "f6d8c743-0916-4483-8333-3c6f107e0caa_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_1.json b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_3.json similarity index 55% rename from packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_1.json rename to packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_3.json index 74b342ad707..2f51a396a10 100644 --- a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_1.json +++ b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_3.json @@ -3,12 +3,13 @@ "author": [ "Elastic" ], - "description": "Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "building_block_type": "default", + "description": "Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation.", "from": "now-9m", "language": "esql", "license": "Elastic License v2", - "name": "Potential PowerShell Obfuscation via Invalid Escape Sequences", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\" and powershell.file.script_block_text LIKE \"*`*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.name, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 10\n\n// Filter FPs, and due to the behavior of the LIKE operator, allow null values\n| WHERE (file.name NOT LIKE \"TSS_*.psm1\" or file.name IS NULL)\n", + "name": "Potential PowerShell Obfuscation via High Special Character Proportion", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n// Excludes spaces, #, = and - as they are heavily used in scripts for formatting\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[^0-9A-Za-z\\s#=-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high special character ratio\n| where Esql.script_block_ratio > 0.30\n", "related_integrations": [ { "package": "windows", @@ -16,7 +17,7 @@ } ], "risk_score": 21, - "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", + "rule_id": "f9753455-8d55-4ad8-b70a-e07b6f18deea", "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", "severity": "low", "tags": [ @@ -24,7 +25,8 @@ "OS: Windows", "Use Case: Threat Detection", "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" + "Data Source: PowerShell Logs", + "Rule Type: BBR" ], "threat": [ { @@ -72,8 +74,8 @@ ], "timestamp_override": "event.ingested", "type": "esql", - "version": 1 + "version": 3 }, - "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_1", + "id": "f9753455-8d55-4ad8-b70a-e07b6f18deea_3", "type": "security-rule" } \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_1.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_1.json deleted file mode 100644 index 4b5afab7388..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential PowerShell Obfuscation via High Numeric Character Proportion", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of numbers and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 25%+ proportion of numbers\n| WHERE proportion > 0.25\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "risk_score": 21, - "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_5.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_5.json new file mode 100644 index 00000000000..56f8083803d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_5.json @@ -0,0 +1,81 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Numeric Character Proportion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via High Numeric Character Proportion\n\nPowerShell is a powerful scripting language used for system administration, but adversaries exploit its capabilities to obfuscate malicious scripts. Obfuscation often involves encoding payloads using numeric characters, making detection challenging. The detection rule identifies scripts with a high proportion of numeric characters, signaling potential obfuscation. By analyzing script length and numeric density, it flags suspicious activity, aiding in defense evasion detection.\n\n### Possible investigation steps\n\n- Review the script block text from the alert to understand the context and identify any obvious signs of obfuscation or malicious intent.\n- Examine the file path and host name fields to determine the origin and location of the script execution, which can help assess the potential impact and scope.\n- Check the user ID and agent ID fields to identify the user and system involved, which may provide insights into whether the activity is expected or suspicious.\n- Analyze the powershell.sequence and powershell.total fields to understand the sequence of script execution and the total number of scripts executed, which can indicate whether this is part of a larger pattern of behavior.\n- Investigate any related logs or alerts from the same host or user to identify patterns or correlations that might suggest broader malicious activity.\n\n### False positive analysis\n\n- Scripts with legitimate numeric-heavy content such as data processing or mathematical calculations may trigger the rule. To handle this, identify and whitelist specific scripts or script patterns that are known to be safe.\n- Automated scripts that generate or manipulate large datasets often contain high numeric content. Consider creating exceptions for scripts executed by trusted users or from known safe directories.\n- PowerShell scripts used for legitimate software installations or updates might include encoded data blocks. Review and exclude these scripts by verifying their source and purpose.\n- Scripts containing large hexadecimal strings for legitimate purposes, such as cryptographic operations, may be flagged. Use the exclusion pattern to filter out these known safe operations.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate scripts that may be introduced.\n\n### Response and remediation\n\n- Immediately isolate the affected host to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Review the PowerShell script block text and script block ID to identify any malicious payloads or encoded strings. If confirmed malicious, remove or quarantine the script.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to detect and remove any additional threats or remnants of the obfuscated script.\n- Analyze the file path and user ID associated with the script execution to determine if unauthorized access or privilege escalation occurred. Revoke any suspicious user access and reset credentials if necessary.\n- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other alerts to assess the scope and impact of the threat across the network.\n- Implement enhanced monitoring and logging for PowerShell activities on all endpoints to detect similar obfuscation attempts in the future, focusing on scripts with high numeric character proportions.\n- Review and update endpoint protection policies to restrict the execution of scripts with high numeric density, ensuring compliance with security best practices and reducing the risk of obfuscation-based attacks.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_ratio,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high numeric character ratio\n| where Esql.script_block_ratio > 0.30\n\n// Exclude Windows Defender Noisy Patterns\n| where not (\n file.directory == \"C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\" or\n file.directory like \"C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n| where not powershell.file.script_block_text like \"*[System.IO.File]::Open('C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n| where not powershell.file.script_block_text : \"26a24ae4-039d-4ca4-87b4-2f64180311f0\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "risk_score": 21, + "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 6aeed6c584a..fd67ebeed63 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.11 +version: 9.0.12-beta.1 From f52b7dc9790bbf8ea6a180fa010802436b2c2f5e Mon Sep 17 00:00:00 2001 From: TRADE Bot <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 19 Aug 2025 02:21:39 -0400 Subject: [PATCH 13/13] [Security Rules] Update security rules package to v9.0.12 (#14970) --- packages/security_detection_engine/changelog.yml | 5 +++++ packages/security_detection_engine/manifest.yml | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index d219d90fa95..f61aca3bd7b 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 9.0.12 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/14970 - version: 9.0.12-beta.1 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index fd67ebeed63..f85a6f744ed 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 9.0.12-beta.1 +version: 9.0.12